Merge branch 'main' into fix-devcenter-cli

Author: colbylwilliams

.openpublishing.redirection.json

@@ -1,5 +1,10 @@
 {
     "redirections": [
+    {
+      "source_path": "articles/databox-online/azure-stack-edge-zero-touch-provisioning.md",
+      "redirect_url": "/azure/databox-online/azure-stack-edge-powershell-based-configuration",
+      "redirect_document_id": false
+    },
     {
       "source_path": "articles/azure-video-analyzer/video-analyzer-docs/access-policies.md",
       "redirect_url": "/previous-versions/azure/azure-video-analyzer/video-analyzer-docs/access-policies",

articles/active-directory-domain-services/migrate-from-classic-vnet.md

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.subservice: domain-services
 ms.workload: identity
 ms.topic: how-to
-ms.date: 03/10/2023
+ms.date: 03/14/2023
 ms.author: justinha 
 ---
 
@@ -177,10 +177,11 @@ Before you begin the migration process, complete the following initial checks an
     | Source      | Source service tag                 | Source port ranges |  Destination  | Service | Destination port ranges | Protocol | Action | Required | Purpose |
     |:-----------:|:----------------------------------:|:------------------:|:-------------:|:-------:|:-----------------------:|:--------:|:------:|:--------:|:--------|
     | Service tag | AzureActiveDirectoryDomainServices | *                  | Any           | WinRM   | 5986        | TCP       | Allow  | Yes       | Management of your domain |
-    | Service tag | CorpNetSaw                         | *                  | Any           | WinRM   | 3389        | TCP       | Allow  | Optional  | Debugging for support |
-    | Service tag | AzureActiveDirectoryDomainServices | *                  | Any           | WinRM   | 636         | TCP       | Allow  | Optional  | Secure LDAP |
+    | Service tag | CorpNetSaw                         | *                  | Any           | RDP   | 3389        | TCP       | Allow  | Optional  | Debugging for support |
+    
+    Make a note of the target resource group, target virtual network, and target virtual network subnet. These resource names are used during the migration process.
 
-    Make a note of this target resource group, target virtual network, and target virtual network subnet. These resource names are used during the migration process.
+    Note that the **CorpNetSaw** service tag isn't available by using Azure portal, and the network security group rule for **CorpNetSaw** has to be added by using [PowerShell](powershell-create-instance.md#create-a-network-security-group).
 
 1. Check the managed domain health in the Azure portal. If you have any alerts for the managed domain, resolve them before you start the migration process.
 1. Optionally, if you plan to move other resources to the Resource Manager deployment model and virtual network, confirm that those resources can be migrated. For more information, see [Platform-supported migration of IaaS resources from Classic to Resource Manager][migrate-iaas].

articles/active-directory-domain-services/network-considerations.md

@@ -9,8 +9,9 @@ ms.service: active-directory
 ms.subservice: domain-services
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 01/29/2023
+ms.date: 03/14/2023
 ms.author: justinha
+ms.reviewer: xyuan
 
 ---
 # Virtual network design considerations and configuration options for Azure Active Directory Domain Services
@@ -110,10 +111,13 @@ The following sections cover network security groups and Inbound and Outbound po
 
 The following network security group Inbound rules are required for the managed domain to provide authentication and management services. Don't edit or delete these network security group rules for the virtual network subnet for your managed domain.
 
-| Inbound port number | Protocol | Source                             | Destination | Action | Required | Purpose |
-|:-----------:|:--------:|:----------------------------------:|:-----------:|:------:|:--------:|:--------|
-| 5986        | TCP      | AzureActiveDirectoryDomainServices | Any         | Allow  | Yes      | Management of your domain. |
-| 3389        | TCP      | CorpNetSaw                         | Any         | Allow  | Optional      | Debugging for support. |
+| Source      | Source service tag                 | Source port ranges |  Destination  | Service | Destination port ranges | Protocol | Action | Required | Purpose |
+|:-----------:|:----------------------------------:|:------------------:|:-------------:|:-------:|:-----------------------:|:--------:|:------:|:--------:|:--------|
+| Service tag | AzureActiveDirectoryDomainServices | *                  | Any           | WinRM   | 5986            | TCP | Allow | Yes | Management of your domain. |
+| Service tag | CorpNetSaw                         | *                  | Any           | RDP     | 3389            | TCP | Allow | Optional | Debugging for support |
+
+
+Note that the **CorpNetSaw** service tag isn't available by using Azure portal, and the network security group rule for **CorpNetSaw** has to be added by using [PowerShell](powershell-create-instance.md#create-a-network-security-group).
 
 Azure AD DS also relies on the Default Security rules AllowVnetInBound and AllowAzureLoadBalancerInBound.
 

articles/active-directory-domain-services/tutorial-configure-ldaps.md

@@ -8,8 +8,9 @@ ms.service: active-directory
 ms.subservice: domain-services
 ms.workload: identity
 ms.topic: tutorial
-ms.date: 01/29/2023
+ms.date: 03/14/2023
 ms.author: justinha
+ms.reviewer: xyuan
 
 #Customer intent: As an identity administrator, I want to secure access to an Azure Active Directory Domain Services managed domain using secure lightweight directory access protocol (LDAPS)
 ---
@@ -236,11 +237,13 @@ Let's create a rule to allow inbound secure LDAP access over TCP port 636 from a
 
     | Setting                           | Value        |
     |-----------------------------------|--------------|
-    | Source                            | IP Addresses |
-    | Source IP addresses / CIDR ranges | A valid IP address or range for your environment |
+    | Source                            | Service tag  |
+    | Source service tag                | AzureActiveDirectoryDomainServices  |
+    | Source IP addresses/CIDR ranges   | A valid IP address or range for your environment |
     | Source port ranges                | *            |
     | Destination                       | Any          |
     | Destination port ranges           | 636          |
+    | Service                           | WinRM        |
     | Protocol                          | TCP          |
     | Action                            | Allow        |
     | Priority                          | 401          |

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/10/2023
+ms.date: 03/14/2023
 ms.author: kenwith
 ms.reviewer: arvinh
 ---
@@ -18,7 +18,7 @@ As an application developer, you can use the System for Cross-Domain Identity Ma
 
 ![Provisioning from Azure AD to an app with SCIM](media/use-scim-to-provision-users-and-groups/scim-provisioning-overview.png)
 
-SCIM 2.0 is a standardized definition of two endpoints: a `/Users` endpoint and a `/Groups` endpoint. It uses common REST API endpoints to create, update, and delete objects. The SCIM consists of a pre-defined schema for common attributes like group name, username, first name, last name and email. 
+SCIM 2.0 is a standardized definition of two endpoints: a `/Users` endpoint and a `/Groups` endpoint. It uses common REST API endpoints to create, update, and delete objects. The SCIM consists of a predefined schema for common attributes like group name, username, first name, last name and email. 
 
 Apps that offer a SCIM 2.0 REST API can reduce or eliminate the pain of working with a proprietary user management API. For example, any compliant SCIM client knows how to make an HTTP POST of a JSON object to the `/Users` endpoint to create a new user entry. Instead of needing a slightly different API for the same basic actions, apps that conform to the SCIM standard can instantly take advantage of pre-existing clients, tools, and code. 
 
@@ -195,7 +195,7 @@ Use the general guidelines when implementing a SCIM endpoint to ensure compatibi
 * Don't require a case-sensitive match on structural elements in SCIM, in particular **PATCH** `op` operation values, as defined in [section 3.5.2](https://tools.ietf.org/html/rfc7644#section-3.5.2). Azure AD emits the values of `op` as **Add**, **Replace**, and **Remove**.
 * Microsoft Azure AD makes requests to fetch a random user and group to ensure that the endpoint and the credentials are valid. It's also done as a part of the **Test Connection** flow in the [Azure portal](https://portal.azure.com). 
 * Support HTTPS on your SCIM endpoint.
-* Custom complex and multivalued attributes are supported but Azure AD doesn't have many complex data structures to pull data from in these cases. Name/value attributes can be mapped to easily, but flowing data to complex attributes with three or more sub-attributes isn't supported.
+* Custom complex and multivalued attributes are supported but Azure AD doesn't have many complex data structures to pull data from in these cases. Name/value attributes can be mapped to easily, but flowing data to complex attributes with three or more subattributes isn't supported.
 * The "type" subattribute values of multivalued complex attributes must be unique. For example, there can't be two different email addresses with the "work" subtype.
 * The header for all the responses should be of content-Type: application/scim+json 
 
@@ -1374,7 +1374,7 @@ 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 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 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 needs 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]

articles/active-directory/authentication/concept-system-preferred-multifactor-authentication.md

@@ -50,7 +50,7 @@ System-preferred MFA can be enabled only for a single group, which can be a dyna
 Use the following API endpoint to enable **systemCredentialPreferences** and include or exclude groups:
 
 ```
-https://graph.microsoft.com/beta/authenticationMethodsPolicy
+https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy
 ```
 
 >[!NOTE]

articles/active-directory/cloud-sync/how-to-accidental-deletes.md

@@ -32,16 +32,17 @@ For more information and an example, see the following video.
 To use the new feature, follow the steps below.
 
 
-1.  In the Azure portal, select **Azure Active Directory**.
-2.  Select **Azure AD Connect**.
-3.  Select **Manage cloud sync**.
+ 1.  In the Azure portal, select **Azure Active Directory**.
+ 2.  On the left, select **Azure AD Connect**.
+ 3.  On the left, select **Cloud sync**.
 4. Under **Configuration**, select your configuration.
-5. Under **Settings** fill in the following information.
+5. Select **View default properties**.
+6. Click the pencil next to **Basics**
+5. On the right, fill in the following information.
 	- **Notification email** - email used for notifications
 	- **Prevent accidental deletions** - check this box to enable the feature
 	- **Accidental deletion threshold** - enter the number of objects to stop synchronization and send a notification
 
-![Accidental deletes](media/how-to-accidental-deletes/accident-1.png)
 
 ## Recovering from an accidental delete instance
 If you encounter an accidental delete you'll see this on the status of your provisioning agent configuration.  It will say **Delete threshold exceeded**.

articles/active-directory/conditional-access/concept-token-protection.md

@@ -17,9 +17,9 @@ ms.collection: M365-identity-device-management
 
 Token protection (sometimes referred to as token binding in the industry) attempts to reduce attacks using token theft by ensuring a token is usable only from the intended device. When an attacker is able to steal a token, by hijacking or replay, they can impersonate their victim until the token expires or is revoked. Token theft is thought to be a relatively rare event, but the damage from it can be significant. 
 
-Token protection creates a cryptographically secure tie between the token and the device (client secret) it's issued to. Without the client secret, the bound token is useless. When a user registers a Windows 10 or newer device in Azure AD, their primary identity is [bound to the device](../devices/concept-primary-refresh-token.md#how-is-the-prt-protected). This connection means that any issued sign-in token is tied to the device significantly reducing the chance of theft and replay attacks. These sign-in tokens are specifically the session cookies in Microsoft Edge and most Microsoft product refresh tokens in this preview release. 
+Token protection creates a cryptographically secure tie between the token and the device (client secret) it's issued to. Without the client secret, the bound token is useless. When a user registers a Windows 10 or newer device in Azure AD, their primary identity is [bound to the device](../devices/concept-primary-refresh-token.md#how-is-the-prt-protected). This connection means that any issued sign-in token is tied to the device significantly reducing the chance of theft and replay attacks.
 
-With this preview, we're giving you the ability to create a Conditional Access policy to require token protection for sign-in tokens for specific services. We support token protection for sign-in tokens in Conditional Access for Exchange Online and SharePoint Online on Windows devices.
+With this preview, we're giving you the ability to create a Conditional Access policy to require token protection for sign-in tokens for specific services. We support token protection for sign-in tokens in Conditional Access for desktop applications accessing Exchange Online and SharePoint Online on Windows devices.
 
 :::image type="content" source="media/concept-token-protection/complete-policy-components-session.png" alt-text="Screenshot showing a Conditional Access policy requiring token protection as the session control":::