How does Azure AD certificate-based authentication work?

Azure AD certificate-based authentication (CBA) is an authentication method that allows you as an enterprise to require system users to authenticate their identity directly through X.509 certificates. The certificates are authenticated against Azure Active Directory (Azure AD) to allow application access and browser login.
This authentication method is much more secure than standard username and password authentication. Whether you’re trying to stay compliant with industry standards, have concerns about intellectual property and trade secrets, or are just passionate about security, Azure AD certificate-based authentication may be the right choice for you. Read on to learn more.
What is Azure AD authentication?
Before cloud-managed support for CBA, users had to use federated certificate-based authentication. This means that in order to authenticate their X.509 certificates against Azure AD, they had to deploy Active Directory Federation Services (AD FS).
With Azure AD certificate-based authentication, you can cut out the middleman and authenticate your certificates directly against Azure AD. This streamlines the user experience and reduces the costs of operating and maintaining your environment.
The benefits of using Azure AD CBA
Better user experience
Instead of taking extra steps and waiting for multiple connections, users who need certificate-based authentication can authenticate directly against Azure AD without having to run and pay for federated AD FS.
The portal user interface allows you to easily and intuitively configure and map your certificate fields to a user object attribute, allowing you to look up the user in the tenant. This means you can create unique usernames and bind certain certificates to those users specifically – a feature that reduces phishing scams and password hacking, while reducing steps for your users.
You can also use the portal’s user interface to configure authentication policies around your authentication preferences. You can decide whether your organization prefers single or multi-factor authentication.
Simple implementation
Azure AD certificate-based authentication is free to implement and use. No complex on-site deployments or network configurations are required. And since this method allows you to authenticate directly against Azure AD, it eliminates the extra step of direct communication.
Increased security
Direct authentication eliminates the need for local passwords to be stored in the cloud. This reduces the likelihood of your users being hacked or phished since their credentials cannot be easily captured.
Your users are further protected by Azure AD Conditional Access policies such as phishing-resistant multi-factor authentication (MFA) and legacy authentication blocking. These policies are automatically integrated with Azure AD CBA.
How does Azure AD certificate-based authentication work?
If we break down the actual steps that a user takes to use Azure AD CBA, it looks something like this:
- The user is trying to access an app such as Outlook or OneDrive.
- The user is directed to the user login page (if they are already logged in, they will be redirected to the appropriate app).
- The user will be prompted to enter their username and click “Next”.
- Once the “Next” button is clicked, Azure AD completes home site discovery based on the tenant name and the unique username is run against Azure AD.
- Azure AD then checks if CBA is enabled for the tenant. If it is, the user will see a link to “Use a certificate or smart card” in the password window.
- When the user selects the certificate option for authentication, the client is redirected to the certificate endpoint where it performs mutual TLS authentication.
- Next, Azure AD prompts for a client certificate, which the user can choose from the selection shown to them. After a certificate is selected, the user selects “OK”.
- Azure AD then ensures that the certificate is valid and not revoked based on the username binding in the tenant map.
- Based on the way your organization is configured, the user will either be signed in automatically or prompted to complete Azure AD Multi-Factor Authentication
- Once this is completed, the user must be logged in and have access to the application.
This is a complex process when you break down the technical steps, but the user should only experience a few seconds of on-screen prompts to log in and start using their application.
Common questions
What are the available Azure AD MFA authentication methods?
Sometimes an organization may want the added security offered by another form of identification in the login process. If you choose multi-factor authentication (MFA), there are several ways to get users to complete the process:
- SMS (text)
- Voice calls
- The Microsoft Authenticator app
- Windows Hello for Business
- Security key
- Smart card
- OATH hardware token (preview)
- OATH software token
The Azure Active Directory MFA options are intended to help further secure the sign-in process. While it may take a few extra moments for your users, it adds another layer of security to your systems.
What can I use Azure AD CBA for?
There are many supported scenarios for Azure AD CBA, including user sign-in to browser-based apps, Office mobile apps, and mobile native browsers. You can also create custom certificate-to-user account bindings using any of the certificate fields.
This means you can log into any network-supported app or browser with just one login at the start of the day. This saves users time, effort and frustration.
Can I use non-HTTP URLs for CDP?
No. Only HTTP URLs can be used. No OCSP or LDAP URLs are compatible.
Learn more
Axiad adds a unified passwordless, phishing-resistant MFA to CBA approaches to multiple IAM approaches, including Azure AD and Microsoft Active Directory (AD). Furthermore, Axiad provides a critical feature – credential management at scale to help organizations migrate to Azure AD. To learn more, visit our certificate-based authentication for IAM page.
The post How does Azure AD certificate-based authentication work? appeared first on Axiad.
*** This is a Security Bloggers Network syndicated blog from Blog – Axiad written by the Axiad Team. Read the original post at: