Merge pull request #226279 from MicrosoftDocs/main

2/03 PM Publish

Author: huypub

.openpublishing.redirection.azure-monitor.json

@@ -25,6 +25,11 @@
             "redirect_url": "/azure/azure-monitor/change/change-analysis",
             "redirect_document_id": false
         },
+        {
+            "source_path_from_root": "/articles/azure-monitor/app/legacy-pricing.md",
+            "redirect_url": "/azure/azure-monitor/best-practices-cost",
+            "redirect_document_id": false
+        },
         {
             "source_path_from_root": "/articles/azure-monitor/app/snapshot-debugger.md",
             "redirect_url": "/azure/azure-monitor/snapshot-debugger/snapshot-debugger",

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

@@ -4,9 +4,9 @@ description: Learn how to use number matching in MFA notifications
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: conceptual
-ms.date: 01/31/2023
+ms.date: 02/03/2023
 ms.author: justinha
-author: mjsantani
+author: justinha
 ms.collection: M365-identity-device-management
 
 # Customer intent: As an identity administrator, I want to encourage users to use the Microsoft Authenticator app in Azure AD to improve and secure user sign-in events.
@@ -305,7 +305,7 @@ GET https://graph.microsoft.com/beta/authenticationMethodsPolicy/authenticationM
 
 ### When will my tenant see number matching if I don't use the Azure portal or Graph API to roll out the change?
 
-Number match will be enabled for all users of Microsoft Authenticator after February 27, 2023. Relevant services will begin deploying these changes after February 27, 2023 and users will start to see number match in approval requests. As services deploy, some may see number match while others don't. To ensure consistent behavior for all your users, we highly recommend you use the Azure portal or Graph API to roll out number match for all Microsoft Authenticator users. 
+Number match will be enabled for all users of Microsoft Authenticator push notifications after February 27, 2023. Relevant services will begin deploying these changes after February 27, 2023 and users will start to see number match in approval requests. As services deploy, some may see number match while others don't. To ensure consistent behavior for all your users, we highly recommend you use the Azure portal or Graph API to roll out number match for all Microsoft Authenticator users. 
 
 ### Will the changes after February 27th, 2023, override number matching settings that are configured for a group in the Authentication methods policy?
 
@@ -362,10 +362,6 @@ If the user has a different default authentication method, there won't be any ch
 
 Regardless of their default method, any user who is prompted to sign-in with Authenticator push notifications will see number match after February 27th, 2023. If the user is prompted for another method, they won't see any change. 
 
-### Will users who don't use number matching be able to perform MFA?
-
-It depends on how the **Enable and Target** tab is configured. The scope for number match approvals will change under the **Configure** tab to include everyone, but it only applies for users and groups targeted on the **Enable and Target** tab for Push or Any. However, if Target on the **Enable and Target** tab is set to specific groups for Push or Any, and the user isn't a member of those groups, then they won't receive the number matching approvals once the change is implemented after February 27th, 2023 because they aren't a member of the groups defined on the **Enable and Target** tab for Push and/or Any.
-
 ### Is number matching supported with MFA Server?
 
 No, number matching isn't enforced because it's not a supported feature for MFA Server, which is [deprecated](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/microsoft-entra-change-announcements-september-2022-train/ba-p/2967454).

articles/active-directory/conditional-access/howto-conditional-access-session-lifetime.md

@@ -58,27 +58,40 @@ Sign-in frequency previously applied to only to the first factor authentication
 
 ### User sign-in frequency and device identities
 
-On Azure AD joined, hybrid Azure AD joined, or Azure AD registered devices, unlocking the device or signing in interactively will satisfy the sign-in frequency policy. In the following two examples user sign-in frequency is set to 1 hour:
+On Azure AD joined and hybrid Azure AD joined devices, unlocking the device, or signing in interactively will only refresh the Primary Refresh Token (PRT) every 4 hours. The last refresh timestamp recorded for PRT compared with the current timestamp must be within the time allotted in SIF policy for PRT to satisfy SIF and grant access to a PRT that has an existing MFA claim. On [Azure AD registered devices](/active-directory/devices/concept-azure-ad-register), unlock/sign-in would not satisfy the SIF policy because the user is not accessing an Azure AD registered device via an Azure AD account. However, the [Azure AD WAM](/azure/active-directory/develop/scenario-desktop-acquire-token-wam) plugin can refresh a PRT during native application authentication using WAM.
 
-Example 1:
+Note: The timestamp captured from user log-in is not necessarily the same as the last recorded timestamp of PRT refresh because of the 4-hour refresh cycle. The case when it is the same is when a PRT has expired and a user log-in refreshes it for 4 hours. In the following examples, assume SIF policy is set to 1 hour and PRT is refreshed at 00:00.
+
+Example 1: *when you continue to work on the same doc in SPO for an hour*
 
 - At 00:00, a user signs in to their Windows 10 Azure AD joined device and starts work on a document stored on SharePoint Online.
 - The user continues working on the same document on their device for an hour.
 - At 01:00, the user is prompted to sign in again based on the sign-in frequency requirement in the Conditional Access policy configured by their administrator.
 
-Example 2:
+Example 2: *when pausing work with a background task running in the browser, then interacting again after the SIF policy time has passed*
 
-- At 00:00, a user signs in to their Windows 10 Azure AD joined device and starts work on a document stored on SharePoint Online.
+- At 00:00, a user signs in to their Windows 10 Azure AD joined device and starts to upload a document to SharePoint Online.
+- At 00:10, the user gets up and takes a break locking their device. The background upload continues to SharePoint Online.
+- At 02:45, the user returns from their break and unlocks the device. The background upload shows completion.
+- At 02:45, the user is prompted to sign in when they interact again based on the sign-in frequency requirement in the Conditional Access policy configured by their administrator since the last sign-in happened at 00:00.
+
+If the client app (under activity details) is a Browser, we defer sign in frequency enforcement of events/policies on background services until the next user interaction.   
+
+Example 3: *with 4-hour refresh cycle of primary refresh token from unlock*
+
+Scenario 1 - User returns within cycle
+
+- At 00:00, a user signs into their Windows 10 Azure AD joined device and starts work on a document stored on SharePoint Online.
 - At 00:30, the user gets up and takes a break locking their device.
 - At 00:45, the user returns from their break and unlocks the device.
-- At 01:45, the user is prompted to sign in again based on the sign-in frequency requirement in the Conditional Access policy configured by their administrator since the last sign-in happened at 00:45.
+- At 01:00, the user is prompted to sign in again based on the sign-in frequency requirement in the Conditional Access policy configured by their administrator, 1 hour after the initial sign-in.
 
-Example 3: If the client app (under activity details) is a Browser, we defer sign in frequency enforcement of events/policies on background services until the next user interaction.
+Scenario 2 - User returns outside cycle
 
-- At 00:00, a user signs in to their Windows 10 Azure AD joined device and starts to upload a document to SharePoint Online.
-- At 00:10, the user gets up and takes a break locking their device. The background upload continues to SharePoint Online. 
-- At 02:45, the user returns from their break and unlocks the device. The background upload shows completion. 
-- At 02:45, the user is prompted to sign in when they interact again based on the sign-in frequency requirement in the Conditional Access policy configured by their administrator since the last sign-in happened at 00:00. 
+- At 00:00, a user signs into their Windows 10 Azure AD joined device and starts work on a document stored on SharePoint Online.
+- At 00:30, the user gets up and takes a break locking their device.
+- At 04:45, the user returns from their break and unlocks the device.
+- At 05:45, the user is prompted to sign in again based on the sign-in frequency requirement in the Conditional Access policy configured by their administrator, 1 hour after the PRT was refreshed at 04:45 (over 4hrs after the initial sign-in at 00:00).
 
 ### Require reauthentication every time