Enhancing Security with Entra ID Certificate-Based Authentication using Intune Cloud PKI: A Step-by-Step Guide to Modern, Passwordless Sign-Ins

 

Microsoft Entra Certificate-Based Authentication (CBA) allows organizations to configure their Entra tenants for user authentication using X.509 certificates from their Enterprise Public Key Infrastructure (PKI). This modern, passwordless method provides strong phishing resistance.

During sign-in, users can choose to authenticate with a certificate instead of a password. If multiple certificates are available on the device, users can select the appropriate one. The selected certificate is then validated against the user account, enabling successful sign-in.

In this post, I will guide you through configuring certificate-based authentication in Microsoft Entra ID using Intune Cloud PKI for end-user device authentication.

Why CBA & Benefits of CBA

Before cloud-managed support for Certificate-Based Authentication (CBA) in Microsoft Entra ID, customers needed Active Directory Federation Services (AD FS) for federated authentication using X.509 certificates. Now, Microsoft Entra CBA allows direct authentication, eliminating the need for AD FS, simplifying environments, and reducing costs.

Some of the CBA Benefits listed below.

Great User Experience:

• Direct authentication against Microsoft Entra ID without needing federated AD FS.
• Easy configuration of certificate fields to user attributes in the portal UI.
• Configure single-factor or multifactor authentication policies in the portal UI.

Easy to Deploy and Administer:

• Microsoft Entra CBA is a free feature with no need for paid editions.
• No complex on-premises deployments or network configuration required.
• Direct authentication against Microsoft Entra ID.

Secure:

• No need to store on-premises passwords in the cloud.
• Works with Microsoft Entra Conditional Access policies for phishing-resistant MFA and blocking legacy authentication.
• Strong authentication policies based on certificate fields like issuer or policy OID.
• Integrates with Conditional Access features and authentication strength capabilities to enforce MFA.

CBA Supported Scenarios

• User sign-ins to web browser-based applications on all platforms.
• User sign-ins to Office mobile apps on iOS/Android and Office native apps on Windows, including Outlook and OneDrive.
• User sign-ins on mobile native browsers.
• Support for granular authentication rules using certificate issuer Subject and policy OIDs for multifactor authentication.
• Configuring certificate-to-user account bindings using any of the following certificate fields: 
•  Subject Alternate Name (SAN) PrincipalName and SAN RFC822Name
• Subject Key Identifier (SKI) and SHA1PublicKey
• Issuer + Subject, Subject and Issuer + SerialNumber
• Configuring certificate-to-user account bindings using any of the following user object attributes: 
•  User Principal Name
• onPremisesUserPrincipalName
• CertificateUserIds

CBA Unsupported Scenarios

• Certificate Authority hints are not supported, so the certificate picker UI list is not scoped.
• Only one CRL Distribution Point (CDP) is supported for a trusted CA, limited to HTTP URLs.
• Online Certificate Status Protocol (OCSP) and Lightweight Directory Access Protocol (LDAP) URLs are not supported.
• Password authentication cannot be disabled; the option to sign in using a password is displayed even when the Microsoft Entra CBA method is available.

Note: Windows Hello For Business (WHFB) can be used for multi-factor authentication in Microsoft Entra ID but is not supported for fresh MFA. WHFB certificates are compatible with Microsoft Entra CBA in Edge and Chrome browsers but not in non-browser scenarios like Office 365 applications. To bypass this issue, use the "Sign in Windows Hello or security key" option when available. This option may not work in older applications.

CBA for Single or Multi-Factor Certificate-Based Authentication!!!

Certificate-based authentication in Microsoft Entra ID can be configured for single-factor (primary) or multi-factor (MFA) authentication, depending on the scenario.

For Everyday Tasks:

•  If the device is user-controlled, adding biometric authentication on top of the issued certificate is advisable for enhanced security.
• Example: On mobile devices with built-in biometric authentication managed by Microsoft Intune, configuring the certificate to satisfy MFA can streamline the user experience, avoiding repeated biometric checks.

For Sensitive Applications:

• For high-security applications, enforce additional biometric authentication when accessing the application.
• The certificate satisfies the primary method, while a password-less sign-in method like Microsoft Authenticator completes the MFA.

This approach balances security and user convenience based on the specific use case.

Creating and Configuring Intune Cloud PKI for Entra CBA

For detailed instructions on setting up Intune Cloud PKI and issuing certificates to Windows device users, check out my blog post: [Step-by-Step Guide to Building Microsoft Cloud PKI]. 

Ensure that when configuring your Cloud PKI Root and Issuing CA, you include the Client Authentication Extended Key Usage.

Setting Up Certificate-Based Authentication in Microsoft Entra Using Cloud PKI

To set up Certificate-Based Authentication (CBA) for Microsoft Entra with Cloud PKI, you'll need to configure your Cloud PKI, enable CBA in Microsoft Entra, and deploy your certificates. Below, I’ll guide you through the final two stages of this process.

Step 1: Download Root and Issuing CA Certificates and CRLs

First, download and gather all necessary information to upload into Microsoft Entra:

1. Log in to Intune.
2. Navigate to Tenant administration > Cloud PKI.
3. Select your Root CA and click Download next to 'Download certificate'.
4. Copy the URL next to CRL distribution point.
5. Repeat these steps for your Issuing CA.

Step 2: Upload Cloud PKI Certificates to Microsoft Entra

Now, upload the gathered information to Microsoft Entra:

1. Log in to Entra.
2. Expand Protection and select Security Center.
3. Under Manage, select Certificate authorities.
4. Click Upload.
   
   
   
5. Upload the Root CA file and select Yes next to Is root CA certificate.
6. Copy and paste the Certificate Revocation List URL and click Add.
   
   
   
7. Repeat the upload for the Issuing CA, but select No under Is root CA certificate.
   
   
   

You should now see both certificates listed on the page. By following these steps, you’ll have successfully configured CBA in Microsoft Entra with Cloud PKI.

Step-3: Enabling Certificate-Based Authentication

To enable certificate-based authentication (CBA) in your environment and assign it to your target users, follow these steps:

1. Log in to [Entra]
2. Expand Protection and select Authentication methods
3. On the Policies page, select Certificate-based authentication

4.Under Enable & Target Select Enable
5.Under Include Target Choose Select Groups and Choose the desired Group, in our case we will select CBA_Users 

6.Select I Acknowledge and click on Configure Tab

7.Under Configure Tab we will see Issuer Hints ,To enable click on the check box Issuer Hints.

Note: 

1. Issuer hints send back a Trusted CA Indication as part of the TLS handshake. The trusted CA list is set to subject of the Certificate Authorities (CAs) uploaded by the tenant in the Entra trust store. Browsers client or native application client use the hints sent back by server to filter the certificates shown in certificate picker. The client shows only the authentication certificates issued by the CAs in the trust store.
2. After you enable issuer hints and add, update, or delete CAs from the trust state, there's a delay of up to 10 minutes to propagate the issuer hints back to client. Users can't authenticate with certificates issued by the new CAs until the hints are propagated.
3. Authentication Policy Administrators should sign in with a certificate after they enable issuer hints to initiate the propagation. Users will see the error message below when CA trust store updates are in propagation.

8. Under the Authentication binding heading, select Single-factor authentication and Low affinity binding. These are the default settings can be overridden during the next step when rules are added.

9.Click Add Rule

10.In the new menu, check the box next to Certificate issuer and select your issuing CA. Then, set the Authenticator strength to multi-factor (or single-factor if required) and the Affinity binding to Low. Finally, click Add.

11.Under Username binding, remove all rows except for the PrincipalName row, ensuring it remains active.

12.Finally, click Save at the bottom of the Certificate-Based Authentication settings page to apply your changes.

Note:

For detailed instructions on issuing certificates to Windows devices using Intune, please refer to my blog post titled Step-by-Step Guide to Building Your Own Microsoft Cloud PKI with the New Intune Suite License.

Testing Entra ID certificate-based authentication(CBA)

After deploying your certificate, you can verify its presence in the User certificate store on your Windows device. To do this, search for "Run" in the Windows search bar and type `certmgr.msc`. The certificate should be listed under Personal > Certificates.

To verify the CBA, go to portal.office.com and enter the user's login ID.

You should be redirected to your company sign-in page where you can select Use a certificate or smart card

When you select this option, your browser will display a popup showing all eligible certificates on your system. Choose the new certificate and click OK.

Note: If you previously selected Multi-factor for the protection level, you will be logged in directly. If you selected Single-factor, you will encounter your second MFA challenge that is already associated with your account.

The Certificate Validation Process Explained

When a user attempts to sign in to an application or browser requiring certificate-based authentication, the following steps validate and grant access to Microsoft Entra:

1. Sign-In Attempt: The user tries to access an application and is redirected to Microsoft Entra ID for authentication.

2. Username Entry: The user enters their username.

3. Authentication Check: Microsoft Entra ID verifies if certificate-based authentication is enabled for the tenant.

4. Certificate Sign-In Selection: The user chooses the ‘Sign in with certificate’ option.

5. Certificate Request: Microsoft Entra ID requests the client certificate.

6 Issuer Hint Checking: The client only shows the authentication certificates issued by the CAs in the Entra trust store.

7. Certificate Selection: The user is prompted to choose from the authorized CA certificates on their device.

8. CRL Download: Microsoft Entra ID downloads the Certificate Revocation List (CRL) from the Certificate Authority (CA). If the CRL is cached but outdated (past the Next CRL Publish date), it will be re-downloaded. If the CRL cannot be downloaded, the login attempt will fail.

9. Certificate Validation: If the certificate is valid, the user is authenticated for single-factor authentication.

10. Multi-Factor Authentication (MFA) Check:

        - If the certificate satisfies MFA requirements, the user is signed in.

        - If the certificate is configured for single-factor authentication only, the user is prompted for MFA.

11. Successful Sign-In: The user is successfully signed in.

Conclusion

Entra ID certificate-based authentication offers a robust, passwordless solution that enhances security and user experience. By eliminating traditional passwords, it mitigates risks like phishing and brute-force attacks, aligning with modern security practices to ensure a secure and efficient authentication process. Adopting advanced measures like Entra ID certificate-based authentication is crucial for protecting users and data. Embrace this solution to enhance your organization's security and streamline access management for a safer, passwordless future.