This document is intended for IT Professionals seeking to understand how “whitepage” identity data is mapped to the NETID domain.
Background
Microsoft Identity Manager (MIM) is one of three Microsoft Infrastructure components which can set directory information on NETID user accounts. The Microsoft Identity Sync Agent is an emerging event-based replacement for MIM. This document covers both MIM and MISA behavior. The NETID Kiwi component also sets some directory information, upon Kiwi events. The reader should consult the NETID Kiwi documentation to be aware of changes which might intersect with what is represented here.
Table Legend
The following table shows which Person Directory Service (PDS) or Identity Registry Web Service (IRWS) attributes are connected to which NETID domain Active Directory (AD) attributes. However, this table doesn’t tell the full story. In most cases, a direct mapping is involved, meaning that the PDS/IRWS attribute value is unchanged and set on the AD attribute. The direct mappings have normal text. However, this is not true of all cases. For the cases where it is not true, a more complicated algorithm is used to determine the NETID value based on input from the PDS/IRWS value(s). The more complex mappings are in italics and explained below.
Publishing Flag and Multiple Affiliations
In almost every case, you’ll see that a PDS/IRWS attribute with “publish” in the name is present. These “publish” attributes are sometimes called publishing flags. They govern whether the individual has allowed a set of information about them to be published. If the individual has chosen to allow publishing, then we make use of that information. However, in some cases it’s more complicated, because there are multiple publishing flags and potentially several sets of personal data depending on the affiliation of the person. In the case where a person is both staff and student, the staff personal information is preferred. If only one of the two flags permits publishing, then only that set of information is used.
| PDS/IRWS | Active Directory (NETID) |
| eduPersonAffiliation | eduPersonAffiliation |
| uidNumber | uidNumber |
| uwRegID | uwRegID |
| uwPriorRegID | uwPriorRegID |
| uwPriorNetID | uwPriorNetID |
| uwWPPublish | extensionAttribute1 |
| uwTest | uwTest |
| uwNetID displayName (aka pdsDisplayName) uwSWPPublish + uwSWPName uwEWPPublish + uwEWPName UWWI: uwDisplayNameOverride |
displayName |
| uwSWPPublish + uwSWPName uwEWPPublish + uwEWPName uwPersonPreferredFirst MI: uwDisplayNameOverride |
givenName |
| uwNetID displayName uwSWPPublish + uwSWPName uwEWPPublish + uwEWPName uwPersonPreferredSurname MI: uwDisplayNameOverride |
sn |
| uwSWPPublish + uwSWPName uwEWPPublish + uwEWPName uwPersonPreferredMiddle MI: uwDisplayNameOverride |
initials |
| uwEWPPublish uwEWPTitle1 uwSWPPublish uwSWPClass |
title |
| uwEWPPublish uwEWPPhone1 uwSWPPublish uwSWPPhone |
telephoneNumber |
| uwEWPPublish uwEWPDept1 uwSWPPublish uwSWPDept1 |
department |
| uwEWPPublish uwEWPAddr1 |
streetAddress |
| uwEWPPublish uwEWPFacsimile |
facsimileTelephoneNumber |
| uwEWPPublish uwEmployeeMailstop |
physicalDeliveryOfficeName |
| uwAccountUUID | None at this time |
| manager | manager (and directReports) |
NOTE: manager data is emerging as part of MISA emergence. It is the first data following the IRWS -> Active Directory flow. Subsets of UW employees already have data, and this will expand during 2024. At this time, the data is updated daily, but as the capability improves it will move to event-based changes with minimal latency. All the other data synchronized by MIM will eventually follow, with the reduced latency.
Complex Attribute Mappings
For naming attributes, a complicated algorithm is used to determine the NETID value based on input from the data sources available. The more complex mappings are italicized in the mapping table above.
Name Attributes
Microsoft Infrastructure “Name Attributes” for the purposes of this discussion:
- givenName
- initials
- sn
- displayName
Exchange, Sharepoint, Skype for Business, and other applications in the Office 365 suite leverage the Microsoft Infrastructure name attributes. There are many other applications which also do their UW NetID identity integration via Microsoft Infrastructure user accounts.
Name Sources
There are many possible data sources for name information (in descending order of priority):
- NETID’s custom uwDisplayNameOverride
- Preferred Name
- uwPersonPreferredFirst
- uwPersonPreferredMiddle
- uwPersonPreferredSurname
- uwEWPName
- uwSWPName
- uwRegisteredName
- uwRegisteredFirstMiddle
- uwRegisteredSurname
- displayName (from PDS–hereafter called pdsDisplayName)
- uwNetID
The uwDisplayNameOverride attribute comes from NETID, and represents an option of last resort for cases where there is a clear business need to override all other data sources. It requires approval from the Microsoft Infrastructure service manager.
The Preferred Name comes from identity.uw.edu. Contrary to how identity.uw.edu seems to present it, as data, it is not a single piece of immediately usable data, but *3* separate pieces of data: uwPersonPreferredFirst, uwPersonPreferredMiddle, uwPersonPreferredSurname which applications are left to interpret and paste together into a usable single piece of data. Of particular concern is the uwPersonPreferredMiddle data, which is allowed to be any length, but which is not usable as such in Microsoft Active Directory. For this reason, we have a “constructed” preferred name, which we hereafter refer to as constructedPreferredName. More information about how we construct this is documented below.
The uwEWPName value comes from the Employee Self-Service (ESS) application and is only available to current employees. That data source does minimal data input validation so the formatting is not consistent.
The uwSWPName comes from the UW Registrar (for students). There is no digital interface to make changes–you must go in person to their offices. This option is only available to current students, not former students.
The uwRegistered* attributes usually reflect the official name of record, but are case insensitive and there is no clear authority to publish that data, so using it carries an associated privacy risk. For this reason, we do not use the uwRegistered* attributes.
The displayName source from PDS has one of two source systems based on the type of UW NetID:
- This is currently the only name data source available for non-personal UW NetIDs. For non-personal UW NetIDs this value comes from the AVF source system. If you want to change this value for a non-personal UW NetID, you can use https://uwnetid.washington.edu/manage and the Name field exposed there.
- For personal UW NetIDs, the Preferred Name, available via a self-service management portal at https://identity.uw.edu, provides a central authority for UW identities to assert name values of their preference for use in UW systems, and results in a change to the pdsDisplayName value.
The uwNetID value provides a default value if no other data source is present.
The availability of each of the name attributes is dependent on a variety of factors. For example, the affiliation of the UW NetID can limit what is possible, e.g. only students can have uwSWPName values. Whether the corresponding publish flag is set (uwEWPPublish and uwSWPPublish) restricts our ability to use the corresponding name value (uwEWPName and uwSWPName). If a UW NetID has not elected to have their information available in one of the information sets (Employee or Student), or the corresponding publish flag indicates we can’t use that data, then that corresponding data will be treated as not available.
The givenName attribute requires special handling. If the value based on data sources ends up with no value, that is overridden and asserted to be “-“. This special handling to required to address applications which assume a non-empty givenName value.
Preferred Data Source For Each Name Attribute
The following list shows the preferred data sources if “available” in order, from most preferred (on the left) to least preferred (on the right):
- givenName <- uwDisplayNameOverride, uwPersonPreferredFirst, uwEWPName, uwSWPName
- sn <- uwDisplayNameOverride, uwPersonPreferredSurname, uwEWPName, uwSWPName, pdsDisplayName, uwNetID
- initials <- uwDisplayNameOverride, uwPersonPreferredMiddle, uwEWPName, uwSWPName
- displayName <- uwDisplayNameOverride, constructedPreferredName, uwEWPName, uwSWPName, pdsDisplayName, uwNetID
So for example, the sn attribute will use the uwDisplayNameOverride source if available, if not, then it’ll use the uwPersonPreferredSurname if available, if not, then it’ll use the uwEWPName or uwSWPName source if available, if not, then it’ll use the pdsDisplayName source if available, if not, then it’ll use the uwNetID source.
Note that it is possible that givenName and initials are not set at all because there are no available data sources. Also note that sn and displayName are always set because there is always a uwNetID value. If the givenName value ends up with no value, that is overridden and asserted to be “-“. This special handling to required to address applications which assume a non-empty givenName value.
Additional Processing for uwPersonPreferredFirst, uwPersonPreferredMiddle, uwPersonPreferredSurname
Because the uwPersonPreferredMiddle is mapped to the Active Directory (AD) initials value, and the AD initials value has a maximum character length of *1*, we must truncate it to a single character.
When using this data source, we must pull together these 3 separate data fields into a single displayName value. We do so via processing equivalent to:
- uwPersonPreferredFirst + ” ” + uwPersonPreferredMiddle (truncated to a single character) + ” ” + uwPersonPreferredSurname
where if the uwPersonPreferredMiddle element is empty, then this becomes:
- uwPersonPreferredFirst + ” ” + uwPersonPreferredSurname
If you want an outcome where your full middle name (or more than a single character) is present in your displayName, then you need to change how you enter the data into identity.uw.edu. For that desired outcome, enter your middle name into the first name field in identity.uw.edu.
For example, let’s say you want a Microsoft displayName of “Joe Bob Smith”. Enter the following in identity.uw.edu for that outcome:
First Name: Joe Bob
Middle Name:
Last Name: Smith
The same is true for any additional prefixes, suffixes, or additional family names. Enter them into the First Name or Last Name field in the right order along with your actual values in identity.uw.edu and they will be present in the resulting Microsoft displayName. Just don’t expect anything but the first character in the identity.uw.edu Middle Name field to survive in the resulting Microsoft displayName.
Additional Processing For uwEWPName and uwSWPName
For the uwEWPName and uwSWPName sources some processing is required to determine what name values are used. This processing is equivalent to:
- A value is taken from the data source
- The value is parsed. That value could be formatted as either:
(a) “Last Name, First Name Middle Name” or
(b) “First Name Middle Name Last Name”.
If a comma is present, then the first form (a) is assumed. Otherwise the second form (b) is assumed. The surname is then extracted from the value using the form already determined. This may result in incorrect values for surname if the surname is composed of multiple parts separated by spaces. To mitigate this, if the second form is encountered, the last part of the name is compared to the uwRegisteredSurname and if they match (case insensitive) then that portion of the name is deemed the sn. After parsing the sn value, the remaining portion of the name is parsed for givenName and initials. The first portion of the remainder is assumed to be the givenName, and the first character of the remainder is assumed to be the middle initial. - The displayName will be set as givenName + “ “ + (initials + “. ”) + sn, where empty values of any of those are dropped and the corresponding spaces if necessary.
Note that multipart first names (e.g. Mary Anne) will be parsed incorrectly under this scheme. Also note that additional unexpected text can cause incorrect parsing (e.g. Joe Johnson Jr.).
The givenName attribute requires special handling. If the value based on data sources ends up with no value, that is overridden and asserted to be “-“. This special handling to required to address applications which assume a non-empty givenName value.
Additional Processing for pdsDisplayName
For the pdsDisplayName source, when the UW NetID type is non-personal, the processing is equivalent to:
- The value is taken from the data source
- If there is a space in the value, the last word becomes the sn
- The value is the displayName
The givenName attribute requires special handling. If the value based on data sources ends up with no value, that is overridden and asserted to be “-“. This special handling to required to address applications which assume a non-empty givenName value.
Additional Processing for uwDisplayNameOverride
For the uwDisplayNameOverride source, the processing is equivalent to:
- A value is taken from the data source
- The value is the displayName
- If there is a uwRegisteredSurname value and it matches (case insensitive) a substring in the Name value, then that substring is the sn. Otherwise, the last word in the value is the sn.
- If there are two or more words in the value, then the first word is the givenName.
- If there are three or more words in the value, then the first character of the second word is the initials.
The givenName attribute requires special handling. If the value based on data sources ends up with no value, that is overridden and asserted to be “-“. This special handling to required to address applications which assume a non-empty givenName value.
A Word About Microsoft Infrastructure Identity Name Design
The approach to name data at the UW is complicated because there are many different user populations with many different data sources behind each identity population. And of course, each of those data sources has different methods to make changes to the data. This means that any given application (and infrastructure like ours), must make a number of decisions about which name data to use. This means that applications are left making complex decisions about which name data to use, which can be especially complicated when a given identity has multiple affiliations. In contrast, the Preferred Name data source is unique in that it is a single central authority for name data for UW identities, and provides a self-service mechanism to effect changes.
Because of this complex background, Microsoft Infrastructure has always documented the algorithm behind our naming logic, so everyone can understand what we are doing and how they might change what they see. Until the Preferred Name data source emerged (and we adopted it), there were a number of scenarios where there was literally nothing you could do to change the display name on an identity. Fortunately, that is no longer the case.
You’ll note that we’ve preferred data sources where the user has the ability to directly change the value. You’ll also note that we’ve chosen to “normalize” naming data which has poor input validation so there is consistency in the resulting values.
There are differing opinions about these choices, but the fact remains that given the history of naming data here at the UW, there are poor options. We must balance privacy and disparate data sources, and correct for consistency.
Fortunately, with the emergence of the Preferred Name data source, the problems left are:
- There is no syntax or formatting enforcement for many of the data sources, which means we must make best guesses on how to correctly parse data that can be formatted an infinite number of ways. Fortunately, this issue is somewhat mitigated by Preferred Name.