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, but each of these have their own requirements. 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 item in logical order. When every requirement is met, the account is created.
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:
Originally the strategic way to coordinate identity services (to reserve a Netid or Email Alias or populate directory information) was to code the logic in Oracle stored procedures in ACS1. Birthright Email reused the existing logic that had previously performed these functions. However, HR was no longer using Oracle and ACS1 was being populated by Talend jobs just to maintain compatibility. Over time we are replacing old stored procedures with new code. Specifically, the logic to select a new Email Alias is now written in Java and runs in IIQ. This depends on Sources of Identity and IDR, which removes the prerequisite for an entry in the ACS1 People File.
The “Email Alias” (firstname.lastname) has become the primary identifier to authenticate through Azure whether you use Email or not. Since it is no longer conditioned on needing Email, it is now assigned when the Netid is also created in the Identity Management IIQ.
O365 licenses cannot be assigned until each Azure AD User is assigned a region in the world where data is to be stored. Originally Birthright processing was the only code that assigned licenses, so it had to store “US” as the region. We reconfigured the Azure AD Connector (“directory synchronization”) to set this value when the Azure User is created.
O365 Licenses are now assigned by “group-based provisioning” managed by Grouper.
Email Provisioning IIQ previously only aggregated IDRIdentities with affiliations granting them Birthright mail (STUDENT, FACULTY, STAFF, and EMPLOYEE). However, when the AD Daily Updater was replaced and the same IIQ also updated mail routing fields in AD, it was necessary to aggregate everyone with an active Source of Identity or an email account. So MEMBER and AFFILIATE identities are already in its database.
As a result, most of the changes that would have been required to assign mail accounts to non-Birthright users like Sponsored Identities and Academic Affiliates has already been performed, for other reasons. These identities have already been aggregated and all the important pre-processing has already been done.
All that is required is to select some field of a table in the Staging Database to indicate that a mail account should be generated for someone with one of the non-Birthright affiliations.
These users will get an O365 account. As a result, IIQ would 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.
Separately Grouper has to look at the same request flag to assign the user to a group that triggers the assignment of licenses.
The UnDead
Having said this, it is now necessary to look at the consequences of our broken Identity lifecycle.
Birthright Email was written to provide mail accounts to completely new users. It works flawlessly for anyone who gets a new AD User object that has no mail account connected to it, and any Netid that has no Eliapps account. If IAM deleted old mail when users left the university, it would work as designed.
However, we have discovered that people leave the university and once they have no active affiliation they are deleted from some Identity systems including Email Provisioning. Then they return, frequently in a different role that may require a different type of Email. Email Provisioning sees this as a new Identity, but when it goes to create a new Email account the request collides with the old undeleted Email account.
I am now going to describe what happens in general today, not just what will happen for Sponsored Identities (although they will be handled in the same way).
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 possibilities:
If the user previously had Email, the mail account still exists, and the Email Alias still points to it (that is, the only thing that was lost was a temporary lack of Affiliation or SOI, then Birthright sees an existing Email Address and decides there is nothing to do.
If the user had an Eliapps mail account that still exists in Google, but which is no longer referenced by a Primary Email Alias and therefore does not appear to be active, and they now have an affiliation that gets O365 mail, then a new O365 mailbox is created and the Alias points to it. The Eliapps mail account still exists, but no new mail is sent to it.
If the user had Eliapps mail, the account still exists, the alias has become Reserved, but the account was not deprovisioned, and the user now becomes a student in a School that uses Eliapps, Birthright goes through the steps of trying to create a new Eliapps account. We cannot aggregate data from Google because they limit request processing, so IIQ cannot ask if an account already exists. The Create operation sent to Google fails because the Google User object already exists. IIQ retries the Create a few times and gives up, but it is unnecessary since the old account becomes active again and behaves normally.
If the user had a no-Mail Eliapps account and a Mail O365 account, leaves, then returns as a student in a School that gets Eliapps mail, then IIQ will create a mail enabled account as “aliasname@yale.edu” the old no-Mail account was called “netid@yale.edu” and is not a duplicate, so now there are two Eliapps accounts. If the user had data in Google Drive, it appears to be gone. Generally there is no problem now, but after the user leaves any attempt to deprovision this account will discover the two accounts and probably fail.
If the user was gone long enough to go through the deprovisioning process, then many options were set to prevent the user from receiving mail in the old account, from logging on, or from being listed in directories. This special processing has to be undone with scripts that IIQ cannot run. 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. This takes a minute or two each day but addresses the problem.
None of this is by design. The full lifecycle of user identities was never considered so what happens in an unintended consequence of how existing code behaves in situations that were not originally thought out.
Once this behavior is enumerated, I would suggest that adding specifically requested Sponsored Identities and Academic Affiliates to the set of people processed by Birthright does not create any new problems. If the same person returned to the university as an employee instead of an SI, they would have gotten the same processing and had the same results.
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.