Extend LDAP plugin to support AD authentication
-
@george1421 I’ve been working on other projects and haven’t had time to get back to this one. I have this plugin working in my production environment and it is working well. I’m to the point where I would like to test it in a few more AD environment as well as OpenLDAP. If you are willing to help test, please let me know and I’ll send the instructions. I have not yet submitted the code to the Developers for their review to be included in the official 1.3.0RC stream as of now. I wanted to ensure it functioned as we expected it before adding additional workload one the developers.
Here is a current screen clip of the fields and the expected values. We’ve added the ability to only do a name match with users at the search base dn. With this option the user must only appear in a defined OU or below. If a user is in that OU and the uid and password match then the user is considered a FOG admin. I don’t like using this option but there were several use cases (like all my fog admins are already in a defined OU) where I can understand the requirement (but still not like it ). The more secure way is to use group matching. In this case you will need to create an AD/LDAP group and put the admin/mobile users in these groups. This now changes the login requirements to 1) You must be a users in the specified OU, 2) Your uid and password must authenticate 3) Your uid must be in the authorized group for FOG.
-
Hi George,
I can see that you added the option to use AD groups to define admin/mobile profiles or not. Can I test it anyway? I have update the server version to RC13, and in this version until is not operative these changes.
-
I’ve updated the working RC 15 branch to contain the changes as @george1421 made and tested some more things. Appears to still work with open LDAP though I need more confirmation to know if it is working for ad.
-
@Tom-Elliott Hi, i would like to test it but what’s the url to checkout working branch with git?
What if RC15 is released can i just change to trunk /bin/installfog.sh again?Regards X23
-
I helped @x23piracy - also - We don’t want folks knowing how, it will cause more issues than help.
-
@Wayne-Workman i sell that information for 10 bucks :D… joking
-
1.3.0RC15 has been released with the updated ldap plugin support. You must upgrade to RC15, uninstall and then reinstall the LDAP plugin to ensure the ldap configuration database is created correctly. Please understand when the ldap plugin is uninstalled it also erases any settings for the plugin. If you need these settings archive the settings before removing the plugin.
We still have an issue with non-base ascii characters in the ldap search dn, or user path. If you have these international characters the ldap plugin will fail to authenticate. We are working on this issue, but we appear unsuccessful at this time. For a US English characters the ldap plugin does work as far as we tested with AD and OpenLDAP
-
Can this be tested again to make sure it’s still working properly George?
-
@Wayne-Workman said in Extend LDAP plugin to support AD authentication:
Can this be tested again to make sure it’s still working properly George?
additionally it would be interesting if there was progress with the vowel mutation (äöü) usage?
Regards X23
-
The ldap plugin works as it did before, I don’t know what you need to test.
There is one caveat and that, currently, if the account isn’t already present the first time you login the return will be “invalid login”.
The next login, however, will work fine.
I’ve corrected this particular problem for the next.
The mutations are still an issue as I don’t know how to get them to escape. Everything I’ve read online says that mutations are not allowed to be a part of the dn strings. If I remember correctly, this is where the mutation is currently stored in your case @x23piracy.
-
@Tom-Elliott said in Extend LDAP plugin to support AD authentication:
The mutations are still an issue as I don’t know how to get them to escape. Everything I’ve read online says that >mutations are not allowed to be a part of the dn strings. If I remember correctly, this is where the mutation is currently >stored in your case @x23piracy.
Sorry, but i cannot change way from the vowel’s and i need to say, i would never use them it was a real expert working in the company before that thougth hey i am a german and best practice is to not use vowels but he gave a shit on it and used them (i really would like to kick his ass).
Regards X23
-
@x23piracy Dude you are hilarious, in a good way.
-
@Wayne-Workman hehe sorry for the bad words but i really have to deal with some stupid people calling themselves it experts
-
@x23piracy To figure this out more properly, I think I need a means to replicate the issue very specifically.
Anybody know of any good guides to create my own internal AD Server?
-
@Tom-Elliott i would simply install a windows server with ad roll enabled, afaik simply building an ad should be no rocket science, i don’t know a simplier way, it would be cool if there is a binary out there who could simulate an ad.
-
@Tom-Elliott said in Extend LDAP plugin to support AD authentication:
@x23piracy To figure this out more properly, I think I need a means to replicate the issue very specifically.
Anybody know of any good guides to create my own internal AD Server?
To find the error its even easier than that. I have a standalone php script that will throw the error, all you need is an ad/ldap server to connect to.
-
<?php $user = 'meUser'; $pass = 'mePassword.1'; $server = '192.168.1.20'; $bindDN = 'cn=BindUserisMe,ou=Domain Users,dc=domain,dc=com'; $bindPass = 'BindPassword.1'; $searchScope = 2; // clean up user name we only want the user's short name without any domain component // note I did not try to understand the regex expression but I expect there to be // issues with non-us english characters, just saying. $user = trim(preg_replace('/[^a-zA-Z0-9\-\_@\.]/', '', $user)); // open connection to the server $ldapconn = ldap_connect($server,389); ldap_set_option($ldapconn, LDAP_OPT_PROTOCOL_VERSION, 3); ldap_set_option($ldapconn, LDAP_OPT_REFERRALS, 0); $userDN = ''; $accessLevel = 0; ## this line will throw the error. $userSearchDN = 'ou=äDomain Users,DC=domain,dc=com'; $adminGroup = 'FoG_Admins'; $userGroup = 'FOG_Users'; $grpMemberAttr = strtolower('memberOf'); if ( ldap_bind($ldapconn, $bindDN, $bindPass) ) { $filter = sprintf('(&(objectCategory=inetOrgPerson)(%s=%s))', 'sAMAccountName', $user); // we want to return the user's DN so that we can bind as the user // we will get his DN based on his samaccountname for AD $attr = array( 'dn' ); switch ($searchScope) { case 1: // LDAP_SCOPE_ONELEVEL search one level down but not base $result = ldap_list($ldapconn, $userSearchDN, $filter, $attr); break; case 2: // LDAP_SCOPE_SUBTREE search base + all subtree (OUs) below $result = ldap_search($ldapconn, $userSearchDN, $filter, $attr); break; default: // LDAP_SCOPE_BASE search base only and don't look any deeper $result = ldap_read($ldapconn, $userSearchDN, $filter, $attr); } // count the number of entries returned $retcount = ldap_count_entries($ldapconn, $result); if ($retcount == 1) { // great we only returned one entry $entries = ldap_get_entries($ldapconn, $result); // pull out the user dn from the entries $userDN = $entries[0]['dn']; } else { $userDN = ''; } } if (!$userDN =='') { // Now rebind as the user we just found if ( ldap_bind($ldapconn, $userDN, $pass) ) { // If we get to here the user is authorized, now lets get the group membership // This time since we know the user DN we can look up the user based on that $filter = '(objectclass=*)'; // get what groups this user is a member of $attr = array( $grpMemberAttr ); $result = ldap_read($ldapconn, $userDN, $filter, $attr); // count the number of entries returned $retcount = ldap_count_entries($ldapconn, $result); if ($retcount > 0) { $entries = ldap_get_entries($ldapconn, $result); // check groups for membership foreach($entries[0][$grpMemberAttr] as $grps) { // is admin user, set level and break loop if(strpos( $grps, $adminGroup )) { $accessLevel = 2; break; } // is user, set level and keep looking just incase user is in both groups if(strpos( $grps, $userGroup )) $accessLevel = 1; } } // close our connection as bindDN ldap_unbind( $ldapconn ); echo $accessLevel; } else { print 'unable to bind using user info, user is not authorized in ldap'; } } else { echo 'User not found in LDAP'; } ?>
-
@george1421 I’m downloading a Windows Server 2012 ISO right now.
I’ll create a domain and this will extend my testing a bit.
- I can test the LDAP plugin in a semi real world environment.
- 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).
- I can test LDAP Groups in an AD frameset.
- I can test mutations and hopefully figure out a solution to this ever going problem. (Or validate with certainty that this will not work).
-
@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).
-
@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