Skip to main content
Prerequisites:
  • Obtaining either the Global admin or Privileged Authentication Administrator role within Microsoft Entra, as only individuals with these roles are authorized to configure the certificate authority (CA) in Microsoft Entra ID
  • Configuring the TruU Cloud Trust PKI as specified in the TruU Cloud Trust Configuration Guide
  • Setting up a certificate authority (CA) in Microsoft Entra ID (Azure AD) and activating certificate-based authentication (CBA)
  • Ensuring the certificate authority (CA) has an Internet-facing URL with a publicly accessible Certificate Revocation List (CRL)
  • Confirming that the domain controller can communicate with the CRL by configuring the necessary firewall ports. Alternative solutions are available if company policies restrict internet access for the domain controller
  • Issuing and publishing a user certificate designed for client authentication to be used with Microsoft Entra ID (Azure AD)

​
To configure and test Microsoft Entra CBA (Azure AD CBA), the following steps should be followed:**

​
Configure TruU Cloud Trust and obtain certs and CRL information

Note: You will need to have the certificates and URLs prepared ahead of time in order to supply this information into the CA setup
  1. In the TruU admin console navigate to the “Identity Servers” tab, then go to the “Key Store” page and search for Cloud Trust entries for Root and client certificate authentication chain entries and download the certificates
  1. Firstly, access the Cloud Trust entry to download the “client_certificate_auth_chain.pem” file
  1. Subsequently, click on the Cloud Trust Root entry and download the “cloud_ca_root.pem” file
  1. Once these files are downloaded, they must be copied to the domain controller or to a system that is accessible by your Microsoft Entra portal
  1. On your domain controller, you must add the Root certificate to the Trusted Root Certificate Authorities store. Additionally, the Issue Cloud Trust CA chain certificate should be added to the Intermediate Certificate Authorities store
Note: The issuing certificate is also placed into the NTAuthCertificates container. For detailed instructions, refer to the TruU Cloud Trust Configuration Guide
  1. To proceed with the certification authorities configuration, sign into the Microsoft Entra portal as a Global Administrator. Navigate to Microsoft Entra ID, select Security, and then choose Certificate Authorities from the menu on the left-hand side
  1. Next, locate your CRL URL by going to the TruU Admin portal, navigating to “Integrations”, then “Adapters”, and click on TruU Cloud Trust. Upon opening the form, scroll to the top to find your Root and Issuing CA CRL information
  1. For both the Root and the Issuing CA certificates, follow these sub-steps
a. Upload the .pem file you have downloaded b. Indicate whether the CA is a root certificate by selecting Yes, and select No if it is not c. Provide the http internet-facing URL for both the Issuing and Root CRLs. The CRLs contain all revoked certificates, which is necessary to ensure that authentication with revoked certificates will fail, thus maintaining control over certificate renewal d. Optionally, set the Delta CRL URL, which is the http internet-facing URL for the CRL that includes all revoked certificates issued since the last base CRL was published e. After clicking Add, remember to save the configuration. Repeat the process for the second .pem file
  1. To ensure the domain controller can successfully reach the published Certificate Revocation List (CRL), there are two verification methods that can be employed: using a web browser or the command prompt
a. Firstly, from the domain controller, copy the URL for the Issuing Certification Authority (CA) CRL obtained earlier and paste it into any web browser. If the URL is accessible, a .crl file should automatically download to the downloads folder b. Alternatively, an administrator can open a command prompt with elevated privileges and execute the following command, making sure to point it to the .pem file that was downloaded in the previous step: certutil -verify -urlfetch “path to truu chain cert” During the command’s output, one should examine the Certificate Distribution Point (CDP) section. A status of “Verified” indicates proper communication with the CRL. Conversely, a “Failed” status suggests that there may be an issue, such as the need to consult with the firewall team to ensure that the domain controller’s internet ports are open to reach the CRL NOTE: Moving on to the configuration of the authentication binding policy, this policy dictates the required strength of authentication, which can be set to either single-factor or multi-factor authentication. Administrators have the ability to modify the default settings and create custom policy rules by associating them with issuer Subject or policy Object Identifier (OID) fields in the certificate

​
To enable certificate-based authentication and configure user bindings in the Entra portal, follow these steps:

  1. Log into the Microsoft Entra portal with Authentication Policy Administrator credentials
  2. Navigate to Microsoft Entra ID (formerly Azure Active Directory), and on the left-hand menu, select Security
  3. Proceed to Authentication methods and then to Policies
  4. Under Manage, find and click on Authentication methods and then Certificate-based Authentication
  1. Use the Configure option to set up authentication binding and username binding
  2. Note that the protection level attribute defaults to Single-factor authentication. To enhance security, select Multi-factor authentication to change the default setting to MFA
  1. We can enhance security by setting up custom authentication binding rules, which determine the protection level required for client certificates. These rules can be based on the certificate’s issuer Subject or Policy OID fields. Essentially, authentication binding rules associate certificate attributes—either issuer or Policy OID—with a specified value, establishing a default protection level for that rule. It’s possible to create multiple rules to meet various security requirements. To introduce custom rules, one should navigate to the “Add Rule” option
  1. When creating a rule based on the certificate issuer, the following steps should be followed
a. Select Certificate issuer b. Choose an identifier for the Certificate issuer from the dropdown menu c. Set Multi-factor authentication as the protection level. To establish a rule using Policy OID, click Policy OID e. Input the desired value for the Policy OID f. Again, select Multi-factor authentication as the protection level After setting up the rules, click Ok to save them NOTE: Moving on to configuring the username binding policy, this is crucial for identifying the user within the tenant. By default, the system maps the Principal Name in the certificate to the onPremisesUserPrincipalName attribute in the user object. However, administrators have the flexibility to override this default setting by creating custom mappings Currently, there are two certificate fields supported for this purpose: SAN (Subject Alternate Name) Principal Name and SAN RFC822Name. These can be mapped against two user object attributes: userPrincipalName and onPremisesUserPrincipalName. To configure the username binding policy, one would follow the specific steps provided for these mappings It’s important to note that if a username binding policy utilizes attributes synced from on-premises, like the onPremisesUserPrincipalName attribute of the user object, any administrator with access to the Entra ID Connect server could potentially alter the sync attribute mapping. Consequently, this could change the value of the synced attribute to fit their requirements. Therefore, caution is advised when implementing policies that rely on synced attributes
  1. To set up username binding, one must choose from the available X.509 certificate fields and associate them with corresponding user attributes. The order in which username bindings are arranged is significant because it establishes the hierarchy of priority. The top binding in the list is given the highest precedence. If the authentication system locates the designated X.509 certificate field within the certificate and fails to match it with a user object, the authentication will not succeed. In this scenario, Microsoft Entra ID ceases further attempts with subsequent bindings. It is only when the specific X.509 certificate field is absent from the certificate that the system proceeds to the next priority level
  2. Once the desired binding is configured, one must click Save to ensure the changes are captured
Note that Microsoft Entra ID supports a specific set of username bindings. They are as follows:
  • Subject Alternative Name (SAN) Principal Name bound to userPrincipalName
  • SAN Principal Name bound to onPremisesUserPrincipalName
  • SAN RFC822Name bound to userPrincipalName
  • SAN RFC822Name bound to onPremisesUserPrincipalName

​
Enabling Certificate-Based Authentication (CBA) within the tenant,

  1. Begin by logging into the Microsoft Entra portal as an Authentication Policy Administrator
  2. Navigate to the “Security” section found in the menu on the left-hand side
  3. Under the “Manage” category, locate and select Authentication methods followed by Certificate-based Authentication
  4. To activate CBA, you will find an “Enable and Target” section, where you should select Enable to switch on CBA
  5. CBA can be implemented for all users or a targeted subset of users
    1. To enable CBA for every user, click on All Users
    2. Alternatively, if you wish to activate CBA for specific users or groups, opt for Select Users
Once certificate-based authentication is enabled on the tenant, all users within the tenant will be presented with the option to sign in using a certificate. However, it’s important to note that only those users who have been specifically enabled for certificate-based authentication will successfully authenticate using an X.509 certificate. Note: To test your configuration, it is essential to verify both your certificate and any custom authentication binding rules you may have set up To begin testing your certificate, attempt to sign into the MyApps portal using the browser on your device. Follow these steps:
  1. Enter your User Principal Name (UPN)
  2. Click Next
  3. Choose the Sign in with a certificate option
  1. Select Use certificate or Smart card option
    1. It is worth mentioning that users might encounter a certificate prompt during their first login attempt. This prompt can be managed through a registry key or a group policy which can suppress the certificate selection prompt if so desired
Configure Certificates Single Sign On