Content Comparison

...

1. The AD Daily Updater, a Java program driven by the Oracle ACS1 database, which populated a select set of "biographical" fields (firstname, lastname, job title) in the AD for non-private people. None of these fields were are important from a systems system point of view, except for UPN which is an identifier to login to services.
2. The Mail Relay configuration, which maps Email Aliases (ending in "@yale.edu") to the native email addresses of Yale systems. Originally this meant "Netid@connect.yale.edu" for Exchange accounts and "Netid@pantheon.yale.edu" for IMAP. Current Exchange has moved to O365 and IMAP has been replaced by Eliapps.
3. The Exchange mail routing fields in AD (MailNickName and ProxyAddresses). When mail was sent to Exchange, it delivered mail addressed to various Email Aliases using data stored in two fields of the AD. A separate Exchange field management function in the AD Daily Updater maintained these two Exchange Mail Routing fields.

This new project continues to support the biographical fields of AD, but now gets the data from IIQ. It updates the logic of function 3) to reflect differences between the original on premise Exchange and the O365 Azure AD requirements, and merges the function 2) code in by populating the MailNickname, ProxyAddresses, and now Target Address field of an AD object for Eliapps and legacy departmental Email Aliases.

We have to plan ahead for expected changes that do not currently have a schedule:

• The on premise Exchange system serves no useful purpose. It should be decommissioned. This would involve removing certain Exchange related fields from the on premise AD (fields that begin with the "msExch" prefix. The old AD Daily Updater code depends on these fields, but the new replacement code will be written to work if they are null. The one exception is that Private users are excluded from the Outlook directory with two of these fields and that function still needs to be supported.
• The Mail Relay machines will at some point be decommissioned and the Exchanged Online function in the Azure Cloud will take over routing all mail addressed to an "@yale.edu" Alias. Since Excahnge Online is configured by Azure AD in essentially the same way that on premise Exchange was configured by on premise AD, we have to add AD Email Aliases to the ProxyAddresses list and the native Email address (MAILBOX) of the aliases to the TargetAddress field for existing User objects or new Contact objects to be created for the purpose.

Currently mail addressed to an "ALIAS_NAME@yale.edu" Email address goes to the Mail Relay machines. They look up the ALIAS_NAME in configuration data and generate a native Email address that in practice sends the mail to O365 or Eliapps (although there are a few legacy entries that may go to deparmental standalone mail servers). If a Primary Email Alias points to a native Email Address ending in "@bulldogs.yale.edu" then the mail goes to Eliapps.

However, when the Mail Relays go away and are replaced by Exchange Online, then what was once a two tiered processing becomes a single step, and Exchange gets first dibs on the mail. Because Exchange Online puts its configuration data in the Azure/Local AD, some rules about the way AD has to work can conflict with specific settings in the Email Alias table. Fortunately, the current configurations that will become invalid are also in violation of Yale policy. This will not, however, avoid the requirement to communicate the change to affected users.

There are a set of Yale and Exchange rules:

• It is a Yale rule that the Primary Email Alias (first.last@yale.edu) also be the UserPrincipalName and its prefix is the MailNickName (first.last). We could have used Netid instead of Primary AliasName, but we didn't.
• It is an Exchange Online rule that the UPN has to be in the ProxyAddress list of the User object (that is, the UPN has to be a deliverable mail address to anyone with an O365 mail account).
• It is an Exchange Online rule that the same Email address cannot be in two ProxyAddress lists of two Azure AD objects.

When you combine the rules, no Netid can have a Primary Email Alias that points to Eliapps if they also have an O365 account. It has been Yale policy that ordinary users must have one or the other, O365 or Eliapps, but not both. This has been relaxed for special users, but there the policy remained that if a user had both types of mail, the O365 account should be Primary and the Eliapps account should be Secondary. It was previously possible to break the rule, because the Mail Relays allows the Primary Alias to point to either system. Exchange Online requires the Primary Alias to effectively point to O365 for any user who has an O365 mail account, and that will happen no matter what the Email Alias table says. Fortunately, only a small number of users are this far out of Yale policy compliance. Unfortunately, they generally had to be important people to get the exception in the first place.

It will not be possible to exactly match the accidental quirks of current two tier mail routing. However, a person can continue to own both an O365 and Eliapps mail account and can continue to route mail addressed to his Primary Email address to the Eliapps account. You can even retain your Email address in Yale directories. However, to do this you need to create a Dependent Netid to own your O365 mailbox, and then someone has to swap your current AD User object (that is connected to your mailbox) for the Dependent Netid User object renaming the CN and SAMAccountName that connect the User object to the Netids. We may do this for a handful of important people, but that is all.

Except for the problem described above, every current Email Alias entry should be routed through Exchange Online to the same destination that the current Email Alias table configures and the current Mail Relays implement. This is accomplished by one of four AD configurations:

1. If you have a Primary O365 mail account, your AD User object on premise and in Azure AD should be unchanged. Some minor adjustments to unimportant fields may be made in anticipation of the decommissioning of the on premise Exchange.
2. If you have a Primary Eliapps account, then your AD User object will be configured so there is a ProxyAddresses entry for every Email Alias that points to that Eliapps account, and a TargetAddress that holds the native "@bulldogs.yale.edu" address of the account in the Google G Suite cloud.
3. If you have both a Primary O365 account and a Secondary Eliapps account, then a new AD Contact object will be created with the Eliapps routing information. The AD User object will continue to have its current data. The Contact object will have the same ProxyAddresses and TargetAddress data that would be configured in the User object had this Secondary account been Primary.
4. Any additional entries in the Email Alias table will generate Contact objects, where the TargetAddress will be the MAILBOX value of the Alias table and the ProxyAddresses list will be the ALIAS_NAME values that share that MAILBOX value.

A given user can own special Alias entries, and therefore can have any number of Contacts generated by option 4 in addition to a User object and perhaps a special Contact object under one of the three options from 1 to 3. An O365 mail user can add a Secondary Eliapps account and go from option 1 to option 3, or drop an Eliapps account and go from 3 to 1. In the special case where someone with both an O365 and an Eliapps account decides to drop the O365 account and promotes Eliapps from Secondary to Primary, then option 3 changes to option 2, but this requires special handling to make sure the AD User object is first cleared of all data from the deleted O365 account before the routing fields can be moved from the Contact to the User object (and the Contact can be deleted).

Some cleanup of the Email Alias table will be required. For example, it has been a convention of the AD Daily Updater to create ProxyAddresses entries for both "Netid@connect.yale.edu" and "AliasName@connect.yale.edu". In a few cases there are Email Alias table entries for two aliases owned by the same person where one MAILBOX points to "Netid@connect" and the other mailbox points to "AliasName@connect". All the MAILBOX values for "AliasName@connect.yale.edu" must be corrected so the aliases can be collected and correlated to the Netid.

The Mail Relay configuration data was just a table that translated every Email Alias address ("@yale.edu") to a native address ("Netid@connect.yale.edu" for Exchange, "AccountName@bulldogs.yale.edu" for Eliapps). The AD Updater had to take the same data but assign Exchange users to an AD User object. You might think that this assignment would be done using the NETID column (the owner of the alias) but a few Netids directly own Aliases that point to Dependent Netids (including group accounts) where the mailbox is actually under a different AD User object. So the only reliable way of correlating Email Alias data to IIQ Identities (and AD User objects) is to group aliases that have the same MAILBOX value and look for the Netid as the value in front of the suffix "@connect.yale.edu". Mailboxes with other suffixes are Eliapps or legacy aliases, and for them the Netid that owns the Alias is information, but the correlation rule is more complicated and will be described later.

If an alias has a MAILBOX column that ends in "@connect.yale.edu" but where the part in front of the "@" does not match any Netid, then it is an Exchange resource of some sort. Exchange Online automatically knows about its own internally configured non-Identity resources (meeting rooms, distribution lists, etc.) and it will automatically route mail that has the address of a native resource without any additional configuration. There is some code to configure such resources in the Mail Relays, but when they are replaced by Exchange Online we can simply ignore them. IIQ does not need to create Identity objects for these Exchange resources (at least not at this time).

Every active Netid generates a Local AD User object. Every Local AD User object generates an Azure AD object within the next hour through the Azure AD Connector synchronization process. However, while the Netid value is important in the Local AD ( it is the first CN=Netid element in the Distinguished Name, and the legacy login ID (the SAMAccountName), and then if it got an Exchange mailbox it also added a "Netid@connect.yale.edu" entry to the ProxyAddresses list.

However, while the Local AD User object and Azure AD User object are connected by UUIDs, the Netid is not actually a direct field in Azure. There is no DN, no SAMAccountName, and not everyone has a mail account. For sanity and to ensure correct management of mail, there will be at most one "Netid@connect.yale.edu" entry in the ProxyAddresses list of an Azure AD User object, and if it exists it will have the Netid in the Local AD user object connected by UUID to that Azure AD object. For this to work, there can be only one "Netid@connect.yale.edu" entry in the ProxyAddresses list of the Local AD object, and it must be attached to the User object whose CN and SAMAccountName have the matching Netid.

Non O365 mail account routing information can be configured in either a User or Contact object. That is determined by Yale policy. The handling of objects with O365 mail accounts is determined by Microsoft system restrictions.

...

1. , but AD information is displayed in the Outlook mail client.
2. A separate function embedded in the AD Daily Updater Java jar file that enforces a standard set of Exchange mail routing fields in AD (MailNickName and ProxyAddresses). This is a subset of the Mail Relay data currently affecting only O365 mail accounts, but while the Mail Relays answer the question "What Mailbox does this Mail Alias point to", the Exchange Mail Routing is provisioned with the equivalent reverse answer "What Aliases are delivered to this Mailbox".

To accomplish this

1. This project will provision the same biographical fields with the same data, only it will source this data from the new IDR instead of the old Oracle ACS1 database. We use this opportunity to alter certain business practices, such as excluding certain fields for SOM users from central administration.
2. This project will also create the same mail routing fields for current O365 users in the Local AD, although the current code was originally designed for On Premise Exchange and certain obsolete features will not be duplicated.

The purpose of this code is to provision fields in the Azure AD. That is where Outlook goes to look for O365 accounts and directories. That is where Exchange Online goes to deliver mail to mailboxes or forward mail to Eliapps. However, because we run a Local AD and an Azure AD synchronized to each other, the current AD Daily Updater and this replacement code populate data only in the Local AD and the expect it to be copied thorough the Azure AD Connector synchronization tool within the next half hour.  Except for an additional feature added to this new code (to directly change the UserPrincipalName in Azure AD if it is incorrect), the specification of this project is to change the Local AD and except for enumerated differences, to put the same data in Local AD that the existing Java code put there. There is no need for an Azure AD to develop the code or test correct function. 

When this project goes live, it will begin to provide features that the old AD Updater did not have, in preparation for changes that are anticipated but do not currently have a target date.

• We currently have an On Premise Exchange system that serves no business purpose, but exists to not disturb incidental behavior required by various tools, including the old AD Updater. For example, the old Updater did not believe you were an Exchange user unless the msExchVersion field in the Local AD was set to a non-null value. That field was populated by On Premise Exchange when it creates a "RemoteMailbox". This project will not look at that field in AD, but believes that you are an O365 user if you have an Email Alias to an O365 account.
• The old AD Updater created Mail Routing fields in AD only for Exchange mail users. The new code creates the same fields for Exchange mail users, but also creates the same fields in other User or Contact objects for Eliapps users. This new data will be required when the Mail Relay system is retired.
• The "Email Alias System" refers to database logic in the Oracle ACS1 table, but in the future we may move this to SQL Server, so the new code will minimize dependencies on Oracle specific features.

The Email Alias and Mail Relay system implements a "goes to" methodology looking up email addresses and selecting a target mail system for that address. Every Alias has a row in the table, and aliases to the same Inbox are represented by multiple rows with the same destination MAILBOX value. The Exchange Online system depends on AD maintaining a "comes from" list, where the AD User object associated with the Inbox has a list of email addresses that get delivered to the mailbox.

For example the current system is based on a table that says:

"john.doe@yale.edu" goes to the mail account for AD User jd234
"jack.doe@yale.edu" goes to the mail account for AD User jd234
"jane.doe@yale.edu" goes to the mail account for AD User jd235

While the Exchange model is:

The AD User object jd234 has a list with "john.doe@yale.edu" and "jack.doe@yale.edu" as names for the mail account.
The AD User object jd235 has a list with just "jane.doe@yale.edu".

This is an over simplification because Exchange also forces us to add several built in required email names on top of the email address published for each user, but the important concept is that the Mail Relay and Exchange models express the same information from two opposite directions. This would not be a problem, except that over time the rules have not been followed and the data in the tables is not clean.

There is also a compatibility issue because the Mail Relays treat O365 and Eliapps equally, while Exchange will deliver mail to the O365 Inbox if at all possible. When information about the Email Aliases is ambiguous, the is mail that the Mail Relays will reliably send to Eliapps but that Exchange will instead send to O365 for a user who has both types of accounts. This is not, however, an issue for the AD Updater replacement project but will have to be addressed later on with the follow on "Mail Relay replacement" project. 

There are a set of Yale and Exchange rules. We can't change the Microsoft rules, and we are not prepared to change Yale rules established long ago. Enumerating the rules explains exactly how and why certain mail routing will change.

• It is an AD rule that every User must have a unique UserPrincipalName. The UPN can be used to login to Windows and must be used to login to Azure.
• It is a Yale rule that for Users with a mail account, the Primary Email Alias (first.last@yale.edu) is also the UserPrincipalName. The ALIAS_NAME (before the "@") is the MailNickName (first.last). For Users marked Private the ALIAS_NAME is the Netid, and for old accounts after the date where they are supposed to be deleted, the ALIAS_NAME is also set to Netid to free the first.last for new people who happen to have the same name.
• It is an Exchange Online rule that for Users with an O365 mail account, the UPN has to be a deliverable Email address to that account. With Mail Relays, the UPN can point to either O365 or Eliapps, but if Exchange Online does all the mail routing, any mail addressed to the Primary Email Alias (which is also the UPN) will go to O365 if there is an O365 mailbox even though the Email Alias table points the Primary Email Alias to an Eliapps account.
• It is an Exchange Online rule that the same Email address cannot be in two ProxyAddress lists of two Azure AD objects. So if we create a Contact object for the Eliapps account, we cannot add the Primary Email Alias to it, and if that is the only alias that points to the account, we cannot meaningfully create the Contact in the first place.

Yale policy is to give users either O365 or Eliapps mail but not both, but exceptions are allowed. Yale policy is that when a user has both O365 and Eliapps mail, the O365 account is Primary. So if we followed our own rules there would be no problem. Unfortunately, either because accounts were "grandfathered" in from previous systems or because someone important asked for an exception, there are about 5 cases where the Primary Email Alias points to Eliapps and there is a secondary alias pointing to an existing O365 account. We will have to remediate these users.

This is not an AD Updater problem. It is a Mail System restriction that we cannot program around and will be ignored by the coding. We will do what we can do. There are ways to change the Email Aliases with Dependent Netids that can work around the problem, but that again is an Email System trick and not part of this project. However, understanding how mail delivery is done and how it changes is important to understanding the design, and this particular glitch is a useful example to motivate a description of the environment to which this code must be designed.

The big design feature that derives from this explanation, is that when the Alias table is read in by IIQ (is "aggregated" in IIQ terms) it is presented as one of four different configurations of object data by a database view that coverts the flat raw table into a usable set of database "rows" (which become program objects):

1. Unchanged User object - Netids with Primary O365 accounts and no Eliapps account (most employees, including faculty). All the Aliases to the O365 account are grouped and presented as an object keyed by the MAILBOX ("Netid@connect.yale.edu"). By extracting the Netid from the MAILBOX name, IIQ correlates this to an Identity and therefore an AD User object. All the ALIAS_NAMES for that MAILBOX become ProxyAddresses. This should produce the exact same result (except for the order of the aliases in the list) as the current AD Daily Updater, so we expect no change to the AD for this type of account.
2. User object with Eliapps routing - Netids with a Primary Eliapps account and no O365 Mail (although non-mail O365 licenses). Adopting the exact same logic as the previous case, except that the MAILBOX is now (AliasName@bulldogs.yale.edu), this populates the ProxyAddresses list with aliases to the Eliapps account, and sets the TargetAddress to the MAILBOX value. Initially this does nothing, but when the Mail Relays are decommissioned, it routes Eliapps mail to Google. Because Netid is not in the MAILBOX, the Netid field in the Alias Table has to be used to find the right Identity to which this data should be attached.
3. Unchanged User object and Contact with Eliapps Routing - Users with a Primary O365 account and a Secondary Eliapps account. The O365 alias data will generate the same data as in Case 1 above. The Eliapps aliases will generate a second row with the Case 2 data, but because it is a secondary Email account, IIQ has to create a second Contact object in AD to hold the Eliapps data since the User object is busy holding the O365 data.
4. Routing "Junk" Contact objects - Entries in the Email Alias table that were not processed to generate a ProxyAddress in one of the previous three steps are grouped by unique MAILBOX value. Each MAILBOX value creates a "junk" Contact whose ProxyAddresses are the list of ALIAS_NAMEs that had that MAILBOX value. Note that this method of collection may combine Aliases owned by different Netids if they point to the same MAILBOX, but this is OK.

There is a fifth category of unprocessed aliases. Any Alias with a MAILBOX of "xxxx@connect.yale.edu" where the prefix xxxx is not a Netid must be a resource (a room, distribution list, etc.) and will not be processed. Exchange Online knows these things and handles them natively, so we don't have to create objects to inform Exchange about its own native stuff.

Any user can have Junk, so while each mail user Netid is either Case 1, 2, or 3, they can also have any number of Type 4 entries. Type 4 is grouped by MAILBOX and correlated to a Contact identified by the MAILBOX. It is not connected in any way to the Netid that owns the Alias. The junk aliases are spread across mailman, elilists, panlists, cs, som, aya, invest, med, physics, chem, geology, cmp, math, astro (all .yale.edu). Some of this is junkobsolete, but cleaning it up is a different project and some of it is not junk and has to be managed by Foreign Mail Aliases (described below).

There are existing Contacts created in AD to make specific Eliapps users visible to Outlook. These "non-routing" Contacts have a Mail attribute and not much else. When we create Routing Contacts (with a targetAddress, MailNickName, and proxyAddresses list) we may duplicate information. We need to decide if we are going to try to identify duplicates and delete old Contacts, and whether routing Contacts and Foreign Contacts we create are going to be put in different OUs and are these old Legacy Contacts going to be moved to yet another OU.

Assumptions

IIQ will be at 7.2p2 or later.

The DEV AD (yale.org) does not work and may be used for a different project (NGN). We will develop and unit test this code in a desktop VM Sandbox environment. However, we may use the yaleorg.onmicrosoft.com Azure AD.

Assignment of Functions to Instances

The update of biographical fields (firstname, lastname) will occur in the Identity Management instance of IIQ and will be driven by changes to Identity variables. The update of mail routing fields will be done in the Email Provisioning instance of IIQ.

The two instances have a common set of Identity Variable names. In this application a common unit of code may run in both applications and set the same Identity Variable name to the same value in both instance, but the variable will be used in one instance and ignored in the other.

The UPN of the Azure AD object should be updated if it gets set to the wrong value. Although this could be regarded as a biographical field (the LocalAD UPN is), AzureAD is currently not an Application in the Identity Management space and there is no reason to add it. So Azure UPN is regarded as a honorary Email Routing field and will be provisioned from the Email Provisioning instance.

Identity Management Instance

Additional Applications (data sources) required:

• LocalAD Users (copy existing application from Email Provisioning instance)

Email Provisioning Instance

Additional Applications (data sources) required:

• Dependent Netids (copy existing application from Identity Management instance)
• Full Email Alias view (there is an existing Application named Email but it only aggregates Primary Aliases)
• Local AD Contacts (provisioned, may become a source of identities)

Provisioning Strategy (Biographical data)

As is currently done in Email Provisioning, Identity Management will have a Role with an Entitlement to membership in the Provisioned Users group of LocalAD. Assigning an Identity to the Role will create a new AD User object for that Netid if one does not already exist. The User object is initially created with minimal information, and is then filled in with the full set of biographical data in the next cycle.

This application adds a set of Identity Variables named ADXXXX (example: ADgivenName) are filled in by a Rule run after an Identity Refresh task. Normally Identity Variables are filled in after new data is read in from a source system, but the ADXXXX variables are assigned values from other Identity Variables that were themselves populated from source systems. For example, your Job Title comes in from Workday Worker and is used to populate a previously configured Identity Variable which then used the raw title for various Yale systems. However, the ADtitle variable is constrained to be a maximum of 128 characters because that is the maximum field length in AD. So at Yale there are currently 51 people with longer Job Titles in Workday Worker and other Yale systems, but we truncate that to 128 when we create the ADtitle variable that provisions the Title property in AD.

There are also restrictions due to Privacy rules for certain people, and in a few cases there are multiple possible source fields for the same AD variable, and the RefreshRule will select the right source based on Affiliation and other attributes.

The Netid System is the source for Identities created for Dependent Netids. It does not have any biographical data, so the source fields are all null, and the ADXXXX variables are all null, and the AD gets no biographical information.

Biographical ADXXXX variables have a LocalAD Target field only in the Identity Management instance. These Identity Variables may be filled in by the RefreshRule running in the Email Provisioning instance of IIQ, but they will not provision AD User objects from that instance.

Provisioning Strategy (Email Routing fields)

The Email Routing ADXXXX variables are calculated from the Account generated by aggregating the Full Email Alias table, an application that is only defined in the Email Provisioning instance. They also only have Target definitions and only update the LocalAD in that instance. The same variables have neither a source nor a target in Identity Management.

Because ADProxyAddresses is a multivalued field, we want to avoid updating it if the only difference between the current value in AD and the calculated correct value from the Email Alias table is to list the same values in a different order.

Dependent Netids and Contacts can own or describe Email accounts, so they do have ADMailNickName, ADProxyAddresses, and ADTargetAddress fields that must be calculated and, if necessary, provisioned.

However, correlating the Email Alias data to the right Identity cannot be done on the fly in IIQ. We rely on a database view to present the data in the right order. So most of the work is done in the database, and a little work may be done in the correlation rule.

Unlike the previous AD Daily Updater Java program, IIQ will create AD User objects for Identities that need themfuture scope.

Users with an O365 or Eliapps account can delete it, and users with one type of account can get the other. So you can transition between Type 1 and 3, or 2 and 3. This is a delicate process because IIQ cannot directly move a field like ProxyAddresses from a User object to a Contact object in a single transaction (as would be possible with database SQL). This is, however, a manual process and becomes a function of the Mail System people. This code does not provide transition services but will provide documentation about how to make the transition correctly

Once you understand the four possible "packages" of mail routing data, the mechanism for gathering the data and passing it to IIQ is relatively simple. A SQL query of the Alias table (DIR_ONLINE_INFO) groups rows by MAILBOX. The AliasNames of the same MAILBOX are concatenated together in a string field. If the MAILBOX is "@connect.yale.edu" it is O365, if it is "@bulldogs.yale.edu" it is Eliapps, and if it is something else it is junk. The trick is then to create SQL clauses that flag primary accounts from secondary accounts, and distinguish Eliapps account that exist alone from Eliapps accounts belonging to someone who also has an O365 mailbox which have to be then assigned to a Contact. If we don't do this processing in SQL where it is easy, it becomes much more difficult in IIQ to know if an incoming Eliapps account record belongs to a Netid who also has an O365 record and therefore correlate it to or create a Contact Identity. If the SQL view has already done that analysis, IIQ can implement the correlation that the SQL has pre-processed.

The Alias table has bad data. We will remediate some problems and ignore issues that cause no problem for data delivery. The following list includes all the the things that need to be remediated, and some other interesting problems:

• There were 555 users with O365 accounts and MAILBOX values of "AliasName@connect.yale.edu". They are to be changed to the more standard "Netid@connect.yale.edu".
• There are Email Aliases to "Netid@connect.yale.edu" where the Netid User object does not appear to have an O365 mail account. Currently the Mail Relays forward mail to these addresses to Exchange Online, which bounces them because they have neither an O365 mail account nor a TargetAddress. This will continue to happen, although the new code will populate the MailNickName and ProxyAddresses field in Azure AD, whereas the old AD Daily Updater code would not populate these fields because the on premise AD did not have a RemoteMailbox indicator. We do not expect to continue to support the unnecessary on premise Exchange just to maintain the RemoteMailbox concept in the on premise AD. Although we have changed fields, the behavior where Exchange Online bounces the mail should be identical because the fields changed do not affect it.

We synchronize the on premise Local AD to the Azure AD. IIQ must provision changes to the Local AD and wait for the synchronization to occur within the next half hour. The only field in Azure AD that can be provisioned directly is UPN.

There are existing Contacts created in AD to make specific Eliapps users visible to Outlook. These Contacts tend to be in the Users container, they are named by the Primary Email Alias, they have "biographical" data, and they do not have anything in the three mail routing fields. The new Contacts we create will be in a special OU, will be named by the MAILBOX, will not have "biographical" fields, and they will have mail routing properties. A given Eliapps user may have one of each type of Contact, but this code only generates the Mail Routing Contact and ignores the other type.

Assignment of Functions to Instances

The update of biographical fields (firstname, lastname) will occur in the Identity Management instance of IIQ and will be driven by changes to Identity variables. The update of mail routing fields will be done in the Email Provisioning instance of IIQ.

For sanity, we try to ensure that both instances of IIQ share a common set of defined Identity Variables, but we do not guarantee that these Variables are actually populated with values in an instance that does not use that particular variable in any code. The two instances will source the variable value from different places, and they MUST in general partition the Target (Application and field) where values are provisioned. We do not want to get into even temporary chase conditions where one Instance sets a field to one value and the other instance sets it back to the previous value due to different schedules in the aggregation.

There is a UserPrincipalName in both Local AD and Azure AD. It is identical to the Primary Email Alias, and the rules constrain it to interact with Mail Routing (it must be in the ProxyAddresses list of an O365 User), but used as a UPN is it a string used to log you in and is therefore like the "biographical" fields. However, it is more closely tied to the other fields used by Mail Routing (it is sourced, for example, from the Alias table, and so we regard it as a Mail Routing field and provision it along with the real Mail Routing fields.

Identity Management Instance

Additional Applications (data sources) required:

• LocalAD Users (copy existing application from Email Provisioning instance)

Email Provisioning Instance

Additional Applications (data sources) required:

• Dependent Netids (copy existing application from Identity Management instance)
• Full Email Alias view (there is an existing Application named Email but it only aggregates Primary Aliases)
• Local AD Contacts (provisioned, may become a source of identities)

Provisioning Strategy (Biographical data)

As is currently done in Email Provisioning, Identity Management will have a Role with an Entitlement to membership in the Provisioned Users group of LocalAD. Assigning an Identity to the Role will create a new AD User object for that Netid if one does not already exist. The User object is initially created with minimal information, and is then filled in with the full set of biographical data in the next cycle.

This application adds a set of Identity Variables named ADXXXX (example: ADgivenName) are filled in by a Rule run after an Identity Refresh task. Normally Identity Variables are filled in after new data is read in from a source system, but the ADXXXX variables are assigned values from other Identity Variables that were themselves populated from source systems. For example, your Job Title comes in from Workday Worker and is used to populate a previously configured Identity Variable which then used the raw title for various Yale systems. However, the ADtitle variable is constrained to be a maximum of 128 characters because that is the maximum field length in AD. So at Yale there are currently 51 people with longer Job Titles in Workday Worker and other Yale systems, but we truncate that to 128 when we create the ADtitle variable that provisions the Title property in AD.

There are also restrictions due to Privacy rules for certain people, and in a few cases there are multiple possible source fields for the same AD variable, and the RefreshRule will select the right source based on Affiliation and other attributes.

The Netid System is the source for Identities created for Dependent Netids. It does not have any biographical data, so the source fields are all null, and the ADXXXX variables are all null, and the AD gets no biographical information.

Biographical ADXXXX variables have a LocalAD Target field only in the Identity Management instance. These Identity Variables may be filled in by the RefreshRule running in the Email Provisioning instance of IIQ, but they will not provision AD User objects from that instance.

Provisioning Strategy (Email Routing fields)

While the Email Alias table is usually viewed by the Netid of the alias owner, provisioning has to go into an AD object associated with the mail account (the MAILBOX value). So this code develops views that group aliases and produce one row for each MAILBOX value. In this approach, the O365 account for a Netid is the row with MAILBOX value "Netid@connect.yale.edu". Rows with a non-Netid before "@connect.yale.edu" a distribution lists, rooms, and other resources that are currently out of scope.

The Eliapps accounts do not have a Netid, so here there is a different rule. If a Netid owns a Primary Email alias pointing to an Eliapps account ("@bulldogs.yale.edu") and there are no other aliases pointing to a "Netid@connect.yale.edu" account, then this is a pure Eliapps user and the mail routing fields can go in the AD User object associated with the Primary Alias owner. Here we have a bit more freedom, because while routing for an O365 account MUST go into the AD User object to which the account is tied, an Eliapps account can be described by either an AD User or Contact object, and our decision here to use the otherwise unused User object is simply an optimization.

Therefore, any Eliapps account that fails the tests to put it in the User object will end up in a Contact, along with Departmental Eliapps accounts and Legacy "junk" alias to neither O365 or Eliapps.

The SQL converts the entries for all Aliases that point to the same mailbox to a string of AliasNames. By sorting the Primary Alias first (if it exists) and setting the first name to have an "SMTP:" prefix and the subsequent aliases to have an "smtp:" prefix, we satisfy the rule that every ProxyAddresses string must have one primary (capitalized) entry and it should be the Primary if one exists. By doing this work in the database, where sorting rows is easy, we avoid the problem of dealing with multiple account records from the same application, which IIQ can handle but which greatly complicates the coding.

There are three database views. One returns the O365 Netid mail routing data. A second returns the Primary Eliapps mail routing for non-O365 Users (which also goes in the User object). The last view returns routing data for Contact objects. The first two views provide the SAMAccountName of the User object to which the data should be attached, while the last returns only the MAILBOX and not a Netid, because Contacts are generated and managed relative to the MAILBOX name.

The MailNickName is used by Exchange Online to route mail, but we do not set it based on its routing properties. Rather, the MailNickName is by Yale Policy set to the Primary ALIAS_NAME, which is also the prefix (before "@yale.edu") of the UserPrincipalName. That policy effectively makes MailNickName a "biographical" field because it is set by biographical rules. However, because of Exchange algorithms, we only want to set MailNickName in the User objects of Email users. So while the value is calculated biographically, the biographical value is only copied to the ADMailNickName field if we have O365 or Eliapps-in-User-Object mail routing view data for that SAMAccountName.

Contact objects are created and deleted for the sole purpose of holding Mail Routing data. So the Application that reads from the Contact view is "authoritative", creating new Contact Identities when a new Contact MAILBOX value appears, and deleting Contacts that are no longer supported by any linked Account. However, User objects are already created by other processes, and since the User object must exist for an O365 account to exist, it makes no sense to create a User object for the purpose of putting in Mail Routing for an O365 account that cannot exist because there is no User object. So the application that feeds Mail Routing information (for both O365 and Eliapps) is not authoritative and waits for the User object to be created by the Identity Management IIQ instance before the data is linked to the Netid Identity object and the fields are provisioned. The difference between authoritative and non-authoritative behavior is the main reason for splitting the Email Routing data into two IIQ Applications.

So in summary:

Netid Identities are created by the existing Identity Management IIQ process from SOI or in Email Provisioning from IDR Identities.

In Identity Managment, the LCM "Joiner" workflow assigns a Netid and UPI to the identity, and a Role Assignment Rule grants the Identity an Entitlement that will cause the AD User object to be created. When the LocalAD is next aggregated, the AD User object is read in and linked to the Identity.

When the Email Provisioning IIQ instance creates the Identity when it gets a new Netid from IDRIdentities. At that point it can correlate the LocalAD User object and the MailRouting-In-UserObject account with a matching SAMAccountName.

It doesn't matter if the MailRouting data arrives before or after the LocalAD User object is aggregated. IIQ will wait until there is a LocalAD object before provisioing the ADXXX Identity Variables to their target properties.

Meanwhile, Contact Identities will be created based on the aggregation of the Contact Mail Routing Application. A Contact Identity automatically gets an Entitlement that creates the Contact Object in AD, and then the Mail Routing variables are synched in.

The view presents ProxyAddresses in an order, Primary Alias first, then Secondary Aliases in alphabetical order. We will test for and write code to prevent any unnecessary reprovisioning of the ProxyAddresses if the calculated and aggregated values contain the same values, but the "smtp:" values are in a different order (unless IIQ variable synchronziation already does this).

Mail Relay Replacement

Currently all mail with an address ending in "@yale.edu" is processed by the Mail Relay machines at Yale. They are configured (once an hour) from the data in the Mail Alias system, where is unique MailAliasName+"@yale.edu" is resolved to a native Mail system address (the Mailbox). If the Mailbox is "netid@connect.yale.edu" then this is an O365 address to be processed by Exchange Online. If it is "@bulldogs.yale.edu" then it is an Eliapps account to be processed by Google. In all other cases, the Mailbox address substitutes for the original "@yale.edu" and is processed through SMTP.

...

The "Mail" attribute in AD is not a technical field. It is the Email Address to be "published" in the directory. At Yale it is the PrimaryAliasName@yale.edu and that happens to be the O365 account of a two-mailbox user because we require O365 to be Primary if it exists.

...

Any personal O365 mail account

User Object

Primary Eliapps with no O365 mail

User Object

Primary O365 with Eliapps Secondary

...

Eliapps account of someone with an O365 mail account

Contact Object

Foreign Mail Alias

Contact Object

...