LDAP Simplification and Standardization 10/4/2016

Background

A simplified, more supportable LDAP was introduced on October 4, 2016.

At Berkeley, our LDAP server had been heavily modified to act as a primary data store for all identity information. As part of the Student Information System development effort, CalNet deployed a new Berkeley Person Registry (BPR). This is a database that sits between the authoritative systems of record and the LDAP servers. BRP replaces LDAP as the primary data store for identity information.  As a result of these changes, the considerable complexity of the heavily modified LDAP schema was no longer necessary and was simplified to a more standard deployment. 

What Changed

The three main changes to the LDAP structure were:

1. Job Appointment, Affiliate and Term Sub-Entries were deprecated.

2. Approximately 130 LDAP attributes were deprecated.

1. See Appendix for list of deprecated attributes

3. Affiliates and expirations are now handled differently.

What Stayed the Same?

The OU structure is remaining the same, for now.  The practice of moving records between OUs will continue at this time. This will be revisited in the future.

Address Sub-Entries also remained the same. These are updated directly from the CalNet Directory update application. This will also be addressed in the future.

Changes to Affiliate IDs

LDAP has traditionally stored unique expiry dates for various affiliations.  Those expiry dates indicated the date on which an affiliation would no longer be valid.  Account expiration scripts would then use those dates to calculate the grace period for the account. This logic was actually duplicated by consumers trying to align with CalNet’s internal calculations.  The affiliation specific expiry dates used to be stored in:

berkeleyEduStuExpDate

berkeleyEduEmpExpDate

berkeleyEduAffExpDate

These fields have been deprecated.  Instead CalNet consistently populates the following field:

berkeleyEduExpDate

The value in berkeleyEduExpDate is the official date on which a record will be expired. This means that systems should assume that this person will no longer be able to log in on that date. (It is possible that an Alumni affiliation will cause this record to be moved to ou=advcon but unless you have access to advcon, this is functionally the same as the record being expired).

The grace period will have been calculated and reflected in this date.  The presence of a value in this field means that all active affiliations have already expired and the account is in it’s grace period.  If a system of record subsequently asserts this person again, the berkeleyEduExpDate will be nulled out.

Why did we change LDAP?

An LDAP schema is effectively a contract between the people who populate the data and the people who consume it. Historically, at Berkeley, it was not treated as such. In everyone’s effort to find the best solution for their applications, we collectively allowed a large and unwieldy LDAP schema to become the defacto contract.  This was not a contract that the University could realistically maintain while meeting the increased demand for advanced Identity and Access services, and also being pressured to reduce costs.  This new LDAP schema represents a contract that bIT can realistically support into the future, with the understanding that future modifications and renegotiations are always possible.

What if I have problems with the new LDAP?

If your code is dependent on deprecated attributes, you should immediately start engaging with api-central to find a new source for the data. 

You can test your application by pointing a test version at test ldap instance:

nds-p6.calnet.berkeley.edu

Appendix: Deprecated Attributes

THE FOLLOWING ATTRIBUTES WILL NO LONGER BE SUPPORTED