acrolinx

Author: Justinha

articles/active-directory/authentication/concept-certificate-based-authentication-technical-deep-dive.md

@@ -41,7 +41,7 @@ Now we'll walk through each step:
 1. Microsoft Entra ID checks whether CBA is enabled for the tenant. If CBA is enabled, the user sees a link to **Use a certificate or smartcard** on the password page. If the user doesn't see the sign-in link, make sure CBA is enabled on the tenant. For more information, see [How do I enable Microsoft Entra CBA?](./certificate-based-authentication-faq.yml#how-can-an-administrator-enable-microsoft-entra-cba-).
 
    >[!NOTE]
-   > If CBA is enabled on the tenant, all users will see the link to **Use a certificate or smart card** on the password page. However, only the users in scope for CBA will be able to authenticate successfully against an application that uses Microsoft Entra ID as their Identity provider (IdP).
+   > If CBA is enabled on the tenant, all users see the link to **Use a certificate or smart card** on the password page. However, only the users in scope for CBA can authenticate successfully against an application that uses Microsoft Entra ID as their Identity provider (IdP).
 
    :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/sign-in-cert.png" alt-text="Screenshot of the Use a certificate or smart card.":::
 
@@ -62,15 +62,15 @@ Now we'll walk through each step:
 
    :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/entry.png" alt-text="Screenshot of the entry for X.509 certificate.":::
 
-1. Microsoft Entra ID will request a client certificate, the user picks the client certificate, and clicks **Ok**.
+1. Microsoft Entra ID requests a client certificate, the user picks the client certificate, and clicks **Ok**.
 
    >[!NOTE] 
    >Trusted CA hints are not supported, so the list of certificates can't be further scoped. We're looking into adding this functionality in the future.
 
    :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/cert-picker.png" alt-text="Screenshot of the certificate picker." lightbox="./media/concept-certificate-based-authentication-technical-deep-dive/cert-picker.png":::
 
 1. Microsoft Entra ID verifies the certificate revocation list to make sure the certificate isn't revoked and is valid. Microsoft Entra ID identifies the user by using the [username binding configured](how-to-certificate-based-authentication.md#step-4-configure-username-binding-policy) on the tenant to map the certificate field value to the user attribute value.
-1. If a unique user is found with a Conditional Access policy that requires multifactor authentication, and the [certificate authentication binding rule](how-to-certificate-based-authentication.md#step-3-configure-authentication-binding-policy) satisfies MFA, then Microsoft Entra ID signs the user in immediately. If MFA is required but the certificate satisfies only a single factor, either passwordless sign-in or FIDO2 will be offered as a second factor if they are already registered.
+1. If a unique user is found with a Conditional Access policy that requires multifactor authentication, and the [certificate authentication binding rule](how-to-certificate-based-authentication.md#step-3-configure-authentication-binding-policy) satisfies MFA, then Microsoft Entra ID signs the user in immediately. If MFA is required but the certificate satisfies only a single factor, either passwordless sign-in or FIDO2 are offered as a second factor if they are already registered.
 1. Microsoft Entra ID completes the sign-in process by sending a primary refresh token back to indicate successful sign-in.
 1. If the user sign-in is successful, the user can access the application.
 
@@ -149,7 +149,7 @@ Let's look at an example of a user who has single factor certificates and has co
 
    :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/cert-picker.png" alt-text="Screenshot of how to select a certificate.":::
 
-1. Because the certificate is configured to be single-factor authentication strength, the user needs a second factor to meet MFA requirements. The user will see available second factors, which in this case is passwordless sign-in. Select **Approve a request on my Microsoft Authenticator app**.
+1. Because the certificate is configured to be single-factor authentication strength, the user needs a second factor to meet MFA requirements. The user sees available second factors, which in this case is passwordless sign-in. Select **Approve a request on my Microsoft Authenticator app**.
    :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/second-factor-request.png" alt-text="Screenshot of second factor request.":::
 
 1. You'll get a notification on your phone. Select **Approve Sign-in?**.
@@ -159,7 +159,7 @@ Let's look at an example of a user who has single factor certificates and has co
 
    :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/number.png" alt-text="Screenshot of number match.":::
 
-1. Select **Yes** and user will be authenticated and signed in.
+1. Select **Yes** and user can authenticate and sign in.
 
 ## Understanding the authentication binding policy
 
@@ -179,8 +179,8 @@ When a user has a multifactor certificate, they can perform multifactor authenti
 
 Because multiple authentication binding policy rules can be created with different certificate fields, there are some rules that determine the authentication protection level. They are as follows:
 
-1. Exact match is used for strong authentication by using policy OID. If you have a certificate A with policy OID **1.2.3.4.5** and a derived credential B based on that certificate has a policy OID **1.2.3.4.5.6**, and the custom rule is defined as **Policy OID** with value **1.2.3.4.5** with MFA, only certificate A will satisfy MFA, and credential B will satisfy only single-factor authentication. If the user used derived credential during sign-in and was configured to have MFA, the user will be asked for a second factor for successful authentication.
-1. Policy OID rules will take precedence over certificate issuer rules. If a certificate has both policy OID and Issuer, the policy OID is always checked first, and if no policy rule is found then the issuer subject bindings are checked. Policy OID has a higher strong authentication binding priority than the issuer.
+1. Exact match is used for strong authentication by using policy OID. If you have a certificate A with policy OID **1.2.3.4.5** and a derived credential B based on that certificate has a policy OID **1.2.3.4.5.6**, and the custom rule is defined as **Policy OID** with value **1.2.3.4.5** with MFA, only certificate A satisfies MFA, and credential B satisfies only single-factor authentication. If the user used derived credential during sign-in and was configured to have MFA, the user is asked for a second factor for successful authentication.
+1. Policy OID rules take precedence over certificate issuer rules. If a certificate has both policy OID and Issuer, the policy OID is always checked first, and if no policy rule is found then the issuer subject bindings are checked. Policy OID has a higher strong authentication binding priority than the issuer.
 1. If one CA binds to MFA, all user certificates that the CA issues qualify as MFA. The same logic applies for single-factor authentication.
 1. If one policy OID binds to MFA, all user certificates that include this policy OID as one of the OIDs (A user certificate could have multiple policy OIDs) qualify as MFA.
 1. If there's a conflict between multiple policy OIDs (such as when a certificate has two policy OIDs, where one binds to single-factor authentication and the other binds to MFA) then treat the certificate as a single-factor authentication.
@@ -208,7 +208,7 @@ There are four supported methods for certificate bindings. In general, mapping t
 Use the highest priority (lowest number) binding.
 
 1. Look up the user object by using the username or User Principal Name.
-1. If the X.509 certificate field is on the presented certificate, Microsoft Entra ID will match the value in the certificate field to the user object attribute value.
+1. If the X.509 certificate field is on the presented certificate, Microsoft Entra ID matches the value in the certificate field to the user object attribute value.
    1. If a match is found, user authentication is successful.
    1. If a match isn't found, move to the next priority binding.
 1. If the X.509 certificate field isn't on the presented certificate, move to the next priority binding.
@@ -222,7 +222,7 @@ Use the highest priority (lowest number) binding.
 Each of the Microsoft Entra attributes (userPrincipalName, onPremiseUserPrincipalName, certificateUserIds) available to bind certificates to Microsoft Entra user accounts has unique constraint to ensure a certificate only matches a single Microsoft Entra user account. However, Microsoft Entra CBA does support configuring multiple binding methods in the username binding policy. This allows an administrator to accommodate multiple certificate configurations. However the combination of some methods can also potentially permit one certificate to match to multiple Microsoft Entra user accounts. 
 
 >[!IMPORTANT]
->When using multiple bindings, Microsoft Entra CBA authentication is only as secure as your low-affinity binding as Microsoft Entra CBA will validate each of the bindings to authenticate the user. In order to eliminate a scenario where a single certificate matching multiple Microsoft Entra accounts, the tenant administrator should:
+>When using multiple bindings, Microsoft Entra CBA authentication is only as secure as your low-affinity binding as Microsoft Entra CBA validates each of the bindings to authenticate the user. In order to eliminate a scenario where a single certificate matching multiple Microsoft Entra accounts, the tenant administrator should:
 >- Configure a single binding method in the username binding policy.
 >- If a tenant has multiple binding methods configured and doesn't want to allow one certificate to multiple accounts, the tenant admin must ensure all allowable methods configured in the policy map to the same Microsoft Entra account, i.e all user accounts should have values matching all the bindings.
 >- If a tenant has multiple binding methods configured, the admin should make sure that they do not have more than one low-affinity binding 
@@ -245,34 +245,34 @@ Microsoft Entra ID downloads and caches the customers certificate revocation lis
 An admin can configure the CRL distribution point during the setup process of the trusted issuers in the Microsoft Entra tenant. Each trusted issuer should have a CRL that can be referenced by using an internet-facing URL.
 
 >[!IMPORTANT]
->The maximum size of a CRL for Microsoft Entra ID to successfully download on an interactive sign-in and cache is 20 MB in Azure Global and 45 MB in Azure US Government clouds, and the time required to download the CRL must not exceed 10 seconds. If Microsoft Entra ID can't download a CRL, certificate-based authentications using certificates issued by the corresponding CA will fail. As a best practice to keep CRL files within size limits, keep certificate lifetimes within reasonable limits and to clean up expired certificates. For more information, see [Is there a limit for CRL size?](certificate-based-authentication-faq.yml#is-there-a-limit-for-crl-size-).
+>The maximum size of a CRL for Microsoft Entra ID to successfully download on an interactive sign-in and cache is 20 MB in Azure Global and 45 MB in Azure US Government clouds, and the time required to download the CRL must not exceed 10 seconds. If Microsoft Entra ID can't download a CRL, certificate-based authentications using certificates issued by the corresponding CA fail. As a best practice to keep CRL files within size limits, keep certificate lifetimes within reasonable limits and to clean up expired certificates. For more information, see [Is there a limit for CRL size?](certificate-based-authentication-faq.yml#is-there-a-limit-for-crl-size-).
 
-When a user performs an interactive sign-in with a certificate, and the CRL exceeds the interactive limit for a cloud, their initial sign-in will fail with the following error:
+When a user performs an interactive sign-in with a certificate, and the CRL exceeds the interactive limit for a cloud, their initial sign-in fails with the following error:
 
 "The Certificate Revocation List (CRL) downloaded from {uri} has exceeded the maximum allowed size ({size} bytes) for CRLs in Microsoft Entra ID. Try again in few minutes. If the issue persists, contact your tenant administrators."
 
-After the error, Microsoft Entra ID will attempt to download the CRL subject to the service-side limits (45 MB in Azure Global and 150 MB in Azure US Government clouds).
+After the error, Microsoft Entra ID attempts to download the CRL subject to the service-side limits (45 MB in Azure Global and 150 MB in Azure US Government clouds).
 
 >[!IMPORTANT]
->If the admin skips the configuration of the CRL, Microsoft Entra ID will not perform any CRL checks during the certificate-based authentication of the user. This can be helpful for initial troubleshooting, but shouldn't be considered for production use.
+>If the admin skips the configuration of the CRL, Microsoft Entra ID doesn't perform any CRL checks during the certificate-based authentication of the user. This can be helpful for initial troubleshooting, but shouldn't be considered for production use.
 
 As of now, we don't support Online Certificate Status Protocol (OCSP) because of performance and reliability reasons. Instead of downloading the CRL at every connection by the client browser for OCSP, Microsoft Entra ID downloads once at the first sign-in and caches it, thereby improving the performance and reliability of CRL verification. We also index the cache so the search is much faster every time. Customers must publish CRLs for certificate revocation.
 
 The following steps are a typical flow of the CRL check:
 
-1. Microsoft Entra ID will attempt to download the CRL at the first sign-in event of any user with a certificate of the corresponding trusted issuer or certificate authority. 
-1. Microsoft Entra ID will cache and re-use the CRL for any subsequent usage. It will honor the **Next update date** and, if available, **Next CRL Publish date** (used by Windows Server CAs) in the CRL document.
-1. The user certificate-based authentication will fail if:
+1. Microsoft Entra ID attempts to download the CRL at the first sign-in event of any user with a certificate of the corresponding trusted issuer or certificate authority. 
+1. Microsoft Entra ID caches and re-uses the CRL for any subsequent usage. It honors the **Next update date** and, if available, **Next CRL Publish date** (used by Windows Server CAs) in the CRL document.
+1. The user certificate-based authentication fails if:
    - A CRL has been configured for the trusted issuer and Microsoft Entra ID can't download the CRL, due to availability, size, or latency constraints.
    - The user's certificate is listed as revoked on the CRL.
 
      :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/user-cert.png" alt-text="Screenshot of the revoked user certificate in the CRL." :::  
 
-   - Microsoft Entra ID will attempt to download a new CRL from the distribution point if the cached CRL document is expired. 
+   - Microsoft Entra ID attempts to download a new CRL from the distribution point if the cached CRL document is expired. 
 
 >[!NOTE]
->Microsoft Entra ID will check the CRL of the issuing CA and other CAs in the PKI trust chain up to the root CA. We have a limit of up to 10 CAs from the leaf client certificate for CRL validation in the PKI chain. The limitation is to make sure a bad actor will not bring down the service by uploading a PKI chain with a huge number of CAs with a bigger CRL size.
-If the tenant’s PKI chain has more than 5 CAs and in case of a CA compromise, the administrator should remove the compromised trusted issuer from the Microsoft Entra tenant configuration.
+>Microsoft Entra ID checks the CRL of the issuing CA and other CAs in the PKI trust chain up to the root CA. We have a limit of up to 10 CAs from the leaf client certificate for CRL validation in the PKI chain. The limitation is to make sure a bad actor doesn't bring down the service by uploading a PKI chain with a huge number of CAs with a bigger CRL size.
+If the tenant's PKI chain has more than 5 CAs and in case of a CA compromise, the administrator should remove the compromised trusted issuer from the Microsoft Entra tenant configuration.
 
 
 >[!IMPORTANT]
@@ -361,7 +361,7 @@ Certificate-based authentication can fail for reasons such as the certificate be
 
 :::image type="content" border="true" source="./media/concept-certificate-based-authentication-technical-deep-dive/validation-error.png" alt-text="Screenshot of a certificate validation error." :::  
 
-If CBA fails on a browser, even if the failure is because you cancel the certificate picker, you need to close the browser session and open a new session to try CBA again. A new session is required because browsers cache the certificate. When CBA is re-tried, the browser will send the cached certificate during the TLS challenge, which causes sign-in failure and the validation error.
+If CBA fails on a browser, even if the failure is because you cancel the certificate picker, you need to close the browser session and open a new session to try CBA again. A new session is required because browsers cache the certificate. When CBA is re-tried, the browser sends the cached certificate during the TLS challenge, which causes sign-in failure and the validation error.
 
 Click **More details** to get logging information that can be sent to an administrator, who in turn can get more information from the Sign-in logs.
 
@@ -376,7 +376,7 @@ Click **Other ways to sign in** to try other methods available to the user to si
 
 ## Certificate-based authentication in MostRecentlyUsed (MRU) methods
 
-Once a user authenticates successfully using CBA, the user's MostRecentlyUsed (MRU) authentication method will be set to CBA. Next time, when the user enters their UPN and clicks **Next**, the user will be taken to the CBA method directly, and need not select **Use the certificate or smart card**.
+Once a user authenticates successfully using CBA, the user's MostRecentlyUsed (MRU) authentication method is set to CBA. Next time, when the user enters their UPN and clicks **Next**, the user is taken to the CBA method directly, and need not select **Use the certificate or smart card**.
 
 To reset the MRU method, the user needs to cancel the certificate picker, click **Other ways to sign in**, and select another method available to the user and authenticate successfully.