How to configure Azure AD certificate-based authentication (Preview)
Azure Active Directory (Azure AD) certificate-based authentication (CBA) enables customers to configure their Azure AD tenants to allow or require users to authenticate with X.509 certificates verified against their Enterprise Public Key Infrastructure (PKI) for app and browser sign-in. This feature enables customers to adopt phishing resistant authentication by using an x.509 certificate.
During sign-in, users will see an option to authenticate with a certificate instead of entering a password. If multiple matching certificates are present on the device, the user can pick which one to use. The certificate is validated, the binding to the user account is checked, and if successful, they are signed in.
This topic covers how to configure and use certificate-based authentication for tenants in Office 365 Enterprise and US Government plans. You should already have a public key infrastructure (PKI) configured.
Follow these instructions to configure and use Azure AD CBA.
Note
Azure AD certificate-based authentication is currently in public preview. Some features might not be supported or have limited capabilities. For more information about previews, see Supplemental Terms of Use for Microsoft Azure Previews.
Prerequisites
Make sure that the following prerequisites are in place.
- Configure at least one certification authority (CA) and any intermediate certification authorities in Azure Active Directory.
- The user must have access to a user certificate (issued from a trusted Public Key Infrastructure configured on the tenant) intended for client authentication to authenticate against Azure AD.
Important
Each CA should have a certificate revocation list (CRL) that can be referenced from internet-facing URLs. If the trusted CA does not have a CRL configured, Azure AD will not perform any CRL checking, revocation of user certificates will not work, and authentication will not be blocked.
Important
Make sure the PKI is secure and cannot be easily compromised. In the event of a compromise, the attacker can create and sign client certificates and compromise any user in the tenant, both synced and cloud-only users. However, a strong key protection strategy, along with other physical and logical controls such as HSM activation cards or tokens for the secure storage of artifacts, can provide defense-in-depth to prevent external attackers or insider threats from compromising the integrity of the PKI. For more information, see Securing PKI.
Steps to configure and test Azure AD CBA
There are some configuration steps to complete before enabling Azure AD CBA. First, an admin must configure the trusted CAs that issue user certificates. As seen in the following diagram, we use role-based access control to make sure only least-privileged administrators make changes. Configuring the certification authority is done only by the Privileged Authentication Administrator role.
Optionally, you can also configure authentication bindings to map certificates to single-factor or multifactor and configure username bindings to map certificate field to a user object attribute. Configuring user-related settings can be done by Authentication Policy Administrators. Once all the configurations are complete, enable Azure AD CBA on the tenant.
Step 1: Configure the certification authorities
Configure certification authorities using the Azure portal
To enable the certificate-based authentication and configure user bindings in the Azure portal, complete the following steps:
Sign in to the Azure portal as a Global Administrator.
Select Azure Active Directory, then choose Security from the menu on the left-hand side.
To upload a CA, click Upload:
Select the CA file.
Select Yes if the CA is a root certificate, otherwise select No.
Set the http internet-facing URL for the certification authority's base CRL that contains all revoked certificates. This should be set or authentication with revoked certificates will not fail.
Set Delta CRL URL - the http internet-facing URL for the CRL that contains all revoked certificates since the last base CRL was published.
Click Add.
To delete a CA certificate, select the certificate and click Delete.
Click Columns to add or delete columns.
Configure certification authorities using PowerShell
Only one CRL Distribution Point (CDP) for a trusted CA is supported. The CDP can only be HTTP URLs. Online Certificate Status Protocol (OCSP) or Lightweight Directory Access Protocol (LDAP) URLs are not supported.
To configure your certificate authorities in Azure Active Directory, for each certificate authority, upload the following:
- The public portion of the certificate, in .cer format
- The internet-facing URLs where the Certificate Revocation Lists (CRLs) reside
The schema for a certificate authority looks as follows:
class TrustedCAsForPasswordlessAuth
{
CertificateAuthorityInformation[] certificateAuthorities;
}
class CertificateAuthorityInformation
{
CertAuthorityType authorityType;
X509Certificate trustedCertificate;
string crlDistributionPoint;
string deltaCrlDistributionPoint;
string trustedIssuer;
string trustedIssuerSKI;
}
enum CertAuthorityType
{
RootAuthority = 0,
IntermediateAuthority = 1
}
For the configuration, you can use the Azure Active Directory PowerShell Version 2:
Start Windows PowerShell with administrator privileges.
Install the Azure AD module version 2.0.0.33 or higher.
Install-Module -Name AzureAD –RequiredVersion 2.0.0.33
As a first configuration step, you need to establish a connection with your tenant. As soon as a connection to your tenant exists, you can review, add, delete, and modify the trusted certificate authorities that are defined in your directory.
Connect
To establish a connection with your tenant, use the Connect-AzureAD cmdlet:
Connect-AzureAD
Retrieve
To retrieve the trusted certificate authorities that are defined in your directory, use the Get-AzureADTrustedCertificateAuthority cmdlet.
Get-AzureADTrustedCertificateAuthority
Add
To create a trusted certificate authority, use the New-AzureADTrustedCertificateAuthority cmdlet and set the crlDistributionPoint attribute to a correct value:
$cert=Get-Content -Encoding byte "[LOCATION OF THE CER FILE]"
$new_ca=New-Object -TypeName Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation
$new_ca.AuthorityType=0
$new_ca.TrustedCertificate=$cert
$new_ca.crlDistributionPoint="<CRL Distribution URL>"
New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_ca
AuthorityType
- Use 0 to indicate that this is a Root certification authority
- Use 1 to indicate that this is an Intermediate or Issuing certification authority
crlDistributionPoint
You can validate the crlDistributionPoint value you provide in the above PowerShell example are valid for the certification authority being added by downloading the CRL and comparing the CA certificate and the CRL Information.
The below table and graphic indicate how to map information from the CA Certificate to the attributes of the downloaded CRL.
| CA Certificate Info | = | Downloaded CRL Info |
|---|---|---|
| Subject | = | Issuer |
| Subject Key Identifier | = | Authority Key Identifier (KeyID) |
Tip
The value for crlDistributionPoint in the above is the http location for the CA’s Certificate Revocation List (CRL). This can be found in a few places.
- In the CRL Distribution Point (CDP) attribute of a certificate issued from the CA
If Issuing CA is Windows Server
- On the Properties of the CA in the certification authority Microsoft Management Console (MMC)
- On the CA running certutil -cainfo cdp
For additional details see: Understanding the certificate revocation process.
Remove
To remove a trusted certificate authority, use the Remove-AzureADTrustedCertificateAuthority cmdlet:
$c=Get-AzureADTrustedCertificateAuthority
Remove-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $c[2]
You can change the command to remove 0th element by changing to
Remove-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $c[0].
Modify
To modify a trusted certificate authority, use the Set-AzureADTrustedCertificateAuthority cmdlet:
$c=Get-AzureADTrustedCertificateAuthority
$c[0].AuthorityType=1
Set-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $c[0]
Step 2: Configure authentication binding policy
The authentication binding policy helps determine the strength of authentication to either a single factor or multi factor. An admin can change the default value from single-factor to multifactor and configure custom policy rules by mapping to issuer Subject or policy OID fields in the certificate.
To enable the certificate-based authentication and configure user bindings in the Azure portal, complete the following steps:
Sign in to the Azure portal as an Authentication Policy Administrator.
Select Azure Active Directory, then choose Security from the menu on the left-hand side.
Click Authentication methods > Policies.
Under Manage, select Authentication methods > Certificate-based Authentication.
Click Configure to set up authentication binding and username binding.
The protection level attribute has a default value of Single-factor authentication. Select Multi-factor authentication to change the default value to MFA.
Note
The default protection level value will be in effect if no custom rules are added. If custom rules are added, the protection level defined at the rule level will be honored instead.
You can also set up custom authentication binding rules to help determine the protection level for client certificates. It can be configured using either the issuer Subject or Policy OID fields in the certificate.
Authentication binding rules will map the certificate attributes (issuer or Policy OID) to a value, and select default protection level for that rule. Multiple rules can be created.
To add custom rules, click on Add rule.
To create a rule by certificate issuer, click Certificate issuer.
Select a Certificate issuer identifier from the list box.
Click Multi-factor authentication.
To create a rule by Policy OID, click Policy OID.
Enter a value for Policy OID.
Click Multi-factor authentication.
Click Ok to save any custom rule.
Step 3: Configure username binding policy
The username binding policy helps determine the user in the tenant. By default, we map Principal Name in the certificate to onPremisesUserPrincipalName in the user object to determine the user.
An admin can override the default and create a custom mapping. Currently, we support two certificate fields, SAN (Subject Alternate Name) Principal Name and SAN RFC822Name, to map against the user object attribute userPrincipalName and onPremisesUserPrincipalName.
Important
If a username binding policy uses synced attributes, such as onPremisesUserPrincipalName attribute of the user object, be aware that any user with administrative access to the Azure AD Connect server can change the sync attribute mapping, and in turn change the value of the synced attribute to their needs. The user does not need to be a cloud admin.
Create the username binding by selecting one of the X.509 certificate fields to bind with one of the user attributes. The username binding order represents the priority level of the binding. The first one has the highest priority and so on.
If the specified X.509 certificate field is found on the certificate, but Azure AD doesn’t find a user object using that value, the authentication fails. Azure AD doesn’t try the next binding in the list.
The next priority is attempted only if the X.509 certificate field is not in the certificate.
Click Save to save the changes.
Currently supported set of username bindings:
- SAN Principal Name > userPrincipalName
- SAN Principal Name > onPremisesUserPrincipalName
- SAN RFC822Name > userPrincipalName
- SAN RFC822Name > onPremisesUserPrincipalName
Note
If the RFC822Name binding is evaluated and if no RFC822Name is specified in the certificate Subject Alternative Name, we will fall back on legacy Subject Name "E=user@contoso.com" if no RFC822Name is specified in the certificate we will fall back on legacy Subject Name E=user@contoso.com.
The final configuration will look like this image:
Step 4: Enable CBA on the tenant
To enable the certificate-based authentication in the Azure MyApps portal, complete the following steps:
Sign in to the MyApps portal as an Authentication Policy Administrator.
Select Azure Active Directory, then choose Security from the menu on the left-hand side.
Under Manage, select Authentication methods > Certificate-based Authentication.
Under Basics, select Yes to enable CBA.
CBA can be enabled for a targeted set of users.
- Click All users to enable all users.
- Click Select users to enable selected users or groups.
- Click + Add users, select specific users and groups.
- Click Select to add them.
Once certificate-based authentication is enabled on the tenant, all users in the tenant will see the option to sign in with a certificate. Only users who are enabled for certificate-based authentication will be able to authenticate using the X.509 certificate.
Note
The network administrator should allow access to certauth endpoint for the customer’s cloud environment in addition to login.microsoftonline.com. Disable TLS inspection on the certauth endpoint to make sure the client certificate request succeeds as part of the TLS handshake.
Step 5: Test your configuration
This section covers how to test your certificate and custom authentication binding rules.
Testing your certificate
As a first configuration test, you should try to sign in to the MyApps portal using your on-device browser.
Enter your User Principal Name (UPN).
Click Next.
If you have enabled other authentication methods like Phone sign-in or FIDO2, users may see a different sign-in screen.
Select Sign in with a certificate.
Pick the correct user certificate in the client certificate picker UI and click OK.
Users should be signed into MyApps portal.
If your sign-in is successful, then you know that:
- The user certificate has been provisioned into your test device.
- Azure Active Directory is configured correctly with trusted CAs.
- Username binding is configured correctly, and the user is found and authenticated.
Testing custom authentication binding rules
Let's walk through a scenario where we will validate strong authentication by creating two authentication policy rules, one via issuer subject satisfying single factor and one via policy OID satisfying multi factor.
Create an issuer Subject rule with protection level as single factor authentication and value set to your CAs Subject value. For example:
CN=ContosoCA,DC=Contoso,DC=orgCreate a policy OID rule, with protection level as multi-factor authentication and value set to one of the policy OID’s in your certificate. For example, 1.2.3.4.
Create a conditional access policy for the user to require multi-factor authentication by following steps at Conditional Access - Require MFA.
Navigate to MyApps portal. Enter your UPN and click Next.
Select Sign in with a certificate.
If you have enabled other authentication methods like Phone sign-in or FIDO2, users may see a different sign-in screen.
Select the client certificate and click Certificate Information.
The certificate will be shown, and you can verify the issuer and policy OID values.
To see Policy OID values, click Details.
Select the client certificate and click OK.
The policy OID in the certificate matches the configured value of 1.2.3.4 and it will satisfy multifactor authentication. Similarly, the issuer in the certificate matches the configured value of CN=ContosoCA,DC=Contoso,DC=org and it will satisfy single-factor authentication.
Because policy OID rule takes precedence over issuer rule, the certificate will satisfy multifactor authentication.
The conditional access policy for the user requires MFA and the certificate satisfies multifactor, so the user will be authenticated into the application.
Enable Azure AD CBA using Microsoft Graph API
To enable the certificate-based authentication and configure username bindings using Graph API, complete the following steps.
Note
The following steps use Graph Explorer which is not available in the US Government cloud. US Government cloud tenants can use Postman to test the Microsoft Graph queries.
Go to Microsoft Graph Explorer.
Click Sign into Graph Explorer and sign in to your tenant.
Follow the steps to consent to the Policy.ReadWrite.AuthenticationMethod delegated permission.
GET all authentication methods:
GET https://graph.microsoft.com/beta/policies/authenticationmethodspolicyGET the configuration for the x509Certificate authentication method:
GET https://graph.microsoft.com/beta/policies/authenticationmethodspolicy/authenticationMethodConfigurations/X509CertificateBy default, the x509Certificate authentication method is disabled. To allow users to sign in with a certificate, you must enable the authentication method and configure the authentication and username binding policies through an update operation. To update policy, run a PATCH request.
Request body:
PATCH https: //graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate Content-Type: application/json { "@odata.type": "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration", "id": "X509Certificate", "state": "enabled", "certificateUserBindings": [ { "x509CertificateField": "PrincipalName", "userProperty": "onPremisesUserPrincipalName", "priority": 1 }, { "x509CertificateField": "RFC822Name", "userProperty": "userPrincipalName", "priority": 2 } ], "authenticationModeConfiguration": { "x509CertificateAuthenticationDefaultMode": "x509CertificateSingleFactor", "rules": [ { "x509CertificateRuleType": "issuerSubject", "identifier": "CN=ContosoCA,DC=Contoso,DC=org ", "x509CertificateAuthenticationMode": "x509CertificateMultiFactor" }, { "x509CertificateRuleType": "policyOID", "identifier": "1.2.3.4", "x509CertificateAuthenticationMode": "x509CertificateMultiFactor" } ] }, "includeTargets": [ { "targetType": "group", "id": "all_users", "isRegistrationRequired": false } ] }You will get a
204 No contentresponse code. Re-run the GET request to make sure the policies are updated correctly.Test the configuration by signing in with a certificate that satisfies the policy.
Next steps
Povratne informacije
Pošalјite i prikažite povratne informacije za