Identity Lifecycle Manager
ILM
Identity Lifecycle Manager (ILM) is a Microsoft product which among other
things can be used to synchronize directories. The existing UWWI ILM component
synchronizes the data set in the Person Directory Service (PDS) commonly known
as "whitepages data" to UWWI. There are limitations on this synchronization
process which are tied to the quality of data, the details involved in
normalizing some of the data, the differences in architecture between Active
Directory and our existing UW directory architecture, and the sheer quantity of
data involved.
UW Directory and ILM Background
From a high level, PDS contains uwPerson and uwEntity objects. uwPerson
objects represent personal UW NetIDs. uwEntity objects represent other types of
UW NetIDs. PDS has all UW NetIDs regardless of whether they have an active
Kerberos status or not. UWWI contains user objects that represent all the UW
NetIDs with an active Kerberos status.
ILM connects or joins PDS objects to UWWI objects primarily via a unique
identifier called the uwRegID. This is a hexadecimal 32 digit string which is
used as a key across UW infrastructure services to track entities of interest,
like UW NetIDs. Secondarily, ILM joins PDS objects to UWWI objects via the
uwNetID value. The uwNetID value is a less accurate join rule because UW NetID
renames happen.
Once a PDS object and a UWWI object are joined, then ILM can perform any
synchronization actions it is configured for. By design, ILM is authoritative
for the attributes it is configured to synchronize on any the UWWI object that
has been joined to a PDS object. In other words, if a UWWI object has been
joined, then certain attribute values will persistently be reset by ILM, and no
amount of modification to the UWWI object, short of intervention to the ILM
configuration, can keep those attribute values from resynchronizing to the value
ILM intends.
Because of the combination of the architectural design of PDS, the sheer
quantity of data involved, and the large number of additional objects that are
in PDS but not in UWWI, only PDS uwPerson objects are attempted to be joined to
UWWI objects. This means that most non-personal UW NetIDs are not synchronized
with PDS data. The consequences of this are not hugely significant, because for
the most part only people have whitepages data. However, in some cases, this can
mean that certain UW NetIDs used in unexpected ways have sparser directory data,
including non-friendly names, in UWWI.
Most of the whitepages data is subject to publishing flags that govern
whether the data can be made generally available. Some UWWI objects may
correctly join with PDS objects that have whitepages data, but not be able to
use that data because the person has chosen to not publish their data.
In the
diagram above, PDS starts the process by sending incremental updates to ILM for
processing [1]. ILM processes these, and pulls UWWI info in for process as well
[2]. ILM looks to find which PDS objects can be joined to UWWI objects [3].
Finally, ILM writes personal information to UWWI for joined objects, as
specified by the ILM configuration [4].
What UWWI Attributes are Involved
The following UWWI user attributes are updated for objects that have been
joined:
- givenName
- initials
- sn
- displayName
- mail
- extensionAttribute1
- uwTest
- eduPersonAffiliation
- telephoneNumber
- fascimileTelephoneNumber
- department
- title
- streetAddress
- physicalDeliveryOfficeName
The
full details on how ILM maps data from PDS to UWWI are here.
ILM Operational Details
ILM receives PDS changes every 15 minutes. These incremental change logs are
processed roughly every 2 hours. It takes ILM ~2 hours to process all the change
logs that have come in within a 2 hour period. So there is a 2 hour latency
period from PDS to UWWI. The source systems which feed PDS can have additional
latency on top of this, with most modifications taking a full day to propogate
to PDS, but in some cases--over weekends or holidays--it can be longer. New
entries to PDS usually happen almost immediately.