Miscellaneous Hacks - LDAP Authentication

I've only recently started using vBulletin, and this is my first mod so if you use this, please click Installed!

This mod (which builds on the fine work from malcomx and zemic) is intended to lower the barriers to using and LDAP directory as an external authentication source for your board. The idea is simple; capture a login attempt before authentication and test it against LDAP first, if that succeeds, see if there is already a matching user in vBulletin. If there is not, create one, using data from the LDAP to fill in the required fields, if there is already a matching user (Determined by comparing email addresses) then update the user.

You might be asking why this mod is better than the two mods I've mentioned above? Well firstly the only additional file is the XML file for the new hooks (See below), and no changes to vBulletin code so installation is simple, and upgrades to vBulletin don't get over complicated by re-applying changes. Secondly, all the settings are controlled from the admincp rather than an external config file. Thirdly (as if two wasn't enough) I've added some hook points so this mod can be extended, for example to get additional data from the LDAP and put it in user profile fields.

One important similarity with the two earlier mods is that in the admincp and modcp no LDAP authentication is performed, this is a safety feature, so even if the mod or an extending to it, breaks your board, you shouldn't ever get locked out of the admincp so you'll be able to turn if off quickly.

Additional Hooks

The mod is essentially a single plugin (plus options and help) which runs at global_complete which is before most other things have happened, but just after all the global setup has occurred.

To enable the additional hooks, you need to upload the file hooks_ldap_auth.xml to /includes/xml under your forum.

The following new hooks are created by this mod:

• ldap_auth_start - After the list of attributes to fetch has been created, this list is in $ldapAttrs. You can simply add your own attributes to this array here.
• ldap_auth_all_user - After a new user has been added to vBulletin or existing user has been updated, but before the user has been saved. The new user is in $newuser and the LDAP data is in $userData. This happens before ldap_auth_new_user or ldap_auth_existing_user.
• ldap_auth_new_user - After a new user has been added to vBulletin, but before the user has been saved. The new user is in $newuser and the LDAP data is in $userData.
• ldap_auth_existing_user - After an existing user has been updated, but before the user has been saved. The new user is in $newuser and the LDAP data is in $userData.

By requesting new attributes at ldap_auth_start and then applying them at either ldap_auth_all_user, ldap_auth_new_user or ldap_auth_existing_user you can setup your users easily without having to write all the LDAP code yourself!

AdminCP Settings

This mod creates a new options group called LDAP Authentication between email options and user registration options where you set the host name and port number of the LDAP server, the initial authentication type (Anonymous or authenticated), optionally the BindDN and Password for the LDAP server. You also set which attribute matches the vBulletin username (The default is cn which works well for inetOrgPerson based entries). You can set additional attributes to retrieve (If you want to quickly knock up a simple plugin which uses them at one of the hook points above). There is also the facility to disable (or rather make unavailable) accounts which exist in vBulletin but not in LDAP. Given that your initial admin may fall into this group, there is also a list of userids who should be allowed to log in anyway.

Requirements

• PHP 4.3+ with LDAP support.

I'll try to provide support to users of my mod, but please bear in mind I fairly new to all this, so I may not be able to solve all problems immediately. Support will only be provided via this thread (Don't PM or email me unless I ask you to). Priority will be given to users who have clicked Installed.

Release Notes

• 1.0 - Initial release
• 1.1 - Corrected SQL queries to use TABLE_PREFIX
• 1.2 - Corrected a bug which prevented the settings page from being created correctly
• 1.3 - Corrected where the existing, new and all user hooks are called (Before, not after the user profile fields are set) to support dependant plugins
• 1.4 - Added the ability to set a search base for directories which do not permit searching from the root
• 1.5 - Fixed reported bug where hooks were called in the wrong order

Installation

1. Add the command define('DISABLE_PASSWORD_CLEARING', 1); to your includes/config.php - This will NOT be overwritten by upgrades, so only needs doing once.
2. Upload the file hooks_ldap_auth.xml to includes/xml under your forum.
3. Install the latest product file (below) using the Add/Import Product link on the Manage Products page under Plugins & Products in your AdminCP.

Haqa...

[Jimbot]

Originally Posted by jugbugs

I followed this process and am getting...

Fatal error: Call to undefined function ldap_connect() in D:\www\vhosts\localhost\includes\functions.php(7038) : eval()'d code on line 36

I am assuming this means I do not have ldap enabled for PHP... any thoughts on an easy way to "add" LDAP to an existing install? What specifically needs to be included and where?

I've not got that error, but I have the LDAP extension for PHP installed. You can check the status of ldap through the vbulletin admincp->Maintenance->PHP info. There's a whole section devoted to ldap in mine.

I run on Windows, so installing LDAP support for PHP was simply an option I chose in the PHP installer (under 'extensions' if I recall correctly).

Good luck!

[roarkh]

I am new to vBulletin so this is all new to me. I just installed the LDAP Authentication plugin referenced in this thread and for the most part it seems to be working just fine. However, I have a question. I have logged in as two different users from our LDAP server and vBulletin did indeed allow them to login and did create user accounts for them. However, I noticed that for some reason the "Primary Usergroup" for both of those users was set by default to "Super Moderators". It seems to me that they should be set to "Registered Users" instead.

If I go into the vbulletin admin panel and manually add a user the default settings does seem to be "Registered Users".

Is there any way to tell the LDAP Authentication plugin that new users should be created as "Registered Users" instead of "Super Moderators"?

Thanks in advance.

[Jimbot]

Originally Posted by roarkh

Is there any way to tell the LDAP Authentication plugin that new users should be created as "Registered Users" instead of "Super Moderators"?

Yes, but you'll need to edit the plugin source, as this option hasn't been added to the LDAP settings.

If you're using my version, from the post above, you'll need to edit line 193 of the plugin, shown in the snip below. The line that sets the usergroupid to 5 makes the new user a supermoderator. The 'Registered users' group has a usergroupid of 2 (at least it does in mine). So change the 5 to a 2, and that should resolve the issue. The usergroup IDs can be found in Usergroup manager in the admin control panel.

PHP Code:

      ($debug = $debug ) ? print_log("New user. Creating with info from ldap") : false;
      $newuser->set('email', strtolower($userData[0]['mail'][0]));
      $newuser->set('username', $vbulletin->GPC['vb_login_username']);
--->      $newuser->set('usergroupid', 5);
      $newuser->set_bitfield('options', 'adminemail', true);
      $newuser->set_bitfield('options', 'emailonpm', true) 


Hope this helps!

[roarkh]

Originally Posted by roarkh

I am new to vBulletin so this is all new to me. I just installed the LDAP Authentication plugin referenced in this thread and for the most part it seems to be working just fine. However, I have a question. I have logged in as two different users from our LDAP server and vBulletin did indeed allow them to login and did create user accounts for them. However, I noticed that for some reason the "Primary Usergroup" for both of those users was set by default to "Super Moderators". It seems to me that they should be set to "Registered Users" instead.

If I go into the vbulletin admin panel and manually add a user the default settings does seem to be "Registered Users".

Is there any way to tell the LDAP Authentication plugin that new users should be created as "Registered Users" instead of "Super Moderators"?

Thanks in advance.

Well, I did some digging through the module code (version 1.5.1_vb4) and noticed this on line 199.

$newuser->set('usergroupid', 5);

I changed the above to the following and reinstalled the addon.

$newuser->set('usergroupid', 2);

And now the default usergroup is Registered Users instead of Super Moderators. I'm wondering if this should not be the default behavior?

Thank you.

[roarkh]

Originally Posted by Jimbot

Yes, but you'll need to edit the plugin source, as this option hasn't been added to the LDAP settings.

If you're using my version, from the post above, you'll need to edit line 193 of the plugin, shown in the snip below. The line that sets the usergroupid to 5 makes the new user a supermoderator. The 'Registered users' group has a usergroupid of 2 (at least it does in mine). So change the 5 to a 2, and that should resolve the issue. The usergroup IDs can be found in Usergroup manager in the admin control panel.

PHP Code:

      ($debug = $debug ) ? print_log("New user. Creating with info from ldap") : false;
      $newuser->set('email', strtolower($userData[0]['mail'][0]));
      $newuser->set('username', $vbulletin->GPC['vb_login_username']);
--->      $newuser->set('usergroupid', 5);
      $newuser->set_bitfield('options', 'adminemail', true);
      $newuser->set_bitfield('options', 'emailonpm', true) 


Hope this helps!

Thanks for your response, apparently I was posting the solution I found to this at the same time you were answering me so I didn't see your post until I completed mine. Clearly we are both on the same track and that indeed did fix my problem.

Thanks again.

[Jimbot]

Originally Posted by roarkh

And now the default usergroup is Registered Users instead of Super Moderators. I'm wondering if this should not be the default behavior?

Perhaps you are right. For my setup, though, by default LDAP users are considered 'trusted', and members using internal VB authentication are not. So all LDAP users are granted the super mod privileges.

What we really should do is make it a config setting.

Not sure when I'll get time to do this....

[rguser]

I didn't have any luck with using the original set_userfields method. The aforementioned code had:

PHP Code:

$newuser->set_userfields($userFields); 


It worked when I switched it to this:

PHP Code:

$newuser->set_userfields($userFields, true, admin); 


I think it's because the account I was testing was my own account which was promoted to administrator.

Has anyone conceived of the idea or attempted setting the username to the LDAP 'displayname' or 'givenname' and 'sn' while allowing the user to both login and authenticate using their LDAP credentials? ie, login as: jdoe, but username is set to John Doe so that all posts, member list, user profile and all show John Doe. My forum is internal, consists only of LDAP users all on the same domain and I've disabled registration since the LDAP auth code can create a new user. I've made a user profile field set to displayname but if I don't have to go through and modify the template to show the displayname userfield in lieu of username, that would be awesome.

Unless it's easier now to modify the template using the built-in search/replace? Suggestions or ideas?

[jugbugs]

Originally Posted by Jimbot

I've not got that error, but I have the LDAP extension for PHP installed. You can check the status of ldap through the vbulletin admincp->Maintenance->PHP info. There's a whole section devoted to ldap in mine.

I run on Windows, so installing LDAP support for PHP was simply an option I chose in the PHP installer (under 'extensions' if I recall correctly).

Good luck!

This worked perfectly... thank you

[jugbugs]

I have another question, which is php related.

I have this plugin (vb4 version) and it is working, however, I cannot get the "Allow Built-in Accounts" (ldap_allow_builtin) setting to work when putting in a comma separated list. If I only have one userid in this setting it works for that user only, which leads me to believe this is an easy solution. Given the fact that I am php retard, the answer is not glaringly obvious, therefore, I will summarize what I know in hopes someone can help me.

In the product xml, this variable (setting) is defined as follows:

<setting varname="ldap_allow_builtin" displayorder="100">
	<datatype>free</datatype>
	<defaultvalue>1</defaultvalue>
</setting>

The piece of code that I believe to be broken that uses this variable is:

PHP Code:

//if login is on the list of allowed logins, don't use ldap authentication
$userid = $vbulletin->db->query_first_slave("
   SELECT userid
   FROM ".TABLE_PREFIX."user
   WHERE userid in ('".$vbulletin->db->escape_string(htmlspecialchars_uni($vbulletin->options['ldap_allow_builtin']))."')
   AND username = '".$vbulletin->db->escape_string(htmlspecialchars_uni($vbulletin->GPC['vb_login_username']))."'");
if ($userid) {
    ($debug = $debug ) ? print_log("user on the non-ldap list. " . $vbulletin->GPC['vb_login_username'] . " with id: ". implode(",",$userid)) : false;
    return;
} 


So, what is wrong with the php code that is not searching "ldap_allow_builtin" as if it is an array?

Thanks.

[alexm]

Originally Posted by Jimbot

For this to work you'll need the following files. They go in the following locations:
./includes/xml/hooks_ldap_auth.xml
./includes/devtools.php

A big thanks to everyone who has contributed to this solution: kpatten, haqa, malcolmx and zemic.

Thanks to everyone for their excellent work!

I have successfully implemented the above version on vBulletin 4.1.10

With regard to this problem:

Originally Posted by kpatten

1. This plugin doesn't seem to work if your Search Base DN begins with a DN in AD. You must have your search base begin with an OU. This means that if you have multiple OU's at the top level of AD that contain users, you may have a problem.

I have managed to get ldap_search to properly recurse through the sub-OU's on a Server 2008 DC running in 2008/2003 mixed mode by doing the following:

After:

PHP Code:

    // Enable LDAP version 3
    ldap_set_option($ldapConnection, LDAP_OPT_PROTOCOL_VERSION, 3); 


Add:

PHP Code:

    ldap_set_option($ldapConnection, LDAP_OPT_REFERRALS, 0); 


Now if I set the Base DN to DC=domain,DC=com it will find users in all OU's in the domain.

Hope this helps someone

Alex