When IIQ Before a 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 that were previously ignored.
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 instead of Oracle stored procedure calls. 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 store the mail. 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 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 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 extend the view to include the other affiliations (MEMBER and AFFILIATE) that might have a mail account. So today there is already an Identity object in that IIQ instance for everyone who might request a mail account.
The Email Provisioning instance of IIQ still double checks each prerequisite before processing a user, its daily reports and special reporting will show a user who has entered processing and not completed. This will alert IAM personnel to investigate and find out what is wrong.
Since SI and Academic Affiliate users are now in its identity database, all that is needed for IIQ to provision mail is an indicator that a request has been made and approved. This indicator could be a column in a StagingDB table that gets aggregated, or it could be a Global Variable in the IIQ identity object. This indicator is then added to the variables examined to decide which identities should be given mail accounts.
Email Provisioning is not a Workflow triggered by an event. It processes identities that evaluate to being mail-entitled but have not yet had a mail account created (as represented by the EmailAddress variable of the identity which is set when the Primary Email Alias has a Mailbox value). If a new request is created and approved, but when it arrives at Email Provisioning the user already has an EmailAddress then the identity will not enter processing in the first place and the request will be treated as complete without any processing.
No substantial new logic is required. The new processing for MEMBER or AFFILIATE who requests mail is essentially the same as would be the case if instead that person was hired as an EMPLOYEE and received the mail account with the current processing, except that Yale may decide not to create a NoMail Eliapps account for MEMBER and AFFILIATE requests while such an account is always created for EMPLOYEEs.
Otherwise, IIQ will do two or possibly three things:
It will call Enable-RemoteMailbox on the Netid which updates the Local AD and Azure AD object, sets the UPN, mail, MailNickName, and some ProxyAddresses values in Azure. This operation can fail if the Mailbox already exists, but in this case there is nothing to do.
For Birthright Entitled users IIQ would create a NoMail Eliapps account. This processing may be skipped for these new requests depending on the requirements we are given.
It will 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
Birthright Email processing was written to assume it processes assign mail to new users. Subsequently we have discovered that it can be fooled by old users who leave the university for a while and then return. Although this was not part of the original design, Birthright processing is robust enough to handle these cases.
When an Identity has no current affiliation (except ALUM), it drops out of the IDRIdentitiesView and is deleted from the Email Provisioning Identity Cube. If the same person then gets a new Affiliation they appear to be a new user and are evaluated for Birthright mail.
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 previously had Eliapps mail but now is entitled to O365, then an O365 account is created. The old Eliapps account is left alone.
If the user was deprovisioned then Birthright Email has no logic to undo that processing. It generates a report of processed users and displays the deprovisioned flag in AD. The reports are retained for a week, so I can read them and manually run a Powershell script to fix anything that normal Birthright process does not correct itself.
This is not changed if we modify Birthright processing for people with Sponsored Identity or Academic Affiliate Affiliations. If they were never previous Yale users then they get Email cleanly. If they previously had mail, even if that mail was deprovisioned, then any new Birthright processing we create for an AFFILIATE or MEMBER who has some sort of residual mail account is the same as Birthright processing we already do today had the same person returned as an employee.
If a former STUDENT graduates and someone is using SI to extend their grace period, they should not be given the proposed new special mail processing. They already have mail. If you give them the proposed new processing, then an Eliapps student will be given O365 mail and will stop receiving mail in their Eliapps accountIt 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 user still has an Email Address. When a new affiliation is assigned to this Identity, it will not enter Birthright processing because the Email Address indicates there is no work do be done.
Without regard to the status of the mail account in O365 or Google, if the Primary Email Alias has a null Mailbox (the alias is “Reserved” rather than active) then Birthright processing begins as if the user has no mail. In some cases it will detect that a step has already been performed and skip it. In other cases it will perform a “create” operation that fails because there is already a duplicate account.
Since Birthright processing first assigns a type of mail based on affiliation, if the user is currently a student in a School that gets Eliapps, an attempt will be made to create a mail Enabled Eliapps Google account. Such an account will be named by the Primary Email Alias (firstname.lastname@yale.edu). NoMail Eliapps accounts would have been named netid@yale.edu and therefore may not be seen as a duplicate. However, now that the Mail Relays no longer exist and all incoming mail goes through Exchange Online, if the user has an O365 mailbox at all, then all mail will be delivered to O365 and the Eliapps account will never receive anything. The user will also have confusing directory entries. Exchange Online will insist that some Azure AD for Email Addresses be set to point to the UPN, which in turn is set to the Primary Email Alias. Therefore the Alias and Local AD entries will indicate Eliapps mail while the Azure AD and Exchange will indicate O365 mail. 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 do an Enable-RemoteMailbox. IIQ will then set the Email Alias Mailbox to point to O365. Exchange Online will now try to deliver incoming mail to the O365 mailbox.
When a user is explicitly deprovisioned other changes are made to an O365 or Eliapps mail account to block mail delivery. For example, there is a “Don’t accept mail from anyone except: Elvis” list. These manual blocks have to be cleared by someone running a Powershell script. IIQ generates a report every day of people it processes for Email, and one of the columns in the report flag deprovisioned users. I read the report each day and run a script on anyone it flags. This will work the same for any new SI or Affiliate people who also get processed.
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. Today the IDRIdentitiesView selects all identities whose PrimaryAffiliation is not NULL or ALUM. The aggregations do not need to be changed unless the flag that triggers special processing for SIs and Affiliates is in a new source not currently being aggregated.It then runs a refresh task that executes 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 against all Identities. This Selector Rule assigns the “Netid” Role to identities entitled to Birthright mail, but only for the period of time while some preliminary requirements are being met.
However, all the requirements are now being handled somewhere else. In particular, a new Netid Role was added to the Identity Management IIQ to reserve a Primary Email Alias and create an AD User object. Any Identity that could be processed at 5:30 AM will have been created by or before the midnight Full Aggregation in the other IIQ. So by the time this task runs the alias is already reserved, the AD object is created, and the Azure AD object was synchronized.
The Netid Role processing is therefore redundant, but it has not been removed. It should find nothing to do, but it is still useful to verify that all the prerequisites are met and initialize a few fields in the current Identity.
This Rule needs to be changed so it does not reject someone with Affiliation of MEMBER or ASSOCIATE when some flag is set indicating this Identity requires special processing. 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 job 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. In current practice, this will probably have happened already sometime after midnight.
The EmailTypeRoleSelector Rule evaluates Identities that are members of an IIQ Population (essentially a query against the Identities). The Population query can be adjusted to include MEMBER or ASSOCIATE uses who have the special processing flag set. The code does not check Affiliation because it relies on the Population to filter users who need processing.
Now that Licenses are being assigned based on AD Group membership, this task
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) for undergrads and grad students in schools that use Eliapps.
...
.
We may decide not to create an Eliapps account for this new class of manually requested SI mail users. However, to avoid creating the Eliapps account we need to create a new Role with different Entitlements, which is a slightly larger programming effort than simply allowing them to get the same NoMail Eliapps that Birthright O365 users get.
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.