Azure AD certificate-based authentication (Preview) + Publishing CRL with Application Proxy

Azure AD CBA allows user to sign-in with a certificate. Microsoft has removed the need for external ADFS federation.

You can see the situation before this change from Sami Lamppu’s post.

Feature highlights

• Facilitates onboarding to Azure quickly without being delayed by additional on-premises infrastructure to support certificate-based authentication in public and United States Government clouds.
• Provides support for unphishable multifactor authentication.
• Supports user sign-in against cloud Azure AD using X.509 certificates into all web browser-based applications and into Microsoft Office client applications that use modern authentication.
• The feature works seamlessly with Conditional Access features such as MFA to help secure your users.
• It’s a free feature, and you don’t need any paid editions of Azure AD to use it.
• Eliminates the need for federated AD FS and reduces the cost and on-premises footprint.

How the authentication works?

How to setup

If You just open the CBA page and select Add rule, You will get a warning.

And this is because You have to first add the Certification Authority’s CRL distribution point with PowerShell.

In my example I used my own PKI which I published with Application Proxy.

Here’s an excellent article from Michael Niehaus on publishing Certificate Revocation Lists with Application proxy.

I will just make couple of additions. You can use Your own custom domain by adding the FQDN to custom domains. If You already have the suffix just add the prefix and don’t have to even verify it.

And here the PowerShell One-liner Michael is using.

And last but not least, You can now add HTTP redirection also.

So Finally You will have these inside Your CA-Root extensions.

Continuing the setup

You will find the CRL point from the certificate that was generated under CRL Distribution Points field.

When You run the commands.

When You have Certificate and CRL published, You can go and select the certificate.

Once You add the rule You will see the selected certificate.

You can select default protection level between Single or Multi-factor.

Understanding the username binding policy

The username binding policy helps locate the user in the tenant. By default, Subject Alternate Name (SAN) Principal Name in the certificate is mapped to onPremisesUserPrincipalName attribute of the user object to determine the user.

An administrator can override the default and create a custom mapping. Currently, we support two certificate fields SAN Principal Name and SAN RFC822Name to map against the user object attribute userPrincipalName and onPremisesUserPrincipalName.

Rules applied for user bindings:

Use the highest priority (lowest number) binding.

1. If the X.509 certificate field is on the presented certificate, try to look up the user by using the value in the specified field.
   1. If a unique user is found, authenticate the user.
   2. If a unique user is not found, authentication fails.
2. If the X.509 certificate field is not on the presented certificate, move to the next priority binding.
3. If the specified X.509 certificate field is found on the certificate, but Azure AD does not find a user object in the directory matching that value, the authentication fails. Azure AD does not attempt to use the next binding in the list in this case.

To flat the explanation out, You will sign in with the user having an account inside Azure AD and requesting a certificate for that user, When you have the users UserPrincipalName inside the certificate, You can logon with it.

End-user experience

Login with certificate.

And select the User certificate generated by the CA.

And Success!

And how You see the logon inside Sign-in logs.

Supported scenarios

The following scenarios are supported:

• User sign-ins to web browser-based applications on all platforms.
• User sign-ins on mobile native browsers.
• Support for granular authentication rules for multifactor authentication by using the certificate issuer Subject and policy OIDs.
• Configuring certificate-to-user account bindings by using the certificate Subject Alternate Name (SAN) principal name and SAN RFC822 name.

Unsupported scenarios

The following scenarios aren’t supported:

• Public Key Infrastructure for creating client certificates. Customers need to configure their own Public Key Infrastructure (PKI) and provision certificates to their users and devices.
• Certificate Authority hints aren’t supported, so the list of certificates that appears for users in the UI isn’t scoped.
• Windows login using smart cards on Windows devices.
• Only one CRL Distribution Point (CDP) for a trusted CA is supported.
• The CDP can be only HTTP URLs. We don’t support Online Certificate Status Protocol (OCSP), or Lightweight Directory Access Protocol (LDAP) URLs.
• Configuring other certificate-to-user account bindings, such as using the subject field, or keyid and issuer, aren’t available in this release.
• Currently, password can’t be disabled when CBA is enabled and the option to sign in using a password is displayed.

Key benefits of using Azure AD CBA

Benefits	Description
Great user experience	– Users who need certificate-based authentication can now directly authenticate against Azure AD and not have to invest in federated AD FS. – Portal UI enables users to easily configure how to map certificate fields to a user object attribute to look up the user in the tenant (certificate username bindings) – Portal UI to configure authentication policies to help determine which certificates are single-factor versus multifactor.
Easy to deploy and administer	– No need for complex on-premises deployments or network configuration. – Directly authenticate against Azure AD. – No management overhead or cost.
Secure	– On-premises passwords need not be stored in the cloud in any form. – Protects your user accounts by working seamlessly with Azure AD Conditional Access policies, including multifactor authentication (MFA) and blocking legacy authentication. – Strong authentication support where users can define authentication policies through the certificate fields like issuer or policy OID (object identifiers) to determine which certificates qualify as single-factor versus multifactor.