...
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 create store the mailboxmail. 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 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 change extend 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 today 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 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.Change . 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 assign mail to new users. It works flawlessly for new identities with new Netids and no prior AD or Google entries.
...
Even though the user lost affiliation, the old Email account may have remained active and the Email Alias still points to it. If that is true, then a new Identity object created from a new affiliation/SOI will already appear to have mail and user still has an Email Address. When a new affiliation is assigned to this Identity, it will not enter Birthright processing . If because the Email Address indicates 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)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 be do an Enable-RemoteMailbox. This will fail if the AD User object already has an O365 account. It 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.
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 deprovisionedWhen 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 Powershell script on anyone it identifies as previously deprovisionedflags. 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).
...
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 systemWe 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.
...