Hybrid Provisioning with Active Directory and Azure Active Directory

7 Kudos

Overview

As customers continue to migrate their applications to the cloud, it is increasingly common to see “hybrid” use cases for provisioning to Microsoft’s Active Directory and Azure Active Directory applications. We term this type of provisioning as “hybrid,” not only because there are on-premise (Active Directory) and cloud (Azure Active Directory) applications in scope, but also because there is usually a certain level of consistency and/or interplay desired by customers between these two applications.

Within hybrid provisioning, there are multiple use cases which could be in scope. This document attempts to describe the most common ones we see across our customer base, and how we’ve successfully met those use cases through IdentityNow. As always, it is best to work with the customer’s subject matter experts when it comes to Active Directory and Azure Active Directory, as they will have the best insights into how their organization’s architecture has been designed to meet their needs.

Common Use Cases

As mentioned above, there are numerous scenarios that can come up during an implementation when working with a hybrid Active Directory / Azure Active Directory environment. Below are some of the most common use cases, and our recommendations for how to meet them via IdentityNow.

Scenario 1: Provision Active Directory Account and Assign O365 licenses via the On-Premise Account

This is by far the simplest use case, and involves only a few small configurations:

Ensure that Azure AD Connect is installed on the client’s network (it can be installed on any domain-joined Windows server), and that it is configured to synchronize accounts and security groups between on-premise Active Directory and Azure Active Directory.
- Note: For cloud license assignment, it is important that the Active Directory c attribute is populated with the ISO 3166-1 alpha-2 (two-character) country code for the user, and that Azure AD Connect is set to synchronize that value with the cloud usageLocation attribute. The user’s usage location is a requirement for O365 mailboxes as it governs where the cloud mailbox’s data resides.
In Azure Active Directory, assign the needed O365 licenses to the synchronized security groups.
In IdentityNow, configure a valid account create policy for Active Directory and assign access profiles either through birthright/lifecycle state provisioning, role-based provisioning, or access request-based provisioning.
For the access profiles being granted, ensure that the desired on-premise security group associated with the correct O365 license have been added.

Once the above is configured, any newly-created account will automatically gain the O365 licenses tied to the on-premise security group. Additionally, any on-premise group add/remove operations would propagate to the same license add/remove operations in Azure Active Directory.

Scenario 2: Provision Active Directory Account and Create an On-Premise Exchange Mailbox to Replicate to the Cloud

For this use case, the customer’s business requirement is often one where they have cloud mailboxes for primary email addresses, but they also have some birthright proxy addresses for other domains. These latter proxy addresses are most often governed by policies on their on-premise Exchange server. Thus, the provisioning solution from IdentityNow is to first create both an on-premise Active Directory account and an Exchange server mailbox, then to enable remote management of the mailbox via Azure Active Directory:

Ensure that Azure AD Connect is installed on the client’s network (it can be installed on any domain-joined Windows server), and that it is configured to synchronize accounts between on-premise Active Directory and Azure Active Directory. Security group synchronization is optional in this solution - it is not needed to satisfy the stated business use case, but may be valuable for the customer’s other use cases.
- Note: For cloud license assignment, it is important that the Active Directory c attribute is populated with the ISO 3166-1 alpha-2 (two-character) country code for the user, and that Azure AD Connect is set to synchronize that value with the cloud usageLocation attribute. The user’s usage location is a requirement for O365 mailboxes, as it governs where the cloud mailbox’s data resides.
In IdentityNow, configure a valid account create policy for Active Directory and assign access profiles either through birthright/lifecycle state provisioning, role-based provisioning or access request-based provisioning.
- The configuration should include, at a minimum, the mailNickname attribute so that Exchange provisioning can be triggered. The Active Directory connector will automatically seek out the “closest” Exchange server as the provisioning target; the create profile’s homeMDB and/or the source’s Exchange server settings can also be used to specifically target a particular server.
- The provisioning policy should also contain the ISO 3166-1 alpha-2 country code as the value for the c attribute on Active Directory accounts, as described in the note above.
Write and deploy a ConnectorAfterCreate rule which invokes a simple PowerShell Enable-RemoteMailbox command against the newly created Active Directory and Exchange accounts:
```
Enable-RemoteMailbox -Identity "someSAMAccountName" -RemoteRoutingAddress "someSAMAccountName@someclient.mail.onmicrosoft.com"
```
- Note that the ConnectorAfterCreate rule can also be leveraged to perform other common operations via PowerShell such as:
  - Set calendar permissions – e.g. everyone can read others' calendars, etc.
  - Set the user location
  - Disable some services – e.g. IMAP, POP3

This configuration should allow for the on-premise Active Directory and Exchange mailboxes to be properly generated, and any proxy address links to be created, prior to the primary mailbox being migrated into Azure.

Scenario 3: Provision Active Directory Account and Create Cloud-Only Mailboxes in Azure Active Directory

The typical business requirement in this use case is to create on-premise Active Directory accounts, but only have O365 mailboxes created for those users - nothing on-premise as the client either does not have an Exchange server or, if it does have one, is not interested in using local mailboxes. For this requirement, we’ve typically implemented the following solution:

Ensure that Azure AD Connect is installed on the client’s network (it can be installed on any domain-joined Windows server), and that it is configured to synchronize accounts between on-premise Active Directory and Azure Active Directory. Security group synchronization is optional in this solution - it is not needed to satisfy the stated business use case, but may be valuable for the customer’s other use cases.
- Note: For cloud license assignment, it is important that the Active Directory c attribute is populated with the ISO 3166-1 alpha-2 (two-character) country code for the user, and that Azure AD Connect is set to synchronize that value with the cloud usageLocation attribute. The user’s usage location is a requirement for O365 mailboxes as it governs where the cloud mailbox’s data resides.
In IdentityNow, configure a valid account create policy for Active Directory and assign access profiles either through birthright/lifecycle state provisioning, role-based provisioning or access request-based provisioning.
- The provisioning policy should also contain the ISO 3166-1 alpha-2 country code as the value for the c attribute on Active Directory accounts, as described in the note above.
Create a source connection for Azure Active Directory, ensure that the necessary correlation logic is configured to link Azure Active Directory accounts to their owning identities, and ensure that aggregations are set to run on a frequent basis (every hour).
- Some common options for correlation between Azure Active Directory and Active Directory are:
  - userPrincipalName → userPrincipalName
  - mailNickname → mailNickname
  - email → mail
Create an Azure Active Directory “birthright role” for each O365 license, which needs to be automatically provisioned.
- The membership criteria for these roles should include requirements around necessary lifecycle states (e.g., prehire, active, onLeave), as well as a requirement that the user has an on-premise Active Directory account.
- Additional membership criteria can be applied to ensure that the proper O365 license is assigned based on the worker’s job function/department/type.

Once the above has been configured, the provisioning flow will ensure that the user gets their on-premise Active Directory account first. Once the account has been created, the Azure AD Connect sync process should replicate the on-premise account into the Azure environment (this may take up to 15 minutes or more depending on how frequently the client configured Azure AD Connect to synchronize). After the cloud object has been created, it will be picked up during the next Azure Active Directory source aggregation, and the Azure account should get correlated to its owning identity. At this point, an identity refresh should process the role membership logic for that user and trigger the O365 license assignment - if a cloud mailbox is part of the license pack being assigned, it will be automatically created by Azure.

Scenario 4: Manage O365 Licenses: Assign Additional Licenses and Remove Unwanted Access

One area that often presents a challenge to implementers working with Active Directory and Azure Active Directory is the reclaiming of licenses when users change roles or depart the organization. To illustrate, imagine that IdentityNow assigns a birthright role that gives users an E1 license. Subsequent to that license assignment, suppose a user requests the E3 license. Assuming this access request is approved, the user would now have both an E1 license and an E3 license, which is costly and undesirable. The business requirement is to automatically de-provision the original license any time a new license is being added to the user.

A few options to accomplish this use case are:

Leverage the role membership criteria of O365 license assignments and include additional attributes that can ensure the user is properly excluded from the originally assigned license.
1. These attributes can be data elements from the user’s HR/authoritative account, specific entitlements contained within the newly granted license pack, etc.
2. The newly restrictive membership criteria should automatically remove the user from his/her previous access and allow him/her to retain the newly granted licenses.

Leverage a “mover” certification campaign construct. This solution keys off a change in the user’s identity or account information to trigger a targeted “mini” certification campaign for that user’s Azure Active Directory access.

In the past, we have leveraged an IdentityAttribute rule to trigger a “certification needed” flag, which can be used in a Certs-over-Search query. One such rule, which has been used in the past, looks like the example below:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Rule PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<Rule language="beanshell" name="Certification Needed Flag" type="IdentityAttribute">
  <Attributes>
    <Map>
      <entry key="requiresPeriodicRefresh" value="true"/>
    </Map>
  </Attributes>
  <Description>Rule to determine if an identity needs to be certified based on changes to company and department attributes</Description>
  <Source><![CDATA[
    import sailpoint.object.*;
    import java.util.Calendar;
    import java.util.Date;
    import java.util.Locale;
    import java.text.SimpleDateFormat;

    
    String returnVal = "";
    String regex = "(.*)(?<WeekDay>\\w+)\\s+(?<Month>\\w+)\\s+(?<MonthDay>\\d+)\\s+(?<Hour>\\d+):(?<Min>\\d+):(?<Sec>\\d+)\\s+(?<TimeZone>\\w+)\\s+(?<Year>\\d+)"; // Regex to check for Flag + Timestamp pattern
    int expirationOffset = 7; //Minimum age of certification flag in days
    String departmentCompany;
    
    
    if (identity != null) {
    
        // Check to see if department company exists on this identity. Return null if not.
        if (identity.getAttribute("departmentCompany") != null) {
            departmentCompany = identity.getAttribute("departmentCompany").toString();
        } else {
            log.info("Unable to find a department company for identity: " + identity.getName() + " returning null.");
            return null;
        }
    
        if (oldValue == null || oldValue.isEmpty()) //Initial Attribute Population
            returnVal = departmentCompany;
        else if (oldValue.equals(departmentCompany)) //No change in department company
            returnVal = oldValue;
        else { //Change in department company detected
            Date now = new Date();
    
            if (oldValue.matches(regex)) { //Timestamp present, this job change has been previously detected. 
                //Parse out timestamp and check if within expirationOffset window
                SimpleDateFormat sdf = new SimpleDateFormat("EEE MMM dd HH:mm:ss Z yyyy", new Locale("us"));
                Calendar expirationCheck = Calendar.getInstance();
    
                // Trim off the True: portion of the string and trim it
                expirationCheck.setTime(sdf.parse(oldValue.substring(oldValue.length() - 28).trim()));
                expirationCheck.add(Calendar.DATE, expirationOffset);
    
                if (expirationCheck.getTime().before(now))
                    returnVal = departmentCompany; //Flag has expired, set to current department company
                else {
                    returnVal = oldValue; //Flag is still valid, return current value
                }
            } else { //New Job Change, set flag
                returnVal = "true " + now;
            }
        }
    }
    return returnVal;
]]>  </Source>
</Rule>

Alternatively, IdentityNow’s Event Trigger Service can be leveraged in conjunction with Workflows to make this certification generation more real-time. Under this solution design, the Identity Changed event trigger would be registered against a workflow, which would then call back into IdentityNow’s certification APIs to generate the relevant campaign and assign it to the proper individual.
As SailPoint’s Workflows feature matures and the out-of-the-box ability to request access removals for entitlements, access profiles and roles becomes fully fleshed out, eventually the workflow could simply call into IdentityNow to remove the undesired access directly and immediately, without requiring certifications.

Scenario 5: Maintain Data Consistency between Active Directory and Azure Active Directory Account Attributes

SailPoint is often leveraged as a tool for ensuring that account-level data is kept consistent across multiple systems for a given identity. Indeed, we have an attribute synchronization service for just this use case, so it is tempting to leverage attribute sync between an identity’s accounts in Active Directory and Azure Active Directory independently (through identity attribute values).

However, for Active Directory and Azure Active Directory, our recommendation is to allow Azure AD Connect to handle this data consistency task. There are a couple of very good reasons for doing so:

Azure AD Connect is usually already in place for customers who are leveraging a hybrid environment, and it is a very robust, well-delivered solution. As this tool is built specifically to keep client’s environments in sync, it is best to defer to the productized solution from Microsoft itself.
There are certain use cases (e.g., multi-valued attributes, group memberships, etc.) for attribute sync that IdentityNow does not support well. The Azure AD Connect utility does support these use cases, so there is much better coverage for customers' use cases through that utility compared to IdentityNow.
The Microsoft-recommended data flow whenever there is a mismatch between on-premise Active Directory accounts and the cloud-based Azure Active Directory object is to push data from Active Directory to Azure Active Directory. This allows the cloud account to remain up-to-date but still take its authoritative attribute values from the on-premise object. Leveraging an attribute sync process outside of Azure AD Connect (i.e., IdentityNow’s attribute sync) could potentially disrupt this data flow by introducing changes to both systems simultaneously, potentially with bad data if the synchronization configuration is not set up properly. It is best to avoid this risk by simply letting the Microsoft Azure AD Connect service do its job.

Hybrid Provisioning with Active Directory and Azure Active Directory