LDAP Plugins in FOG 1.3.0 RC 8

[george1421]

@Steuve68 Again I’m just speaking in general terms here since I haven’t worked with the FOG LDAP, but I would say there are some missing fields that would typically be required.

Based on what is there, I would say the DN is the base or search DN That would be the container where the ldap plugin would search for users. That field should be in ldap format.

The ldap server address should just be an ip address of the ldap server.

Now what I see missing is the bind dn and password (the user account that is used to query ldap). Some ldap systems allow for unauthenticated queries, and others like AD require an authorized user to be able to query AD (this keeps the bad guys from enumerating your internal AD structure). So I would suspect even if you had the visible fields filled out properly that this query would fail because of an authorization issue.

The last bit of information I see missing is that sometimes there will be a field for a goup name. That way the ldap query would see if the user that is logging in would be a memberof group “abc” would be allowed to login. Right now the way its setup if anyone in the search base dn logs in it will be allowed.

That reminds me of one more for your search base. Typically there is a field for how deep to search from the search base. To only search in the search base or to include all OUs below the search base too.

But again this is only speculation, probably Tom will need to comment on the actual function of the ldap plugin. If it would work, I would surely move to that method, that way we have only valid

I release this is WAY more information than you are asking for. I’m documenting it here since I feel the ldap plugin may require some needed bits.

[Tom Elliott]

@george1421 To be honest I’m not the guy you want for commenting. I made it work through a ton of testing with @x23piracy and an open LDAP layout. I don’t think we ever got it to work with Active Directory and there, currently, isn’t any extra information to pass along. This plugin was created by @Fernando-Gietz and was mainly used for open LDAP I think. Maybe one of them can chime in? Of course anybody with more experience integratingnsuch a system would be greatly appreciated. An AD and LDAP authentication system I think would be great for fog.

[Steuve68]

@george1421 OK … it is also what I think … is missing fields … user an pass to query LDAP … ! Thanks for your different answers and explanation.

@Tom-Elliott Yes, i think LDAP and/or AD authentication and delegation rights by users would be great for FOG.
If the LDAP Plugins developpers can explain how does it work it would be top !

Thanks for speed answers

Sorry for my bad english … i’m french.

[george1421]

@Steuve68 said in LDAP Plugins in FOG 1.3.0 RC 8:

Sorry for my bad english … i’m french.

Oh I didn’t know you were French, you loose 50 points for that. (just kidding your engish is great)

Yes lets see if the other developers can chime in. I can take a look at the code but I don’t have a clue on the programming part. I know what has to be in the query based on how other FLOSS applications work.

[davido38]

maybe it can help

I have Glpi on the same server of fog with ldap auth on a 2008 srv and it works fine.

[george1421]

@davido38 Thank you this confirms my concept that its possible to make the ldap code work generally with AD. I’ve been looking at the ldap plugin code over my lunch hour, and I see what they are doing. There are several assumptions (i.e. your LDAP should be setup in a certain way) in the code to fill in the missing fields, which may not work in all situations.

But, in concept the code should be able to be updated to support AD.

[Tom Elliott]

@george1421 totally agree

[george1421]

I’ve started a feature request here to document the process of reviewing the current LDAP plugin.
https://forums.fogproject.org/topic/8575/extend-ldap-plugin-to-support-ad-authentication

After reviewing the current ldap plugin there are only about 30 lines of code that is used for authentication. I believe that if I can add a few database fields to remove some of the assumptions that the code CAN be converted to support AD authentication.

[x23piracy]

@Tom-Elliott if this will work with AD it would be cool if a normal user can login into fog (webif or and pxe) to have to possibility to reset his computer (reimage).

Regards X23

[george1421]

@x23piracy Are you currently using ldap authentication today? I think I found a good example code that I can upgrade the bits in the plugin. I just want to make sure the upgraded bits don’t break what you are using.

[x23piracy]

@george1421 i discard using it because it didn’t work as intended with Active Directory, Tom and me tried a lot but in the end it was not fully working like i wanted to.

the Main Problem is that we couldn’t get it to work with two LDAP definitions pointing to a deeper laying OU unit in the AD
What i wanted was to have one conneciton for normal users that can logon to fog and another one that allows all admins access with higher rights.

Not easy to explain what exactly went wrong but it seems that the current plugin cannot work with a specific OU.

Regards X23

[george1421]

@x23piracy Great info, thank you.

The approach I’m looking at is to have user authentication and then if user is in AD group ( X ) then they are an admin, if they are in group ( Y ) then user, if they are not in either AD group then no access. Initially I was only thinking about a single group, but if there is admin and user levels in FOG then the dual group is the answer.

Your explanation also tells me why there was an admin field in the database. I hope to have time over the weekend to do a little coding to see if I can do a proof of concept test.

[Wayne Workman]

@george1421 said in LDAP Plugins in FOG 1.3.0 RC 8:

Your explanation also tells me why there was an admin field in the database

It was setup to restrict someone to just fog mobile if they weren’t an admin. It’s a checkbox in user management, for a user. When checked, they can only access fog mobile I think. Or vice versa… or something.