Azure AD certificate-based authentication

Feb 14 2022 Microsoft announced the public preview of Azure AD certificate-based authentication (Azure AD CBA). This is a direct response to the US Presidents Executive Order 14028 on Improving the Nation’s Cybersecurity that calls for the Federal Government to modernize and adopt a Zero Trust architecture including resistant MFA for employees, partners and vendors.

This seems like a good response from Microsoft - after all PIV/CAC cards with X.509 certificates are certainly used a lot and especially in government agencies and surely in a lot of large enterprises. A lot of these organizations has not migrated to any other passwordless method, like authenticator apps or FIDO2. Being able to reuse the Public Key Infrastructure already in place - and then taking advantage of all the benefits of cloud authentication seems like a good fit for a lot of organizations.

For the organizations taking this into use you can also reduce your infrastructure costs and simplify management since you now can eliminate the need for something like federated ADFS. Before Azure AD CBA you needed to use ADFS or another federation service on-prem to be able to utilize your on-prem Public Key Infrastructure. This means no need for a complex on-premises deployment and network configuration, direct authentication to Azure AD and no management overhead or cost.

How does it work?

The diagram from Microsofts docs explains things pretty well: Azure AD CBA explained

As a user this means:

  • You get the login screen and type your email
  • You now can choose any supported auth methods, included certificate-based if eligable/configured
  • If you chose certificate-based auth you are typically challenged with entering your pin code

Limitations

In the public preview there are some limitations.

The only supported scenarios are:

  • User sign-ins to web browser-based applications on all platforms
  • User sign-ins on mobile native browsers

In addition there are some limitations on auth rules by using certificate issuer Subject and policy OIDs, as well as certificate-to user account bindings.

The unsupported scenarios are: There are some here. But with regard to being able to f.ex kill your ADFS-infrastructure the most notable is that Windows login using smart cards on Windows devices aren’t supported.

You also can’t disable passwords when CBA is enabled, you need to front your own Public Key Infrastructure and provision certificates to users and devices, CA hints aren’t supported, only one CRL Distribution Point for a trusted CA is supported + a couple of more.

Summary

Azure AD CBA is just in public preview so we can expect some more features before it is made GA. Maybe we’ll see the limitation of not being able to log in to Windows on a Windows device with CBA solved? I can see some organizations wanting this if they move to direct Azure AD authentication.

Despite the limitations Azure AD CBA seems like a good move for Microsoft and a good choice for many organizations. Being able to take advantage of Conditional Access including MFA and blocking legacy authentication in Azure AD for logging into both web browser-based apps and mobile native browsers with your smart card surely must improve your security posture - at least compared to fronting your own ADFS or other federation service-infrasturcture with all the complications that brings.