Merge pull request #213257 from MicrosoftDocs/main

9/30 AM Publish

Author: huypub

articles/active-directory-domain-services/powershell-create-instance.md

@@ -209,7 +209,7 @@ $replicaSetParams = @{
   Location = $AzureLocation
   SubnetId = "/subscriptions/$AzureSubscriptionId/resourceGroups/$ResourceGroupName/providers/Microsoft.Network/virtualNetworks/$VnetName/subnets/DomainServices"
 }
-$replicaSet = New-AzADDomainServiceReplicaSet @replicaSetParams
+$replicaSet = New-AzADDomainServiceReplicaSetObject @replicaSetParams
 
 $domainServiceParams = @{
   Name = $ManagedDomainName

articles/active-directory/app-provisioning/accidental-deletions.md

@@ -8,12 +8,12 @@ ms.service: active-directory
 ms.subservice: app-provisioning
 ms.topic: how-to
 ms.workload: identity
-ms.date: 09/27/2021
+ms.date: 09/30/2022
 ms.author: kenwith
 ms.reviewer: arvinh
 ---
 
-# Enable accidental deletions prevention in the Azure AD provisioning service (Preview)
+# Enable accidental deletions prevention in the Azure AD provisioning service
 
 The Azure AD provisioning service includes a feature to help avoid accidental deletions. This feature ensures that users aren't disabled or deleted in an application unexpectedly.
 
@@ -32,7 +32,7 @@ threshold. Also, be sure the notification email address is completed. If the del
 When the deletion threshold is met, the job will go into quarantine and a notification email will be sent. The quarantined job can then be allowed or rejected. To learn more about quarantine behavior, see [Application provisioning in quarantine status](application-provisioning-quarantine-status.md).
 
 ## Recovering from an accidental deletion
-If you encounter an accidental deletion you'll see it on the provisioning status page.  It will say **Provisioning has been quarantined. See quarantine details for more information.**.
+If you encounter an accidental deletion you'll see it on the provisioning status page.  It will say **Provisioning has been quarantined. See quarantine details for more information**.
 
 You can click either **Allow deletes** or **View provisioning logs**.
 

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

@@ -70,8 +70,8 @@ Let's cover each step:
 
    :::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. Azure AD verifies the certificate revocation list to make sure the certificate is not revoked and is valid. Azure AD identifies the user in the tenant by using the [username binding configured](how-to-certificate-based-authentication.md#step-3-configure-username-binding-policy) on the tenant by mapping the certificate field value to user attribute value.
-1. If a unique user is found and the user has a conditional access policy and needs multifactor authentication (MFA) and the [certificate authentication binding rule](how-to-certificate-based-authentication.md#step-2-configure-authentication-binding-policy) satisfies MFA, then Azure AD signs the user in immediately. If the certificate satisfies only a single factor, then it requests the user for a second factor to complete Azure AD Multi-Factor Authentication.
+1. Azure AD verifies the certificate revocation list to make sure the certificate is not revoked and is valid. Azure AD identifies the user in the tenant by using the [username binding configured](how-to-certificate-based-authentication.md#step-4-configure-username-binding-policy) on the tenant by mapping the certificate field value to user attribute value.
+1. If a unique user is found and the user has a conditional access policy and needs multifactor authentication (MFA) and the [certificate authentication binding rule](how-to-certificate-based-authentication.md#step-3-configure-authentication-binding-policy) satisfies MFA, then Azure AD signs the user in immediately. If the certificate satisfies only a single factor, then it requests the user for a second factor to complete Azure AD Multi-Factor Authentication.
 1. Azure AD 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.
 
@@ -244,4 +244,4 @@ For the next test scenario, configure the authentication policy where the **poli
 - [Windows SmartCard logon using Azure AD CBA](concept-certificate-based-authentication-smartcard.md)
 - [Azure AD CBA on mobile devices (Android and iOS)](concept-certificate-based-authentication-mobile.md)
 - [FAQ](certificate-based-authentication-faq.yml)
-- [Troubleshoot Azure AD CBA](troubleshoot-certificate-based-authentication.md)
+- [Troubleshoot Azure AD CBA](troubleshoot-certificate-based-authentication.md)

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

@@ -167,6 +167,12 @@ To switch the directory in the Azure portal, click the user account name in the
 
 ![External users can switch directory.](media/concept-registration-mfa-sspr-combined/switch-directory.png)
 
+Or, you can specify a tenant by URL to access security information.
+
+`https://mysignins.microsoft.com/security-info?tenant=<Tenant Name>`
+
+`https://mysignins.microsoft.com/security-info/?tenantId=<Tenant ID>`
+
 ## Next steps
 
 To get started, see the tutorials to [enable self-service password reset](tutorial-enable-sspr.md) and [enable Azure AD Multi-Factor Authentication](tutorial-enable-azure-mfa.md).

articles/active-directory/authentication/concept-sspr-writeback.md

@@ -42,7 +42,7 @@ Password writeback provides the following features:
 
 To get started with SSPR writeback, complete either one or both of the following tutorials:
 
-- [Tutorial: Enable self-service password reset (SSPR) writeback](tutorial-enable-cloud-sync-sspr-writeback.md)
+- [Tutorial: Enable self-service password reset (SSPR) writeback](tutorial-enable-sspr-writeback.md)
 - [Tutorial: Enable Azure Active Directory Connect cloud sync self-service password reset writeback to an on-premises environment (Preview)](tutorial-enable-cloud-sync-sspr-writeback.md)
 
 ## Azure AD Connect and cloud sync side-by-side deployment

articles/active-directory/authentication/how-to-certificate-based-authentication.md

@@ -129,8 +129,29 @@ For additional details see: [Understanding the certificate revocation process](.
 
 [!INCLUDE [Set-AzureAD](../../../includes/active-directory-authentication-set-trusted-azuread.md)]
 
+## Step 2: Enable CBA on the tenant
 
-## Step 2: Configure authentication binding policy 
+To enable the certificate-based authentication in the Azure Portal, complete the following steps:
+
+1. Sign in to the [Azure portal](https://portal.azure.com/) as an Authentication Policy Administrator.
+1. Select **Azure Active Directory**, then choose **Security** from the menu on the left-hand side.
+1. Under **Manage**, select **Authentication methods** > **Certificate-based Authentication**.
+1.	Under **Basics**, select **Yes** to enable CBA.
+1. CBA can be enabled for a targeted set of users.
+   1. Click **All users** to enable all users.
+   1. Click **Select users** to enable selected users or groups. 
+   1. Click **+ Add users**, select specific users and groups.
+   1. Click **Select** to add them.
+
+   :::image type="content" border="true" source="./media/how-to-certificate-based-authentication/enable.png" alt-text="Screenshot of how to enable CBA.":::
+ 
+Once certificate-based authentication is enabled on the tenant, all users in the tenant will see the option to sign in with a certificate. Only users who are enabled for certificate-based authentication will be able to authenticate using the X.509 certificate. 
+
+>[!NOTE]
+>The network administrator should allow access to certauth endpoint for the customer’s cloud environment in addition to login.microsoftonline.com. Disable TLS inspection on the certauth endpoint to make sure the client certificate request succeeds as part of the TLS handshake.
+
+
+## Step 3: Configure authentication binding policy 
 
 The authentication binding policy helps determine the strength of authentication to either a single factor or multi factor. An admin can change the default value from single-factor to multifactor and configure custom policy rules by mapping to issuer Subject or policy OID fields in the certificate.
 
@@ -176,7 +197,7 @@ To enable the certificate-based authentication and configure user bindings in th
 
 1. Click **Ok** to save any custom rule.
 
-## Step 3: Configure username binding policy
+## Step 4: Configure username binding policy
 
 The username binding policy helps determine the user in the tenant. By default, we map Principal Name in the certificate to onPremisesUserPrincipalName in the user object to determine the user.
 
@@ -209,27 +230,6 @@ The final configuration will look like this image:
 
 :::image type="content" border="true" source="./media/how-to-certificate-based-authentication/final.png" alt-text="Screenshot of the final configuration.":::
 
-## Step 4: Enable CBA on the tenant
-
-To enable the certificate-based authentication in the Azure MyApps portal, complete the following steps:
-
-1. Sign in to the [MyApps portal](https://myapps.microsoft.com/) as an Authentication Policy Administrator.
-1. Select **Azure Active Directory**, then choose **Security** from the menu on the left-hand side.
-1. Under **Manage**, select **Authentication methods** > **Certificate-based Authentication**.
-1.	Under **Basics**, select **Yes** to enable CBA.
-1. CBA can be enabled for a targeted set of users.
-   1. Click **All users** to enable all users.
-   1. Click **Select users** to enable selected users or groups. 
-   1. Click **+ Add users**, select specific users and groups.
-   1. Click **Select** to add them.
-
-   :::image type="content" border="true" source="./media/how-to-certificate-based-authentication/enable.png" alt-text="Screenshot of how to enable CBA.":::
- 
-Once certificate-based authentication is enabled on the tenant, all users in the tenant will see the option to sign in with a certificate. Only users who are enabled for certificate-based authentication will be able to authenticate using the X.509 certificate. 
-
->[!NOTE]
->The network administrator should allow access to certauth endpoint for the customer’s cloud environment in addition to login.microsoftonline.com. Disable TLS inspection on the certauth endpoint to make sure the client certificate request succeeds as part of the TLS handshake.
-
 ## Step 5: Test your configuration
 
 This section covers how to test your certificate and custom authentication binding rules.

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

@@ -25,7 +25,7 @@ This topic covers how to troubleshoot Azure AD certificate-based authentication
 
 ## Why don't I see an option to sign in using certificates against Azure Active Directory after I enter my username?
 
-An administrator needs to enable CBA for the tenant to make the sign-in with certificate option available for users. For more information, see [Step 2: Configure authentication binding policy](how-to-certificate-based-authentication.md#step-2-configure-authentication-binding-policy).
+An administrator needs to enable CBA for the tenant to make the sign-in with certificate option available for users. For more information, see [Step 3: Configure authentication binding policy](how-to-certificate-based-authentication.md#step-3-configure-authentication-binding-policy).
 
 ## User-facing sign-in error messages
 
@@ -47,12 +47,12 @@ Make sure the certificate is valid and works for the user binding and authentica
 
 :::image type="content" border="true" source="./media/troubleshoot-certificate-based-authentication/reset.png" alt-text="Screenshot of password reset error." :::
 
-Make sure the user is trying to sign in with the correct username. This error happens when a unique user can't be found using the [username binding](how-to-certificate-based-authentication.md#step-3-configure-username-binding-policy) on the certificate fields.
+Make sure the user is trying to sign in with the correct username. This error happens when a unique user can't be found using the [username binding](how-to-certificate-based-authentication.md#step-4-configure-username-binding-policy) on the certificate fields.
 
 - Make sure user bindings are set correctly and the certificate field is mapped to the correct user Attribute.
 - Make sure the user Attribute contains the correct value that matches the certificate field value.
 
-For more information, see [Step 3: Configure username binding policy](how-to-certificate-based-authentication.md#step-3-configure-username-binding-policy).
+For more information, see [Step 4: Configure username binding policy](how-to-certificate-based-authentication.md#step-4-configure-username-binding-policy).
 
 If the user is a federated user moving to Azure AD and if the user binding configuration is Principal Name > onPremisesUserPrincipalName:
 
@@ -70,7 +70,7 @@ There is also a known issue when a user who is not in scope for CBA ties to sign
 
 :::image type="content" border="true" source="./media/troubleshoot-certificate-based-authentication/alt-failed.png" alt-text="Screenshot of the alternative error message for Azure Active Directory certificate-based authentication in Azure AD.":::
 
-In both cases, the error can be resolved by making sure the user is in scope for Azure AD CBA. For more information, see [Step 4: Enable CBA on the tenant](how-to-certificate-based-authentication.md#step-4-enable-cba-on-the-tenant).
+In both cases, the error can be resolved by making sure the user is in scope for Azure AD CBA. For more information, see [Step 2: Enable CBA on the tenant](how-to-certificate-based-authentication.md#step-2-enable-cba-on-the-tenant).
 
 ### AADSTS90100: flowtoken parameter is empty or not valid
 

articles/active-directory/develop/TOC.yml

@@ -146,8 +146,10 @@
       items:
         - name: Workload identity federation
           href: workload-identity-federation.md
-        - name: Trust an external identity provider (federation)
+        - name: Configure an app to trust an external identity provider
           href: workload-identity-federation-create-trust.md
+        - name: Configure a managed identity to trust an external identity provider
+          href: workload-identity-federation-create-trust-user-assigned-managed-identity.md
         - name: Access identity platform-protected resources from GCP
           href: workload-identity-federation-create-trust-gcp.md
         - name: Exchange AD FS SAML for Microsoft Graph access token
@@ -783,6 +785,8 @@
               href: active-directory-signing-key-rollover.md
             - name: UserInfo endpoint (OIDC)
               href: userinfo.md
+            - name: Federated identity credentials considerations and limitations
+              href: workload-identity-federation-considerations.md
         - name: SAML 2.0
           items:
             - name: How Azure AD uses the SAML protocol

articles/active-directory/develop/includes/federated-credential-configuration-considerations.md

@@ -0,0 +1,40 @@
+---
+title: Workload identity federation for app considerations
+description: Important considerations and restrictions for creating a federated identity credential on an app. 
+services: active-directory
+author: rwike77
+manager: CelesteDG
+
+ms.service: active-directory
+ms.subservice: develop
+ms.workload: identity
+ms.topic: include
+ms.date: 09/26/2022
+ms.author: ryanwi
+ms.reviewer: shkhalid, udayh, vakarand
+ms.custom: aaddev
+---
+
+A maximum of 20 federated identity credentials can be added to an application or user-assigned managed identity.
+
+When you configure a federated identity credential, there are several important pieces of information to provide:
+
+- *issuer* and *subject* are the key pieces of information needed to set up the trust relationship. The combination of `issuer` and `subject` must be unique on the app.  When the external software workload requests Microsoft identity platform to exchange the external token for an access token, the *issuer* and *subject* values of the federated identity credential are checked against the `issuer` and `subject` claims provided in the external token. If that validation check passes, Microsoft identity platform issues an access token to the external software workload.
+
+- *issuer* is the URL of the external identity provider and must match the `issuer` claim of the external token being exchanged. Required. If the `issuer` claim has leading or trailing whitespace in the value, the token exchange is blocked. This field has a character limit of 600 characters.
+    
+- *subject* is the identifier of the external software workload and must match the `sub` (`subject`) claim of the external token being exchanged. *subject* has no fixed format, as each IdP uses their own - sometimes a GUID, sometimes a colon delimited identifier, sometimes arbitrary strings. This field has a character limit of 600 characters.
+    
+    > [!IMPORTANT]
+    > The *subject* setting values must exactly match the configuration on the GitHub workflow configuration.  Otherwise, Microsoft identity platform will look at the incoming external token and reject the exchange for an access token.  You won't get an error, the exchange fails without error.
+    
+    > [!IMPORTANT]
+    > If you accidentally add the incorrect external workload information in the *subject* setting the federated identity credential is created successfully without error.  The error does not become apparent until the token exchange fails.
+
+- *audiences* lists the audiences that can appear in the external token.  Required. You must add a single audience value, which has a limit of 600 characters. The recommended value is "api://AzureADTokenExchange". It says what Microsoft identity platform must accept in the `aud` claim in the incoming token.  
+
+- *name* is the unique identifier for the federated identity credential. Required.  This field has a character limit of 3-120 characters and must be URL friendly. Alphanumeric, dash, or underscore characters are supported, the first character must be alphanumeric only.  It's immutable once created.
+
+- *description* is the user-provided description of the federated identity credential.  Optional. The description isn't validated or checked by Azure AD. This field has a limit of 600 characters.
+
+Wildcard characters aren't supported in any federated identity credential property value.