Detecting Entry Changes

Contents

Overview

Any given entry in the CalNet Directory (LDAP) has many attributes which track when other attributes have changed. We have recently added two new attributes which will help developers keep track of when a user has upgraded to a CalNet Friendly ID (berkeleyEduCalNetIDUpdatedDate), or when we have consolidated multiple entries (berkeleyEduCalNetUIDConsolidationDate). We have also added an index to the global attribute which tracks changes when any attribute on an entry changes (modifytimestamp). Each of these attributes is documented below.

Detecting a change to any part of an entry

Any time any attribute within an entry in LDAP changes, the LDAP server automatically updates the modifytimestamp attribute for that entry with the current date and time (timestamp).

The timestamp for this attribute is UTC, which is represented by the letter "Z" at the end of the timestamp. An example of the attribute is as follows:

So, if a record changed at 20080529205326Z, then this means the record was changed at 1:53:26 PM Pacific Daylight Time, which is -7 hours from GMT. If the record changed during Standard Time, then it would be -8 hours from GMT.

We have recently added an index to this attribute, and now you can search for records that have changed, for any reason, since a given date and time. For example, to search for records that have changed since 12:00 AM Pacific Daylight Time 6/1/2008, your filter would look like this:

Keep in mind, too, that the +7 (or +8) hours from Pacific Time can run into the next day, and of course, the next month. So, if you wanted to find changes since 6:00 PM Pacific Daylight Time 5/31/2008, then your filter would look like this:

The allowed operations on this attribute are as follows:

Note: This attribute only has an equality index, so you can only do a search where you actually provide a date to compare against (see above). If you try a presence search, i.e., modifytimestamp=*, your search will not work!

modifytimestamp is an unique attribute in that if you want to get the attribute back as part of your search results, you need to explicitly ask for it by name. Therefore, if you are currently telling LDAP to return all attributes for which you have access (), then this attribute will not be returned. If you are doing this, and you want *modifytimestamp then you need to list out all of the attributes you want back, including this one.

modifytimestamp is a public attribute, so all applications binds, and even anonymous binds, have access to it. In other words, you do not have to ask permission to use this attribute. However, we do ask that you only use it if necessary.

Detecting a change to a CalNet ID

Whenever a user changes his/her CalNet ID, the attribute berkeleyEduCalNetIDUpdatedDate is set with the current date and time (timestamp). Unlike modifytimestamp, berkeleyEduCalNetIDUpdatedDate is set in Pacific Time. Although this is a departure from LDAP best-practices, we felt that it would be worth it given that developers do not have to worry about time conversions. Also, when you look at the timestamp, you will see the time when it actually happened here at UCB. Because of this, the berkeleyEduCalNetIDUpdatedDate timestamp does not have a "Z" at the end of it.

To search for records that have IDs that have changed since 12:00 AM Pacific time 6/1/2008, your filter would look like this:

The allowed operations on this attribute are as follows:

Note: This attribute only has an equality index, so you can only do a search where you actually provide a date to compare against (see above). If you try a presence search, i.e., berkeleyEduCalNetIDUpdatedDate=*, your search will not work!

Although the berkeleyEduCalNetIDUpdatedDate attribute is new, we have back-dated all ID changes to the end of September, 2007. So, as of June 1, 2008, there are over 500 entries in the directory that have this attribute set for them. This will allow you to do testing.

If you are explicitly asking for attributes by name, and you now want this attribute back as well, you will need to include it in your list of attributes to return. However, if you are just asking LDAP to return all attributes to which you have access (*), then this attribute will be returned if you have access to it (see next paragraph).

This attribute is available to any registered application bind which already has access to berkeleyEduKerberosPrincipalString (which is aliased to berkeleyEduCalNetID, hence the naming of this new attribute).

Note: Along with berkeleyEduKerberosPrincipalString, you may want to see what a person's old CalNet ID(s) was, for which you will need to request access to berkeleyEduKerberosPrincipalStringOld. If you need access to this attribute, please send email to calnet-admin@lists.berkeley.edu and include the name of the bind for which you are requesting access.

Detecting a change to a UID (UID consolidated)

Whenever the CalNet Team consolidates UIDs*, we set the attribute berkeleyEduCalNetUIDConsolidationDate with the current date and time (timestamp). Just like with berkeleyEduCalNetIDUpdatedDate, this timestamp is set in Pacific Time. When this happens, we also set the attribute berkeleyEduCalNetUIDOld with any UID(s) the person had before.

To search for records that have consolidated UIDs since 12:00 AM Pacific Daylight Time 6/1/2008, your filter would look like this:

The allowed operations on this attribute are as follows:

Note: This attribute only has an equality index, so you can only do a search where you actually provide a date to compare against (see above). If you try a presence search, i.e.,berkeleyEduCalNetUIDConsolidationDate=*, your search will not work!

If you are explicitly asking for attributes by name, and you now want this attribute back as well, you will need to include it in your list of attributes to return. However, if you are just asking LDAP to return all attributes to which you have access (*), then this attribute will be returned if you have access to it (see next paragraph).

These attributes are available to any registered application bind.

Note: Do not search on berkeleyEduCalNetUIDOld as this is not an indexed attribute, and your search will probably never find any results.

*CalNet uids occasionally are changed. We do so only if:

1. Two records were created as part of the data load due to mismatched data between the student, employee and/or affiliate record.
2. An employee who left the University in 2001 or earlier, returned and was assigned a new employee id. If we retained the old id, a new uid would be created and the two would need to be reconciled.
3. A student was assigned a second student id, usually due to a mismatch of data.
4. A person has multiple affiliate records. The new LDAP allows a single uid to have multiple affiliate records. We will have to reconcile these in the new LDAP.

FAQs

Below are some frequently asked questions about the various modify date attributes within a given LDAP entry.

1. What is the difference between the berkeleyEduModDate and modifytimestamp attributes? For many entries, they have different values. 
   
   The modifytimestamp attribute is automatically updated by the LDAP server software whenever any change is made to any attribute within an entry, including attributes that user's have the ability to update themselves, e.g., email, telephoneNumber, and other address data. 
   
   The berkeleyEduModDate attribute is only set by the CalNet Sync Process when data from Student Systems, HR, or Alumni sources has changed.