When IIQ Birthright Email Provisioning was written there was a long sequence of tests and steps that were required. Over the last five years, however, some of the tests have been relaxed and some processing has been moved elsewhere.
The Identity Management IIQ (which shares Java code with Email Provisioning) now calls some of the code written for Email Provisioning when it assigns a new Netid. Specifically, it creates an AD User object and it reserves an Email Alias.
The Azure AD Connector (“directory synchronization”) process now assigns required information in new Azure AD objects so Email Provisioning no longer has to set these values itself.
O365 Licenses are now assigned by “group-based provisioning” managed by Grouper.
Email Provisioning IIQ now has to update Email routing fields of AD, so it now aggregates identity data with affiliations MEMBER and AFFILIATE in addition to the previous affiliations entitled to Brighright mail (STUDENT, FACULTY, STAFF, and EMPLOYEE).
With these changes, the Email Provisioning instance of IIQ has data on the Sponsored Identities and Academic Affiliates for whom a manual Email account might be requested and even before it runs, all the preliminary work has already been done. If we define some new flag in a database or AD that indicates it should create mail for these users, it can fill in a few additional fields and then do the two remaining steps of Enable-RemoteMailbox and setting the Email Alias MAILBOX and EMAILTO to “netid@connect.yale.edu”.
However, there is one situation where Birthright Email processing is triggered in a way that was not part of the original design. It happens to do the right thing in existing cases, but we need to walk through the problem to make sure this new use will not cause problems.
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 requires 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.
This is not necessarily a problem. 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. There are three possibilities:
If the user previously had an O365 mail account and it is still active, then Birthright processing will clean up any missing attribute values and reuse the old account. If the user is in a school that ordinarily gets Eliapps mail accounts then converting from O365 to Eliapps requires a special request to the Help Desk and is outside the scope of the mailbox creation process.
If the user previously had Eliapps mail but now is entitled to O365, then an O365 account is created. The old Eliapps account is left alone. Because all mail coming to “@yale.edu” now flows through Exchange Online, it will discover the O365 Mailbox and start delivering mail to that account. There is still some confusion and it would be useful for the Help Desk to clean it up, but everything happens by default to do what the rules say should be done.
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.
Adding specifically requested Sponsored Identities and Academic Affiliates to the set of people processed by Birthright does not change anything. New identities with no mail will get new O365 accounts just as they would have gotten automatically if they were employees. Users with an active Email account should not have made the request, but it such a request comes in Birthright processing will ignore them since there is nothing to do. Deprovisioned users will show up in the report and get additional manual processing.
This leaves us with one special category. After graduation, RecentAlumni keep their student Email account for a year, but they no longer have what is otherwise regarded as an active affiliation. Today they can transition to a professional school or become an employee, and when their identity reappears with an active Eliapps mail account, the fact that they would normally get O365 mail with their new affiliation is ignored. They have mail and do not go through Birthright again. If a year after graduation their Eliapps account is deleted or hidden, any entry into Birthright processing (as an employee today or as a specially request SI in the proposed new code) will give them an O365 account.
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.