Merge branch 'main' into release-ga-virtual-network-manager

Author: v-alje

.openpublishing.redirection.active-directory.json

@@ -95,6 +95,11 @@
       "redirect_url": "/graph/tutorial-lifecycle-workflows-onboard-custom-workflow",
       "redirect_document_id": false
     },
+    {
+      "source_path_from_root": "/articles/active-directory/governance/manage-lifecycle-workflows.md",
+      "redirect_url": "/azure/active-directory/governance/understanding-lifecycle-workflows",
+      "redirect_document_id": false
+    },
     {
       "source_path_from_root": "/articles/active-directory/governance/lifecycle-workflows-developer-reference.md",
       "redirect_url": "/graph/api/resources/identitygovernance-workflow",

.openpublishing.redirection.json

@@ -22440,6 +22440,11 @@
             "source_path": "articles/private-multi-access-edge-compute-mec/metaswitch-fusion-core-overview.md",
             "redirect_URL": "/azure/private-5g-core",
             "redirect_document_id": false
+        },
+        {
+            "source_path": "articles/communications-gateway/rotate-secrets.md",
+            "redirect_URL": "/azure/communications-gateway/whats-new",
+            "redirect_document_id": false
         }
     ]
 }

articles/active-directory/app-provisioning/on-premises-scim-provisioning.md

@@ -64,3 +64,4 @@ The following video provides an overview of on-premises provisoning.
 - [App provisioning](user-provisioning.md)
 - [Generic SQL connector](on-premises-sql-connector-configure.md)
 - [Tutorial: ECMA Connector Host generic SQL connector](tutorial-ecma-sql-connector.md)
+- [Known issues](known-issues.md)

articles/active-directory/app-provisioning/scim-validator-tutorial.md

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.subservice: app-provisioning
 ms.workload: identity
 ms.topic: tutorial
-ms.date: 09/13/2022
+ms.date: 03/17/2023
 ms.custom: template-tutorial
 ms.reviewer: arvinh
 ---
@@ -41,7 +41,7 @@ The first step is to select a testing method to validate your SCIM endpoint.
 
 **Use default attributes** - The system provides the default attributes, and you modify them to meet your need.
 
-**Discover schema** - If your end point supports /Schema, this option will allow the tool to discover the supported attributes. We recommend this option as it reduces the overhead of updating your app as you build it out.
+**Discover schema** - If your end point supports /Schema, this option lets the tool discover the supported attributes. We recommend this option as it reduces the overhead of updating your app as you build it out.
 
 **Upload Azure AD Schema** - Upload the schema you've downloaded from your sample app on Azure AD.
 
@@ -75,7 +75,7 @@ Finally, you need to test and validate your endpoint.
 
 ### Use Postman to test endpoints (optional)
 
-In addition to using the SCIM Validator tool, you can also use Postman to validate an endpoint. This example provides a set of tests in Postman that validate CRUD (create, read, update, and delete) operations on users and groups, filtering, updates to group membership, and disabling users.
+In addition to using the SCIM Validator tool, you can also use Postman to validate an endpoint. This example provides a set of tests in Postman. The example validates create, read, update, and delete (CRUD) operations. The operations are validated on users and groups, filtering, updates to group membership, and disabling users.
 
 The endpoints are in the `{host}/scim/` directory, and you can use standard HTTP requests to interact with them. To modify the `/scim/` route, see *ControllerConstant.cs* in **AzureADProvisioningSCIMreference** > **ScimReferenceApi** > **Controllers**.
 
@@ -120,10 +120,10 @@ If you created any Azure resources in your testing that are no longer needed, do
 ## Known Issues with Azure AD SCIM Validator
 
 - Soft deletes (disables) aren’t yet supported.
-- The time zone format is randomly generated and will fail for systems that try to validate it.
-- The preferred language format is randomly generated and will fail for systems that try to validate it.
+- The time zone format is randomly generated and fails for systems that try to validate it.
+- The preferred language format is randomly generated and fails for systems that try to validate it.
 - The patch user remove attributes may attempt to remove mandatory/required attributes for certain systems. Such failures should be ignored.
 
 
 ## Next steps
-- [Learn how to add an app that is not in the Azure AD app gallery](../manage-apps/overview-application-gallery.md)
+- [Learn how to add an app that's not in the Azure AD app gallery](../manage-apps/overview-application-gallery.md)

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

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.subservice: app-provisioning
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 03/16/2023
+ms.date: 03/17/2023
 ms.author: kenwith
 ms.reviewer: arvinh
 ---
@@ -102,7 +102,7 @@ That's it! Your SCIM endpoint is now published, and you can use the Azure App Se
 
 ## Test your SCIM endpoint
 
-Requests to a SCIM endpoint require authorization. The SCIM standard has multiple options for authentication and authorization, including cookies, basic authentication, TLS client authentication, or any of the methods listed in [RFC 7644](https://tools.ietf.org/html/rfc7644#section-2).
+Requests to a SCIM endpoint require authorization. The SCIM standard has multiple options available.  Requests can use cookies, basic authentication, TLS client authentication, or any of the methods listed in [RFC 7644](https://tools.ietf.org/html/rfc7644#section-2).
 
 Be sure to avoid methods that aren't secure, such as username and password, in favor of a more secure method such as OAuth. Azure AD supports long-lived bearer tokens (for gallery and non-gallery applications) and the OAuth authorization grant (for gallery applications).
 

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

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.subservice: app-provisioning
 ms.workload: identity
 ms.topic: tutorial
-ms.date: 03/16/2023
+ms.date: 03/17/2023
 ms.author: kenwith
 ms.reviewer: arvinh
 ---

articles/active-directory/develop/TOC.yml

@@ -137,6 +137,8 @@
               href: active-directory-jwt-claims-customization.md
             - name: Customize SAML claims
               href: active-directory-saml-claims-customization.md
+            - name: Set an access token lifetime policy
+              href: registration-config-change-token-lifetime-how-to.md
             - name: Directory extension attributes
               href: active-directory-schema-extensions.md
             - name: SAML app multi-instancing

articles/active-directory/develop/active-directory-configurable-token-lifetimes.md

@@ -58,10 +58,10 @@ ID tokens are passed to websites and native clients. ID tokens contain profile i
 
 ## Token lifetime policies for refresh tokens and session tokens
 
-You can not set token lifetime policies for refresh tokens and session tokens. For lifetime, timeout, and revocation information on refresh tokens, see [Refresh tokens](refresh-tokens.md).
+You cannot set token lifetime policies for refresh tokens and session tokens. For lifetime, timeout, and revocation information on refresh tokens, see [Refresh tokens](refresh-tokens.md).
 
 > [!IMPORTANT]
-> As of January 30, 2021 you can not configure refresh and session token lifetimes. Azure Active Directory no longer honors refresh and session token configuration in existing policies.  New tokens issued after existing tokens have expired are now set to the [default configuration](#configurable-token-lifetime-properties). You can still configure access, SAML, and ID token lifetimes after the refresh and session token configuration retirement.
+> As of January 30, 2021 you cannot configure refresh and session token lifetimes. Azure Active Directory no longer honors refresh and session token configuration in existing policies.  New tokens issued after existing tokens have expired are now set to the [default configuration](#configurable-token-lifetime-properties). You can still configure access, SAML, and ID token lifetimes after the refresh and session token configuration retirement.
 >
 > Existing token's lifetime will not be changed. After they expire, a new token will be issued based on the default value.
 >
@@ -74,7 +74,7 @@ A token lifetime policy is a type of policy object that contains token lifetime
 
 Reducing the Access Token Lifetime property mitigates the risk of an access token or ID token being used by a malicious actor for an extended period of time. (These tokens cannot be revoked.) The trade-off is that performance is adversely affected, because the tokens have to be replaced more often.
 
-For an example, see [Create a policy for web sign-in](configure-token-lifetimes.md#create-a-policy-for-web-sign-in).
+For an example, see [Create a policy for web sign-in](registration-config-change-token-lifetime-how-to.md).
 
 Access, ID, and SAML2 token configuration are affected by the following properties and their respectively set values:
 
@@ -99,7 +99,7 @@ Refresh and session token configuration are affected by the following properties
 |Single-Factor Session Token Max Age  |MaxAgeSessionSingleFactor |Session tokens (persistent and nonpersistent)  |Until-revoked |
 |Multi-Factor Session Token Max Age  |MaxAgeSessionMultiFactor  |Session tokens (persistent and nonpersistent)  |Until-revoked |
 
-Non-persistent session tokens have a Max Inactive Time of 24 hours whereas persistent session tokens have a Max Inactive Time of 90 days. Anytime the SSO session token is used within its validity period, the validity period is extended another 24 hours or 90 days. If the SSO session token isn't used within its Max Inactive Time period, it's considered expired and will no longer be accepted. Any changes to this default periods should be change using [Conditional Access](../conditional-access/howto-conditional-access-session-lifetime.md).
+Non-persistent session tokens have a Max Inactive Time of 24 hours whereas persistent session tokens have a Max Inactive Time of 90 days. Anytime the SSO session token is used within its validity period, the validity period is extended another 24 hours or 90 days. If the SSO session token isn't used within its Max Inactive Time period, it's considered expired and will no longer be accepted. Any changes to this default period should be changed using [Conditional Access](../conditional-access/howto-conditional-access-session-lifetime.md).
 
 You can use PowerShell to find the policies that will be affected by the retirement.  Use the [PowerShell cmdlets](configure-token-lifetimes.md#get-started) to see the all policies created in your organization, or to find which apps and service principals are linked to a specific policy.