Share via


Manage identities for single-forest hybrid environments using on-premises authentication

 

How can this guide help you?

Corporate users want to be able to use applications that reside in the cloud from anywhere and any device, but they cannot because they do not have a way to authenticate. Corporate IT wants to be able to allow users the ability to authenticate to these cloud applications, and it also wants the ability in real time to control who can access these applications.

This guide provides a prescriptive, tested design about how to integrate an on-premises directory with a cloud directory so that users can easily access applications that reside in the cloud from anywhere and any device. This is accomplished using on-premises authentication. For an example of using cloud authentication, see Manage identities for single-forest hybrid environments using cloud authentication.

On-premises problem

In this solution guide:

  • Scenario, problem statement, and goals

  • What is the recommended planning and design approach for this solution?

  • Why are we recommending this design?

  • What are the high-level steps to implement this solution?

Scenario, problem statement, and goals

This section describes the scenario, problem statement, and goals for an example organization.

Scenario

Your organization is a large-sized corporation with offices all over the world, including in North and South America, Europe, and Asia. The research and development (R&D) teams work primarily in North America and Europe. They develop the formulas that will be used by the manufacturing centers that are located primarily in Asia.

The R&D teams work closely together when developing new formulas or improving upon existing ones. This is done by running similar, standardized tests in facilities in North America and Europe, and then sharing the results. The results are then made final and new formulas are developed. These formulas are considered trade secrets and are patented. After this process is completed, the formulas are sent to the manufacturing facilities to begin production.

Currently, if a member of the R&D team wants to share results with counterparts in another part of the company or wants to send a formula to one of the plants in Asia, the team uses the Encrypting File System (EFS) to encrypt and email the files. The person on the other end then decrypts the files.

Your organization has several issues with the current process:

  • Privacy: Data is transferred via email, and although it is encrypted, it is still susceptible to hacking over the Internet. Also, many employees are accessing email from their own devices and there is no guarantee that those devices are secure.

  • Integrity: The EFS Certificate used to encrypt files must be exported and sent to the destination. Users are using email to send those certificates, which could violate the integrity of the certificate.

  • Confidentiality: The same certificate is often used for encrypting the test results and the formulas. Employees at the manufacturing plants will have the ability to decrypt these results, if they get a copy of them by mistake.

In order to address these concerns, your organization has decided it would like to set up Office 365 SharePoint in the cloud and use this as its portal for sharing test results and formulas. However, your organization wants to use its on-premises Active Directory as the authentication provider and does not want to use cloud authentication.

Problem statement

Your organization currently has an authentication provider, the on-premises Active Directory, but this provider is currently unable to authenticate employees to the new Office 365 SharePoint sites that will be hosted in Azure.

The overall problem your organization wants to solve is:

As a system architect or IT administrator, how can you provide users with a common identity when accessing resources that are on-premises and cloud-based? And how can you manage these identities and keep the information synchronized across several environments without using excessive IT resources?

Providing access to your organization’s SharePoint sites will require the ability to authenticate the employees with an authentication provider, the on-premises instance of Active Directory. Also, your organization wants to restrict access to just the R&D and manufacturing employees who require access to the sites. They are currently the only ones who will need to access the sites.

Having looked into the options, you have determined that you can leverage your existing instance of Active Directory Federation Services (AD FS) to use on-premises authentication with Azure. Your organization set up AD FS several years ago. This will save time and money because the IT staff is already familiar with using AD FS.

Management has authorized the purchase of Office 365 and Azure subscriptions. It is now up to the Active Directory administrators to set up their instance of Azure AD and federate it with the on-premises Active Directory.

The Active Directory administrators need to be able to leverage the on-premises Active Directory to populate the instance of Azure AD. The Active Directory administrators must be able to do this quickly. Next, the Active Directory administrators need to federate the on-premises instance of Active Directory with Azure AD. Also, your organization wants employees who will be accessing the SharePoint sites to have a true single sign-on experience and only be able to access the sites when logged on to the corporate network. Your organization does not want these sites to be accessed from external computers or devices. Your organization would like the ability to quickly disable a user in the event of a separation so that the user cannot access the SharePoint site after their account has been disabled. Finally, your organization would like to be able to customize the sign-in page so that users know they are logging in to a corporate site.

Organizational goals

Your organization’s goals for its hybrid identity solution are:

  • Ability to manage identities in the on-premises directory with identities in the cloud.

  • Ability to quickly set up synchronization with the on-premises single-forest directory.

  • Ability to provide on-premises authentication directory.

  • Ability to control who and what gets synchronized to the cloud.

  • Ability to offer single sign-on (SSO). Alerts are received if either synchronization or SSO is down.

  • Ability to restrict access to only R&D and manufacturing users who are signing in from a secure, on-premises location.

  • Ability to prevent real-time user access to cloud resources in the event of a separation.

  • Ability to quickly get on-premises identity systems cleaned up and well managed so that they can be the source for the cloud.

  • Ability to customize the sign-in page so that it presents a corporate identity.

This section describes the solution design that addresses the problem described in the previous section and provides high-level planning considerations for this design.

By using Azure AD, your organization is able to integrate the on-premises instance of Active Directory with the Azure AD instance. This instance will then be used to re-direct users to the AD FS sign-in page where they will be issued a token that is then presented to Azure AD and authentication granted.

On-premises solution

The following table lists the elements that are part of this solution design and describes the reason for the design choice.

Solution design element

Why is it included in this solution?

Azure Active Directory Sync tool

Is used to synchronize on-premises directory objects with Azure AD. For an overview of this technology, see Directory synchronization roadmap.

Active Directory Federation Services

A feature of Windows Server 2012 R2 that is a security token service (STS) that uses Active Directory as its identity store. The STS in AD FS can issue security tokens to the caller using various protocols, including OAuth, WS-Trust, WS-Federation, and Security Assertion Markup Language (SAML) 2.0. For an overview of this technology, see Active Directory Federation Services Overview.

IdFix DirSync Error Remediation Tool

Provides customers with the ability to identify and remediate the majority of object synchronization errors in their Active Directory forests. For an overview of this technology, see IdFix DirSync Error Remediation Tool.

AD FS is a feature of Windows Server 2012 R2 that allows federation between your on-premises Active Directory and Azure AD. This feature enables users to log in to their Azure AD services (such as Office 365, Intune, and CRM Online) by using an SSO experience. This will provide your users with the ability to have SSO that uses your on-premises Active Directory instance as the authentication provider.

The IdFix DirSync Error Remediation Tool can be used to perform discovery and remediation of identity objects and their attributes in an on-premises Active Directory environment in preparation for migration. This will allow you to quickly identify any issues that may occur with synchronization before you start synchronizing. Using this information, you can make changes to your environment so that you can avoid these errors.

Why are we recommending this design?

This design is recommended because it addresses the design goals of your organization. That is, there are two ways to provide authentication to Azure based resources: through cloud authentication or on-premises authentication using an STS.

One of your organization’s main concerns is that they have the ability in real time to stop a user who may have been separated from the corporation from accessing the cloud-based resources. There is up to a three-hour lag associated with using the Azure Active Directory Synchronization Tool and cloud authentication. That is, if you disable a user account on-premises, it may take up to three hours for that change to appear in Azure. This is not the case if the user must come back to the on-premises environment and authenticate. If a user account is disabled on-premises, that user will not be able to receive a token and will not be authorized to access the cloud resources.

Your organization wants the ability to provide SSO. This can be accomplished only by federating your on-premises instance of Active Directory with Azure AD.

The ability to customize the sign-in page is available only by using AD FS and AD FS customization.

What are the high-level steps to implement this solution?

You can use the steps in this section to implement the solution. Make sure to verify the correct deployment of each step before proceeding to the next step.

  1. Prepare for single sign-on (SSO)

    To prepare, you must make sure your environment meets the requirements for SSO and verify that your Active Directory and Azure AD tenant are set up in a way that is compatible with SSO requirements. For more information, see Prepare for single sign-on.

  2. Set up your on-premises security token service—AD FS

    After you have prepared your environment for SSO, you will need to set up a new on-premises AD FS infrastructure to provide your local and remote Active Directory users with SSO access to the cloud service. If you currently have AD FS in your production environment, you can use it for SSO deployment rather than setting up a new infrastructure as long as it is supported by Azure AD. For more information about how to get started with setting up an AD FS STS, follow the steps provided in Checklist: Use AD FS to implement and manage single sign-on.

  3. Install Windows PowerShell for single sign-on with AD FS

    The Azure AD Module for Windows PowerShell is a download for managing your organization’s data in Azure AD. This module installs a set of cmdlets in Windows PowerShell that you run to set up SSO access to Azure AD and in turn to all of the cloud services to which you are subscribed. For more information, see Install Windows PowerShell for single sign-on with AD FS.

  4. Set up a trust between AD FS and Azure AD

    You need to establish a trust between Azure AD and your on-premises Active Directory. Each domain that you want to federate must either be added as a single sign-on domain or converted to be a single sign-on domain from a standard domain. Adding or converting a domain sets up a trust between AD FS and Azure AD. For more information, see Set up a trust between AD FS and Azure AD.

  5. Prepare for directory synchronization

    Verify system requirements, create the right permissions, and allow for performance considerations. For more information, see Prepare for directory synchronization. After you complete this step, verify you have a completed worksheet showing your selected solution design options.

  6. Activate directory synchronization

    Activate directory synchronization for your company. For more information, see Activate directory synchronization. After you complete this step, verify you have the features configured.

  7. Set up your directory synchronization computer

    Install the Azure AD Synchronization Tool. If you’ve already done so, learn how to upgrade, uninstall, or move it to another computer. For more information, see Set up your directory sync computer. After you complete this step, verify you have the features configured.

  8. Synchronize your directories

    Perform an initial sync and verify that the data synchronized successfully. You will also learn how to configure the Azure AD Synchronization Tool to set up recurring synchronization and how to force directory synchronization. For more information, see Use the Configuration Wizard to sync your directories. After you complete this step, verify you have the features configured.

  9. Activate synced users

    Activate the users in the Office 365 portal before they can use the services to which you have subscribed. This involves assigning them a license to use Office 365. You can do this individually or in bulk. For more information, see Activate synced users. After you complete this step, verify you have the features configured. Note that this is an optional step and is required only if you are using Office 365.

  10. Verify the solution.

    After the users have been synchronized, test logging in to https://myapps.microsoft.com. You should be redirected to the AD FS sign-in page. After you have signed in and AD FS has authenticated the user, the user will be redirected back to https://myapps.microsoft.com. If you have Office 365 applications, you will see them here. A regular user can log in here without needing an Azure subscription.

See Also

Content type

References

Product evaluation/ Getting started

Test Lab Guide: Creating an Azure AD and Windows Server AD Environment Using DirSync with Password Sync 

Test Lab Guide: Creating an Azure AD and Windows Server AD Environment with Federation (SSO)

Planning and design

AD FS Design Guide in Windows Server 2012

Directory integration

Deployment

Windows Server 2012 R2 AD FS Deployment Guide

Directory synchronization roadmap

Single sign-on roadmap

Operations

AD FS Operations

Support

Troubleshoot directory synchronization

Forefront Identity Manager Forum

Azure Forums

Reference

Checklist: Use AD FS to implement and manage single sign-on

Determine which directory integration scenario to use

Community resources

Cloud Identity

Related solutions

Streamlined management for mobile devices and computers in a hybrid environment

Related technologies

Azure

Forefront Identity Manager 2010 R2

Active Directory Federation Services