October 23, 2014 at 11:11

Active Directory vs. Azure Active Directory

    Traditionally, Active Directory is used to manage the corporate network. But increasingly, organizations are introducing various cloud services into their work that require the creation of their accounts. The tool for creating and managing user accounts used in various Microsoft cloud services purchased by the organization is Azure Active Directory . In this article, we will talk about some of the differences between Active Directory and Azure Active Directory, and also look at the main scenarios for their synchronization.




    I am sure that the vast majority of those who read this article are familiar with Active Directory, which is part of the Windows Server operating systems and is a directory service offered by Microsoft. Having an AD account, the user authenticates in the system and gets access to applications, file services, printers and other local resources.

    Like local Active Directory, Azure Active Directory authenticates users and gives them access to applications. However, Azure Active Directory is not intended for the user to work in the local infrastructure, but when working with third-party cloud applications such as Office365 and Windows Intune.

    For example, your organization purchases a subscription to Windows Intune. At the same time, you, as an administrator, gain access to the Windows Intune management portal and must provide access to other users on your network (all or several of them are already details). Windows Intune is a Microsoft cloud service that does not work with on-premises Active Directory. In order to create user accounts to access the cloud services that the organization implements and uses, you must use Azure Active Directory.

    From a technical point of view, it should be noted that business applications can use LDAP to access data in the local Active Directory service, and third-party cloud applications can interact with data using the Graph API. Kerberos protocol is used for authentication in AD DS, and OAuth 2.0 is used in Azure Active Directory. The diagram below shows how applications hosted either locally or in the cloud use similar methodologies to access credential data that is stored in the most suitable identity service.



    But back to our example. The company has purchased a subscription to Windows Intune, and now the system administrator must create user accounts in Azure AD. Of course, he can do this with handles via a graphical interface or even use PowerShell cmdlets and scripts. But, using this option of adding users, you create completely independent users, not connected in any way with those that have long existed in your local grid. Yes, logins can be the same, but they can be different; passwords - even more so. All this is a huge source of potential headache for the administrator and regular calls from users to the support service. In order to minimize these problems, we propose three scenarios for synchronizing AD and Azure AD, which we will discuss later.

    Sync Active Directory and Azure Active Directory



    There are three main scenarios for synchronizing Active Directory and Azure Active Directory:
    1. A directory synchronization script allows you to automatically synchronize new user and group accounts with the cloud, upgrade to existing accounts in the local Active Directory, configure the client to work in combined scenarios using Office 365, and enable multi-factor authentication solutions in the cloud.
    2. Active Directory synchronization with a password synchronization script, in addition to directory synchronization capabilities, enables users to use a password from a local account to access cloud-based applications and services, which in turn reduces the cost of administering passwords and allows you to manage password policies from the local directory Active Directory
    3. Active Directory synchronization using a single sign -on script, unlike the first two scenarios, does not support the ability to enable multi-factor authentication solutions in the cloud, but it does support this feature in the on-premises environment, and also provides user authentication in the local Active Directory and allows implementing scripts single sign-on using corporate credentials, configure the page for single sign-on and restrict access to cloud services and applications by location, client type or the Exchange client endpoint.

    All this, finished, sounds wonderful, but it is more interesting to see how each of the synchronization scenarios works and what its fundamental feature is.

    1 Directory synchronization script


    The directory synchronization script is used to synchronize the local domain network objects to the cloud. When implementing this scenario, you end up with a user account in Azure Active Directory that matches the local account in everything except the password. Passwords when implementing a directory synchronization script are NOT synchronized. So now you are telling your users that you can use your usual username to access, for example, Windows Intune, but you will need to come up with a different password. In this case, the user will be authenticated using the Azure Active Directory when accessing the cloud service. An example diagram of how this process works is presented below.



    After the configuration is complete, administrators can manage directory objects using the local Active Directory, and these changes will be synchronized with client computers. Directory service synchronization is scheduled and synchronized with Azure AD.

    Among the advantages of the directory synchronization script are:
    • Reduce administration costs. Using existing local user and group accounts, you don’t need to manually manage them in Azure AD, which saves you budget and time.
    • Increase productivity. Automatic synchronization of user accounts and groups reduces the time required to provide the user with access to cloud services and applications.
    • Increase security. Granting access and its revocation for user accounts and groups occurs automatically, which allows guaranteeing access to the resources of the corporate network only to those who really need it, and also indicate the period for which access is granted.


    2 Active Directory synchronization with a password synchronization script


    Still, the sore spot of user accounts are not logins, but passwords. Usually it’s not difficult to remember a login, but having different passwords to access different resources is a test for the user. Therefore, he either invents simple passwords, or writes them on stickers and glues them to a monitor , or he realizes that he will use the same password everywhere .There is an extension of the directory synchronization script - a password synchronization script. If you enable password synchronization on a computer with already implemented directory synchronization, then your organization’s employees will be able to connect to Microsoft cloud services (for example, Office 365, Dynamics CRM, Windows InTune) using the password from the local account. Changing the password on the local corporate network will be synchronized with the cloud, and passwords are synchronized more often than other directory data.

    The following is an outline of Active Directory synchronization using a password synchronization script. To keep the password synchronized, the directory synchronization tool retrieves the user's password hash from the on-premises Active Directory service and synchronizes it with Azure Active Directory.



    Now, with a calm mind, we tell users that we are using a new cloud service, access to which can be obtained with our usual username and password. Everyone is happy, everyone is happy.

    When using this synchronization scenario, among the advantages it should be noted:
    • Reduce operating costs. Reducing the number of passwords that the user needs to work on the corporate network entails a decrease in the number of requests to change the password to the support service.
    • Increase productivity. Reducing the number of passwords that a user needs to access certain corporate resources increases the time during which these resources are available.


    However, when implementing the password synchronization scenario, the user still goes through the authentication process using the Azure Active Directory account, and we want to go further and use the local Active Directory for authentication. In order to implement our idea, you must use the Active Directory synchronization script using single sign-on.

    3 Active Directory Sync with Single Sign-On

    To implement single sign-on, a directory synchronization script must be implemented and the security token service (STS) infrastructure built. Azure AD supports single sign-on scripts that use one of the following security token services: Active Directory Federation Services, Shibboleth identity provider, and third-party identity providers.

    The single sign-on script process is shown in the following diagram.


    When implementing a single sign-on scenario, federated relationships are set up between the Security Token Service (STS) and the Azure Active Directory authentication system. When trying to connect to the cloud service, the user will be redirected to the STS service server. For example, when using ADFS, the user will be redirected to the ADFS server, which can be seen by changing the address in the browser:


    After successful authentication, the user with the local Active Directory account will receive an authentication token from the local STS and with which it will gain access to the cloud service. The fundamental difference from the first two scenarios is that in a single sign-on scenario, the user is authenticated using Windows Server Active Directory.

    Using a single sign-on scenario offers a major advantage: an employee uses their credentials to access cloud-based applications and services. System administrators also get a number of new features:
    • Policy Management. An administrator does not need to perform any additional tasks in the cloud in order to control Active Directory account policies.
    • Access control. An administrator can restrict access to cloud services so that access can only be obtained through the organization’s environment or through an Internet server.
    • Reducing the number of calls for support. Everything is the same here: less passwords to remember - less calls from users.
    • Security. Since all servers and services used as part of the single sign-on scenario are managed and controlled locally, user credentials and information about them are protected.
    • Strong authentication support. A single sign-on script enables multi-factor authentication to access a cloud service or application.


    I hope this article gave you an idea of ​​the difference between Active Directory and Azure Active Directory and their synchronization scenarios.

    Detailed instructions on how to implement each of the scenarios described here can be found on the TechnNet portal:
    1. Directory Sync Script
    2. Active Directory synchronization with a password synchronization script
    3. Active Directory Sync with Single Sign-On


    Thanks!

    useful links


    Tags:

    Also popular now: