Next Generation LDAP
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
Using "replace: userPassword" with no values does not completely delete password
Status: Bug report submitted to vendor
Recently fixed:
Binding as the target person (as opposed to special DN) works but does not allow searches
Description:
Bind using your special DN, searching for uid=username, and retrieve DN for username works
Bind using username's DN and password works
Bound successfully as username, this search returns nothing: uid=username broken
Status: One of the recent updates supposedly fixed this, but we still had to add an apparently redundant ACI on 9/19/2014 11:30 AM to make it work.
Error when replacing values of a multi-valued attribute (only when replication is enabled)
Status: Patch has been applied to ldap.hawaii.edu
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.
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.
CAS will not be affected by any these changes. 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.