...
There are a set of Yale and Exchange rules:
- It is an AD rule that the UserPrincipalName must be unique.
- It is a Yale rule that for Users with a mail account, 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'tUsers marked "Private" and Users without mail get a UPN of "Netid@yale.edu". These are the only two possible values.
- It is an Exchange Online rule that the UPN has to be in the ProxyAddress list of the a Yale rule that everyone with an ITS mail account (O365 or Eliapps) must have a Mail Alias that points to that account. (Everyone with any Mail Alias is supposed to have a Primary Alias, but that rule has been broken and the data would have to be cleaned up to enforce it.)
- It is an Exchange Online rule that the UPN has to be in the ProxyAddress list of a mail 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 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 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:
- 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.
- 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.
- 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.
- 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.
There are 1800 is Primary. There are a small number of case where that is not true, but when you combined all the rules we will no longer be able to allow exceptions. Exchange Online will force the O365 account to be Primary even if the Email Alias table says that Eliapps is supposed to be Primary.
Except when one of these structural rules forces a change, the objective of this design is to deliver mail with the same Email address to the same mailbox it was delivered to with the old Updater and the old Mail Relays. That is, changes may be forced by structural differences but they will not happen by coding accidents.
It should generally be possible to accomplish exactly the same mail delivery for all addresses, but this may require a slightly complicated rearrangement of Aliases and the AD. For example, you can rename AD objects so that an O365 Mail account that previously belonged to a personal Netid now appears to belong to a dependent Netid, and point the old alias to it. This frees the personal Netid User object to point to Eliapps, while the O365 account, now on the dependent Netid, continues to get mail through all the old addresses. However, this is a very delicate operation and will not be done for any but the most important users.
Taking all of these requirements into consideration, data from the Alias table will be arranged by a database view to create one of four situations:
- Unchanged User object - Netids with Primary O365 accounts and no Eliapps account (most employees, including faculty). The Mail Routing fields are populated by entries in the Alias table that have a MAILBOX value of "Netid@connect.yale.edu" (the formal address of an O365 account).
- User object with Eliapps routing - Netids with a Primary Eliapps account and no O365 Mail (although non-mail O365 licenses) will have the mail routing data in the Alias Table turned into fields of the AD User object. The MAILBOX column value from the Primary Alias row is used to find the Secondary Aliases of the same account, and it also becomes the TargetAddress. The matching column values that share that MAILBOX will become ProxyAddresses.
- Unchanged User object and Contact with Eliapps Routing - Users with a Primary O365 account and a Secondary Eliapps account will find their User object unchanged, but a new Contact object will be created with the same TargetAddress and ProxyAddresses values described in the previous case, but now applied to the new Contact
- 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 1, 2, or 3, they can also have any number of Type 4 entries. Since Type 4 is grouped by MAILBOX and not owner, several Netids can share a Type 4.
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 is outside the scope of the current design.
There is bad data in the Alias table which will have to be cleaned up. For example, some O365 users have a MAILBOX value that is not "Netid@connect.yale.edu" and alternate names for that MAILBOX have to be changed to the proper value in order for the grouping to work correctly.
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 1800 Junk Email Aliases that do not resolve to O365 or Eliapps. They 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)future scope.
There are existing Contacts created in AD to make specific Eliapps users visible to Outlook. These "non-routing" Contacts have a Mail biographical (non routing) "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 instanceWe will not create or delete these objects, and we will attempt to make Routing Contact objects invisible to Outlook.
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
...