Merge branch 'master' of https://github.com/MicrosoftDocs/azure-docs-pr into release-preview-arr

Author: v-alje

articles/active-directory/conditional-access/app-protection-based-conditional-access.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: conditional-access
 ms.topic: article
-ms.date: 03/04/2020
+ms.date: 04/02/2020
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -56,7 +56,7 @@ Organizations must complete the following steps in order to require the use of a
 1. Under **Access controls** > **Grant**, select the following options:
    - **Require approved client app**
    - **Require app protection policy (preview)**
-   - **Require one of the selected controls**
+   - **Require all the selected controls**
 1. Confirm your settings and set **Enable policy** to **On**.
 1. Select **Create** to create and enable your policy.
 

articles/active-directory/conditional-access/concept-conditional-access-users-groups.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: conditional-access
 ms.topic: conceptual
-ms.date: 02/11/2020
+ms.date: 04/02/2020
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -41,7 +41,7 @@ The following options are available to include when creating a Conditional Acces
 
 ## Exclude users
 
-Exclusions are commonly used for emergency access or break-glass accounts. More information about emergency access accounts and why they are important can be found in the following articles: 
+When organizations both include and exclude a user or group the user or group is excluded from the policy, as an exclude action overrides an include in policy. Exclusions are commonly used for emergency access or break-glass accounts. More information about emergency access accounts and why they are important can be found in the following articles: 
 
 * [Manage emergency access accounts in Azure AD](../users-groups-roles/directory-emergency-access.md)
 * [Create a resilient access control management strategy with Azure Active Directory](../authentication/concept-resilient-controls.md)
@@ -55,6 +55,16 @@ The following options are available to exclude when creating a Conditional Acces
 - Users and groups
    - Allows targeting of specific sets of users. For example, organizations can select a group that contains all members of the HR department when an HR app is selected as the cloud app. A group can be any type of group in Azure AD, including dynamic or assigned security and distribution groups.
 
+### Preventing administrator lockout
+
+To prevent an administrator from locking themselves out of their directory when creating a policy applied to **All users** and **All apps**, they will see the following warning.
+
+> Don't lock yourself out! We recommend applying a policy to a small set of users first to verify it behaves as expected. We also recommend excluding at least one administrator from this policy. This ensures that you still have access and can update a policy if a change is required. Please review the affected users and apps.
+
+By default the policy will provide an option to exclude the current user from the policy, but this default can be overridden by the administrator as shown in the following image. 
+
+![Warning, don't lock yourself out!](./media/concept-conditional-access-users-groups/conditional-access-users-and-groups-lockout-warning.png)
+
 ## Next steps
 
 - [Conditional Access: Cloud apps or actions](concept-conditional-access-cloud-apps.md)

articles/active-directory/conditional-access/howto-conditional-access-policy-admin-mfa.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: conditional-access
 ms.topic: conceptual
-ms.date: 03/25/2020
+ms.date: 04/02/2020
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -39,7 +39,7 @@ Conditional Access policies are powerful tools, we recommend excluding the follo
 
 * **Emergency access** or **break-glass** accounts to prevent tenant-wide account lockout. In the unlikely scenario all administrators are locked out of your tenant, your emergency-access administrative account can be used to log into the tenant take steps to recover access.
    * More information can be found in the article, [Manage emergency access accounts in Azure AD](../users-groups-roles/directory-emergency-access.md).
-* **Service accounts** and **service principals**, such as the Azure AD Connect Sync Account. Service accounts are non-interactive accounts that are not tied to any particular user. They are normally used by back-end services and allow programmatic access to applications. Service accounts should be excluded since MFA can't be completed programmatically.
+* **Service accounts** and **service principals**, such as the Azure AD Connect Sync Account. Service accounts are non-interactive accounts that are not tied to any particular user. They are normally used by back-end services allowing programmatic access to applications, but are also used to sign in to systems for administrative purposes. Service accounts like these should be excluded since MFA can't be completed programmatically.
    * If your organization has these accounts in use in scripts or code, consider replacing them with [managed identities](../managed-identities-azure-resources/overview.md). As a temporary workaround, you can exclude these specific accounts from the baseline policy.
 
 ## Create a Conditional Access policy

articles/active-directory/conditional-access/howto-conditional-access-policy-all-users-mfa.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: conditional-access
 ms.topic: conceptual
-ms.date: 03/25/2020
+ms.date: 04/02/2020
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -29,7 +29,7 @@ Conditional Access policies are powerful tools, we recommend excluding the follo
 
 * **Emergency access** or **break-glass** accounts to prevent tenant-wide account lockout. In the unlikely scenario all administrators are locked out of your tenant, your emergency-access administrative account can be used to log into the tenant take steps to recover access.
    * More information can be found in the article, [Manage emergency access accounts in Azure AD](../users-groups-roles/directory-emergency-access.md).
-* **Service accounts** and **service principles**, such as the Azure AD Connect Sync Account. Service accounts are non-interactive accounts that are not tied to any particular user. They are normally used by back-end services and allow programmatic access to applications. Service accounts should be excluded since MFA can't be completed programmatically.
+* **Service accounts** and **service principals**, such as the Azure AD Connect Sync Account. Service accounts are non-interactive accounts that are not tied to any particular user. They are normally used by back-end services allowing programmatic access to applications, but are also used to sign in to systems for administrative purposes. Service accounts like these should be excluded since MFA can't be completed programmatically.
    * If your organization has these accounts in use in scripts or code, consider replacing them with [managed identities](../managed-identities-azure-resources/overview.md). As a temporary workaround, you can exclude these specific accounts from the baseline policy.
 
 ## Application exclusions

articles/active-directory/conditional-access/howto-conditional-access-policy-azure-management.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: conditional-access
 ms.topic: conceptual
-ms.date: 03/25/2020
+ms.date: 04/02/2020
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -31,7 +31,7 @@ Conditional Access policies are powerful tools, we recommend excluding the follo
 
 * **Emergency access** or **break-glass** accounts to prevent tenant-wide account lockout. In the unlikely scenario all administrators are locked out of your tenant, your emergency-access administrative account can be used to log into the tenant take steps to recover access.
    * More information can be found in the article, [Manage emergency access accounts in Azure AD](../users-groups-roles/directory-emergency-access.md).
-* **Service accounts** and **service principles**, such as the Azure AD Connect Sync Account. Service accounts are non-interactive accounts that are not tied to any particular user. They are normally used by back-end services and allow programmatic access to applications. Service accounts should be excluded since MFA can't be completed programmatically.
+* **Service accounts** and **service principals**, such as the Azure AD Connect Sync Account. Service accounts are non-interactive accounts that are not tied to any particular user. They are normally used by back-end services allowing programmatic access to applications, but are also used to sign in to systems for administrative purposes. Service accounts like these should be excluded since MFA can't be completed programmatically.
    * If your organization has these accounts in use in scripts or code, consider replacing them with [managed identities](../managed-identities-azure-resources/overview.md). As a temporary workaround, you can exclude these specific accounts from the baseline policy.
 
 ## Create a Conditional Access policy

articles/active-directory/conditional-access/howto-conditional-access-policy-block-access.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: conditional-access
 ms.topic: conceptual
-ms.date: 03/25/2020
+ms.date: 04/02/2020
 
 ms.author: joflore
 author: MicrosoftGuyJFlo
@@ -30,7 +30,7 @@ Conditional Access policies are powerful tools, we recommend excluding the follo
 
 * **Emergency access** or **break-glass** accounts to prevent tenant-wide account lockout. In the unlikely scenario all administrators are locked out of your tenant, your emergency-access administrative account can be used to log into the tenant take steps to recover access.
    * More information can be found in the article, [Manage emergency access accounts in Azure AD](../users-groups-roles/directory-emergency-access.md).
-* **Service accounts** and **service principals**, such as the Azure AD Connect Sync Account. Service accounts are non-interactive accounts that are not tied to any particular user. They are normally used by back-end services and allow programmatic access to applications. Service accounts should be excluded since MFA can't be completed programmatically.
+* **Service accounts** and **service principals**, such as the Azure AD Connect Sync Account. Service accounts are non-interactive accounts that are not tied to any particular user. They are normally used by back-end services allowing programmatic access to applications, but are also used to sign in to systems for administrative purposes. Service accounts like these should be excluded since MFA can't be completed programmatically.
    * If your organization has these accounts in use in scripts or code, consider replacing them with [managed identities](../managed-identities-azure-resources/overview.md). As a temporary workaround, you can exclude these specific accounts from the baseline policy.
 
 ## Create a Conditional Access policy

articles/active-directory/conditional-access/media/concept-conditional-access-users-groups/conditional-access-users-and-groups-lockout-warning.png

@@ -151,6 +151,8 @@
             href: plan-migrate-adfs-password-hash-sync.md
           - name: Migrate from federation to PTA
             href: plan-migrate-adfs-pass-through-authentication.md
+          - name: Move groups from one forest to another
+            href: how-to-connect-migrate-groups.md
     - name: Hybrid Identity Design Considerations
       items:
           - name: Hybrid Identity Design Considerations Overview

articles/active-directory/hybrid/TOC.yml

@@ -0,0 +1,122 @@
+---
+title: 'Azure AD Connect: Migrate groups from one forest to another | Microsoft Docs'
+description: This article describes the steps needed to successfully migrate groups from one forest to another for Azure AD Connect.
+services: active-directory
+author: billmath
+manager: daveba
+ms.service: active-directory
+ms.topic: reference
+ms.workload: identity
+ms.date: 04/02/2020
+ms.subservice: hybrid
+ms.author: billmath
+
+ms.collection: M365-identity-device-management
+---
+
+# Migrate groups from one forest to another for Azure AD Connect
+
+This article describes the steps needed to successfully migrate groups from one forest to another so that the migrated group objects match to the existing objects in the cloud.
+
+## Prerequisites
+
+- Azure AD Connect version 1.5.18.0 or higher
+- Source Anchor attribute is `mS-DS-ConsistencyGuid`
+
+Starting from version 1.5.18.0, Azure AD Connect has started supporting the use of `mS-DS-ConsistencyGuid` for groups. If `mS-DS-ConsistencyGuid` is chosen as the source anchor attribute and the value is populated in AD, Azure AD Connect uses the value of `mS-DS-ConsistencyGuid` as the immutableId. Otherwise, it falls back to using `objectGUID`. However, please note that Azure AD Connect **DOES NOT** write back the value to the `mS-DS-ConsistencyGuid` attribute in AD.
+
+During a cross-forest move scenario where a group object is moving from one forest (say F1) to another forest (say F2), we will need to copy over either the `mS-DS-ConsistencyGuid` value (If PRESENT) or `objectGUID` value from the object in forest F1 to the `mS-DS-ConsistencyGuid` attribute of the object in F2. 
+
+Please use the following scripts as guideline to see how you can migrate a single group from forest F1 to forest F2. Please feel free to use this as a guideline to do the migration for multiple groups.
+
+First, we get the `objectGUID` and `mS-DS-ConsistencyGuid` of group object in forest F1. These attributes are exported to a CSV file.
+```
+<#
+DESCRIPTION
+============
+This script will take DN of a group as input.
+It then copies the objectGUID and mS-DS-ConsistencyGuid values along with other attributes of the given group to a CSV file.
+
+This CSV file can then be used as input to Export-Group script
+#>
+Param(
+       [ValidateNotNullOrEmpty()]
+       [string]
+       $dn,
+
+       [ValidateNotNullOrEmpty()]
+       [string]
+       $outputCsv
+)
+
+$defaultProperties = @('samAccountName', 'distinguishedName', 'objectGUID', 'mS-DS-ConsistencyGuid')
+$group  = Get-ADGroup -Filter "DistinguishedName -eq '$dn'" -Properties $defaultProperties -ErrorAction Stop
+$results = @()
+if ($group -eq $null)
+{
+       Write-Error "Group not found"
+}
+else
+{
+       $objectGUIDValue = [GUID]$group.'objectGUID'
+       $mSDSConsistencyGuidValue = "N/A"
+       if ($group.'mS-DS-ConsistencyGuid' -ne $null)
+       {
+              $mSDSConsistencyGuidValue = [GUID]$group.'mS-DS-ConsistencyGuid'
+       }
+       $adgroup = New-Object -TypeName PSObject
+       $adgroup | Add-Member -MemberType NoteProperty -Name samAccountName -Value $($group.'samAccountName')
+       $adgroup | Add-Member -MemberType NoteProperty -Name distinguishedName -Value $($group.'distinguishedName')
+       $adgroup | Add-Member -MemberType NoteProperty -Name objectGUID -Value $($objectGUIDValue)
+       $adgroup | Add-Member -MemberType NoteProperty -Name mS-DS-ConsistencyGuid -Value $($mSDSConsistencyGuidValue)
+       $results += $adgroup
+}
+
+Write-Host "Exporting group to output file"
+$results | Export-Csv "$outputCsv" -NoTypeInformation
+
+```
+
+Next, we use the generated output CSV file to stamp the `mS-DS-ConsistencyGuid` attribute on the target object in forest F2.
+
+
+```
+<#
+DESCRIPTION
+============
+This script will take DN of a group as input and the CSV file that was generated by Import-Group script
+It copies either the objectGUID or mS-DS-ConsistencyGuid value from CSV file to the given object.
+
+#>
+Param(
+       [ValidateNotNullOrEmpty()]
+       [string]
+       $dn,
+
+       [ValidateNotNullOrEmpty()]
+       [string]
+       $inputCsv
+)
+
+$group  = Get-ADGroup -Filter "DistinguishedName -eq '$dn'" -ErrorAction Stop
+if ($group -eq $null)
+{
+       Write-Error "Group not found"
+}
+
+$csvFile = Import-Csv -Path $inputCsv -ErrorAction Stop
+$msDSConsistencyGuid = [GUID] $csvFile.'mS-DS-ConsistencyGuid'
+$objectGuid = [GUID] $csvFile.'objectGUID'
+$targetGuid = $msDSConsistencyGuid
+
+if ($msDSConsistencyGuid -eq "N/A")
+{
+       $targetGuid = $objectGuid
+}
+
+Set-ADGroup -Identity $dn -Replace @{'mS-DS-ConsistencyGuid'=$targetGuid} -ErrorAction Stop
+
+```
+
+## Next steps
+Learn more about [Integrating your on-premises identities with Azure Active Directory](whatis-hybrid-identity.md).