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 that the organization acquires is Azure Active Directory . In this article, we’ll talk about some of the differences between Active Directory and Azure Active Directory, as well as the main scenarios of their synchronization.
I’m sure that the vast majority of those reading this article are familiar with Active Directory, which is part of the Windows Server operating systems and is a directory service offered by Microsoft. With an AD account, the user is authenticated to the system and gains access to applications, file services, printers, and other local resources.
')
Just like the local Active Directory, Azure Active Directory authenticates users and gives them access to applications. However, Azure Active Directory is designed to work with the user not in the local infrastructure, but when working with third-party cloud applications, such as Office365 and Windows Intune.
For example, your organization purchases a Windows Intune subscription. At the same time, you, as an administrator, are accessing the Windows Intune Management Portal and must provide access to other users on your network (all or several - these are details). Windows Intune is a Microsoft cloud service that does not work with the local Active Directory. In order to create user accounts to access 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-based applications can interact with the data using the Graph API. Authentication in AD DS uses the Kerberos protocol, and Azure Active Directory uses OAuth 2.0. The diagram below shows how applications hosted either locally or in the cloud use similar methodologies for accessing credential data that is stored in the credential service that is most suitable for them.
But back to our example. The company has acquired a subscription for Windows Intune, and now the system administrator must create user accounts in Azure AD. He can do it of course with pens through a graphical interface or even use cmdlets and PowerShell scripts. But using this option of adding users, you create absolutely independent users who are not connected with those that have long existed in your local grid. Yes, logins may be the same, but they may differ; passwords - even more so. All this is a huge source of potential headaches for the admin and regular calls from users to the support service. In order to minimize these problems, three scenarios of AD and Azure AD are proposed, which we will discuss later.
There are three main scenarios for Active Directory and Azure Active Directory directory synchronization:
All this, of course, sounds great, but it is more interesting to see how each of the synchronization scenarios works and what its fundamental feature is.
Directory synchronization script is used to synchronize local domain network objects to the cloud. When you implement this scenario, you end up with a user account in Azure Active Directory that will match the local account in everything except the password. Passwords when implementing a directory synchronization script are NOT synchronized. Therefore, now you tell your users that, for example, you can use your normal login to access, for example, Windows Intune, but you will need to create 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 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:
Still, the sore point of user accounts are not logins, but passwords. Login is usually not difficult to remember, but to have different passwords for access to different resources is a test for the user.Therefore, he either comes up with simple passwords, or writes them on stickers and glues to the monitor , or he guesses to use the same password everywhere . There is an extension of the directory synchronization script - password synchronization script. If you enable password synchronization on a computer with directory synchronization already implemented, your organization’s employees will be able to connect to Microsoft cloud services (for example, Office 365, Dynamics CRM, Windows InTune) using a password from a local account. Changing the password in the local corporate network will be synchronized with the cloud, and passwords are synchronized more often than other directory data.
The following is a diagram of Active Directory synchronization using a password synchronization script. In order for the password to be synchronized, the directory synchronization tool retrieves the user's password hash from the local Active Directory and synchronizes it with the Azure Active Directory.
Now, with peace of mind, we are telling users that we are using a new cloud service, access to which can be obtained with our usual login and password. Everyone is happy, everyone is happy.
When using this synchronization scenario, among the advantages you need to note:
However, when implementing the password synchronization script, 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 for our idea to be implemented, you must use an Active Directory synchronization script using single sign-on.
To implement single sign-on, a directory synchronization script must be implemented and the security token service infrastructure (STS) must be 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 process for running a single sign-on script is presented in the following diagram.
When implementing a single sign-on scenario, a federated relationship is established between the Security Token Service (STS) and the Azure Active Directory authentication system. When attempting to connect to the cloud service, the user will be redirected to the STS 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, a user with an account in the local Active Directory will receive an authentication token from the local STS and with which he will get access to the cloud-based service. The principal difference from the first two scenarios is that in the single sign-on scenario the user is authenticated using Windows Server Active Directory.
Applying a single sign-on script offers a major advantage: an employee uses his credentials to access cloud applications and services. System administrators also receive a number of new features:
I hope this article has given you an idea of the difference between Active Directory and Azure Active Directory and their synchronization scripts.
Detailed instructions on how to implement each of the scenarios described here, you can look at the TechnNet portal:
Thank!
I’m sure that the vast majority of those reading this article are familiar with Active Directory, which is part of the Windows Server operating systems and is a directory service offered by Microsoft. With an AD account, the user is authenticated to the system and gains access to applications, file services, printers, and other local resources.
')
Just like the local Active Directory, Azure Active Directory authenticates users and gives them access to applications. However, Azure Active Directory is designed to work with the user not in the local infrastructure, but when working with third-party cloud applications, such as Office365 and Windows Intune.
For example, your organization purchases a Windows Intune subscription. At the same time, you, as an administrator, are accessing the Windows Intune Management Portal and must provide access to other users on your network (all or several - these are details). Windows Intune is a Microsoft cloud service that does not work with the local Active Directory. In order to create user accounts to access 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-based applications can interact with the data using the Graph API. Authentication in AD DS uses the Kerberos protocol, and Azure Active Directory uses OAuth 2.0. The diagram below shows how applications hosted either locally or in the cloud use similar methodologies for accessing credential data that is stored in the credential service that is most suitable for them.
But back to our example. The company has acquired a subscription for Windows Intune, and now the system administrator must create user accounts in Azure AD. He can do it of course with pens through a graphical interface or even use cmdlets and PowerShell scripts. But using this option of adding users, you create absolutely independent users who are not connected with those that have long existed in your local grid. Yes, logins may be the same, but they may differ; passwords - even more so. All this is a huge source of potential headaches for the admin and regular calls from users to the support service. In order to minimize these problems, three scenarios of AD and Azure AD are proposed, which we will discuss later.
Synchronize Active Directory and Azure Active Directory
There are three main scenarios for Active Directory and Azure Active Directory directory synchronization:
- The directory synchronization script allows you to automatically synchronize with the cloud new user and group accounts, 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.
- Active Directory synchronization using a password synchronization script in addition to directory synchronization capabilities allows users to use a local account password to access cloud applications and services, which in turn reduces password administration costs and allows you to manage password policies from the local directory Active Directory.
- Active Directory synchronization using a single sign -on script, unlike the first two scenarios, does not support the ability to enable multi-factor authentication solution in the cloud, but it supports this feature in the local environment, and also provides user authentication in the local Active Directory and allows scripts to be implemented 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 endpoint of the Exchange client.
All this, of course, sounds great, but it is more interesting to see how each of the synchronization scenarios works and what its fundamental feature is.
1 Directory synchronization script
Directory synchronization script is used to synchronize local domain network objects to the cloud. When you implement this scenario, you end up with a user account in Azure Active Directory that will match the local account in everything except the password. Passwords when implementing a directory synchronization script are NOT synchronized. Therefore, now you tell your users that, for example, you can use your normal login to access, for example, Windows Intune, but you will need to create 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 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:
- Reduced administration costs. With existing local user and group accounts, there is no need to manage them manually in Azure AD, which saves 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.
- Enhance security. Granting access and revoking it to user accounts and groups is automatic, which allows you to guarantee access to corporate network resources only to those who really need it, and also indicate the period for which access is granted.
2 Synchronize Active Directory with Password Synchronization Script
Still, the sore point of user accounts are not logins, but passwords. Login is usually not difficult to remember, but to have different passwords for access to different resources is a test for the user.
The following is a diagram of Active Directory synchronization using a password synchronization script. In order for the password to be synchronized, the directory synchronization tool retrieves the user's password hash from the local Active Directory and synchronizes it with the Azure Active Directory.
Now, with peace of mind, we are telling users that we are using a new cloud service, access to which can be obtained with our usual login and password. Everyone is happy, everyone is happy.
When using this synchronization scenario, among the advantages you need to note:
- Reduced operating costs. Reducing the number of passwords that a user needs to work on a 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 script, 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 for our idea to be implemented, you must use an Active Directory synchronization script using single sign-on.
3 Active Directory synchronization using single sign-on script
To implement single sign-on, a directory synchronization script must be implemented and the security token service infrastructure (STS) must be 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 process for running a single sign-on script is presented in the following diagram.
When implementing a single sign-on scenario, a federated relationship is established between the Security Token Service (STS) and the Azure Active Directory authentication system. When attempting to connect to the cloud service, the user will be redirected to the STS 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, a user with an account in the local Active Directory will receive an authentication token from the local STS and with which he will get access to the cloud-based service. The principal difference from the first two scenarios is that in the single sign-on scenario the user is authenticated using Windows Server Active Directory.
Applying a single sign-on script offers a major advantage: an employee uses his credentials to access cloud applications and services. System administrators also receive a number of new features:
- Policy management. The 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 requests for support. It's all the same: remember fewer passwords - fewer calls from users.
- Security. Since all servers and services used within the implementation of the single sign-on scenario are managed and controlled locally, user identities and information about them are protected.
- Support strong authentication. A single sign-on script allows for multi-factor authentication to access a cloud service or application.
I hope this article has given you an idea of the difference between Active Directory and Azure Active Directory and their synchronization scripts.
Detailed instructions on how to implement each of the scenarios described here, you can look at the TechnNet portal:
- Directory synchronization script
- Active Directory synchronization using password synchronization script
- Active Directory synchronization using single sign-on script
Thank!
useful links
- Try Azure for free for 30 days!
- Explore Microsoft Virtual Academy courses on cloud and other technologies
- Download free or trial Visual Studio
- Microsoft Azure Development Center (azurehub.ru) - scripts, tutorials, examples, design recommendations
- Twitter.com/windowsazure_ru - the latest Microsoft Azure news
- Microsoft Azure Community on Facebook - experts, questions
- Become a universal Windows application developer
Source: https://habr.com/ru/post/241313/
All Articles