Next Generation LDAP

Owned by Julio Polo
Last updated: Oct 17, 2014 by mhodges
4 min read

We deployed the redesigned Next Generation LDAP service on April 2013 and it is now considered to be the current production LDAP services.  It utilizes Red Hat's 389 Directory Server.

What's included as of the April 2013 rollout?

  • Central Active Directory Authentication Service (people branch only, see also notes at the end)
  • A "pruned" people branch and non-visitor entries in the misc branch. We no longer retain in LDAP people no longer affiliated with the University. Note that 'Ohana and retirees may be affiliated with the University well past their enrollment dates, position appointments, etc.

Known Issues

(tick) Recently fixed:

  • New host name
    • Production environment: ldap.hawaii.edu
    • Test environment: ldap-test.its.hawaii.edu
  • No anonymous binds.
    • Applications would need to request a special DN
    • Individuals who rely on anonymous binds for contact searches may continue pointing to ldap1.its.hawaii.edu
  • Secure LDAP connection is required
    • Cleartext binds will be rejected.
    • LDAP over SSL uses port 636

    • Port 389 is allowed if using startTLS 

  • Only active people.
    • LDAP data will only include current students, faculty, staff, ohana and applicants.
    • See UH Role Assignments and Transitions for the life cycle of these roles.
    • Basically, LDAP will have anyone with any value in any one of these:
      • uhOrgAffiliation
      • uid
      • WPMS-related attributes:
        • title
        • physicaldeliveryofficename
        • telephoneNumber
        • facsimileTelephoneNumber
        • labeledURI
    • Do not rely on our definition of active
      • Always check that the authenticated person has the appropriate roles for your application
      • We might allow a recently deactivated person to remain in LDAP. Our goal is to reduce the number of unnecessary entries in LDAP, so we cannot guarantee that all people in LDAP are truly active.
  • Format of DN will change
    • Applications should always use the get-DN function in LDAP modules:
      • PHP: ldap_get_dn
      • Perl: Net::LDAP::Entry->dn
      • Java: I think it's NameClassPair.getNameInNameSpace (someone please verify)
    • Consider data in DN as transient
    • Do not parse the DN for information
    • Do not store the DN as an identifier
    • You will notice that a new attribute called uhEntry is now in the DN. Do not use this value as an identifier, it is not guaranteed to be immutable.
  • Removed uhPreferredMail
    • This attribute is misleading since a person does not really choose his or her preferred email address. Therefore it will be removed.
  • Removed uhAllowedService
    • This attribute will be removed since it was never really used.
    • (warning) Visitors had a value of "via", but this will no longer be supported.
  • Replaced uhDataOrigin with uhMetaData
    • This should not affect applications, but in the unlikely event someone was actually reading the uhDataOrigin attribute, these are no longer available:
      • uhDataOrigin: dataOriginType=UHIMS,dataOriginID=miscUsernames
      • uhDataOrigin: dataOriginType=application,dataOriginID=VIA,requesterID=jdoe
    • The uhMetaData attribute replaces the above using a slightly different format:
      • uhMetaData: dataOrigin=uhims,usernameType=misc
      • uhMetaData: dataOrigin=via,requesterID=jdoe
      • There may be other values appearing in this attribute, but they are for internal use and are not supported.
  • Standardized on case
    • LDAP should not be case-sensitive, but for the sake of consistency, we have standardized as follows:
    • eduPersonOrgDN (you may have seen edupersonorgdn or eduPersonOrgDn)
    • eduPersonAffiliation (you may have seen edupersonaffiliation)
    • uhOrgAffiliation (you may have see uhorgaffiliation)
      • uhOrgAffiliation values use eduPersonOrgDN= (you may have seen eduPersonOrgDn=)
    • uhRestrict (you may have seen uhrestrict)
      • If uhRestrict is defined, the value should be uhUnlisted (you may have seen uhunlisted)
  • Multiple values for phone numbers
    • telephoneNumber and facsimileTelephoneNumber sometimes had multiple phone numbers separated by a comma, e.g.
      • telephoneNumber: (808) 555-5551, (808) 555-5552
      • facsimileTelephoneNumber: (808) 555-5553, (808) 555-5554
    • whereas the new LDAP will have
      • telephoneNumber: (808) 555-5551
      • telephoneNumber: (808) 555-5552
      • facsimileTelephoneNumber: (808) 555-5553
      • facsimileTelephoneNumber: (808) 555-5554
    • This is also consistent with the data presented by UHIMS Events.
  • Replace ccc with uhsystem in eduPersonOrgDN
    • You may have seen eduPersonOrgDN with the value of ccc (Chancellor for Community Colleges) in the past.
    • They should now have the value of uhsystem
    • This includes values for eduPersonOrgDN appearing within uhOrgAffiliation.
    • This is also consistent with the data presented by UHIMS Events.
  • Listing @hawaii.edu email addresses other than your own
    • For this initial release, the new LDAP is not including certain @hawaii.edu email addresses that the departmental contact entered but that belong to another person or to a department/group as a whole.
    • We will follow up on this topic on a separate email.
  • This new LDAP will remove inconsistencies in some records in the current LDAP:
    • Several non-compensated employees should have been listed as "staff" instead of "other" (and as any staff, they will be listed in the public online directory)
    • Some old email addresses entered by departmental contacts should have been deleted.
    • Some people had an extra blank email address.

(info) CAS will not be affected by any these changes. (thumbs up) Reminder: Use CAS instead of LDAP if it does the job

About the new Central Active Directory Authentication Service

  • Requires a one-time password change.
    • Microsoft requires that passwords be sent to a domain in cleartext so that it can handle the hashing, and we don't keep cleartext passwords.
    • As UHIMS encounters password creation and password change events it will synchronize passwords with the Central AD Authentication Service.
    • We will initialize synchronize all Active Directory entries with random passwords.
    • UH Usernames created before 4/10/13 will have to perform a one-time password change in order to use Microsoft services that federate authentication against this Central AD Authentication Service.