Before a Birthright Email account can be created, there must be an initialized AD and Azure AD user object and an Email alias must have been reserved. Five years ago when the code was being written, none of the prerequisites could be assumed. Therefore, the processing starts at the beginning (“Has this identity been assigned a Netid?”) and checks each prerequisite in logical order. When every requirement is met, the account is created. If something has not yet been done, it skips the identity until next time.
Yale has other requirements, and many things that were originally just a prerequisite for Email are now required for other systems. Over time, most of this preprocessing is now done by other systems:
The Netid and Email Alias are now created by Java code in the Identity Management IIQ. In both cases uniqueness of the identifier is guaranteed by a unique key constraint on the database table, with a retry for another identifier if an error indicates a duplicate value.
There is a rule that an O365 account cannot be created until the Azure AD User is assigned a region (of the world) in which to create the mailbox. The Windows AD Connector was changed to set the region of all users to “US” when the Azure AD User object is first created from the Local AD object.
O365 Licenses are now assigned by “group-based provisioning” managed by Grouper.
The Email Provisioning IIQ creates identities from a view on the IDRIdentities. Originally that view only included affiliations entitled to Birthright mail (STUDENT, FACULTY, STAFF, and EMPLOYEE). However, when the AD Daily Updater was replaced it became necessary to change the view to include the other affiliations (MEMBER and AFFILIATE) that are associated with a source of identity and might have a mail account. So currently there is already an Identity object in that IIQ instance for everyone who might request one of these special mail accounts.
So while there might have been a lot of work to do when the original Birthright code was written, today all the requirements are met and we already have all the data we need.
We must add some column to some Staging Database table to indicate users with a pending new request.
Assumption: If a user already has a personal email account (a non-reserved Primary Email Alias) then we do no processing.
Assumption: The a user already has a Remote Mailbox (in local AD) then we will set the Reserved Primary Email Alias to indicate an O365 account but otherwise do no more processing. This may be a deprovisioned user, but reversing a deprovisioning operation is a manual step now for current Birthright users (like employees) and these new users will be handled in the same way.
Assumption: These new requests will get an O365 mailbox. It is yet to be determined if a no-Mail Eliapps account will be created or nothing will be done in Eliapps.
Assumption: Grouper will be changed to put these users in a group that will receive the right type of O365 License.
IIQ will do the following things:
Enable-RemoteMailbox which updates the Local AD and Azure AD object, sets the UPN, mail, MailNickName, and some ProxyAddresses values in Azure.
Change the reserved Email Alias to have a Mailbox of netid@connect.yale.edu and an EmailTo of aliasname@yale.edu which in turn will set the Email Address in IDR and the directories.
The UnDead
Having said this, it is now necessary to look at the consequences of our broken Identity lifecycle.
Birthright Email processing was written to assign mail to new users. It works flawlessly for new identities with new Netids and no prior AD or Google entries.
However, if someone loses their active affiliation and their Source of Identity, then IIQ regards them as deleted and removes them from its database. Should they return with a new source of Identity and become eligible for an Email account, they go through Birthright processing because they are a new IIQ identity. During the processing, IIQ may encounter an existing RemoteMailbox on the AD User object or an existing Google G Suite User object for the Netid.
Failing to create an account because one already exists is not an error. The user is supposed to have mail and ends up with mail, even if it is an old account. There are several possible results:
Even though the user lost affiliation, the old Email account may have remained active and the Email Alias still points to it. If that is true, then a new Identity object created from a new affiliation/SOI will already appear to have mail and will not enter Birthright processing.
If there is no active Email Alias (with a Mailbox pointer), then Birthright begins processing. It decides if the user should get O365 or Eliapps based on the current affiliation before it looks for old accounts.
Currently: If the new affiliation is STUDENT and the user would get Eliapps mail, then IIQ will try to provision that configuration. It will do nothing to O365 and try to create a new mail-enabled Eliapps account, which will fail if there was an old Eliapps account. It will then set the Email Alias Mailbox to Eliapps. However, since Exchange Online now handles all “@yale.edu” incoming mail, it will look first for an O365 mailbox on the AD User object, and if it finds one (which we did not see because we did not look for it) Exchange will try to deliver the mail to it (without regard for the Alias Mailbox value). This user may now be broken and may need to be fixed by the Help Desk.
If the user should have O365 mail based on the current affiliation, then IIQ will try to be an Enable-RemoteMailbox. This will fail if the AD User object already has an O365 account. It will then set the Email Alias Mailbox to point to O365. Exchange Online will now deliver mail to the O365 mailbox.
If the user was deprovisioned, however, other changes will have been made to the account that block mail delivery. These setting have to be manually cleared with a script. To address this a report is generated each morning at 8:30 listing the users who were processed for Birthright Email. The report include a flag set when someone is deprovisioned. I read the report each day and run a Powershell script on anyone it identifies as previously deprovisioned.
The new behavior of IIQ when a request is made to assign mail to an SI will be exactly the same as its current behavior should the same person have entered Birthright processing as an employee (except that we may decide not to try and create a NoMail Eliapps account for an SI).
Changes
The 5:30 AM Sequential Task
This job aggregates IDRIdentitiesView, the LocalAD, and the Email aliases in StagingDB. MEMBER and AFFILIATE identities are already being read and Identities are created for them.
After the aggregations, a “refresh task” calls the “Netid” Role Selector Rule. Currently this rule ignores MEMBER and AFFILIATE identities, but this will be changed to look for the flag indicating approved special mail processing for identities with these affiliations.
Most of the processing originally done by this task is now done in the other IIQ or Azure AD directory synchonization. There are a few flags that need to be set. However, this task still runs for regular Birthright Email and it is not intended to change this for the new category of users.
The 7:30 AM Sequential Task
This is the code that actually creates the Email account. It runs two hours after the first job, originally to allow time for changes to the AD to be synchronized out to Azure AD.
While it is true that most preprocessing, delay, and synchronization is now unnecessary and almost all users will be set up to receive their Email after the midnight processing, it would a bad programming practice to assume that the person who approves a request will not wake up at 4AM and decide for some reason to make an approval. The existing code made no assumptions that new HR or Banner users would not show up in the middle of the night, and that design will also work for SIs who appear in the middle of the morning processing.
While the 5:30AM job has Java code to decide who gets processed, this second job is controlled by an IIQ Population (users who match a configured Identity query). The test for Population membership includes fields set by the earlier job, so you have to have been processed by the first job to be looked at by the second job. If we have changed the first job to begin processing new types of users, that may automatically put them in the Population during the later job.
There is code to double check all prerequisites. Early morning is a window for system changes, so we do not assume that other systems (like Azure AD Synchronization) are actually running on their normal schedule. If a requirement is not met, then the identity waits for the next run, which may be tomorrow.
The EmailTypeRoleSelector Rule gives O365 mail to anyone who is not a STUDENT or is a STUDENT in one of the School Codes that get O365 mail. MEMBER and AFFILIATE identities are not STUDENT and therefore get O365.
O365 Licenses (with or without mail) are assigned by Grouper and Group Based Licensing. This may happen before or after this code runs. This code no longer assigns any licenses. It does two things:
Enable-RemoteMailbox for anyone entitled to O365 Mail.
Create an Eliapps account (Mail or NoMail).
Although the requirement is described as “giving mail to an SI or Affiliate”, the existing code also gives a no-Mail account on the other system (O365 or Eliapps). The code would have to be changed if this new class of users is not supposed to also get a no-Mail account in the other system.
Grouper
For this to work, these new users also have to be put in a Group that will get the appropriate O365 licenses. Today this is done by Grouper. IIQ could do it, but we have decided to assign this function exclusively to Grouper.