Merge pull request #924 from MicrosoftDocs/main

12/19/2023 PM Publish

docs/id-governance/entitlement-management-organization.md

@@ -37,8 +37,8 @@ If you want to only allow individuals from designated organizations to request a
 There are four ways that entitlement management lets you specify the users that form a connected organization.  It could be
 
 * users in another Microsoft Entra directory (from any Microsoft cloud),
-* users in another non-Azure AD directory that has been configured for direct federation,
-* users in another non-Azure AD directory, whose email addresses all have the same domain name in common, or
+* users in another non-Microsoft directory that has been configured for [SAML/WS-Fed identity provider (IdP) federation](/entra/external-id/direct-federation),
+* users in another non-Microsoft directory, whose email addresses all have the same domain name in common and specific to that organization, or
 * users with a Microsoft Account, such as from the domain *live.com*, if you have a business need for collaboration with users that have no common organization.
 
 For example, suppose you work at Woodgrove Bank and you want to collaborate with two external organizations.  You want to give users from both external organizations access to the same resources, but these two organizations have different configurations:
@@ -62,7 +62,7 @@ How users from the Microsoft Entra directory or domain authenticate depends on t
 
 - Microsoft Entra ID, in the same cloud
 - Microsoft Entra ID, in another cloud
-- [Direct federation](~/external-id/direct-federation.md)
+- [SAML/WS-Fed identity provider (IdP) federation](~/external-id/direct-federation.md)
 - [One-time passcode](~/external-id/one-time-passcode.md) (domain)
 - Microsoft Account
 

docs/id-governance/identity-governance-applications-existing-users.md

@@ -112,11 +112,11 @@ This section explains three approaches for how to get a list of users in a comma
 
 This section applies to applications that use an LDAP directory as the underlying data store for users who don't authenticate to Microsoft Entra ID. Many LDAP directories, such as Active Directory, include a command that outputs a list of users.
 
-1. Identify which of the users in that directory are in scope for being users of the application. This choice will depend n your application's configuration. For some applications, any user who exists in an LDAP directory is a valid user. Other applications might require the user to have a particular attribute or be a member of a group in that directory.
+1. Identify which of the users in that directory are in scope for being users of the application. This choice will depend on your application's configuration. For some applications, any user who exists in an LDAP directory is a valid user. Other applications might require the user to have a particular attribute or be a member of a group in that directory.
 
 1. Run the command that retrieves that subset of users from your directory. Ensure that the output includes the attributes of users that will be used for matching with Microsoft Entra ID. Examples of these attributes are employee ID, account name, and email address. 
 
-   For example, this command would produce a CSV file in the current directory with the `userPrincipalName` attribute of every person in the directory:
+   For example, this command would produce a CSV file in the current file system directory with the `userPrincipalName` attribute of every person in the LDAP directory:
 
    ```powershell
    $out_filename = ".\users.csv"

docs/identity/authentication/concept-certificate-based-authentication-technical-deep-dive.md

@@ -191,6 +191,19 @@ Because multiple custom authentication binding policy rules can be created with
 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. One certificate issuer can only have one valid strong authentication binding (that is, a certificate can't bind to both single-factor and MFA).
 
+>[!IMPORTANT]
+>There is a known issue where an Entra tenant admin configures a CBA authentication policy rule using both Issuer and Policy OID impacts some device registration scenarios including:
+>- Windows Hello For Business enrollment
+>- Fido2 Security Key registration
+>- Windows Passwordless Phone Sign-in
+>  
+>Device registration with Workplace Join, Entra ID and Hybrid Entra ID device join scenarios are not impacted. CBA authentication policy rules using either Issuer OR Policy OID are not impacted.
+>To mitigate, admins should :
+>- Edit the certificate-based authentication policy rules currently using both Issuer and Policy OID options and remove either the Issuer or OID requirement and save. OR
+>- Remove the authentication policy rule currently using both Issuer and Policy OID and create rules
+>  
+>We are working to fix the issue.
+
 ## Understanding the username binding policy
 
 The username binding policy helps validate the certificate of the user. By default, Subject Alternate Name (SAN) Principal Name in the certificate is mapped to UserPrincipalName attribute of the user object to determine the user.

docs/identity/authentication/how-to-certificate-based-authentication.md

@@ -219,6 +219,19 @@ To enable CBA and configure user bindings in the Microsoft Entra admin center, c
 
    1. Authenticate with a certificate that has policy OID of 3.4.5.6 and Issued by CN=CBATestRootProd. Authentication should pass and get a multifactor claim.
 
+>[!IMPORTANT]
+>There is a known issue where an Entra tenant admin configures a CBA authentication policy rule using both Issuer and Policy OID impacts some device registration scenarios including:
+>- Windows Hello For Business enrollment
+>- Fido2 Security Key registration
+>- Windows Passwordless Phone Sign-in
+>  
+>Device registration with Workplace Join, Entra ID and Hybrid Entra ID device join scenarios are not impacted. CBA authentication policy rules using either Issuer OR Policy OID are not impacted.
+>To mitigate, admins should :
+>- Edit the certificate-based authentication policy rules currently using both Issuer and Policy OID options and remove either the Issuer or OID requirement and save. OR
+>- Remove the authentication policy rule currently using both Issuer and Policy OID and create rules
+>  
+>We are working to fix the issue.
+
    To create a rule by Issuer and Serial Number:
 
    1. Add an authentication binding policy that requires any cert issued by CN=CBATestRootProd with policyOID 1.2.3.4.6 needs only high affinity binding (that is, Issuer and serial number are used).