...
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 ignoredso 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).
After With these changes, the Email Provisioning instance of IIQ can be easily changed to assign O365 Email to new SIs and Academic Affiliates based on setting some 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 directory.Birthright Email processing was written to assume it processes 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 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, 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.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 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.
...
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. 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. However, almost all of the processing done by this Rule is now obsolete. We created a new Netid Role in the Identity Management IIQ that runs during Full and Delta Aggregation and does most of the same things.
However, the simplest change is to add logic to the Netid Selector to look for whatever new flag identifies MEMBER and AFFILIATE identities that require Mail Provisioning and run them through this code just to be sure.
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 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 This was necessary when the code was written, but in the current environment all the prerequisites will have been handled and the Azure AD will have been updated after the midnight Full Aggregation of the Identity Management IIQ.
However, if the request to create a mail account is processed automatically by Service Now, 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 earlier job has Java code to decide who gets processed, this job is controlled by an IIQ Population (users who match a configured Identity query). We need to change that Population to include people who have the as yet to be defined flag indicating they are MEMBER or AFFILIATE identities who should be given mail accounts.
All Identities in the population are checked, and if the prerequisites have been met they are assigned a type of mail.
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 Eliapps mail. This logic will given O365 mail to MEMBER and AFFILIATE identities, which is the right choice, so no new code is required.
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.
...
.
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.