...
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 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 in (of 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) 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 previously only aggregated IDRIdentities with affiliations granting them 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 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.
...
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.
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 processing was written to provide assign 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)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 possibilitiespossible results:
If Even though the user previously had Emaillost affiliation, the mail account still exists, old Email account may have remained active and the Email Alias still points to it (. If 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 (which should not occur) 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. If they now have an affiliation that gets Eliapps mail, IIQ attempts to create the Eliapps account but that fails because one already exists. We ignore this type of error and the old account becomes active again.
If the user had O365 mail and the account remained active but the Email Alias was deleted (which again should not have happened) then the account is still active. Now that Exchange Online processes all incoming mail, the Alias is no longer used to deliver mail to an O365 mailbox. Nor can this be changed. If Birthright processing were to try and create an Eliapps mail account, and even set the Primary Alias to point to “bulldogs”, then O365 mailbox would still get all the mail from Exchange Online.
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 runtrue, 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. 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 resultsThe 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
...