Extend LDAP plugin to support AD authentication

[Tom Elliott]

@george1421 I’m downloading a Windows Server 2012 ISO right now.

I’ll create a domain and this will extend my testing a bit.

1. I can test the LDAP plugin in a semi real world environment.
2. I can test client domain joins internally. (Joe created a server for us to use, but i’m always hesitant towards it as it is going straight across the internet).
3. I can test LDAP Groups in an AD frameset.
4. I can test mutations and hopefully figure out a solution to this ever going problem. (Or validate with certainty that this will not work).

[george1421]

@Tom-Elliott I do have questions if it is failing on mine because I don’t have some international character set loaded. While I’m not saying that is the case, it is a possibility.

At home I have a 2012 reference image that is built by mdt. That way I can spin up a new 2012 server quickly and have 3 days before it needs to be activated. Its not an ideal situation, but if you are playing and mess the up the server you can rebuild it quickly. (been there, done that).

[x23piracy]

@george1421 @Tom-Elliott if you like tom i will give you tv access to my environment and you can do your experiments if you like?

Regards X23

[Wayne Workman]

I have a windows domain at home…

[Tom Elliott]

I have a windows domain at home now.

And I’m very close to figuring this out, I hope.

[Wayne Workman]

I’m trying to setup the LDAP stuff at work right now… some guidance would be appreciated… I’m going to poke around still though.

[Tom Elliott]

With any luck, this will now work woot woot.

[Tom Elliott]

I’ve pushed into the working-RC-37 branch which, from my limited testing, appears this is now working properly.

[Wayne Workman]

Working with RC-36,

I’ve not got it working yet. I’m not sure I fully understand the purpose of these fields or if they are all required or not.

What I would like is instructions on how to authenticate a user, and require that user to be in a group called “fog_admins”. The group is in one spot in AD, the users are in another spot.

I’m assuming I path to the group in the group search dn field, and path to the users in the search base dn? Don’t know.

Admin group is obvious enough.
I am not worried about the mobile group.

bind DN is the exact username and pass used to authenticate a user’s credentials, this is clear.

[Tom Elliott]

@Wayne-Workman
Here’s how mine is setup:

Connection Name: What do you want to call it – not used for anything in regards to functionality.
Description: Self explanatory – not used for anything in regards to functionality.
Server Address: ###Needed### The address of your server.
Server Port: ###Needed### The port of your server (usually 389).
Search Base DN: ###Needed### The DN you need to search starting at… For me I’m searching under users common name.
Group Search DN: ###Needed### The dn you need to start searching for Groups… For me I’m searching under the OU named Groups.
Admin Group: ###Not required if mobile group is set### This is the group that will be looked at for ldap to be scanning for “FOG Admins”
Mobile Group: ###Not required if admin is set### This is the group that will be looked at to allow “mobile” users. These users cannot login to the main dashboard but they can login to the mobile page.
Initial Template: Does not do anything to the DB store. Just a “template” holder.
User Nam Attribute, what field to search for user names.
Group member attribute, what field to search for groups.
Bind DN, Not required as user based element should be able to find.
Bind Password the bind dn password.

[Wayne Workman]

George helped me figure out what I was doing wrong. But what you posted Tom is very valuable.