Azure AD is the provider of identity management for Microsoft Azure. It’s very important to understand its features and how it works in details to be able to build secure solutions on Azure. While most of what I have written here is also available on Microsoft website, I believe this post will give you enough high level information on fundamentals of Azure AD to be able to form an understanding of its different service offerings and when to choose what.
Azure AD Connect (Hybrid Identity)
This is the option for organisations with existing AD either on-premise or cloud (mainly on premise) to achieve their hybrid identity goals by providing users a single identity for authentication and authorisation to all resources, on the cloud and on-premise.
Azure AD Connect Health
When identity infrastructure is managed on-premise, Azure AD Connect Health comes handy to maintain a reliable connection between your cloud platforms and on-premise identity infrastructure by providing monitoring capabilities for the key identity components. You can also use the Azure AD Connect Health to view alerts (such as sync errors), performance KPIs, usage analytics and other information.
Monitoring and gaining insights into your on-premises identity infrastructure is as simple as installing an agent on each of your identity servers. Using Azure portal you can download the agent and troubleshoot the most common issues such as agent registration failures
Going through more details on how to setup different functionalities with Azure AD Connect Health ie beyond the scope of this post, since I don’t have access to an on-premise AD. Read more on different ADFS issues you can get alerted on, its rich usage metrics, and setting up email notifications.
Azure AD Connect Authentication Modes
When starting with moving workloads to cloud, the very first decision organisations need to make is to decide how users will sign in and access applications deployed on the cloud. It forms the foundation of all other security and access management frameworks that will be put in place and therefore, it is a decision not to be made lightly because once it is in it will be very hard to change since it’ll disrupt users’ ability to sign in.
The first authentication mode is Cloud Only. This is for organisations that are born in the cloud and don’t have on-premises identity management solutions and user identities are established in the cloud. This is NOT a hybrid identity solution (although Microsoft docs discusses this option for hybrid situations)
Next option is Password Hash Sync, which is the case where users sign in to the cloud applications using the same user/pass they use on-premises. This is the simplest method to enable authentication for on-premises directory objects in Azure AD, in which Azure AD Connect sync agents extract password hash from the on-premises Active Directory instance every 2 minutes and stores them in Azure AD. When a user attempts to sign in to Azure AD and enters their password, the password is run through the same MD4+salt+PBKDF2+HMAC-SHA256 process. If the resulting hash matches the hash stored in Azure AD, the user has entered the correct password and is authenticated. It also provides leaked credentials report, that is a result of Microsoft working alongside dark web researchers and law enforcement agencies to find publicly available username/password pairs.
Next is Azure AD Pass-through Authentication. It is very similar to Password Hash Sync, for organisations wanting to re-use their security policies (such as immediately enforce on-premises user account states, password policies, and sign-in hours) in the cloud. In this case password validation happens on-premises, not in cloud, using agents that run on servers deployed on the same data centre as the identity solution.
There is also the option for Federated Authentication, when Azure AD hands off authentication process to the on-premises AD FS (or other third party federation providers that have established trust with Azure AD) to validate user credentials. This is the best fit for organisations with advanced requirements that are not natively supported in Azure AD such as smartcard-based authentication or third-party multi-factor authentication.
Providing Access to External Identities
Azure AD has solutions that enable providing access to resources deployed in your Azure environment to external identities, e.g. people outside of your organisation, by bringing the identities they prefer. They can use credentials such as the user name and password provided by their organisation’s identity management solution or unmanaged social identities such as Google or Facebook to login and sign up. Let’s look at Azure AD B2B and Azure AD B2C
Azure AD B2B
This is the option that enables B2B collaboration by inviting users into our tenant as guests and giving them permissions. Users will be able to authenticate using any of the credentials mentioned above. This feature is called Azure B2B Collaboration since it enables users from multiple organisations to collaborate in developing new applications on Azure Cloud and share resources.
Guest users from other organisations are onboarded using a simple invitation and redemption process. To invite users to an Azure AD tenant, navigate to Azure Active Directory page on Azure portal and click on Users:
Click on “New User” and then select the box for “Invite user” or click on “New Guest User”. The only required field in this form is Email address. Assign user to necessary Group and make sure “Block sign in” is set to No:
Invited users will receive an email with an “Accept Invitation” button which will take them to Azure portal:
Authorise Invited Users
Authorisation for the invited users to the Azure AD tenant is done via Azure AD Groups and assigning users to relevant groups. This way we can control which resources and applications they have access to by assigning roles to groups in Azure IAM, the same way we would implement access control for other users.
Go to your Subscription where the group exists, click on “Add role assignments”, and assign role to group and click save:
Azure AD B2C
Azure Active Directory Business to Customer is a customer identity access management (CIAM) solution that could be used when there is the requirement to support millions of users per day. The main use cases for Azure AD B2C are mobile and web applications. Azure AD B2C allows customisation of every page displayed during sign up/sign in process to provide an experience that looks and feels like it’s a native part of your application. It supports standard authentication protocols such as OpenID Connect, OAuth 2.0 and SAML.
To be able to utilise the functionalities of Azure AD B2C, we need to create tenants. Azure AD B2C tenants are similar to Azure AD tenants in that they hold directories of users. But they are different since Azure AD B2C needs to have the following resources set up as well:
- Application Registration: mobile and web apps and APIs should be registered with Azure AD B2C to enable identity management.
- User flows: are used to configure and enable identity tasks such as sign up and sign in. There are 2 types: built-in and custom policies. The latter is used for customising complex identity and workflows that might be quite specific to an organisation, such as Google captcha at login or sign on or login with phone number.
- Identity providers: federation settings for social identity providers, external identity providers and local accounts (sign in with username and password).
- Keys: to add and manage encryption keys for signing and validating tokens, client secrets, certificates, and passwords.
Azure AD B2C allows for user federation with external identity providers where user will be able to sign in to the application with their existing social or enterprise accounts.
Accounts Types in Azure AD B2C
- Work accounts: Users with this type of account will be able to manage resources in a tenant as well as manage other users’ accounts such as create new account, reset passwords, block/unblock accounts.
- Guest accounts: External users we invite to our tenant, they will get limited access which can be controlled as we saw above.
- Consumer accounts: Users with this type of account will be able to sign in to applications secured by Azure AD B2C, but cannot access Azure resources such as the Azure portal.
Azure Active Directory Domain Services
When we need to lift and shift legacy applications from on-premises to cloud and can’t use modern authentication methods, Azure Active Directory Domain Services (AD DS) helps by providing managed domain services such as domain join, group policy, lightweight directory access protocol (LDAP), and Kerberos / NTLM authentication. We won’t need to manage the AD DS environment in the cloud since Azure AD DS integrates with the existing Azure AD tenant.
A managed domain will perform a one-way synchronization from Azure AD to provide access to a central set of users, groups, and credentials. You can create resources directly in the managed domain, but they aren’t synchronized back to Azure AD. Note that In a hybrid environment with an on-premises AD DS environment, Azure AD Connect synchronizes identity information with Azure AD, which is then synchronized to the managed domain.
Selecting the right option
Consider the following factors when determining which Azure AD service is right for you:
- Where the user identities reside: on-premise or on cloud
- You would need Azure AD Connect if identity management solution runs on-premise (Hybrid Identity Management )
- Azure AD Connect Health helps with monitoring the connection and user synch between on-premise servers and cloud solutions
- Do you need collaboration with other organisations and tenants?
- If yes, use Azure AD B2B
- Would you need to support large number of users using your web or mobile application?
- If yes, use Azure AD B2C
- Are you migrating legacy applications from on-premises to cloud?
- Use Azure Active Directory Domain Services
I hope this post sheds some light on how to choose the right user management solution for your workloads on Azure. There are definitely more details to be worked out when the implementation phase starts. Feel free to share your thoughts and your experiences here in the comments section.
In Data we trust 