Extend LDAP plugin to support AD authentication

[george1421]

@Fernando-Gietz I haven’t tested it as of now since it was pushed to RC11. I was working on a pre release of RC11 and it worked with AD.

I know the wiki page hasn’t been written as of now so there is no information on the new features of the plugin and we have not tested it with all situations.

I’ll have to look at the lines you mentioned to see what is going on.

To answer your question about the logic of the Admin and mobile groups. The reason is security. Just because you are a valid ldap user doesn’t mean you should have access to FOG. So in addition to being a valid ldap user, your account must be found in either an Admin group (as defined by that field) or a Mobile group (as defined by that field). This is consistent with the two user classes in FOG. If your account appears in both groups then the Admin account wins and you have admin access to FOG. There is a graphic below in this thread that I posted with text telling what each field does too.

I’ll refresh my server with RC11 and see if I can track down the bug.

I do have to say if you had the ldap plugin installed before RC11 you must uninstall and reinstall it for the database to be updated correctly. The structure has changed from the older style ldap plugin

[george1421]

@george1421 I can report (at least for AD LDAP) the plugin works as intended. I’m going to dig a bit deeper to make sure its not just a mistake on my part.

I can say I based it working off a false assumption. I still had the AD user cached based on some of the intermediate code. That is why the login worked every time. There is something wrong in the code. Tom and I worked on it for several hours last night. I see what its doing, but need to focus on why its doing what its doing.

[george1421]

@george1421 This thread and the ldap plugin is not dead. I have the code working with AD just fine, I need to perform some GUI updates to the web form to get it to work the way I want it to. But I think we are really close with the working solution.

[george1421]

@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.

[Fernando Gietz]

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.

[Tom Elliott]

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.

[x23piracy]

@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

[Wayne Workman]

I helped @x23piracy - also - We don’t want folks knowing how, it will cause more issues than help.

[x23piracy]

@Wayne-Workman i sell that information for 10 bucks :D… joking

[george1421]

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

[Wayne Workman]

Can this be tested again to make sure it’s still working properly George?

[x23piracy]

@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

[Tom Elliott]

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.

[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

[Wayne Workman]

@x23piracy Dude you are hilarious, in a good way.

[x23piracy]

@Wayne-Workman hehe sorry for the bad words but i really have to deal with some stupid people calling themselves it experts

[Tom Elliott]

@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?

[x23piracy]

@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.

[george1421]

@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.

[george1421]

@george1421

<?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';
     }
 ?>