Merge pull request #233627 from MicrosoftDocs/main

Merge main to live, 4 AM

Author: v-ccolin

.openpublishing.redirection.active-directory.json

@@ -60,6 +60,11 @@
       "redirect_url": "/azure/active-directory/saas-apps/atlassian-cloud-tutorial",
       "redirect_document_id": false
     },
+    {
+      "source_path_from_root": "/articles/active-directory/saas-apps/easy-metrics-auth0-connector-tutorial.md",
+      "redirect_url": "/azure/active-directory/saas-apps/easy-metrics-connector-tutorial",
+      "redirect_document_id": false
+    },
     {
       "source_path_from_root": "/articles/active-directory/saas-apps/iauditor-tutorial.md",
       "redirect_url": "/azure/active-directory/saas-apps/safety-culture-tutorial",
@@ -135,7 +140,7 @@
       "redirect_url": "/azure/active-directory/saas-apps/f5-big-ip-headers-easy-button",
       "redirect_document_id": false
     },
-	{
+    {
       "source_path_from_root": "/articles/active-directory/saas-apps/tripactions-tutorial.md",
       "redirect_url": "/azure/active-directory/saas-apps/navan-tutorial",
       "redirect_document_id": false

articles/active-directory/authentication/how-to-mfa-number-match.md

@@ -4,7 +4,7 @@ description: Learn how to use number matching in MFA notifications
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: conceptual
-ms.date: 03/28/2023
+ms.date: 04/05/2023
 ms.author: justinha
 author: justinha
 ms.collection: M365-identity-device-management
@@ -371,21 +371,11 @@ No, number matching isn't enforced because it's not a supported feature for MFA
 
 ### What happens if a user runs an older version of Microsoft Authenticator?  
 
-If a user is running an older version of Microsoft Authenticator that doesn't support number matching, authentication won't work if number matching is enabled. Users need to upgrade to the latest version of Microsoft Authenticator to use it for sign-in if they use Android versions prior to 6.2006.4198, or iOS versions prior to 6.4.12.
+If a user is running an older version of Microsoft Authenticator that doesn't support number matching, authentication won't work if number matching is enabled. Users need to upgrade to the latest version of Microsoft Authenticator to use it for sign-in.
 
 ### Why is my user prompted to tap on one of three numbers rather than enter the number in their Microsoft Authenticator app?
 
-Older versions of Microsoft Authenticator prompt users to tap and select a number rather than enter the number in Microsoft Authenticator. These authentications won't fail, but Microsoft highly recommends that users upgrade to the latest version of Microsoft Authenticator if they use Android versions prior to 6.2108.5654, or iOS versions prior to 6.5.82, so they can use number match.
-
-Minimum Microsoft Authenticator version supporting number matching:
-
-- Android: 6.2006.4198
-- iOS: 6.4.12
-
-Minimum Microsoft Authenticator version for number matching which prompts to enter a number:
-
-- Android 6.2111.7701
-- iOS 6.5.85
+Older versions of Microsoft Authenticator prompt users to tap and select a number rather than enter the number in Microsoft Authenticator. These authentications won't fail, but Microsoft highly recommends that users upgrade to the latest version of Microsoft Authenticator.
 
 ### How can users recheck the number on mobile iOS devices after the match request appears?
 

articles/active-directory/authentication/how-to-mfa-server-migration-utility.md

@@ -6,7 +6,7 @@ services: multi-factor-authentication
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: how-to
-ms.date: 03/27/2023
+ms.date: 04/05/2023
 
 ms.author: justinha
 author: justinha
@@ -185,7 +185,14 @@ Once complete, navigate to the Multi-factor Authentication Server folder, and op
 You've successfully installed the Migration Utility.
 
 >[!NOTE]
-> To ensure no changes in behavior during migration, if your MFA Server is associated with an MFA Provider with no tenant reference, you'll need to update the default MFA settings (e.g. custom greetings) for the tenant you're migrating to match the settings in your MFA Provider. We recommend doing this before migrating any users.
+> To ensure no changes in behavior during migration, if your MFA Server is associated with an MFA Provider with no tenant reference, you'll need to update the default MFA settings (such as custom greetings) for the tenant you're migrating to match the settings in your MFA Provider. We recommend doing this before migrating any users.
+
+### Run a secondary MFA Server (optional)
+
+If your MFA Server implementation has a large number of users or a busy primary MFA Server, you may want to consider deploying a dedicated secondary MFA Server for running the MFA Server Migration Utility and Migration Sync services. After upgrading your primary MFA Server, either upgrade an existing secondary server or deploy a new secondary server. The secondary server you choose should not be handling other MFA traffic. 
+
+The Configure-MultiFactorAuthMigrationUtility.ps1 script should be run on the secondary server to register a certificate with the MFA Server Migration Utility app registration. The certificate is used to authenticate to Microsoft Graph. Running the Migration Utility and Sync services on a secondary MFA Server should improve performance of both manual and automated user migrations.
+
 
 ### Migrate user data
 Migrating user data doesn't remove or alter any data in the Multi-Factor Authentication Server database. Likewise, this process won't change where a user performs MFA. This process is a one-way copy of data from the on-premises server to the corresponding user object in Azure AD.

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

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: how-to
-ms.date: 03/22/2023
+ms.date: 04/05/2023
 
 ms.author: justinha
 author: justinha
@@ -36,7 +36,7 @@ The following limitations apply to using SSPR from the Windows sign-in screen:
 - This feature doesn't work for networks with 802.1x network authentication deployed and the option "Perform immediately before user logon". For networks with 802.1x network authentication deployed, it's recommended to use machine authentication to enable this feature.
 - Hybrid Azure AD joined machines must have network connectivity line of sight to a domain controller to use the new password and update cached credentials. This means that devices must either be on the organization's internal network or on a VPN with network access to an on-premises domain controller.
 - If using an image, prior to running sysprep ensure that the web cache is cleared for the built-in Administrator prior to performing the CopyProfile step. More information about this step can be found in the support article [Performance poor when using custom default user profile](https://support.microsoft.com/help/4056823/performance-issue-with-custom-default-user-profile).
-- The following settings are known to interfere with the ability to use and reset passwords on Windows devices:
+- The following settings are known to interfere with the ability to use and reset passwords on Windows 10 devices:
     - If lock screen notifications are turned off, **Reset password** won't work.
     - *HideFastUserSwitching* is set to enabled or 1
     - *DontDisplayLastUserName* is set to enabled or 1

articles/active-directory/develop/multi-service-web-app-access-microsoft-graph-as-app.md

@@ -8,7 +8,7 @@ manager: CelesteDG
 ms.service: app-service
 ms.topic: tutorial
 ms.workload: identity
-ms.date: 08/19/2022
+ms.date: 04/05/2023
 ms.author: ryanwi
 ms.reviewer: stsoneff
 ms.devlang: csharp, javascript
@@ -54,32 +54,38 @@ When accessing the Microsoft Graph, the managed identity needs to have proper pe
 # [PowerShell](#tab/azure-powershell)
 
 ```powershell
-# Install the module. (You need admin on the machine.)
-# Install-Module AzureAD.
+# Install the module.
+# Install-Module Microsoft.Graph -Scope CurrentUser
 
-# Your tenant ID (in the Azure portal, under Azure Active Directory > Overview).
-$TenantID="<tenant-id>"
-$resourceGroup = "securewebappresourcegroup"
-$webAppName="SecureWebApp-20201102125811"
+# The tenant ID
+$TenantId = "11111111-1111-1111-1111-111111111111"
 
-# Get the ID of the managed identity for the web app.
-$spID = (Get-AzWebApp -ResourceGroupName $resourceGroup -Name $webAppName).identity.principalid
+# The name of your web app, which has a managed identity.
+$webAppName = "SecureWebApp-20201106120003" 
+$resourceGroupName = "SecureWebApp-20201106120003ResourceGroup"
 
-# Check the Microsoft Graph documentation for the permission you need for the operation.
-$PermissionName = "User.Read.All"
+# The name of the app role that the managed identity should be assigned to.
+$appRoleName = "User.Read.All"
 
-Connect-AzureAD -TenantId $TenantID
+# Get the web app's managed identity's object ID.
+Connect-AzAccount -Tenant $TenantId
+$managedIdentityObjectId = (Get-AzWebApp -ResourceGroupName $resourceGroupName -Name $webAppName).identity.principalid
 
-# Get the service principal for Microsoft Graph.
-# First result should be AppId 00000003-0000-0000-c000-000000000000
-$GraphServicePrincipal = Get-AzureADServicePrincipal -SearchString "Microsoft Graph" | Select-Object -first 1
+Connect-MgGraph -TenantId $TenantId -Scopes 'Application.Read.All','AppRoleAssignment.ReadWrite.All'
 
-# Assign permissions to the managed identity service principal.
-$AppRole = $GraphServicePrincipal.AppRoles | `
-Where-Object {$_.Value -eq $PermissionName -and $_.AllowedMemberTypes -contains "Application"}
+# Get Microsoft Graph app's service principal and app role.
+$serverApplicationName = "Microsoft Graph"
+$serverServicePrincipal = (Get-MgServicePrincipal -Filter "DisplayName eq '$serverApplicationName'")
+$serverServicePrincipalObjectId = $serverServicePrincipal.Id
 
-New-AzureAdServiceAppRoleAssignment -ObjectId $spID -PrincipalId $spID `
--ResourceId $GraphServicePrincipal.ObjectId -Id $AppRole.Id
+$appRoleId = ($serverServicePrincipal.AppRoles | Where-Object {$_.Value -eq $appRoleName }).Id
+
+# Assign the managed identity access to the app role.
+New-MgServicePrincipalAppRoleAssignment `
+    -ServicePrincipalId $managedIdentityObjectId `
+    -PrincipalId $managedIdentityObjectId `
+    -ResourceId $serverServicePrincipalObjectId `
+    -AppRoleId $appRoleId
 ```
 
 # [Azure CLI](#tab/azure-cli)

articles/active-directory/reports-monitoring/howto-manage-inactive-user-accounts.md

@@ -1,89 +1,84 @@
 ---
-title: How to manage inactive user accounts in Azure AD
-description: Learn about how to detect and handle user accounts in Azure AD that have become obsolete
+title: How to manage inactive user accounts
+description: Learn how to detect and resolve user accounts that have become obsolete
 services: active-directory
 author: shlipsey3
 manager: amycolannino
 ms.service: active-directory
 ms.topic: how-to
 ms.workload: identity
 ms.subservice: report-monitor
-ms.date: 10/31/2022
+ms.date: 04/05/2023
 ms.author: sarahlipsey
 ms.reviewer: besiler
 
 ms.collection: M365-identity-device-management
 ---
-# How To: Manage inactive user accounts in Azure AD
+# How To: Manage inactive user accounts
 
-In large environments, user accounts are not always deleted when employees leave an organization. As an IT administrator, you want to detect and handle these obsolete user accounts because they represent a security risk.
+In large environments, user accounts aren't always deleted when employees leave an organization. As an IT administrator, you want to detect and resolve these obsolete user accounts because they represent a security risk.
 
-This article explains a method to handle obsolete user accounts in Azure AD. 
+This article explains a method to handle obsolete user accounts in Azure Active Directory (Azure AD). 
 
 ## What are inactive user accounts?
 
-Inactive accounts are user accounts that are not required anymore by members of your organization to gain access to your resources. One key identifier for inactive accounts is that they haven't been used *for a while* to sign-in to your environment. Because inactive accounts are tied to the sign-in activity, you can use the timestamp of the last sign-in that was successful to detect them. 
+Inactive accounts are user accounts that aren't required anymore by members of your organization to gain access to your resources. One key identifier for inactive accounts is that they haven't been used *for a while* to sign in to your environment. Because inactive accounts are tied to the sign-in activity, you can use the timestamp of the last sign-in that was successful to detect them. 
 
-The challenge of this method is to define what *for a while* means in the case of your environment. For example, users might not sign-in to an environment *for a while*, because they are on vacation. When defining what your delta for inactive user accounts is, you need to factor in all legitimate reasons for not signing in to your environment. In many organizations, the delta for inactive user accounts is between 90 and 180 days. 
+The challenge of this method is to define what *for a while* means for your environment. For example, users might not sign in to an environment *for a while*, because they are on vacation. When defining what your delta for inactive user accounts is, you need to factor in all legitimate reasons for not signing in to your environment. In many organizations, the delta for inactive user accounts is between 90 and 180 days. 
 
 The last successful sign-in provides potential insights into a user's continued need for access to resources.  It can help with determining if group membership or app access is still needed or could be removed. For external user management, you can understand if an external user is still active within the tenant or should be cleaned up. 
 
-    
-## How to detect inactive user accounts
+## Detect inactive user accounts with Microsoft Graph
+<a name="how-to-detect-inactive-user-accounts"></a>
 
-You detect inactive accounts by evaluating the **lastSignInDateTime** property exposed by the **signInActivity** resource type of the **Microsoft Graph** API. The **lastSignInDateTime** property shows the last time a user made a successful interactive sign-in to Azure AD. Using this property, you can implement a solution for the following scenarios:
+You can detect inactive accounts by evaluating the `lastSignInDateTime` property exposed by the `signInActivity` resource type of the **Microsoft Graph API**. The `lastSignInDateTime` property shows the last time a user made a successful interactive sign-in to Azure AD. Using this property, you can implement a solution for the following scenarios:
 
-- **Users by name**: In this scenario, you search for a specific user by name, which enables you to evaluate the lastSignInDateTime: `https://graph.microsoft.com/v1.0/users?$filter=startswith(displayName,'markvi')&$select=displayName,signInActivity`
+- **Last sign-in date and time for all users**: In this scenario, you need to generate a report of the last sign-in date of all users. You request a list of all users, and the last `lastSignInDateTime` for each respective user:
+    - `https://graph.microsoft.com/v1.0/users?$select=displayName,signInActivity` 
 
-- **Users by date**: In this scenario, you request a list of users with a lastSignInDateTime before a specified date: `https://graph.microsoft.com/v1.0/users?$filter=signInActivity/lastSignInDateTime le 2019-06-01T00:00:00Z`
+- **Users by name**: In this scenario, you search for a specific user by name, which enables you to evaluate the `lastSignInDateTime`:
+    - `https://graph.microsoft.com/v1.0/users?$filter=startswith(displayName,'markvi')&$select=displayName,signInActivity`
 
-> [!NOTE]
-> When you request the signInActivity property while listing users, the maximum page size is 120 users. Requests with $top set higher than 120 will fail. SignInActivity supports `$filter` (`eq`, `ne`, `not`, `ge`, `le`) *but* not with any other filterable properties. 
+- **Users by date**: In this scenario, you request a list of users with a `lastSignInDateTime` before a specified date:
+    - `https://graph.microsoft.com/v1.0/users?$filter=signInActivity/lastSignInDateTime le 2019-06-01T00:00:00Z`
 
 > [!NOTE]
-> There may be the need to generate a report of the last sign in date of all users, if so you can use the following scenario.
-> **Last Sign In Date and Time for All Users**: In this scenario, you request a list of all users, and the last lastSignInDateTime for each respective user: `https://graph.microsoft.com/v1.0/users?$select=displayName,signInActivity` 
-
-## What you need to know
-
-This section lists what you need to know about the lastSignInDateTime property.
-
-### How can I access this property?
-
-The **lastSignInDateTime** property is exposed by the [signInActivity resource type](/graph/api/resources/signinactivity) of the [Microsoft Graph API](/graph/overview#whats-in-microsoft-graph).   
+> When you request the `signInActivity` property while listing users, the maximum page size is 120 users. Requests with $top set higher than 120 will fail. The `signInActivity` property supports `$filter` (`eq`, `ne`, `not`, `ge`, `le`) *but not with any other filterable properties*. 
 
-### Is the lastSignInDateTime property available through the Get-AzureAdUser cmdlet?
+### What you need to know
 
-No.
+The following details relate to the `lastSignInDateTime` property.
 
-### What edition of Azure AD do I need to access the property?
+- The `lastSignInDateTime` property is exposed by the [signInActivity resource type](/graph/api/resources/signinactivity) of the [Microsoft Graph API](/graph/overview#whats-in-microsoft-graph).   
 
-To access this property, you need an Azure Active Directory Premium edition.
+- The property is *not* available through the Get-AzureAdUser cmdlet.
 
-### What permission do I need to read the property?
+- To access the property, you need an Azure Active Directory Premium edition license.
 
-To read this property, you need to grant the app the following Microsoft Graph permissions: 
+- To read the property, you need to grant the app the following Microsoft Graph permissions: 
+    - AuditLog.Read.All
+    - Directory.Read.All  
+    - User.Read.All
 
-- AuditLog.Read.All
-- Directory.Read.All  
-- User.Read.All
-
-
-### When does Azure AD update the property?
-
-Each interactive sign-in that was successful results in an update of the underlying data store. Typically, successful sign-ins show up in the related sign-in report within 10 minutes.
+- Each interactive sign-in that was successful results in an update of the underlying data store. Typically, successful sign-ins show up in the related sign-in report within 10 minutes.
 
+- To generate a `lastSignInDateTime` timestamp, you need a successful sign-in. The value of the `lastSignInDateTime` property may be blank if:
+    - The last successful sign-in of a user took place before April 2020.
+    - The affected user account was never used for a successful sign-in.
+
+- The last sign-in date is associated with the user object. The value is retained until the next sign-in of the user. 
 
-### What does a blank property value mean?
+## How to investigate a single user
 
-To generate a lastSignInDateTime timestamp, you need a successful sign-in. Because the lastSignInDateTime property is a new feature, the value of the lastSignInDateTime property can be blank if:
+If you need to view the latest sign-in activity for a user you can view the user's sign-in details in Azure AD. You can also use the Microsoft Graph **users by name** scenario described in the [previous section](#detect-inactive-user-accounts-with-microsoft-graph).
 
-- The last successful sign-in of a user took place before April 2020.
-- The affected user account was never used for a successful sign-in.
+1. Sign in to the [Azure portal](https://portal.azure.com). 
+1. Go to **Azure AD** > **Users** > select a user from the list.
+1. In the **My Feed** area of the user's Overview, locate the **Sign-ins** tile. 
 
-### For how long is the last sign-in retained?
+    ![Screenshot of the user overview page with the sign-in activity tile highlighted.](media/howto-manage-inactive-user-accounts/last-sign-activity-tile.png)
 
-The last sign-in date is associated with the user object. The value is retained until the next sign-in of the user. 
+The last sign-in date and time shown on this tile may take up to 24 hours to update, which means the date and time may not be current. If you need to see the activity in near real time, select the **See all sign-ins** link on the **Sign-ins** tile to view all sign-in activity for that user. 
 
 ## Next steps