MIM
Microsoft Identity Manager (FIM) is a Microsoft product which among other things can be used to synchronize directories. The existing NETID MIM component synchronizes the dataset in the Person Directory Service (PDS) commonly known as “whitepages data” to the NETID domain. 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 MIM 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. The NETID domain contains user objects that represent all the UW NetIDs with an active Kerberos status.
MIM connects or joins PDS objects to NETID users via UW NetID. Obviously, UW NetID renames happen and so occasionally a particular NETID user will become disconnected for a short period, not picking up directory data changes during that period. However, this is rare. Infrequently, two or more PDS objects will be merged (because they represent the same person), and if those objects correspond to multiple NETID users, then sometimes it can take a short period before directory changes catch up with the merge.
Once a PDS object and a NETID object are joined, then MIM can perform any synchronization actions it is configured for. By design, MIM is authoritative for the attributes it is configured to synchronize. In other words, if a NETID object has been joined, then certain attribute values will persistently be reset by MIM, and no amount of modification to the NETID object, short of intervention at the MIM configuration, can keep those attribute values from resynchronizing to the value MIM 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 NETID 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 MIM for processing [1]. MIM processes these, and pulls NETID domain info in for processing as well [2]. MIM looks to find which PDS objects can be joined to NETID objects [3]. Finally, MIM writes personal information to NETID for joined objects, as specified by the MIM configuration [4].
What NETID Attributes are Involved
The following NETID user attributes are updated for objects that have been joined:
- givenName
- initials
- sn
- displayName
- extensionAttribute1
- uwTest
- eduPersonAffiliation
- telephoneNumber
- fascimileTelephoneNumber
- department
- title
- streetAddress
- physicalDeliveryOfficeName
The full details on how MIM maps data from PDS to NETID are here.
MIM Operational Details
MIM receives PDS changes every 15 minutes. MIM is triggered to process these incremental change logs every 15 minutes, unless a prior process is still running. For changes that MIM has received, it generally takes about an hour for that change to make it to Active Directory. 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.
The whitepage data updates that MIM provides to the NETID domain are not considered a mission-critical capability, so the expected service level for changes is the time it would take us to bring up a fresh working copy of this, i.e. 4 days. In reality, we rarely exceed latency of more than a couple hours. When we do, it is because we have to replace the existing MIM server and this operation takes several days. There is a hot-spare MIM server with the existing configuration, but due to the way MIM works, it could still take several days for it to “catch up” and provide fresh updates.
We plan to replace this capability with an event-message based architecture that integrates with the UW NetID Preferred Name data source. This will address the latency and design flaws of the existing system, and provide a better source of name data.
Data Mapping
Details about how the data in the Identity Service is mapped to Active Directory are documented.