Merge branch 'main' into release-db-ship

Author: v-alje

articles/active-directory/authentication/howto-sspr-authenticationdata.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: how-to
-ms.date: 10/05/2020
+ms.date: 07/12/2022
 
 ms.author: justinha
 author: justinha
@@ -18,7 +18,7 @@ ms.custom: devx-track-azurepowershell
 ---
 # Pre-populate user authentication contact information for Azure Active Directory self-service password reset (SSPR)
 
-To use Azure Active Directory (Azure AD) self-service password reset (SSPR), authentication contact information for a user must be present. Some organizations have users register their authentication data themselves. Other organizations prefer to synchronize from authentication data that already exists in Active Directory Domain Services (AD DS). This synchronized data is made available to Azure AD and SSPR without requiring user interaction. When users need to change or reset their password, they can do so even if they haven't previously registered their contact information.
+To use Azure Active Directory (Azure AD) self-service password reset (SSPR), authentication information for a user must be present. Most organizations have users register their authentication data themselves while collecting information for MFA. Some organizations prefer to bootstrap this process through synchronization of authentication data that already exists in Active Directory Domain Services (AD DS). This synchronized data is made available to Azure AD and SSPR without requiring user interaction. When users need to change or reset their password, they can do so even if they haven't previously registered their contact information.
 
 You can pre-populate authentication contact information if you meet the following requirements:
 
@@ -80,13 +80,13 @@ The following fields can be set through PowerShell:
     * Can only be set if you're not synchronizing with an on-premises directory.
 
 > [!IMPORTANT]
-> There's a known lack of parity in command features between PowerShell v1 and PowerShell v2. The [Microsoft Graph REST API (beta) for authentication methods](/graph/api/resources/authenticationmethods-overview) is the current engineering focus to provide modern interaction.
+> Azure AD PowerShell is planned for deprecation. You can start using [Microsoft Graph PowerShell](/powershell/microsoftgraph/overview) to interact with Azure AD as you would in Azure AD PowerShell, or use the [Microsoft Graph REST API for managing authentication methods](/graph/api/resources/authenticationmethods-overview).
 
-### Use PowerShell version 1
+### Use Azure AD PowerShell version 1
 
 To get started, [download and install the Azure AD PowerShell module](/previous-versions/azure/jj151815(v=azure.100)#bkmk_installmodule). After it's installed, use the following steps to configure each field.
 
-#### Set the authentication data with PowerShell version 1
+#### Set the authentication data with Azure AD PowerShell version 1
 
 ```PowerShell
 Connect-MsolService
@@ -98,7 +98,7 @@ Set-MsolUser -UserPrincipalName [email protected] -PhoneNumber "+1 4252345678"
 Set-MsolUser -UserPrincipalName [email protected] -AlternateEmailAddresses @("[email protected]") -MobilePhone "+1 4251234567" -PhoneNumber "+1 4252345678"
 ```
 
-#### Read the authentication data with PowerShell version 1
+#### Read the authentication data with Azure AD PowerShell version 1
 
 ```PowerShell
 Connect-MsolService
@@ -120,21 +120,21 @@ Get-MsolUser -UserPrincipalName [email protected] | select -Expand StrongAuthentic
 Get-MsolUser -UserPrincipalName [email protected] | select -Expand StrongAuthenticationUserDetails | select Email
 ```
 
-### Use PowerShell version 2
+### Use Azure AD PowerShell version 2
 
 To get started, [download and install the Azure AD version 2 PowerShell module](/powershell/module/azuread/).
 
 To quickly install from recent versions of PowerShell that support `Install-Module`, run the following commands. The first line checks to see if the module is already installed:
 
 ```PowerShell
-Get-Module AzureADPreview
-Install-Module AzureADPreview
+Get-Module AzureAD
+Install-Module AzureAD
 Connect-AzureAD
 ```
 
 After the module is installed, use the following steps to configure each field.
 
-#### Set the authentication data with PowerShell version 2
+#### Set the authentication data with Azure AD PowerShell version 2
 
 ```PowerShell
 Connect-AzureAD
@@ -146,7 +146,7 @@ Set-AzureADUser -ObjectId [email protected] -TelephoneNumber "+1 4252345678"
 Set-AzureADUser -ObjectId [email protected] -OtherMails @("[email protected]") -Mobile "+1 4251234567" -TelephoneNumber "+1 4252345678"
 ```
 
-#### Read the authentication data with PowerShell version 2
+#### Read the authentication data with Azure AD PowerShell version 2
 
 ```PowerShell
 Connect-AzureAD
@@ -158,6 +158,45 @@ Get-AzureADUser -ObjectID [email protected] | select TelephoneNumber
 Get-AzureADUser | select DisplayName,UserPrincipalName,otherMails,Mobile,TelephoneNumber | Format-Table
 ```
 
+### Use Microsoft Graph PowerShell
+
+To get started, [download and install the Microsoft Graph PowerShell module](/powershell/microsoftgraph/overview).
+
+To quickly install from recent versions of PowerShell that support `Install-Module`, run the following commands. The first line checks to see if the module is already installed:
+
+```PowerShell
+Get-Module Microsoft.Graph
+Install-Module Microsoft.Graph
+Select-MgProfile -Name "beta"
+Connect-MgGraph -Scopes "User.ReadWrite.All"
+```
+
+After the module is installed, use the following steps to configure each field.
+
+#### Set the authentication data with Microsoft Graph PowerShell
+
+```PowerShell
+Connect-MgGraph -Scopes "User.ReadWrite.All"
+
+Update-MgUser -UserId '[email protected]' -otherMails @("[email protected]")
+Update-MgUser -UserId '[email protected]' -mobilePhone "+1 4251234567"
+Update-MgUser -UserId '[email protected]' -businessPhones "+1 4252345678"
+
+Update-MgUser -UserId '[email protected]' -otherMails @("[email protected]") -mobilePhone "+1 4251234567" -businessPhones "+1 4252345678"
+```
+
+#### Read the authentication data with Microsoft Graph PowerShell
+
+```PowerShell
+Connect-MgGraph -Scopes "User.Read.All"
+
+Get-MgUser -UserId '[email protected]' | select otherMails
+Get-MgUser -UserId '[email protected]' | select mobilePhone
+Get-MgUser -UserId '[email protected]' | select businessPhones
+
+Get-MgUser -UserId '[email protected]' | Select businessPhones, mobilePhone, otherMails | Format-Table
+```
+
 ## Next steps
 
 Once authentication contact information is pre-populated for users, complete the following tutorial to enable self-service password reset:

articles/active-directory/cloud-sync/media/plan-cloud-provisioning-topologies/attributes-multiple-sources.png

@@ -20,18 +20,18 @@ This article describes various on-premises and Azure Active Directory (Azure AD)
 > [!IMPORTANT]
 > Microsoft doesn't support modifying or operating Azure AD Connect cloud sync outside of the configurations or actions that are formally documented. Any of these configurations or actions might result in an inconsistent or unsupported state of Azure AD Connect cloud sync. As a result, Microsoft can't provide technical support for such deployments.
 
-For more information see the following video.
+For more information, see the following video.
 
 > [!VIDEO https://www.microsoft.com/en-us/videoplayer/embed/RWJ8l5]
 
 ## Things to remember about all scenarios and topologies
-The following is a list of information to keep in mind when selecting a solution.
+The information below should be kept in mind, when selecting a solution.
 
 - Users and groups must be uniquely identified across all forests
-- Matching across forests does not occur with cloud sync
+- Matching across forests doesn't occur with cloud sync
 - A user or group must be represented only once across all forests
 - The source anchor for objects is chosen automatically.  It uses ms-DS-ConsistencyGuid if present, otherwise ObjectGUID is used.
-- You cannot change the attribute that is used for source anchor.
+- You can't change the attribute that is used for source anchor.
 
 ## Single forest, single Azure AD tenant
 ![Diagram that shows the topology for a single forest and a single tenant.](media/tutorial-single-forest/diagram-2.png)
@@ -42,7 +42,7 @@ The simplest topology is a single on-premises forest, with one or multiple domai
 ## Multi-forest, single Azure AD tenant
 ![Topology for a multi-forest and a single tenant](media/plan-cloud-provisioning-topologies/multi-forest-2.png)
 
-A common topology is a multiple AD forests, with one or multiple domains, and a single Azure AD tenant.  
+Multiple AD forests is a common topology, with one or multiple domains, and a single Azure AD tenant.  
 
 ## Existing forest with Azure AD Connect, new forest with cloud Provisioning
 ![Diagram that shows the topology for an existing forest and a new forest.](media/tutorial-existing-forest/existing-forest-new-forest-2.png)
@@ -55,7 +55,29 @@ The piloting scenario involves the existence of both Azure AD Connect and Azure
 
 For an example of this scenario see [Tutorial: Pilot Azure AD Connect cloud sync in an existing synced AD forest](tutorial-pilot-aadc-aadccp.md)
 
+## Merging objects from disconnected sources 
+### (Public Preview)
+![Diagram for merging objects from disconnected sources](media/plan-cloud-provisioning-topologies/attributes-multiple-sources.png)
+In this scenario, the attributes of a user are contributed to by two disconnected Active Directory forests. 
 
+An example would be:
+
+ - one forest (1) contains most of the attributes
+ - a second forest (2) contains a few attributes
+
+ Since the second forest doesn't have network connectivity to the Azure AD Connect server, the object can't be merged through Azure AD Connect. Cloud Sync in the second forest allows the attribute value to be retrieved from the second forest. The value can then be merged with the object in Azure AD that is synced by Azure AD Connect. 
+
+This configuration is advanced and there are a few caveats to this topology: 
+
+ 1. You must use `msdsConsistencyGuid` as the source anchor in the Cloud Sync configuration.
+ 2. The `msdsConsistencyGuid` of the user object in the second forest must match that of the corresponding object in Azure AD.
+ 3. You must populate the `UserPrincipalName` attribute and the `Alias` attribute in the second forest and it must match the ones that are synced from the first forest. 
+ 4. You must remove all attributes from the attribute mapping in the Cloud Sync configuration that don't have a value or may have a different value in the second forest – you can't have overlapping attribute mappings between the first forest and the second one. 
+ 5. If there's no matching object in the first forest, for an object that is synced from the second forest, then Cloud Sync will still create the object in Azure AD. The object will only have the attributes that are defined in the mapping configuration of Cloud Sync for the second forest. 
+ 6. If you delete the object from the second forest, it will be temporarily soft deleted in Azure AD. It will be restored automatically after the next Azure AD Connect sync cycle.  
+ 7. If you delete the object from the first forest, it will be soft deleted from Azure AD.  The object won't be restored unless a change is made to the object in the second forest. After 30 days the object will be hard deleted from Azure AD and if a change is made to the object in the second forest it will be created as a new object in Azure AD. 
+
+ 
 
 ## Next steps 
 

articles/active-directory/cloud-sync/plan-cloud-sync-topologies.md

@@ -72,7 +72,7 @@ A service principal must be created in each tenant where the application is used
 
 ### Consequences of modifying and deleting applications
 
-Any changes that you make to your application object are also reflected in its service principal object in the application's home tenant only (the tenant where it was registered). This means that deleting an application object will also delete its home tenant service principal object. However, restoring that application object will not restore its corresponding service principal. For multi-tenant applications, changes to the application object are not reflected in any consumer tenants' service principal objects until the access is removed through the [Application Access Panel](https://myapps.microsoft.com) and granted again.
+Any changes that you make to your application object are also reflected in its service principal object in the application's home tenant only (the tenant where it was registered). This means that deleting an application object will also delete its home tenant service principal object. However, restoring that application object through the app registrations UI won't restore its corresponding service principal. For more information on deletion and recovery of applications and their service principal objects, see [delete and recover applications and service principal objects](../manage-apps/recover-deleted-apps-faq.md).
 
 ## Example
 

articles/active-directory/develop/app-objects-and-service-principals.md

@@ -31,7 +31,7 @@ In the following sections, you learn how to:
 
 ## Remove an application authored by you or your organization
 
-Applications that you or your organization have registered are represented by both an application object and service principal object in your tenant. For more information, see [Application Objects and Service Principal Objects](./app-objects-and-service-principals.md).
+Applications that you or your organization have registered are represented by both an application object and service principal object in your tenant. For more information, see [Application objects and service principal objects](./app-objects-and-service-principals.md).
 
 > [!NOTE]
 > Deleting an application will also delete its service principal object in the application's home directory. For multi-tenant applications, service principal objects in other directories will not be deleted.
@@ -50,7 +50,7 @@ To delete an application, be listed as an owner of the application or have admin
 
 If you are viewing **App registrations** in the context of a tenant, a subset of the applications that appear under the **All apps** tab are from another tenant and were registered into your tenant during the consent process. More specifically, they are represented by only a service principal object in your tenant, with no corresponding application object. For more information on the differences between application and service principal objects, see [Application and service principal objects in Azure AD](./app-objects-and-service-principals.md).
 
-In order to remove an application’s access to your directory (after having granted consent), the company administrator must remove its service principal. The administrator must have Global Admininstrator access, and can remove the application through the Azure portal or use the [Azure AD PowerShell Cmdlets](/previous-versions/azure/jj151815(v=azure.100)) to remove access.
+In order to remove an application’s access to your directory (after having granted consent), the company administrator must remove its service principal. The administrator must have Global Administrator access, and can remove the application through the Azure portal or use the [Azure AD PowerShell Cmdlets](/previous-versions/azure/jj151815(v=azure.100)) to remove access.
 
 ## Next steps
 

articles/active-directory/develop/howto-remove-app.md

@@ -102,15 +102,15 @@ services.Configure<MsalDistributedTokenCacheAdapterOptions>(options =>
     options.DisableL1Cache = false;
 
     // Or limit the memory (by default, this is 500 MB)
-    options.L1CacheOptions.SizeLimit = 1024 * 1024 * 1024, // 1 GB
+    options.L1CacheOptions.SizeLimit = 1024 * 1024 * 1024; // 1 GB
 
     // You can choose if you encrypt or not encrypt the cache
     options.Encrypt = false;
 
     // And you can set eviction policies for the distributed
     // cache.
     options.SlidingExpiration = TimeSpan.FromHours(1);
-  }
+  });
 
 // Then, choose your implementation of distributed cache
 // -----------------------------------------------------
@@ -708,4 +708,4 @@ The following samples illustrate token cache serialization.
 | ------ | -------- | ----------- |
 |[active-directory-dotnet-desktop-msgraph-v2](https://github.com/azure-samples/active-directory-dotnet-desktop-msgraph-v2) | Desktop (WPF) | Windows Desktop .NET (WPF) application that calls the Microsoft Graph API. ![Diagram that shows a topology with a desktop app client flowing to Azure Active Directory by acquiring a token interactively and to Microsoft Graph.](media/msal-net-token-cache-serialization/topology.png)|
 |[active-directory-dotnet-v1-to-v2](https://github.com/Azure-Samples/active-directory-dotnet-v1-to-v2) | Desktop (console) | Set of Visual Studio solutions that illustrate the migration of Azure AD v1.0 applications (using ADAL.NET) to Microsoft identity platform applications (using MSAL.NET). In particular, see [Token cache migration](https://github.com/Azure-Samples/active-directory-dotnet-v1-to-v2/blob/master/TokenCacheMigration/README.md) and [Confidential client token cache](https://github.com/Azure-Samples/active-directory-dotnet-v1-to-v2/tree/master/ConfidentialClientTokenCache). |
-[ms-identity-aspnet-webapp-openidconnect](https://github.com/Azure-Samples/ms-identity-aspnet-webapp-openidconnect) | ASP.NET (net472) | Example of token cache serialization in an ASP.NET MVC application (using MSAL.NET). In particular, see [MsalAppBuilder](https://github.com/Azure-Samples/ms-identity-aspnet-webapp-openidconnect/blob/master/WebApp/Utils/MsalAppBuilder.cs).
+[ms-identity-aspnet-webapp-openidconnect](https://github.com/Azure-Samples/ms-identity-aspnet-webapp-openidconnect) | ASP.NET (net472) | Example of token cache serialization in an ASP.NET MVC application (using MSAL.NET). In particular, see [MsalAppBuilder](https://github.com/Azure-Samples/ms-identity-aspnet-webapp-openidconnect/blob/master/WebApp/Utils/MsalAppBuilder.cs).