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

Certificate-Based Authentication (CBA) In Azure AD – Notes From The Field

I have been working with ADDS (AD) & ADCS (PKI) almost whole of my IT career and still love to do stuff with these technologies, even my focus has been in the cloud for almost a decade now. Bac…

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.

Publish Certificate Services CRL and OCSP sites to the internet using Azure App Proxy

I have set up a variety of test domains over the years, and inevitably I need to set up Active Directory Certificate Services (ADCS) on them because I need to issue certificates of some kind for so…

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.

New-AzureADApplicationProxyApplication -DisplayName "MyApplicationName" -ExternalUrl "http://YourPreferredFQDN/certenroll/" -InternalUrl "http://YourCAName/certenroll/" -ExternalAuthenticationType Passthru

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.

$cert=Get-Content -Encoding byte "YourPath\YourCA-root.cer" $new_ca=New-Object -TypeName Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation $new_ca.AuthorityType=0 $new_ca.TrustedCertificate=$cert $new_ca.crlDistributionPoint="http://mycrl.cloudpartnerdemo.fi/CertEnroll/myca.crl" New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_ca

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

Share this: