-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 operational LDAP server is also required.
|
+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: ^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} |
+ |
+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. |
+ |
+||Schema|login|email|real_name |
+ |LDAP User Attribute|LDAP User E-Mail Address|LDAP User Display Name |
+inetOrgPerson|cn|mail|displayName |
+Active Directory|cn|mail|displayName |
+ | | || |
+Not having an AD server to test against it is a little difficult to confirm things, but it does seem that modern AD schemas will accept the international standard fields and return the same results. |
+ |
+As will be seen from the config page, the feilds used for each of these can be customised if required, and the object schema can also be changed from the default inetOrgPerson. |
+ |
+The group section of settings are not currently being used, but have been left to provide hooks for future development. |
+ |
+The LDAP User and Password will have been set up while the server was installed and should be copied from that setup. |
|
-++yellow:Now to work out what it all means++
|
+The LDAP Scope is used to define the depth of search. The default 'Sub' will allow the whole tree below the provided 'Base DN' and 'User DN' to be inspected, while base and one will restrict searches to just the specified level, or one layer below. [http://www.idevelopment.info/data/LDAP/LDAP_Resources/SEARCH_Setting_the_SCOPE_Parameter.shtml| This page provides a nice summary of the Scope setting] |
|
!!!Other useful links
|
[http://uk.php.net/ldap|PHP LDAP Package]
|
[http://pear.php.net/manual/en/package.authentication.auth.php|PEAR Auth Module]
|
[http://phpldapadmin.sourceforge.net/wiki/index.php/Main_Page|phpLDAPAdmin administration package] |
+[http://www.it.ufl.edu/projects/directory/ldap-schema/objectclasses.html|Useful schema tree - use links at bottom] Need something a little tidier, but this is a useful start |
+[http://www.symas.com/documents/Adam-Eval1-0.pdf|Very nice comparison document for Active Directory] This also outlines a number of more advanced fatures. |