Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into cdnfreshness2

Author: duongau

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

@@ -74,30 +74,24 @@ Now we'll walk through each step:
 
 ## Certificate-based authentication is MFA capable
 
-Azure AD CBA is an MFA (Multi factor authentication) capable method, that is Azure AD CBA can be either Single (SF) or Multi-factor (MF) depending on the tenant configuration. Enabling CBA for a user indicates the user is potentially capable of MFA. This means a user may need additional configuration to proof up to register other authentication methods when the user is in scope for CBA. 
+Azure AD CBA is an MFA (Multi factor authentication) capable method, that is Azure AD CBA can be either Single (SF) or Multi-factor (MF) depending on the tenant configuration. Enabling CBA for a user indicates the user is potentially capable of MFA. This means a user may need additional configuration to get MFA and proof up to register other authentication methods when the user is in scope for CBA.
 
-This can happen when: 
-
-If CBA enabled user only has a Single Factor (SF) certificate
-	To unblock user:
-	1. Use Password + SF certificate.
+If CBA enabled user only has a Single Factor (SF) certificate and need MFA
+   1. Use Password + SF certificate.
    1. Issue Temporary Access Pass (TAP)
    1. Admin adds Phone Number to user account and allows Voice/SMS method for user.
 
-If CBA enabled user but has not yet been issued a certificate
-   To unblock user:
+If CBA enabled user has not yet been issued a certificate and need MFA
    1. Issue Temporary Access Pass (TAP)
    1. Admin adds Phone Number to user account and allows Voice/SMS method for user.
 
-If CBA enabled user cannot use MF cert (such as on mobile device without smart card support)
-   To unblock user: 
+If CBA enabled user cannot use MF cert (such as on mobile device without smart card support) and need MFA
    1. Issue Temporary Access Pass (TAP)
    1. User Register another MFA method (when user can use MF cert)
    1. Use Password + MF cert (when user can use MF cert)
    1. Admin adds Phone Number to user account and allows Voice/SMS method for user
 
 
-
 ## MFA with Single-factor certificate-based authentication
 
 Azure AD CBA can be used as a second factor to meet MFA requirements with single-factor certificates. The supported combintaions are

articles/active-directory/authentication/concept-certificate-based-authentication.md

@@ -66,7 +66,7 @@ The following scenarios are supported:
 
 The following scenarios aren't supported:
 
-- Certificate Authority hints aren't supported, so the list of certificates that appears for users in the certificate picket UI isn't scoped.
+- Certificate Authority hints aren't supported, so the list of certificates that appears for users in the certificate picker UI isn't scoped.
 - Only one CRL Distribution Point (CDP) for a trusted CA is supported.
 - The CDP can be only HTTP URLs. We don't support Online Certificate Status Protocol (OCSP), or Lightweight Directory Access Protocol (LDAP) URLs.
 - Configuring other certificate-to-user account bindings, such as using the **Subject**, **Subject + Issuer** or **Issuer + Serial Number**, aren’t available in this release.

articles/active-directory/authentication/howto-authentication-methods-activity.md

@@ -112,7 +112,7 @@ The registration details report shows the following information for each user:
 - SSPR Registered (Registered, Not Registered)
 - SSPR Enabled (Enabled, Not Enabled)
 - SSPR Capable (Capable, Not Capable) 
-- Methods registered (Email, Mobile Phone, Alternative Mobile Phone, Office Phone, Microsoft Authenticator Push, Software One Time Passcode, FIDO2, Security Key, Security questions, Hardware OATH token)
+- Methods registered (Alternate Mobile Phone, Email, FIDO2 Security Key, Hardware OATH token, Microsoft Authenticator app, Microsoft Passwordless phone sign-in, Mobile Phone, Office Phone, Security questions, Software OATH token, Temporary Access Pass, Windows Hello for Business)
 
   ![Screenshot of user registration details](media/how-to-authentication-methods-usage-insights/registration-details.png)
 

articles/active-directory/authentication/howto-registration-mfa-sspr-combined.md

@@ -36,6 +36,9 @@ To enable combined registration, complete these steps:
 
    ![Enable the combined security info experience for users](media/howto-registration-mfa-sspr-combined/enable-the-combined-security-info.png)
 
+   > [!IMPORTANT]
+   > If your Azure tenant has already been enabled for combined registration, you might not see the configuration option for **Users can use the combined security information registration experience** or even see it grayed out.
+
 > [!NOTE]
 > After you enable combined registration, users who register or confirm their phone number or mobile app through the new experience can use them for Azure AD Multi-Factor Authentication and SSPR, if those methods are enabled in the Azure AD Multi-Factor Authentication and SSPR policies.
 >

articles/active-directory/develop/workload-identity-federation-create-trust-user-assigned-managed-identity.md

@@ -137,7 +137,7 @@ For a workflow triggered by a pull request event, specify an **Entity type** of
 
 Fill in the **Cluster issuer URL**, **Namespace**, **Service account name**, and **Name** fields:
 
-- **Cluster issuer URL** is the [OIDC issuer URL](../../aks/cluster-configuration.md#oidc-issuer) for the managed cluster or the [OIDC Issuer URL](https://azure.github.io/azure-workload-identity/docs/installation/self-managed-clusters/oidc-issuer.html) for a self-managed cluster.
+- **Cluster issuer URL** is the [OIDC issuer URL](../../aks/use-oidc-issuer.md) for the managed cluster or the [OIDC Issuer URL](https://azure.github.io/azure-workload-identity/docs/installation/self-managed-clusters/oidc-issuer.html) for a self-managed cluster.
 - **Service account name** is the name of the Kubernetes service account, which provides an identity for processes that run in a Pod. 
 - **Namespace** is the service account namespace.
 - **Name** is the name of the federated credential, which can't be changed later.

articles/active-directory/develop/workload-identity-federation-create-trust.md

@@ -64,7 +64,6 @@ To add a federated identity for GitHub actions, follow these steps:
 
     :::image type="content" source="media/workload-identity-federation-create-trust/add-credential.png" alt-text="Screenshot of the Add a credential window, showing sample values." :::
 
-
 Use the following values from your Azure AD application registration for your GitHub workflow:
 
 - `AZURE_CLIENT_ID` the **Application (client) ID** 
@@ -146,7 +145,7 @@ Select the **Kubernetes accessing Azure resources** scenario from the dropdown m
 
 Fill in the **Cluster issuer URL**, **Namespace**, **Service account name**, and **Name** fields:
 
-- **Cluster issuer URL** is the [OIDC issuer URL](../../aks/cluster-configuration.md#oidc-issuer) for the managed cluster or the [OIDC Issuer URL](https://azure.github.io/azure-workload-identity/docs/installation/self-managed-clusters/oidc-issuer.html) for a self-managed cluster.
+- **Cluster issuer URL** is the [OIDC issuer URL](../../aks/use-oidc-issuer.md) for the managed cluster or the [OIDC Issuer URL](https://azure.github.io/azure-workload-identity/docs/installation/self-managed-clusters/oidc-issuer.html) for a self-managed cluster.
 - **Service account name** is the name of the Kubernetes service account, which provides an identity for processes that run in a Pod. 
 - **Namespace** is the service account namespace.
 - **Name** is the name of the federated credential, which can't be changed later.
@@ -220,7 +219,7 @@ az ad app federated-credential create --id f6475511-fd81-4965-a00e-41e7792b7b9c
 
 ### Kubernetes example
 
-*issuer* is your service account issuer URL (the [OIDC issuer URL](../../aks/cluster-configuration.md#oidc-issuer) for the managed cluster or the [OIDC Issuer URL](https://azure.github.io/azure-workload-identity/docs/installation/self-managed-clusters/oidc-issuer.html) for a self-managed cluster).  
+*issuer* is your service account issuer URL (the [OIDC issuer URL](../../aks/use-oidc-issuer.md) for the managed cluster or the [OIDC Issuer URL](https://azure.github.io/azure-workload-identity/docs/installation/self-managed-clusters/oidc-issuer.html) for a self-managed cluster).  
 
 *subject* is the subject name in the tokens issued to the service account. Kubernetes uses the following format for subject names: `system:serviceaccount:<SERVICE_ACCOUNT_NAMESPACE>:<SERVICE_ACCOUNT_NAME>`.
 
@@ -309,6 +308,7 @@ az ad app federated-credential delete --id f6475511-fd81-4965-a00e-41e7792b7b9c
 ::: zone pivot="identity-wif-apps-methods-powershell"
 
 ## Prerequisites
+
 - To run the example scripts, you have two options:
   - Use [Azure Cloud Shell](../../cloud-shell/overview.md), which you can open by using the **Try It** button in the upper-right corner of code blocks.
   - Run scripts locally with Azure PowerShell, as described in the next section.
@@ -364,7 +364,7 @@ New-AzADAppFederatedCredential -ApplicationObjectId $appObjectId -Audience api:/
 ### Kubernetes example
 
 - *ApplicationObjectId*: the object ID of the app (not the application (client) ID) you previously registered in Azure AD.
-- *Issuer* is your service account issuer URL (the [OIDC issuer URL](../../aks/cluster-configuration.md#oidc-issuer) for the managed cluster or the [OIDC Issuer URL](https://azure.github.io/azure-workload-identity/docs/installation/self-managed-clusters/oidc-issuer.html) for a self-managed cluster).  
+- *Issuer* is your service account issuer URL (the [OIDC issuer URL](../../aks/use-oidc-issuer.md) for the managed cluster or the [OIDC Issuer URL](https://azure.github.io/azure-workload-identity/docs/installation/self-managed-clusters/oidc-issuer.html) for a self-managed cluster).  
 - *Subject* is the subject name in the tokens issued to the service account. Kubernetes uses the following format for subject names: `system:serviceaccount:<SERVICE_ACCOUNT_NAMESPACE>:<SERVICE_ACCOUNT_NAME>`.
 - *Name* is the name of the federated credential, which can't be changed later.
 - *Audience* lists the audiences that can appear in the `aud` claim of the external token.
@@ -464,7 +464,7 @@ And you get the response:
 
 Run the following method to configure a federated identity credential on an app and create a trust relationship with a Kubernetes service account.  Specify the following parameters:
 
-- *issuer* is your service account issuer URL (the [OIDC issuer URL](../../aks/cluster-configuration.md#oidc-issuer) for the managed cluster or the [OIDC Issuer URL](https://azure.github.io/azure-workload-identity/docs/installation/self-managed-clusters/oidc-issuer.html) for a self-managed cluster).  
+- *issuer* is your service account issuer URL (the [OIDC issuer URL](../../aks/use-oidc-issuer.md) for the managed cluster or the [OIDC Issuer URL](https://azure.github.io/azure-workload-identity/docs/installation/self-managed-clusters/oidc-issuer.html) for a self-managed cluster).  
 - *subject* is the subject name in the tokens issued to the service account. Kubernetes uses the following format for subject names: `system:serviceaccount:<SERVICE_ACCOUNT_NAMESPACE>:<SERVICE_ACCOUNT_NAME>`.
 - *name* is the name of the federated credential, which can't be changed later.
 - *audiences* lists the audiences that can appear in the external token.  This field is mandatory.  The recommended value is "api://AzureADTokenExchange".

articles/active-directory/fundamentals/2-secure-access-current-state.md

@@ -1,14 +1,14 @@
 ---
-title: Discover the current state of external collaboration with Azure Active Directory 
-description: Learn methods to discover the current state of your collaboration
+title: Discover the current state of external collaboration in your organization
+description: Discover the current state of an organization's collaboration with audit logs, reporting, allowlist, blocklist, and more.
 services: active-directory
 author: gargi-sinha
 manager: martinco
 ms.service: active-directory
 ms.workload: identity
 ms.subservice: fundamentals
 ms.topic: conceptual
-ms.date: 12/15/2022
+ms.date: 02/21/2023
 ms.author: gasinh
 ms.reviewer: ajburnle
 ms.custom: "it-pro, seodec18"
@@ -19,53 +19,55 @@ ms.collection: M365-identity-device-management
 
 Before you learn about the current state of your external collaboration, determine a security posture. Consider centralized vs. delegated control, also governance, regulatory, and compliance targets.
 
-Learn more: [Determine your security posture for external users](1-secure-access-posture.md)
+Learn more: [Determine your security posture for external access with Azure Active Directory](1-secure-access-posture.md)
 
-Users in your organization likely collaborate with users from other organizations. Collaboration can occur with productivity applications like Microsoft 365, by email, or sharing resources with external users. The foundation of your governance plan can include:
+Users in your organization likely collaborate with users from other organizations. Collaboration occurs with productivity applications like Microsoft 365, by email, or sharing resources with external users. These scenarios include users:
 
-* Users initiating external collaboration
-* Collaboration with external users and organizations
-* Access granted to external users
+* Initiating external collaboration
+* Collaborating with external users and organizations
+* Granting access to external users
 
-## Users initiating external collaboration
+## Determine who initiates external collaboration
 
-Users seeking external collaboration know the applications needed for their work, and when access ends. Therefore, determine users with delegated permission to invite external users, create access packages, and complete access reviews.
+Generally, users seeking external collaboration know the applications to use, and when access ends. Therefore, determine users with delegated permissions to invite external users, create access packages, and complete access reviews.
 
 To find collaborating users:
 
-* [Microsoft 365, audit log activities](/microsoft-365/compliance/audit-log-activities?view=o365-worldwide&preserve-view=true)
-* [Auditing and reporting a B2B collaboration user](../external-identities/auditing-and-reporting.md)
+* Microsoft 365 [Audit log activities](/microsoft-365/compliance/audit-log-activities?view=o365-worldwide&preserve-view=true) - search for events and discover activities audited in Microsoft 365
+* [Auditing and reporting a B2B collaboration user](../external-identities/auditing-and-reporting.md) - verify guest user access, and see records of system and user activities
 
-## Collaboration with external users and organizations
+## Enumerate guest users and organizations
 
-External users might be Azure AD B2B users with partner-managed credentials, or external users with locally provisioned credentials. Typically, these users are a UserType of Guest. See, [B2B collaboration overview](../external-identities/what-is-b2b.md).
+External users might be Azure AD B2B users with partner-managed credentials, or external users with locally provisioned credentials. Typically, these users are the Guest UserType. To learn about inviting guests users and sharing resources, see [B2B collaboration overview](../external-identities/what-is-b2b.md).
 
 You can enumerate guest users with:
 
 * [Microsoft Graph API](/graph/api/user-list?tabs=http)
 * [PowerShell](/graph/api/user-list?tabs=http)
 * [Azure portal](../enterprise-users/users-bulk-download.md)
 
-There are tools to identify Azure AD B2B collaboration, external Azure AD tenants and users accessing applications:
+Use the following tools to identify Azure AD B2B collaboration, external Azure AD tenants, and users accessing applications:
 
-* [PowerShell module](https://github.com/AzureAD/MSIdentityTools/wiki/Get-MSIDCrossTenantAccessActivity)
-* [Azure Monitor workbook](../reports-monitoring/workbook-cross-tenant-access-activity.md)
+* PowerShell module, [Get MsIdCrossTenantAccessActivity](https://github.com/AzureAD/MSIdentityTools/wiki/Get-MSIDCrossTenantAccessActivity)
+* [Cross-tenant access activity workbook](../reports-monitoring/workbook-cross-tenant-access-activity.md)
 
-### Email domains and companyName property
+### Discover email domains and companyName property
 
-Determine external organizations with the domain names of external user email addresses. This discovery might not be possible with consumer identity providers such as Google. We recommend you write the companyName attribute to identify external organizations.
+You can determine external organizations with the domain names of external user email addresses. This discovery might not be possible with consumer identity providers. We recommend you write the companyName attribute to identify external organizations.
 
-### Allowlist, blocklist, and entitlement management
+### Use allowlist, blocklist, and entitlement management
 
-For your organization to collaborate with, or block, specific organizations, at the tenant level, there is allowlist or blocklist. Use this feature to control B2B invitations and redemptions regardless of source (such as Microsoft Teams, SharePoint, or the Azure portal). See, [Allow or block invitations to B2B users from specific organizations](../external-identities/allow-deny-list.md).
+Use the allowlist or blocklist to enable your organization to collaborate with, or block, organizations at the tenant level. Control B2B invitations and redemptions regardless of source (such as Microsoft Teams, SharePoint, or the Azure portal). 
+
+See, [Allow or block invitations to B2B users from specific organizations](../external-identities/allow-deny-list.md)
 
 If you use entitlement management, you can confine access packages to a subset of partners with the **Specific connected organizations** option, under New access packages, in Identity Governance.
 
-   ![Screenshot of the Specific connected organizations option, under New access packages.](media/secure-external-access/2-new-access-package.png)
+   ![Screenshot of settings and options under Identity Governance, New access package.](media/secure-external-access/2-new-access-package.png)
 
-## External user access
+## Determine external user access
 
-After you have an inventory of external users and organizations, determine the access to grant to these users. You can use the Microsoft Graph API to determine Azure AD group membership or application assignment.
+With an inventory of external users and organizations, determine the access to grant to the users. You can use the Microsoft Graph API to determine Azure AD group membership or application assignment.
 
 * [Working with groups in Microsoft Graph](/graph/api/resources/groups-overview?context=graph%2Fcontext&view=graph-rest-1.0&preserve-view=true)
 * [Applications API overview](/graph/applications-concept-overview?view=graph-rest-1.0&preserve-view=true)