Azure AD introduces native Certificate-based authentication

Certificate-based authentication (CBA) has long been the de-facto standard in some organizations, and accordingly, requirements for CBA to cloud apps are not uncommon. In fact, Office 365 has long supported CBA as part of federated authentication flows, with support for some additional scenarios added later on. Now, Microsoft is finally enabling “native” support for CBA in Azure AD, without the need for federation. Let’s go over the details!

Configure certificate-based authentication

First things first, if you are planning to use CBA for any Azure AD integrated applications, you need to have your own Public Key Infrastructure (PKI). Windows Server has long included various PKI components, such as Certification Authority for handling certificate issuance. The role(s) of the PKI are then complemented by authentication/authorization services, in our case Azure AD. You cannot however use Azure AD to issue certificates, thus even the “native” CBA implementation has dependencies on external infrastructure.

Speaking of dependencies, one of the biggest “selling points” for the “native” CBA implementation is the removal of the dependency on external federation infrastructure, such as AD FS. This was an inherent requirement for the previous “federated” approach, and in turn brought other dependencies, especially in larger organizations. In this sense, Azure AD native CBA is yet another feature that helps you offload on-premises workloads and replace them with a cloud service.

Certificate authority data

To configure native CBA, one must provide few details about the external certificate authority (or authorities) that will be involved in validating certificate credentials. This is done by configuring the CertificateAuthorityInformation object, which is currently possible via the New-AzureADTrustedCertificateAuthority cmdlet from the Azure AD PowerShell module, but not available in the Azure AD blade UI. Alternatively, you can also configure it via the /organization/{id}/certificateBasedAuthConfiguration Graph API endpoint or the New-MgOrganizationCertificateBasedAuthConfigurationByRef cmdlet from the Microsoft Graph SDK. If using the Azure AD PowerShell cmdlet, you need to be logged in with a user with the Privileged Authentication admin role granted. If using the Graph API method, the Organization.ReadWrite.All scope is required.

If you have tiered PKI infrastructure, you will need to provide information about each certification authority. In other words, the CertificateAuthorityInformation object will then represent a collection of certificate authority objects, with their corresponding settings. Speaking of settings, two mandatory fields need to be provided: the TrustedCertificate representing the given CA (certificate if using the Graph API) and the AuthorityType (isRootAuthority), indicating whether the CA is root or intermediate. Few other optional properties can be provided to configure certificate revocation checks: CrlDistributionPoint and DeltaCrlDistributionPoint (certificateRevocationListUrl and deltaCertificateRevocationListUrl when using the Graph API). Here’s the schema:

{
"certificateAuthorities": [
{
"isRootAuthority": true,
"certificateRevocationListUrl": "https://crl.domain.com/root-CA.crl",
"deltaCertificateRevocationListUrl": "https://crl.domain.com/root-CA+.crl",
"certificate": "MIIDaTCCAlGgAwIBAgIQUtzE…"
"issuer": "CN=root-CA, DC=domain, DC=com",
"issuerSki": "BC49D3CE01AE19B7969DA54A6D03425F0B2A24F7"
},
{
"isRootAuthority": false,
"certificateRevocationListUrl": "https://crl.domain.com/root-CA.crl",
"deltaCertificateRevocationListUrl": null,
"certificate": "MIIGDjCCA/agAwIBAgIQNoJe…"
"issuer": "CN=ENT-CA, DC=domain, DC=com",
"issuerSki": "9AF32BDACFAD4FB62FBB2A48482A12B71B42C124"
}
]
}

Two derived, read-only properties are also shown above, issuer and issuerSki. They are automatically calculated from the certificate you provide. This all is then packaged within a certificateBasedAuthConfiguration object, which is technically what you configure when using the Graph API method. This object in turn has only a single additional property, namely the id, with a predefined value of “29728ade-6ae4-4ee9-9103-412912537da5”. The rest of the configuration is represented by the (series of) certificateAuthorities object we described above. Here’s how it all looks like:

Do note that updating (PATCH-ing) the configuration is not currently supported via the Graph API, instead you need to remove/recreate it. For additional details, refer to the official documentation. And if you want to use the Azure AD PowerShell cmdlets, the process is the same as with the good old “federated” scenario, so I will again refer you to the official documentation.

Authentication method configuration

While configuring the CertificateAuthorityInformation object remains the same, what’s new is the ability to control which users will be able to perform native CBA, the authentication method strength and user bindings. Thanks to the /beta/policies/authenticationMethodsPolicy endpoint, we can perform this part of the setup via the Graph API as well, and for that we will need the Policy.ReadWrite.AuthenticationMethod permission. As the steps are covered in detail in the official documentation, we will not cover them here. We do need to mention some key elements of the process though.

These can be found under the Azure AD blade > Security > Authentication methods > Policies > Certificate-based authentication (preview). Under the Basics tab, you can toggle native CBA as available authentication method, as well as target it to specific users or groups. The Configure tab contains the interesting settings, the first being Protection Level. This basically specifies whether CBA should be considered a single- or multi-factor authentication method. More granular control is made available thanks to the Rules, which allow you to bind specific certificates, such as those issued by an intermediate CA, to a given protection level. Alternatively, you can create a binding based on the Policy OID value of the certificate. If you do not configure any rules, the selection under Protection level will be applied to all native CBA-based logons.

Lastly, you can control the Username bindings, as in which certificate field will be used to uniquely identify the user. The current supported values are (SAN) PrincipalName and the (SAN) RFC822Name, which you can map against the userPrincipalName and/or onPremisesUserPrincipalName as needed. Should you opt to use the RFC822Name binding and no such field is found in the certificate presented by the user, a fallback mechanism is used, and the value of the Subject field will be leveraged.

Leveraging Azure AD Native CBA

Enough about configuration, let’s now see native CBA in action! If your administrator has done his job right, as an end user all you’d need to do is enter your UPN at the login screen, then click the Sign in with a certificate link on the next screen. Both cloud-only and synchronized users can take advantage of native CBA. Do note that the login options presented to the user might look different, depending on the methods available within the tenant, or enabled per-user.

Once you press the Sign in with a certificate link, a dialog will pop up, asking you to select from the available certificates. While this is not something end users should generally be concerned with, you need to make sure that the certificate is issued by (one of) the trusted CA you configured above, is within its validity, the SAN is properly mapped against a valid user within your tenant, and optionally, that the configured CDP is accessible. As and end user though, all you need to do is point to the correct certificate and press OK:

Yes, I am using IE here, for the sole purpose of being able to reposition the Select a certificate dialog 🙂 On the negative side, IE doesn’t show that the request is coming from https://certauth.login.microsoftonline.com/, which is the URL you should whitelist for the CBA functionality to work as expected.

On Azure AD side of things, you can expect the corresponding Sign-in events to be captured, as showcased below. A current known issue is causing the User id to be displayed as GUID in the CBA-related entry, however this will likely be addressed going forward. Similarly, the Application field is empty, but the corresponding GUID is provided for the Application ID.

 

Apart from that, you can expect the same level of detail as with other sign-in events, with the important difference being the actual method used. You can find information about it under the Authentication Details tab, as shown below:

More importantly, you can find information about the actual certificate used under the Additional details tab. Those include the subject, issuer, serial number, thumbprint, validity, as well as information as to the “resolved” value for whichever field we use as the binding, as configured in the Azure AD CBA settings.

As mentioned above, you can also control whether CBA is counted as single- or multi-factor authentication. This information will also be reflected in the sing-in event details.

Some additional notes

And with that, we can conclude our short overview of the “native” CBA functionality in Azure AD. Removing the dependencies on additional federation infrastructure and being released free of charge (no licensing requirements!), native CBA will surely make some organizations very happy. That said, the feature is still in preview, so you can expect the occasional issue or limitation.

While Azure AD native CBA can address the requirements for phishing-resistant authentication, it is not a holy grail type of solution. One can argue that such implementation is only as secure as your PKI infrastructure, which in turn now represents an even broader attack surface as compromising it will allow access to cloud services as well. The need for properly securing your PKI cannot be stressed enough, especially considering that any user in the tenant, including cloud-only Global admins can be targeted. I would expect that going forward, Microsoft will adjust security guidance to explicitly mention native CBA as potential attack vector and recommend excluding any privileged roles from the authentication method configuration for CBA.

Another factor to keep in mind is certificate revocation. This is currently not a mandatory configuration step, however it’s highly recommended. Revocation events will not result in revoking any already issued tokens for the given user, so keep that in mind and add additional steps to your workflows as needed. In addition, Azure AD will use a caching mechanism for the CRL and will only update it when the next update date is reached, there is no way to force a manual update. Do note that Azure AD will only check the CRL of the issuing CA but not of the entire PKI trust chain up to the root CA, which means that in the event of CA compromise, you should remove the trusted issuer from the CertificateAuthorityInformation config object as soon as possible. Lastly, no support for OCSP is currently available.

This entry was posted in Azure AD, Graph API, Microsoft 365, Office 365. Bookmark the permalink.

3 Responses to Azure AD introduces native Certificate-based authentication

  1. Thomas says:

    So this is not a step towards pki as a service in Azure?

    Some companies don’t have enough resources to maintain a complete ADCS pki infrastructure and that would be great to have a pki in the cloud natively in Azure

  2. Joe Todd says:

    Hello,
    Based on what’s written here, is CBA enabled only at the tenant level or on a per-user basis?
    Thanks,
    Joe

Leave a Reply to Vasil Michev Cancel reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.