Setting Sites Up for LDAP

Site Configuration Support

Using an LDAP setup it's important to disable user creation of accounts or else users may end up creating one.  This can cause login and user management confusion and if they happen to create an account with the same username as thier LDAP (we've seen this several times), it will cause the site to hang.

To disable creation of user accounts go to Administration -> User Settings and select the radio button for "Only site administrators can create new user accounts."

Setup Directions

Step by step directions for configuring a new drupal site for ldap authentication.

  1. In Administer -> Site Building -> Modules,  enable Ldap Authentication.   You may also want to enable:
    • Ldap Data -- get user profile information from Ldap
    • Ldap Groups -- use information in Ldap to automatically assign users to groups (most likely not useful here, because we don't currently have much data in Ldap that is going to map to any of the groups we want)
  2. Once Ldap is enable, add your settings under Administer -> Site Configuration -> Ldap Authentication
    1. Add a new server with these settings
      • LDAP server : ldaps:// *
      • port: 636
      • base dns:
      • username attribute: uid  (default setting)
      • email attribute: mail (default setting)
      • store passwords in encrypted form unchecked? **
    2. Under advanced, settings you must add credentials for an ldap service account because Emory's Ldap does not permit anonymous searches.  For credentials, see syswiki ldap information.  The DN for non-anonymous search must be set; ours takes the form of 'uid=<account>,ou=services,' where <account> is replaced with the account name for the particular service.
    3. Choose top-level settings appropriate for your site.
      • If you will ONLY be using LDAP logins select LDAP only mode, this will still enable you to use the original local account (id 1) registered at install but ONLY that local account will be used. Enable mixed authentication mode if you will have any non-ldap users
      • For user conflict resolution, associate local account with ldap account (most likely)
      • Remove password change fields from user edit form §
      • Remove or disable email field on user edit form
  3.  If you wish to use Ldap Data, configure that under Administer -> Site Configuration -> Ldap Data
    • Mapping should be read-only (see notes on email and password if you don't understand why)
    • The shared version of the ldap dapa config file mentioned for advanced configuration has already been edited to expose the attributes we have access to in ldap that are likely to be useful
    • Enable whichever fields you want to be available (readable, not editable)
    • Under the advanced configuration, enter ldap service account credentials (should be the same as used for the anonymous search above)
    • NOTE:  If you deactivate the ldap data module it clears the user connection string and password from the setup screen and you will have to reenter this information.
  4.  If you wish to use Ldap Groups, configure that under Administer -> Site Configuration -> Ldap Groups
    • Not currently in use in any of our sites
    • Example/possible usage: in the groups by attribute section, add departmentnumber. Whenever an ldap user account is created, they will automatically be added to this group (drupal role is created if it does not already exist).  If the ldap group name or code is not human readable, it can be mapped to a drupal role in the ldapgroups conf file.

* When configuring LDAP in drupal you have to prepend the server with ldaps:// when using the SSL Port (636).  This is unnecessary when using an unsecure port or Start-TLS.
** Enabling this does not break authentication, but this setting may only be relevant for when drupal is attempting to update a password in ldap, which we shouldn't be using anyway.
§ This is not currently set in the configurations I checked, but I have my doubts that a password change made through drupal would even work, and I certainly don't think it's a good idea-- ldap password changes should be made with the UTS password utility.
Similar to password above-- I don't think we can edit this in ldap, and email changes should be made through the UTS preferred email web form.