The purpose of this project is to replace the old AD Daily Updater with newer better code residing in an IIQ instance. However, the future plan to support Exchange Online routing of Email (Mail Relay Replacement) adds and additional set of requirements.
Issues
This project replaces
- The AD Daily Updater
...
- , a Java program driven by the Oracle ACS1 database, which populated a select set of "biographical" fields
...
Everything about this original design is now obsolete. We continue to have an on premise Exchange, but it has no local mailboxes because all mail accounts have moved to O365. Since there is no longer a reason to have on premise Exchange, we need to correct our processes so it is no longer needed and can be decomissioned. The IMAP system was shut down years ago and replaced by Google G Suite (branded "Eliapps").
AD Daily Updater continues to run, and it puts data into the on premise AD. A half hour later, the Azure AD Connector synchronizes those changes to the Azure AD. The values that were appropriate when we had a local Exchange are still valid in Azure AD, but that is because of good luck rather than any careful design.
The current plan is to replace AD Daily Updater Java program with code running in our IIQ identity management system. We will remove dependencies on legacy systems (so on premise Exchange is no longer needed) and prepare for future developments (to replace the Mail Relays with Exchange Online running in Azure). This involves merging what are now two separate functions.
...
- in the AD for non-private people. None of these fields were important from a systems point of view, except for UPN which is an identifier to login to services.
- 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.
- 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.
Both the current AD Daily Updater and the current Mail Relay configuration program get the same mail routing data from the Email Alias system (the SMART schema in ACS1, and in particular the SMART.DIR_ONLINE_INFO table). AD Daily Updater only uses the Exchange subset of the data, but this will change in the new code where the non-Exchange data will also be added to AD. The TargetAddress field is not used for Exchange mail accounts, but will point to the native email account address (the MAILBOX field of the Email Alias table) for non-Exchange AD objects.
...