다음을 통해 공유

Azure Active Directory: Introduction

  • 아티클

 

↑ Back to top

Introduction

Managing identity is a big challenge in today’s heterogeneous IT infrastructure, where user can log on from anywhere, which includes corporate network, partner network, public cloud, private cloud etc. Also, users can use different types of devices to login which includes desktop, laptop , mobile to name a few. Without a central authentication and access management source, it is very difficult to manage who can login to what, and who can do what with these resources.

Azure Active Directory (AD) is the Microsoft’s way to encounter this challenge.

 

↑ Back to top

About Azure AD

Azure Active Directory is the Identity and Access Management (IAM) solution offered by Microsoft.

Azure AD can authenticate accounts from different sources, which are as follows:

  • Azure Subscription
  • Office 365 Subscription
  • Microsoft Intune and Dynamics Subscription
  • Third Party cloud based SaaS applications (which supports Azure AD authentication)
  • On Premise Active Directory accounts

Important points regarding Azure AD

  • If an organization is already having Azure or Office 365 subscription, it is already having a tenant in Azure AD. Similarly, if an organization is already using products like SharePoint Online or Lync Online, they are already using Azure AD for authentication and access management. This is because the IAM services for all these products are catered by Azure AD.
  • Azure AD supports both single tenant and multi-tenant options. In single tenant mode, it accepts authentication request only from its own tenant. In multi-tenant mode, it accepts authentication requests from its own as well as other Azure tenants. This is typically useful if an application needs to be published in one Azure AD tenant, which can be used by other Azure AD tenant users.
  • Azure AD deployment does not require an on premise deployment of Active Directory. Azure AD can exist and function independently, without on premise Active Directory. However, if an organization is already using on premise Active Directory, they can integrate that with Azure AD. We will discuss that in detail in the upcoming sections.
  • Azure AD is an IDaaS (ID as a Service) solution from Microsoft. If an organization deploys Domain Controllers in Azure VMs, and connect it with on premise Domain Controllers (through Express Route or Site-to-Site VPN) that is not an Azure AD implementation. 

 

↑ Back to top

Azure AD vs. on Premises Active Directory

It is important to understand that Azure AD is not a replacement of on Premises Active Directory, which is shipped with Microsoft Windows Server. Let’s discuss some of the key differences between on Premises AD and Azure AD.

  • There are five major services offered by on Premises AD, which includes ADDS (Active Directory Domain Service), ADCS (Active Directory Certificate Service), ADFS (Active Directory Federation Service), ADLDS (Active Directory Lightweight Directory Service) and ADRMS (Active Directory Rights Management Service). On the other hand, Azure AD offers only IAM (Identity and Access Management) Service, which is Authentication and Authorization.
  • We do not create AD Forest and AD Domain within Azure AD. Instead, we create Tenant in Azure AD, which typically represents an entire organization.
  • There is no concept of Global Catalog, Group Policies and FSMO role in Azure AD.
  • ADDS uses Kerberos /NTLM protocols for Authentication, and LDAP for Directory browsing. Azure AD does not support these protocols. Azure AD uses SAML 2.0 / WS-Fed / OAuth 2.0 for authentication, and REST over HTTPS for directory browsing.
  • We do not need to promote Domain Controllers or manage replication in Azure AD. Since Azure AD is a PaaS offering, these backend tasks are managed by Microsoft. Also, we do not need to worry about patching / updating / securing Domain Controllers in Azure AD for the same reason. In fact, Domain Controllers are not visible in Azure AD.

 

↑ Back to top

Relationship between Azure subscription and Azure AD

  • Azure subscription has a trust relationship with Azure AD. Having a trust relationship means that subscription trusts and accepts Azure AD to authenticate users, services and devices.
  • Multiple subscriptions can trust the same directory, but each subscription cannot trust  more than one Azure AD directory.
  • The trust relationship between subscription and Azure AD is different, than the relationship between subscription and other Azure resources (Ex: VM, VNET, Databases etc). 

If an Azure subscription expires, access to all the resources associated with that subscription would also be blocked. However, there would be no impact in corresponding Azure AD to which the subscription was pointing to , and it can be re used by associating the same Azure AD directory with a new subscription.

For more details, please refer this article.

 

↑ Back to top

Azure AD Editions

There are four different editions available for Azure AD, which are as follows:

  1. Free
  2. Basic,
  3. Premium P1
  4. Premium P2

Important points regarding Azure AD Editions:

  •  Azure AD Free Edition is included by default with every Azure subscription. Basic and Premium Editions need to be purchased separately based on the organization requirement.
  •  The free edition offers maximum 5,00,000 Directory Object creation. However, this limit in free edition is not applicable for O365 / Intune or any other Microsoft paid services that use Azure AD for Identity and Access Management.
  •  The Premium P2 Edition includes all features of all other editions, with some additional features.

The below image captures the features offered by different editions. However, as Microsoft keeps on adding new features , we recommend to refer this link for the up to date information.

 

↑ Back to top

Azure MFA (Multi Factor Authentication)

While discussion Azure AD, it is worth covering the topic of Azure MFA.

Multi Factor Authentication (MFA) enhances the security, by enabling more than one verification method while authenticating user sign-in. 

Typically, password verification is the most common way of authentication. However, it is recommended to use more than one authentication method rather than just relying on password verification. Using Azure MFA, we can deploy two step (or more) verification solution.

Additional Verification method includes:

  • Phone call
  • Text message
  • Mobile app notification
  • Mobile app verification code
  • Third party OATH tokens

Azure MFA (Full Version) can be deployed either in the cloud or on-premises.

Based on the requirement and deployment scenarios, there are different versions available for Azure MFA:

  • MFA for Office 365: Designed exclusively for O365, and this is managed from the O365 portal. 
  • MFA for Azure AD Admins:  This is a free feature available in all Azure AD editions. Using this feature, two steps MFA can be enabled for Azure AD Global Admin accounts. Please note that this version works only for the Global Admins accounts, and not for other Azure AD accounts.
  • Azure MFA: This is the full version of Azure MFA, with all capabilities. This version is included in below editions:
    • Azure Active Directory Premium editions.
    • Azure “Enterprise Mobility + Security” edition.

Please note that MFA is single tenant, whether created in on-premises or azure. We can have primary and secondary MFA. If we have to create MFA for different customer, we need separate AAD tenant.

The detailed discussion on Azure MFA is beyond the scope of this article. Please refer these links for more information on MFA:

 

↑ Back to top

Azure AD B2B

Azure AD B2B is an additional feature which is available in all Azure AD editions, including Free Edition. This feature allows an organization to invite users from other organizations to share application, documents and other resources. Also, developers can use Azure B2B APIs to develop applications which can be used in a collaborative way across multiple organizations.

For Example, Organization A is using an Azure AD Tenant A in Subscription A, and Organization B is using an Azure AD Tenant B or any other IAM solution. Now organization A has deployed an Application A , which is using Azure AD A for Authentication. Organization A wants that users from Organization B can access Application A ,using their existing accounts. 

There are multiple advantages of Azure B2B, and the key advantages are as follows:

  • Organization who wants external users to access application or resources, can invite external users through their Azure AD. These external users are called guest users.
  • Guest users use their own credential, and getting authenticated by their own IAM solution which could be Azure AD or something else. No additional account need to be created in Azure AD.
  • Access to the resources is still controlled by the organization who is granting access to the application or resources, in this case Organization A.
  • For B2B model to work, it is not mandatory for partners to use Azure AD.

If required, we can convert guest user to member user using MsolUser command.

For more information on Azure B2B, please refer this article.

 

↑ Back to top

Azure AD B2C

Azure AD B2C (Business to Consumer) is a separate service from Azure AD. 

The main purpose of Azure AD B2C is to allow organizations to build a cloud identity directory for their customers. This means, customers can login using their existing email ID, or using their social media account. There are multiple advantages of this model, which are as follows:

  •  Business does not need to worry about managing millions of user accounts, password management, password reset etc.
  •  Users do not need to create separate account to login to each web site. They can use their existing account to login, example: their Facebook or LinkedIn account.
  •  MFA (Multi Factor Authentication) can also be implemented for two step authentication.

For more information on Azure B2C, please refer this article.

 

↑ Back to top

Integrate Azure AD with on premise AD

As mentioned earlier, on premise AD is not mandatory for Azure AD deployment. However, organizations who already have on premises Active Directory implemented would like to integrate that with Azure AD. 

The benefit of integrating on premises AD with Azure AD is, users / services can use their on premises credential to login to Azure AD / Office 365 or any other cloud based SaaS services which are getting authenticated to Azure AD.

Azure AD Connect

Microsoft recommends to use Azure AD Connect tool , to integrate on premises Active Directory with Azure AD and Office 365.  Previously, Microsoft released many other tools for this purpose which included DirSync and Azure AD Sync, however Microsoft strongly recommends to depreciate all those tools and upgrade to Azure AD Connect.

Azure AD connect is a free tool, and synchronizing users to Azure AD is a free feature which does not need any paid subscription.

There are three major components of Azure AD Connect, which are as follows:

Synchronization

Azure Active Directory Connect synchronization services is the main component of Azure AD Connect. This component is responsible for the synchronization between on premises and Azure AD.

The sync service consists of below two components:

  1.  On Premises: Azure AD Connect Sync (Sync Engine)
  2.  Azure AD side: Azure AD Connect sync service

AD FS

Azure AD Connect also offers a solution for federated login, using on premises ADFS. If an organization has already deployed ADFS, they can leverage this feature once they integrate on premise AD with Azure AD.

Health Monitoring

Azure AD Connect Health can monitor on premises Active Directory Domain Controllers, ADFS Servers and synchronization services. Please note that this service is different from Azure AD health Monitoring service.

To deploy Azure AD connect, we need to download the Azure AD connect software from Microsoft web site, and then we need to install it to a server, called as Azure AD Connect Sync Server. The Sync Server is typically installed on premises.

Azure AD Connect can be initially installed in Staging Mode, to assess the impact. In Staging Mode, it will import all credentials from on premises AD, but will not export to Azure AD.

For more information on staging mode deployment and Disaster Recovery, please refer this article.

To know the prerequisite of installing Azure AD Connect, please refer this article.

Please note that we cannot use more than one Azure AD Connect sync servers to connect to a single Azure AD tenant. Even if we need to connect multiple on premises AD Forests to a single Azure AD tenant, we need to use a single Azure AD Sync Server. If these forests are in different locations and different network, we may need to place the sync server in DMZ Network, so that all forests (and Azure AD) can access the sync server through required ports.

Azure AD connect supports many topologies, please refer to this Microsoft article for more details.

There are two different types of installation for Azure AD connect:

  • Express Settings: If we want to sync a single forest with Azure AD, then this is the recommended method. The only sign in option available in Express Settings is Password Hash Synchronization.
  • Customized Settings: Customized settings support many options which are not available in express settings. It supports many on premises topologies, including syncing multiple forests with same Azure AD tenant. It also supports additional sign in options like sign in through ADFS, or pass through authentication. In addition, it supports customized synchronization features like filtering and write back.

 

↑ Back to top

Sign in option in Azure AD

There are multiple ways to configure, how a synchronized on premise user signs in to Azure AD

These options can be configured using Azure AD Connect.

  1. Password Hash Synchronization (PHA):

    Using this feature, the Hash (Hash of Hash) of user passwords are synced with Azure AD, so that user can use same credential for login to on premises AD as well as Azure AD, O365, Intune and other SaaS applications.

  2. Pass-through authentication (PTA):

    Pass-through authentication is the latest and recommended solution from Microsoft.  PTA offers same features of PHA, but there is one notable difference. Unlike PHA, PTA does not store user passwords in Azure AD, not even in the hash format. This offers more security and greater compliance for organizations who do not want to float user passwords outside corporate network. One of the advantages of Pass through authentication is, we do not need to deploy ADFS infrastructure for the SSO, yet we are getting the benefits of SSO. PTA works through a light agent, which would be deployed in a Windows Server 2012 R2 Domain Joined system that is deployed on premises. Also, it does not require any inbound port to be opened to the Internet.

  3. Federation with ADFS: 

    Organizations which already have an on premises ADFS infrastructure can leverage this solution. User passwords are not stored in Azure AD, and Azure AD contacts the on premise ADFS Server to validate the user credential. We can also deploy a new ADFS farm on premise and configure SSO with Azure AD, using this option.

  4. Do not configure:

    If we do not want Azure AD to handle user sign on request, we can select the option “Do not configure” in Azure AD Connect. This is typically applicable if organization is already using some SSO solution for user sign on.

For more information on Azure AD user sign in options, please refer this URL.

Azure AD Seamless Single Sign On

Azure AD Seamless SSO feature enables users to access cloud based resources from corporate network, without typing their credential.

If user is within corporate network, and trying to access some cloud based resources (Azure/O365/ other SaaS), they do not need to type their credential if this feature is enabled. However, if the same user would access the same resource outside corporate network, they need to type their credential.

Please note that seamless SSO feature is not applicable if we are using ADFS, as ADFS itself will provide the SSO feature. Azure AD seamless SSO is applicable for Password Hash Synchronization or Pass-through Authentication.

Seamless SSO feature can be enabled during Azure AD Connect installation, or after the installation. During installation, we need to check the option “Enable Single Sign-on” to enable this feature. If we want to enable it post installation, we need to go to “Change user sign-in” page and enabled seamless SSO.

For more details on seamless SSO please refer this link

 

 

↑ Back to top

Azure AD and Domain Name

Each Azure AD implementation comes with an initial domain name. The format of the initial domain name is domainname.onmicrosoft.com. By default, this is the primary domain name, which means all the user accounts are created with this domain name.

However, organizations typically have their corporate domain name which is globally registered, and which they want to use along with Azure AD. It is possible to add additional domain name to Azure AD, and make that domain name primary.   While adding custom domain name, Azure will verify whether the domain name is owned by that organization. For the verification to be successful, we need to go to our DNS zone and update a DNS entry provided by Azure. Verification sometime takes time, and once the verification is successful, the domain status will be displayed as “Verified” in Azure AD portal.

Microsoft states that we can add up to a maximum of 900 managed domain names. If we are configuring all of these domains for federation on-premises with Active Directory, then we can add up to a maximum of 450 domain names in each directory.

Using non routable domain name with Azure AD

Most organizations prefer to use non routable domain names (or internal domain names) which cannot be resolved outside the corporate network. If a company is using an internal domain name corp.org, then the UPN (user principle name) of user would be userid@corp.org.

This configuration is fine for internal use, but when we need to integrate with Azure AD, we need to use a routable domain name which can be resolved globally, and which Azure can verify. For example, we would like to use the domain example.com with Azure AD, although current UPN Suffix is userid@corp.org. Also, for many organizations, user UPN and their email addresses are different, due to the fact that AD Domain and Mail Domains are different.

By default, Azure AD connect uses the attribute “userPrincipalName” to very an on premise account, however it also gives us option to use any other attribute, for example “mail’ attribute. If the value of the userPrincipalName attribute doesn't match to any verified domain in Azure AD, then Azure AD replaces it with a default .onmicrosoft.com UPN suffix.

Some of the common solution includes 

  • Using alternate UPN suffix for on premises users, we can add additional UPN suffix. 
  • Configure Azure AD connect to use “mail” as UPN while signing to Azure AD / O365. 

For more information on this topic, please refer this URL.

 

↑ Back to top

Write-back for passwords

Password write back feature is available in Azure AD premium editions, and can be configured through Azure AD Connect.

With this feature, Azure AD can write backs passwords to on premises AD. User can update their password through self-service portal from Azure AD or O365, and the updated password is synced immediately to on premise AD. This feature is compatible with Password Hash Synchronization, Pass through authentication and ADFS.

Also, when a user resets password in Azure portal, password write back feature enforces that the new password complies with on premises password policy, in terms of password complexity, history, length , age and any other parameters which are defined in ADDS.

This feature is not supported for user accounts that exist within protected groups in on-premises Active Directory.

For more information on password write back, please refer this link.

 

↑ Back to top

Device Management in Azure AD

With the advent of cloud computing and mobile devices, users would like to use the corporate infrastructure from any place, from any device and at any time. This poses a challenge to comply with security and protect the IT assets of the organization.

The best possible solution for this problem is to allow the users to access company resources from anywhere, through their devices (or through company provided devices), at the same time to have some control on those devices.

Azure AD offers two such features for device management

  1. Registering
  2. Joining

Azure AD Device Registration

Registering a device to Azure AD creates an identity of the device in Azure AD. Once the device is registered in Azure AD, we can configure a feature called device based conditional access, which would allow login to Azure AD only through a trusted device.

Device Registration feature is suitable in the BOYD (Bring Your Own Device) scenarios, where users can log in using their personal device which is registered in Azure AD.  Some of the key benefits of Azure AD Device Registration are :

  •  Seamless MFP 
  •  SSO to company’s cloud apps.
  •  Access to on-premises apps via the Web Application Proxy and ADFS Device Registration.

It supports Windows, Android and IOS devices. We can also use MDM in conjunction with Device Registration feature to impose more control on managed devices.

Azure AD Join

Azure AD join offers all the features which are offered by Azure AD Device Registration, in addition there are few additional features. Azure AD join is primarily beneficial to manage and control corporate owned devices.

Azure AD join offers few additional features, which include:

  • Phone / PIN sign in
  • Bitlocker Key Storage

Unlike Device registration which supports multiple platforms, Azure AD Join only supports Windows based devices. 

This Microsoft Blog compares these two features in great detail.

In addition, we can refer this link for more information on Azure Device Registration.

 

↑ Back to top

Azure Active Directory Application Proxy

Traditionally, when users need to access company resources from outside, they typically login to VPN and access those resources. However, nowadays users are not only accessing company resources from their laptop, but also from their mobile devices and from various other devices. In such a scenario, we need a solution which is easy to use and at the same time comply with organization security standard.

Azure Active Directory Application Proxy offers one such solution. It provides single sign-on (SSO) and secure remote access for web applications which are hosted on-premises.   Once implemented, these applications are integrated with Azure AD and users can access these web applications from outside, the same way they access O365 and other SaaS based applications. We do not need to deploy VPN or any other complex infrastructure to facilitate this.

There are two components of Azure AD Application Proxy 

  • A connector: This is an agent which is installed in an on premises Windows Server.
  • An external endpoint: By using external endpoint, users can identify and contact the application.

For more information on Azure AD Application Proxy, please refer this link.

 

↑ Back to top

Azure Active Directory Domain Service

We discussed earlier that Azure AD does not support protocols like Kerberos, NTLM and LDAP. This can be a problem for legacy applications, which use these protocols for authentication and directory browsing.

In addition, some applications may have some additional requirement like Domain Joined and Group Policy, which are not available in Azure AD.

Migrating these applications from on premises Ad to Azure AD would be a challenge because of these compatibility issues. One possible solution is to provision Azure VMs, promote to Domain Controllers and integrate with on premises DCs through VPN or Express Route. However, that involves high cost and management overhead, and we will not be able to leverage Azure managed solution.

Azure Active Directory Domain Service is designed to solve this compatibility issue. Azure AD Domain Services offer all key features in the form of managed service, which are available in on premises AD. The features include Domain Join, Group Policy and support to protocols like Kerberos, NTLM and LDAP. This solves the “Lift and Shift” problem for those applications from on premises to Azure, which are depended on traditional AD features.

Unlike Domain Controller provisioning is Azure which is an IaaS solution, Azure AD Domain Service is a SaaS service, which means there is no management overhead involved for commissioning, patching and maintaining Domain Controllers in Azure.

Whether the Azure AD tenant is cloud only or hybrid (integrated with on premises AD), Azure AD Domain Service works in both the scenarios.

Few important points regarding Azure AD Domain Services:

  • To use Azure AD Domain Service in a hybrid scenario, password synchronization is mandatory. This is because Azure AD Domain Service needs to know the user credential while authenticating the user through Kerberos or NTLM protocols.
  • The Azure AD Domain Service managed Domain is a stand-alone domain and it is not an extension of the on premises domain.
  • Azure AD Domain Service does not offer all services offered by traditional AD, however services which are required for application compatibility are there.
  • The user credential and group membership are synched from on premises AD to Azure AD, and from Azure AD it is synced with Azure AD Domain Services. So administrators do not need to create these objects manually.
  • There is no Enterprise Admin and Domain Admin access available for Azure AD Domain Services, as it is a managed service and administrators do not need to manage Domain Controllers.

For more information on Azure AD Domain Service, please refer this link.

↑ Back to top

Azure AD Administrator Roles

Unlike on premises Active Directory, Azure AD does not have any Enterprise Admin and Domain Admin roles.

Global Administrator Role is the most powerful role in Azure AD. By default, the person who signs up for an Azure subscription becomes the first Global Admin of that directory. Global Admins can assign other administrative roles, and can create other Global Admins.

For a complete list of all the available Administrative roles in Azure AD and their priviledges, please refer this link.

Summary

In this article, we have covered all the key features of Azure Active Directory. We have compared different Azure AD Editions and  discussed deployment scenarios. We have also covered Azure AD Domain Service.

Azure AD is a vast topic, which cannot be covered in a single article. However, this article could act as a starting point for exploring the vast world of Azure AD and different deployment scenarios.

 

↑ Back to top

References

Azure AD Connect Sync Options

Azure AD Connect User Login

Application Proxy

Azure AD Connect SSO

Azure AD Domain Service

B2B & B2C

Device Registration

Domain Name

MFA

Password Write Back

Pricing

Subscription

↑ Back to top