Future LDAP

We plan to deploy a redesigned LDAP service in 2013:

What's included with the 4/10/2013 soft rollout?

A single non-replicated ldap.hawaii.edu
Central Active Directory Authentication Service (people branch only, see also notes at the end)
Only the (pruned) people branch is live.
Visitor and ACER data synchronized as of 4/18/2013 7pm

Several weeks later, after 389 directory server software patches some bugs:

Replicated and load-balanced LDAP environment

Known Issues

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: Bug report submitted to vendor
Using "replace: userPassword" with no values does not completely delete password
- Status: Bug report submitted to vendor

Recently fixed:

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
- ldap.hawaii.edu
- Will be deployed in parallel to ldap1.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.
- Port 389 only for startls
Only active people.
- LDAP data will only include current students, faculty, staff, ohana and applicants.
- See UH Role Assignments, Role Transitions and Systems of Record 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 ( new!)
- 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 ( new!)
- 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 ( new!)
- 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: ( new!)
- 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.
This new service is being piloted by one of our campuses. From that experience we hope to obtain recommendations and experiences that we can then publish for others to utilize.