This document presents an executive summary of the business case for moving forward with enabling Azure Active Directory automatic user provisioning for «APPLICATIONNAME» ("The Application").
Many organizations rely upon software as a service (SaaS) applications such as Office 365, Box and Salesforce for end user productivity. Historically, IT staff have relied on manual provisioning methods or custom scripts to securely manage user identities in each SaaS application.
Azure Active Directory User Provisioning simplifies this process by securely automating the creation, maintenance, and removal of user identities in cloud (SaaS) applications based on business rules. This allows an enterprise to effectively scale their identity management systems on both cloud-only and hybrid environments as they expand their dependency on cloud-based solutions.
INCREASE PRODUCTIVITY
Simplify the management of user identities across SaaS applications by providing a single user provisioning management interface. This includes having a single set of policies to determine who is provisioned, who can sign into an application and what user information to provision.
MANAGE RISK
Secure your organization by ensuring that user identities and access to key SaaS apps are automatically updated when users transition or leave the organization. This can be implemented based on a user's employee status or groups that define user roles and/or access.
ADDRESS COMPLIANCE AND GOVERNANCE
Supports native audit logs for every user provisioning request performed by each application for both source and target systems. This includes user imports, exports, and synchronization.
MANAGE COST
Reduce costs by avoiding inefficiencies and human error associated with manual provisioning. This includes maintaining custom-developed user provisioning solutions, scripts, and audit logs.
Comparing Azure Active Directory automatic user provisioning to other solutions
User provisioning options | Advantages of automatic user provisioning |
Manual provisioning |
|
SAML Just-in-Time provisioning |
|
Custom solutions |
|
Other IDaaS solutions |
|
The following section serves to identify all the stakeholders that are involved in the project and need to sign off, review, or stay informed. Add stakeholders to the table below as appropriate for your organization.
Name | Role | Action |
Enter name and email | IT Support Manager A representative from the IT support organization who can provide input on the supportability of this change from a helpdesk perspective. | SO |
Enter name and email | Identity Architect or Azure Global Administrator A representative from the identity management team in charge of defining how this change is aligned with the core identity management infrastructure in the customer's organization. | SO |
Enter name and email | Application Business Owner A representative colleague who can provide input on the user experience and usefulness of this change from an end-user's perspective and owns the overall business aspect of the application, which may include managing access. | SO/I |
Enter name and email | Security Owner A representative from the security team that can sign off that the plan will meet the security requirements of your organization. | SO |
Proper planning is essential to any successful integration in an IT environment. This section will guide you through planning steps that will help simplify your organization's onboarding of automatic user provisioning for <<APPLICATION NAME>>.
The following is in scope for this project:
The following are out of scope of this project:
Tracking your plan is an important aspect of project success. You may use the embedded Deployment Plan Tracker spreadsheet below to monitor and schedule your committed timelines for this project. Begin tracking additional items as you progress through the deployment plan that may require an action or prerequisite:
You will need an Azure AD License. The number of objects in your directory and the features you wish to deploy will affect your licensing choices. While many features are included with Azure Free and Azure Basic, some features require Azure AD Premium (P1 or P2). Common Azure AD scenarios include the following recommended security features:
The following table describes some of the license requirements that may be relevant. For a full list of license requirements, click here.
LICENSE TYPE | FREE | BASIC | PREMIUM P1 | PREMIUM P2 |
Directory Objects | 500,000 Object Limit | No Object Limit | No Object Limit | |
Single Sign-On | 10 apps per user (pre-integrated SaaS and developer-integrated apps) | 10 apps per user (free tier + Application proxy apps) | No Limit (free, Basic tiers + Self-Service App Integration templates) | |
Group Provisioning | Not Available | Available | Available | |
User Provisioning | Available | Available | ||
Bring your own application SCIM | Available | Available | ||
Access based on group membership | Not Available | Available | ||
CA based on group and location | Not available | Available | ||
CA based on device state (Allow access from managed devices) | Not available | Available |
If you have an existing Enterprise Mobility and Security (EMS) subscription with Microsoft, you may already have Azure AD Premium.
Enterprise Mobility and Security (EMS) subscriptions:
If you have an existing Enterprise Agreement or Server and Cloud Enrollment, you may already have Azure Premium. Check the details of your agreement.
You will also need the appropriate license for your application to meet your business needs.
Discuss with the application owner whether the users assigned to and accessing the application have the appropriate licenses for their roles within the application. If Azure AD manages the automatic provisioning based on roles, the roles that are assigned in Azure AD must align with the correct number of licenses owned within the application. Improper number of licenses owned in the application may lead to errors during the provisioning/updating of a user.
The topologies for outbound automatic user provisioning are represented below:
The following diagram illustrates the end-to-end user provisioning workflow that occurs for common hybrid environments. In this example, user creation occurs in an HR database connected to an on-premises directory while outbound automatic user provisioning is managed by the Azure AD provisioning service to the target SaaS applications:
Description of workflow:
The following diagram illustrates the end-to-end user provisioning workflow that occurs for common cloud-only environments. In this example, user creation occurs in Azure AD and the automatic user provisioning is managed by the Azure AD provisioning service to the target (SaaS) applications:
Description of workflow:
Azure Active Directory (Azure AD) features pre-integrated user provisioning support for a variety of popular SaaS applications as well as generic user provisioning support for applications that implement specific parts of the System for Cross-Domain Identity Management (SCIM) 2.0 protocol specification.
Applications that support provisioning in the Azure AD application gallery come pre-configured with default user provisioning settings. However, you have the option to customize the configuration of the user provisioning connector to suit your organization's needs.
Once configured, Azure AD will be able to send requests to create, modify, deactivate, or delete assigned users and/or groups to the desired applications via their web services. The web services can then translate those requests into operations on the target identity store.
Below is a list of items that are useful when planning your Azure AD automatic user provisioning implementation:
SCIM, or System for Cross-domain Identity Management, is an open standard that allows for the automation of user provisioning. SCIM communicates user identity data between identity providers (e.g. Microsoft) and service providers requiring user identity information (e.g. SaaS apps like Salesforce).
To learn more about SCIM, refer to http://www.simplecloud.info/.
Even if an application utilizes SCIM, each CRUD (Create, Replace, Update, Delete) operation or attributes/objects used may differ from application to application. Before implementing Azure AD automatic user provisioning, define a list of objects and operations needed based on the list below:
User accounts
Groups (for selected apps)
Before setting up Azure AD automatic user provisioning, be aware of the following (if applicable) to reduce issues post-deployment:
When the Azure AD provisioning service runs for the first time, it performs an initial sync against the source system and target systems to create a snapshot of all user objects for each target system.
The time taken for initial syncs are directly dependent on how many users, groups and group members are present in the source system. Initial syncs for Azure AD tenants with over 100,000 users and/or group objects combined can take a long time.
After a successful initial sync, the Azure AD provisioning service will continue to run back-to-back incremental syncs indefinitely, at intervals defined in the tutorials specific to each application, until one of the following events occur:
To review these events, refer to the provisioning audit logs and reporting which are described here.
It is common for a security review to be required as part of a deployment of a new service. If a security review is required or has not yet been conducted, please review the many Azure AD whitepapers that will provides an overview for the identity as a service.
This section is used to assist you in designing the automatic user provisioning implementation in your environment that best meets your business needs. This document will indicate when Microsoft has a recommendation among the choices presented.
Go through the workflow below to scope the key requirements needed to implement automatic user provisioning in your environment:
Check if <<APPLICATION NAME>> already has a pre-integrated user provisioning connector with Azure AD. You can do so by referring to the SaaS application integration tutorial list which will list an application tutorial for user provisioning if the target application has a pre-integrated user provisioning connector. Depending on the outcome, your next steps are as below:
Scoping Question | Answer | Recommended Next Steps |
Does <<APPLICATION NAME>> have a pre-integrated user provisioning connector? | Yes |
|
No |
When implementing Azure AD automatic user provisioning, you will need to provide certain admin credentials that are used to connect to the target system's user management endpoint - to facilitate user provisioning which may differ for each application. Common admin credentials include:
Use the following tables to document the admin credentials required for <<APPLICATION NAME>>:
Credential Type | Values |
e.g. Admin Username | e.g. test@contoso.com |
To implement automatic user provisioning, you will need to define the user and/or group attributes that are needed by your organization.
Note: Unless an application utilizes SCIM, each application may have their own schema for attributes needs.
Use the tables below to document the Azure AD (or AD if applicable) attributes needed along with their expected mappings to the attributes for <<APPLICATION NAME>>. Feel free to extend the tables as needed.
User attributes needed:
AD Attribute (if applicable) | Azure AD Attribute | <<APPLICATION NAME>> Attribute |
e.g. User Principal Name (UPN) | e.g. User Principal Name (UPN) | e.g. userName |
Group attributes needed:
AD Attribute (if applicable) | Azure AD Attribute | <<APPLICATION NAME>> Attribute |
e.g. member | e.g. members | e.g. memberships |
Note: Azure Active Directory supports attribute mapping by direct attribute to attribute mapping, providing constant values, or writing expressions for attribute mappings. This flexibility gives you ultimate control to what will be populated in the targeted application attribute.
Before automatic user provisioning can be implemented, you will need to determine the users and/or groups to be synchronized to <<APPLICATION NAME>>. The table below will help you understand and decide which method is best for your needs:
Scoping Question | Answer |
|
What is the source system for your automatic user provisioning implementation? | Active Directory |
|
Azure Active Directory |
|
This section is used to guide you through the implementation and testing of your automatic user provisioning using your design requirements documented in the previous section. This workflow is divided into four phases.
If <<APPLICATION NAME>> has a pre-integrated user provisioning connector:
If <<APPLICATION NAME>> does not have a pre-integrated user provisioning connector:
Once you have configured automatic user provisioning for <<APPLICATION NAME>>, you will need to run test cases to verify whether this solution meets your organization's requirements. These test cases should reflect your Business Use Cases. Use the table below to document your test scenarios along with the expected and actual results:
Scenarios | Expected Results | Actual Results |
e.g. User is added to a group that is assigned to <<APPLICATION NAME>>. | e.g. User object is provisioned in <<APPLICATION NAME>>. User can log into <<APPLICATIO NAME>> and perform the desired actions. | |
e.g. User is removed from a group that is assigned to <<APPLICATION NAME>>. | e.g. User object is deprovisioned in <<APPLICATION NAME>>. User cannot log into <<APPLICATIO NAME>> and perform the desired actions. | |
e.g. User information is updated in Azure AD through Azure AD Connect or via Graph API. | e.g. Updated user information is reflected in <<APPLICATION NAME>> after an incremental sync. |
Use the results above to determine how to transition your automatic user provisioning implementation into production based on your established timelines. Feel free to extend the table as needed.
Once your testing is complete and successful, move your automatic user provisioning implementation into production by repeating all the steps in Phase 1 to Phase 3 in your production environment.
If the automatic user provisioning implementation fails to work as desired in the production environment, the following rollback steps below can assist you in reverting back to a previous known good state:
This section will guide you in best practices to maintain the automatic user provisioning implementation that has been deployed.
Azure AD can provide additional insights into your organization's user provisioning usage and operational health through audit logs and reports. The table below lists the provisioning reports and logs available along with the insights that they provide:
Report Type | Insights | Location |
Provisioning summary report |
|
|
Provisioning audit logs |
|
|
To learn more about how to navigate the user provisioning reports and audit logs, refer to the tutorial here.
To learn more about common issues that affect automatic user provisioning and how to resolve them, refer to the troubleshooting documentation here. The table below documents additional user provisioning issues that should be considered:
Issue | Possible Cause | Recommended Steps |
User provisioning stopped working despite configuration not being changed since last known good state. | The admin account password for your application in the Admin Credentials section may have been changed and/or expired. |
|
You have updated the admin account password for your application in the Admin Credentials section but have not yet updated the Security Token. |
|