Search | Directories | Reference Tools
UW Windows Infrastructure Service banner image
Skip Navigation LinksUW Home > Computing and Networking > Support > UW Domains > UW Windows Infrastructure > UWWI Architecture Guide > Identity Lifecycle Manager

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 dataset 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 other 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 users via uw NetID. Obviously, UW NetID renames happen and so occasionally a particular UWWI user will become disconnected for a short period, not picking up directory data changes during that short period. However, this is exceptionally rare. Infrequently, two or more PDS objects will be merged (because they represent the same person), and if those objects correspond to multiple UWWI users, then sometimes it can take a short period before directory changes catch up with the merge.

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. 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 at the ILM configuration, can keep those attribute values from resynchronizing to the value ILM intends them to be set to.

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.

ILM Process

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 and exported to UWWI every 15 minutes. The source systems which feed PDS have additional latency on top of this; most of the source systems only update PDS once a day, but in some cases--over weekends or holidays--it can be longer. New entries to PDS happen at all times of day, not in a single daily event.