Active Directory traditionally used to manage elements of a domain-based network. But companies increasingly implement various cloud services that require its own user accounts. A tool for creating and managing user accounts, that are used by different Microsoft cloud services, which a company acquires, is Azure Active Directory.
This article describes some differences between Active Directory and Azure Active Directory. We also consider the basic synchronization scenarios.
It is assumed that the reader is familiar with the use of Active Directory, which is actually the part of Windows Server Operational Systems, and is the directory service provided by Microsoft.
If you have Active Directory user account, you can use it to pass the authentication process and get the access to applications, file services, printers, and other local resources.
Azure Active Directory provides authentication for users and grants them access to applications, in the same way as the local Active Directory. However, Azure Active Directory allows users to work with third-party cloud applications such as Office 365 and Windows Intune (not local infrastructure).
For example, your company purchases the Windows Intune subscription. Upon that, you as the administrator get access to the Windows Intune management portal and need to grant access to other users on your network. Windows Intune is the Microsoft cloud service, which does not work with your local Active Directory. To create user accounts for accessing cloud services, which uses the company, you must use Azure Active Directory. To access data in local Active Directory, business applications can use LDAP. Third-party cloud applications can interact with data by using API Graph.
In Active Directory the Kerberos protocol is used for authentication. Azure Active Directory uses OAuth 2.0 to enable you to authorize access to web applications and web APIs in your Azure AD tenant.
The following diagram illustrates how the applications hosted either locally or in the cloud, using a similar methodology to access identity information that is stored in the most appropriate identity service for them.
Let’s go back to our scenario. The company has purchased a subscription to Windows Intune, and now the system administrator must create an Azure AD accounts for users. For this purpose, the system administrator can use GUI or even use PowerShell commands and scripts. However, in this case, you create independent users, unrelated to those that already exist in your local network. Their logins may coincide, but can be different. Passwords must be different. Generally speaking, this is a source of potential headaches for the administrator. This will lead to regular support calls.
Synchronization of Active Directory and Azure Active Directory
There are three primary scenarios for synchronization Active Directory and Azure Active Directory:
Directory Sync Scenario allows you to:
— automatically sync with the cloud new user accounts and groups
— automatically sync updates 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.
Password Sync Scenario enables users to use the password of 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 your on-premises Active Directory.
Single Sign-On Sync. Unlike the first two scenarios, this scenario does not support multi-factor authentication in the cloud. However, it supports multi-factor authentication in the local environment, as well as ensures authentication of users in your local Active Directory.
It also allows you to implement a single sign-on scenario with use corporate credentials, configure single sign-on page and limit access to cloud-based services and applications by location, type of client or Exchange client endpoint.
Let’s examine these scenarios in more details.
Directory Sync Scenario
This scenario is used to synchronize the local objects, located in a domain network with the cloud. By implementing this scenario, eventually, you get a user account in Azure Active Directory, that will coincide (except the password, as far as passwords do not sync) with the local user account. You can notify users that they can use their usual login to get an access to Windows Intune. All they need to do is to create a new password. In such a case, a user will be authenticated with Azure Active Directory. The following diagram demonstrates the process.
Once it is configured, administrators can manage directory objects using the local Active Directory and the changes will be synchronized with client computers. Directory synchronization is run on schedule and is synchronized with the Azure AD.
The main advantages are:
Reduction of administration costs. While using already existing local user and group accounts, you do not need to manage them manually in the Azure AD, which saves time and budget.
Productivity increase. Automatic synchronization of user accounts and groups reduces the time required to provide user access to cloud services and applications.
Safety benefits. Automatic access grant and access lock for a user and group accounts. It allows to guarantee access to resources on the corporate network only to those who really need it and specify the period for which access is granted.
Password Sync Scenario
The passwords are the bottleneck of user accounts, not logins. It is quite a simple task to remember logins, however having different passwords to access different resources could become a problem. That’s why users come up with simple passwords, or put passwords down on stickers and attach the stickers to the screens, or even use the same password everywhere.
If there is the Directory Sync Scenario is implemented on a PC and you additionally implement Password Sync Scenario on the same PC, then users are able to connect to the cloud-based Microsoft services (for example, Office 365, Dynamics CRM, Windows InTune) by using the password of a local account.
All password changes in the local corporate network will be synchronized with the cloud. In particular, the passwords are being synchronized more frequently than other directory data.
The following diagram illustrates the Active Directory synchronization with the help of the Password Sync scenario. To synchronize passwords, the directory synchronization tool retrieves the user’s password hash from the local Active Directory and synchronizes it with Azure Active Directory.
Now you can notify users that we use a new cloud-based service that can be accessed with your usual user ID and password. Everyone is happy.
The main advantages are:
Reduction of operating costs. Reducing the number of passwords that are required for the user to work on a corporate network, entails a reduction in the number of password reset requests to technical support.
Productivity increase. Reducing the number of passwords that a user needs to access the business resources increases the time during which these resources are available.
However, when you implement the password sync scenario, the user still need to go through authentication process by using Azure Active Directory account. We want to go further and use local Active Directory to authenticate users. For this, we need to use the Single Sign-On Sync scenario.
Single Sign-On Sync Scenario
In order to implement Single Sign-On Sync Scenario, the Directory Sync Scenario must be implemented first. Also, the Security Token Service (STS) must be implemented. Azure Active Directory supports Single Sign-On Sync Scenarios that use one of the following security token services: Active Directory Federation Services, Shibboleth identity provider, and third-party identity providers. The following diagram demonstrates the process.
When you implement single sign-on, federated relationships are configured between Security Token Service and the Azure Active Directory authentication system. The user, while attempting to connect to the cloud-based service will be redirected to the STS server. For example, when using ADFS, the user will be redirected to the ADFS server. You can see this in the browser’s address bar.
After successful authentication, a user with local Azure Active Directory account gets the authentication token from the local STS. The token provides access to the cloud-based service.
The main advantages are:
An employee uses their credentials to access cloud-based applications and services. System administrators also get a number of new features:
Policy management. The administrator does not need to perform any additional tasks in the cloud in order to control the account policies in Active Directory.
Access control. The administrator can restrict access to cloud services in such a way that access could be obtained only through an enterprise environment or over the Internet server.
Reduce the number of support calls. Users do not need to remember many different passwords.
Security. Because all of the servers and services that are used as part of a single sign-on scenario are managed and controlled locally, user identities and information are reserved.
Strong authentication support. The single sign-on scenario allows you to implement multifactor authentication to access a cloud service or application.
