LDAP is the Lightweight Directory Access Protocol, and provides user authentication via an LDAP server. Use of the plugin requires that both PEAR:Auth and the php ldap module are installed in your web server setup. In addition, obviously, an ((LDAPServerConfiguration|operational LDAP server)) is also required.
|
|
-Ubuntu/Debian Example:^apt-get install php-auth php-ldap^Note for v2.6: ^You must also uncomment ./users/auth/ldap/auth.php line 15. This allows the PEAR::Auth module to be found on your system. Oops; LDAP support is broke in 2.6, working on it now...^
|
+Ubuntu/Debian Example:^apt-get install php-auth php-ldap^ |
+Note for v2.6: ^LDAP in the 2.6 release is broken, but the LDAP auth module has been completely rewritten and is fully functional in CVS.^ |
|
[http://www.openldap.org/|The OpenLDAP Project] is a useful starting point for setting up a working LDAP system although alternatives are also available. Most of the Linux distributions will have an LDAP server setup that can be enabled if required.
|
|
!!!Configuring access
|
Once correctly enabled, an LDAP tab will be provided on the Login Settings page, and this needs to be populated with the access information for your LDAP server.
|
|
-{attachment id=990 size=medium}
|
+{attachment id=992 size=medium} |
|
-++yellow:Now to work out what it all means++
|
+The LDAP host and port entries should be self explanatory, and point to the machine hosting your ldap server. The LDAP Base DN will also become understandable. It provides a unique name for the top level of the data, and should be distinct from other sites so that several ldap servers can be combined at a higher level. Normal practice is to use the domain name of the site that you are managing, but this is not essential. [http://www.idevelopment.info/data/LDAP/LDAP_Resources/DEPLOY_Choosing_a_Base_DN.shtml|This page provides a nice summary on deciding on a base setting] |
+ |
+The LDAP User DN is a little more complex, and possibly does not even need to be set, but it will direct the authentication plugin to the particular branch that contains the 'people' records that we want to scan. If there are more than one user table for a multiple site, this will restrict access to the section we currently want to access. ( If the setup is using multisite, then it is anticipated that each area of the site would have their own user table, and would amend the User DN based on the particular site name ) |
|
Bitweaver requires a number of fields available in it's USERS_USERS table in order to correctly identify and work with it's internal user_id. The three that must be available are login, email and real_name, although real_name can probably be defaulted to login if not available. The password fields provided in the USERS_USERS table can be ignored if LDAP is being used to provide those checks, although at present we have no details on how things like password time-out are handled at the ldap end. At some point we may be able to link user avatars stored in ldap with the local attachments, but having all files stored via ldap may be a little further off. This just leaves the 'default_group_id', but at this stage it will be assumed that this is only managed locally, although the role/group overlap does come into play.
|
|