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

Author: maud-lv

.openpublishing.redirection.azure-monitor.json

@@ -30,6 +30,16 @@
             "redirect_url": "/azure/azure-monitor/change/change-analysis",
             "redirect_document_id": false
         },
+        {
+            "source_path_from_root": "/articles/azure-monitor/app/visual-studio.md",
+            "redirect_url": "https://learn.microsoft.com/visualstudio/azure/azure-app-insights-add-connected-service",
+            "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/azure-monitor/app/visual-studio-codelens.md",
+            "redirect_url": "https://learn.microsoft.com/visualstudio/azure/azure-app-insights-add-connected-service",
+            "redirect_document_id": false
+        },
         {
             "source_path_from_root": "/articles/azure-monitor/app/javascript-react-plugin.md",
             "redirect_url": "/azure/azure-monitor/app/javascript-framework-extensions",
@@ -201,6 +211,11 @@
             "redirect_url": "/troubleshoot/azure/azure-monitor/app-insights/troubleshoot-portal-connectivity",
             "redirect_document_id": false
         },
+        {
+            "source_path_from_root": "/articles/azure-monitor/app/javascript-sdk-load-failure.md",
+            "redirect_url": "https://learn.microsoft.com/troubleshoot/azure/azure-monitor/app-insights/javascript-sdk-troubleshooting",
+            "redirect_document_id": false
+        },
         {
             "source_path_from_root": "/articles/azure-monitor/app/java-2x-troubleshoot.md",
             "redirect_url": "/troubleshoot/azure/azure-monitor/app-insights/java-2x-troubleshoot",

.openpublishing.redirection.json

@@ -146,7 +146,7 @@ Content-type: application/json
  "displayName": "John Smith",
  "objectId": "11111111-0000-0000-0000-000000000000",
  "givenName":"John",
- "lastName":"Smith",
+ "surname":"Smith",
  "step": "PostFederationSignup",
  "client_id":"<guid>",
  "ui_locales":"en-US"

articles/active-directory-b2c/add-api-connector.md

@@ -59,7 +59,7 @@ In the legacy experience, apps were always created as customer-facing applicatio
 > [!NOTE]
 > This option is required to be able to run Azure AD B2C user flows to authenticate users for this application. Learn [how to register an application for use with user flows.](tutorial-register-applications.md)
 
-You can also use this option  to use Azure AD B2C as a SAML service provider. [Learn more](identity-provider-adfs.md).
+You can also use this option  to use Azure AD B2C as a SAML service provider. [Learn more](saml-service-provider.md).
 
 ## Applications for DevOps scenarios
 

articles/active-directory-b2c/app-registrations-training-guide.md

@@ -75,16 +75,16 @@ A job can go into quarantine regardless of failure counts for issues such as adm
 
 The logic documented here may be different for certain connectors to ensure best customer experience, but we generally have the below retry cycles after a failure:
 
-After the first failure, the first retry happens within the next 2 hours (usually in the next sync cycle).
-- The second retry happens 6 hours after the first failure.
-- The third retry happens 12 hours after the first failure.
-- The fourth retry happens 24 hours after the first failure.
-- The fifth retry happens 48 hours after the first failure.
-- The sixth retry happens 72 hours after the first failure.
-- The seventh retry happens 96 hours after the first failure.
-- The eighth retry happens 120 hours after the first failure.
-
-This cycle is repeated every 24 hours until the 30th day when retries are stopped and the job is disabled. 
+After the failure, the first retry will happen in 6 hours.
+- The second retry happens 12 hours after the first failure.
+- The third retry happens 24 hours after the first failure.
+- The fourth retry happens 48 hours after the first failure.
+- The fifth retry happens 96 hours after the first failure.
+- The sixth retry happens 192 hours after the first failure.
+- The seventh retry happens 384 hours after the first failure.
+- The eighth retry happens 768 hours after the first failure.
+
+The retries are stopped after the 8th retry and the escrow entry is removed. The job will continue unless it hits the escrow thresholds from the section above 
 
 
 ## How do I get my application out of quarantine?

articles/active-directory/app-provisioning/application-provisioning-quarantine-status.md

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.subservice: app-provisioning
 ms.workload: identity
 ms.topic: tutorial
-ms.date: 11/04/2022
+ms.date: 02/23/2023
 ms.author: kenwith
 ms.reviewer: arvinh
 ---
@@ -74,7 +74,7 @@ The following table lists an example of required attributes:
 |lastName|name.familyName|surName|
 |workMail|emails[type eq “work”].value|Mail|
 |manager|manager|manager|
-|tag|urn:ietf:params:scim:schemas:extension:CustomExtensionName:2.0:User:tag|extensionAttribute1|
+|tag|`urn:ietf:params:scim:schemas:extension:CustomExtensionName:2.0:User:tag`|extensionAttribute1|
 |status|active|isSoftDeleted (computed value not stored on user)|
 
 The following JSON payload shows an example SCIM schema:
@@ -117,7 +117,7 @@ It helps to categorize between `/User` and `/Group` to map any default user attr
 
 The following table lists an example of user attributes:
 
-| Azure AD user | urn:ietf:params:scim:schemas:extension:enterprise:2.0:User |
+| Azure AD user | `urn:ietf:params:scim:schemas:extension:enterprise:2.0:User` |
 | --- | --- |
 | IsSoftDeleted |active |
 |department| `urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:department`|
@@ -140,7 +140,7 @@ The following table lists an example of user attributes:
 
 The following table lists an example of group attributes:
 
-| Azure AD group | urn:ietf:params:scim:schemas:core:2.0:Group |
+| Azure AD group | `urn:ietf:params:scim:schemas:core:2.0:Group` |
 | --- | --- |
 | displayName |displayName |
 | members |members |
@@ -218,7 +218,7 @@ Use the general guidelines when implementing a SCIM endpoint to ensure compatibi
 ### /Schemas (Schema discovery):
 
 * [Sample request/response](#schema-discovery)
-* Schema discovery isn't currently supported on the custom non-gallery SCIM application, but it's being used on certain gallery applications. Going forward, schema discovery will be used as the sole method to add more attributes to the schema of an existing gallery SCIM application. 
+* Schema discovery is being used on certain gallery applications. Schema discovery is the sole method to add more attributes to the schema of an existing gallery SCIM application. Schema discovery isn't currently supported on custom non-gallery SCIM application.
 * If a value isn't present, don't send null values.
 * Property values should be camel cased (for example, readWrite).
 * Must return a list response.
@@ -1373,8 +1373,8 @@ The SCIM spec doesn't define a SCIM-specific scheme for authentication and autho
 |--|--|--|--|
 |Username and password (not recommended or supported by Azure AD)|Easy to implement|Insecure - [Your Pa$$word doesn't matter](https://techcommunity.microsoft.com/t5/azure-active-directory-identity/your-pa-word-doesn-t-matter/ba-p/731984)|Not supported for new gallery or non-gallery apps.|
 |Long-lived bearer token|Long-lived tokens don't require a user to be present. They're easy for admins to use when setting up provisioning.|Long-lived tokens can be hard to share with an admin without using insecure methods such as email. |Supported for gallery and non-gallery apps. |
-|OAuth authorization code grant|Access tokens are much shorter-lived than passwords, and have an automated refresh mechanism that long-lived bearer tokens don't have.  A real user must be present during initial authorization, adding a level of accountability. |Requires a user to be present. If the user leaves the organization, the token is invalid, and authorization will need to be completed again.|Supported for gallery apps, but not non-gallery apps. However, you can provide an access token in the UI as the secret token for short term testing purposes. Support for OAuth code grant on non-gallery is in our backlog, in addition to support for configurable auth / token URLs on the gallery app.|
-|OAuth client credentials grant|Access tokens are much shorter-lived than passwords, and have an automated refresh mechanism that long-lived bearer tokens don't have. Both the authorization code grant and the client credentials grant create the same type of access token, so moving between these methods is transparent to the API.  Provisioning can be automated, and new tokens can be silently requested without user interaction. ||Supported for gallery apps, but not non-gallery apps. However, you can provide an access token in the UI as the secret token for short term testing purposes. Support for OAuth client credentials grant on non-gallery is in our backlog.|
+|OAuth authorization code grant|Access tokens have a shorter life than passwords, and have an automated refresh mechanism that long-lived bearer tokens don't have.  A real user must be present during initial authorization, adding a level of accountability. |Requires a user to be present. If the user leaves the organization, the token is invalid, and authorization will need to be completed again.|Supported for gallery apps, but not non-gallery apps. However, you can provide an access token in the UI as the secret token for short term testing purposes. Support for OAuth code grant on non-gallery is in our backlog, in addition to support for configurable auth / token URLs on the gallery app.|
+|OAuth client credentials grant|Access tokens have a shorter life than passwords, and have an automated refresh mechanism that long-lived bearer tokens don't have. Both the authorization code grant and the client credentials grant create the same type of access token, so moving between these methods is transparent to the API.  Provisioning can be automated, and new tokens can be silently requested without user interaction. ||Supported for gallery apps, but not non-gallery apps. However, you can provide an access token in the UI as the secret token for short term testing purposes. Support for OAuth client credentials grant on non-gallery is in our backlog.|
 
 > [!NOTE]
 > It's not recommended to leave the token field blank in the Azure AD provisioning configuration custom app UI. The token generated is primarily available for testing purposes.

articles/active-directory/app-provisioning/use-scim-to-provision-users-and-groups.md

@@ -7,9 +7,9 @@ metadata:
   ms.service: active-directory
   ms.subservice: authentication
   ms.topic: faq
-  ms.date: 10/05/2022
+  ms.date: 02/21/2023
   ms.author: justinha
-  author: vimrang
+  author: justinha
   manager: amycolannino
   ms.reviewer: vimrang
   ms.collection: M365-identity-device-management
@@ -69,7 +69,7 @@ sections:
           
           Use the [Set-AzureADTrustedCertificateAuthority](/powershell/module/azuread/set-azureadtrustedcertificateauthority) cmdlet:
           
-          ```powershell
+          ```PowerShell
           $c=Get-AzureADTrustedCertificateAuthority
           $c[0]. crlDistributionPoint=""
           Set-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $c[0]
@@ -120,14 +120,14 @@ sections:
           The browser caches the certificate after the certificate picker appears. If the user retries, the cached certificate is used automatically. The user should close the browser, and reopen a new session to try CBA again.          
 
       - question: |
-          Why does not proof up for registering other auth methods come up when I use single factor certificates?
+          Why doesn't proof up for registering other auth methods come up when I use single factor certificates?
         answer: |
-          A user will be considered MFA capable when a user is in scope for Certificate-based authentication auth method. This means user will not be able to use proof up as part of their authentication to registerd other available methods and should have MFA via another method to register other available auth methods.
+          A user is considered capable for MFA when the user is in scope for **Certificate-based authentication** in the Authentication methods policy. This policy requirement means a user can't use proof up as part of their authentication to register other available methods.
           
       - question: |
           How can I use single-factor certificates to complete MFA?
         answer: |
-          We have support for single factor CBA to get MFA. CBA SF + PSI (passwordless phone sign in) and CBA SF + FIDO2 are the two supported combinations to get MFA using single factor certificates.
+          We have support for single factor CBA to get MFA. CBA SF + passwordless phone sign-in (PSI) and CBA SF + FIDO2 are the two supported combinations to get MFA using single factor certificates.
           [MFA with single factor certificates](../authentication/concept-certificate-based-authentication-technical-deep-dive.md#mfa-authentication-flow-using-single-factor-certificates-and-passwordless-sign-in) 
           
       - question: |
@@ -146,7 +146,16 @@ sections:
            GET  https://graph.microsoft.com/v1.0/users?$filter=certificateUserIds/any(x:x eq '[email protected]')
            ```
 
-       
+      - question: |
+           After a CRL endpoint is configured, end users aren't able to sign in and they see the following diagnostic message:
+           
+           ```http
+           AADSTS500173: Unable to download CRL. Invalid status code Forbidden from CRL distribution point
+           errorCode: 500173
+           ```
+           
+        answer: |
+          This is commonly seen when a firewall rule setting blocks access to the CRL endpoint. 
           
 additionalContent: |
   ## Next steps

articles/active-directory/authentication/certificate-based-authentication-faq.yml

@@ -31,7 +31,7 @@ Microsoft verified partners can help you onboard Microsoft Entra Permissions Man
 * **Onboarding and Deployment Support**
 
     Partners can guide you through the entire onboarding and deployment process for 
-    ermissions Management across AWS, Azure, and GCP.
+    Permissions Management across AWS, Azure, and GCP.
 
 
 ## Partner list

articles/active-directory/cloud-infrastructure-entitlement-management/partner-list.md

@@ -37,9 +37,6 @@ There are multiple scenarios that organizations can now enable using filter for
 
 Filter for devices is an option when creating a Conditional Access policy in the Azure portal or using the Microsoft Graph API.
 
-> [!IMPORTANT]
-> Device state and filter for devices cannot be used together in Conditional Access policy.
-
 The following steps will help create two Conditional Access policies to support the first scenario under [Common scenarios](#common-scenarios). 
 
 Policy 1: All users with the directory role of Global Administrator, accessing the Microsoft Azure Management cloud app, and for Access controls, Grant access, but require multifactor authentication and require device to be marked as compliant.

articles/active-directory/conditional-access/concept-condition-filters-for-devices.md

@@ -94,7 +94,6 @@ To apply this grant control, the device must be registered in Azure AD, which re
 The following client apps support this setting, this list isn't exhaustive and is subject to change::
 
 - Microsoft Azure Information Protection
-- Microsoft Bookings
 - Microsoft Cortana
 - Microsoft Dynamics 365
 - Microsoft Edge
@@ -114,7 +113,6 @@ The following client apps support this setting, this list isn't exhaustive and i
 - Microsoft PowerPoint
 - Microsoft SharePoint
 - Microsoft Skype for Business
-- Microsoft StaffHub
 - Microsoft Stream
 - Microsoft Teams
 - Microsoft To-Do
@@ -194,7 +192,7 @@ When user risk is detected, administrators can employ the user risk policy condi
 When a user is prompted to change a password, they'll first be required to complete multifactor authentication. Make sure all users have registered for multifactor authentication, so they're prepared in case risk is detected for their account.  
 
 > [!WARNING]
-> Users must have previously registered for self-service password reset before triggering the user risk policy.
+> Users must have previously registered for multifactor authentication before triggering the user risk policy.
 
 The following restrictions apply when you configure a policy by using the password change control: