📝 Modified Documentation Files

MODIFIED docs/identity/conditional-access/concept-session-lifetime.md

Modified by John Flores on Dec 5, 2025 3:49 PM
📖 View on learn.microsoft.com

+25 / -25 lines changed

Commit: [Feedback items] December 2025

Changes:

Before

After

---
title: Conditional Access adaptive session lifetime policies
description: Learn how to use Conditional Access adaptive session lifetimes to enhance security.
 
ms.service: entra-id
ms.subservice: conditional-access
ms.topic: article
ms.date: 09/12/2025
 
ms.author: joflore
author: MicrosoftGuyJFlo
* High impact users
* Critical business applications
 
Conditional Access provides adaptive session lifetime policy controls, letting you create policies that target specific use cases within your organization without affecting all users.
 
Before exploring how to configure the policy, examine the default configuration.
 
 
### User sign-in frequency and multifactor authentication

---
title: Conditional Access adaptive session lifetime policies
description: Learn to configure Conditional Access adaptive session lifetime policies to protect critical apps, sensitive data, and high-impact users in your organization.
 
ms.service: entra-id
ms.subservice: conditional-access
ms.topic: article
ms.date: 12/05/2025
 
ms.author: joflore
author: MicrosoftGuyJFlo
* High impact users
* Critical business applications
 
Conditional Access provides adaptive session lifetime policy controls, so you can create policies that target specific use cases within your organization without affecting all users.
 
Before exploring how to configure the policy, examine the default configuration.
 
 
### User sign-in frequency and multifactor authentication

MODIFIED docs/identity/hybrid/cloud-sync/tutorial-group-provisioning.md

Modified by Ortagus Winfrey on Dec 5, 2025 8:20 PM
📖 View on learn.microsoft.com

+21 / -20 lines changed

Commit: new location

Changes:

Before

After

 
[!INCLUDE [pre-requisites](../includes/gpad-prereqs.md)]
 
## Assumptions
This tutorial assumes:
- You have an AD DS on-premises environment
 
:::image type="content" border="true" source="media/tutorial-group-provision/sync-blocked.png" alt-text="Screenshot of a blocked sync.":::
 
### Nested groups and membership references handling
 
The following table explains how the provisioning handles membership references after you convert SOA in different use cases.
 
## Group and User SOA Scenarios
 
Use case | Parent group type | User member group type | Sync Direction | How sync works 
A security group whose SOA is in **cloud** and **all user members** have SOA **on-premises** | Security group whose SOA is in cloud | Users whose SOA is on-premises | **Entra to AD (AAD2ADGroup provisioning)** | The job provisions the parent group with all its member references (member users). 
A security group whose SOA is in **cloud** and **all user members** have SOA **in cloud** | Security group whose SOA is in cloud | Users whose SOA is in cloud | **Entra to AD (AAD2ADGroup provisioning)** | The job provisions the security group but does not provision any member references.

 
[!INCLUDE [pre-requisites](../includes/gpad-prereqs.md)]
 
## Group and User SOA Scenarios
 
Use case | Parent group type | User member group type | Sync Direction | How sync works 
----------|--------------------|-------------------------|----------------|----------------
A security group whose SOA is in **cloud** and **all user members** have SOA **on-premises** | Security group whose SOA is in cloud | Users whose SOA is on-premises | **Entra to AD (AAD2ADGroup provisioning)** | The job provisions the parent group with all its member references (member users). 
A security group whose SOA is in **cloud** and **all user members** have SOA **in cloud** | Security group whose SOA is in cloud | Users whose SOA is in cloud | **Entra to AD (AAD2ADGroup provisioning)** | The job provisions the security group but does not provision any member references. 
A security group whose SOA is in **cloud** and **some user members** have SOA **in cloud** while others have SOA **on-premises** | Security group whose SOA is in cloud | Some users have SOA in cloud while some have SOA on-premises | **Entra to AD (AAD2ADGroup provisioning)** | The job provisions the security group and includes only member references whose SOA is on-premises. It skips member references whose SOA is in cloud. 
A security group whose SOA is in **cloud** and has **no user members** | Security group whose SOA is in cloud | No user members | **Entra to AD (AAD2ADGroup provisioning)** | The job provisions the security group (empty membership). 
A security group whose SOA is in **on-premises** and **all user members** have SOA **on-premises** | Security group whose SOA is on-premises | Users whose SOA is on-premises | **Entra to AD (AAD2ADGroup provisioning)** | The job does **not** provision the security group. 
A security group whose SOA is in **on-premises** and **all user members** have SOA in **cloud** | Security group whose SOA is on-premises | Users whose SOA is in cloud | **Entra to AD (AAD2ADGroup provisioning)** | The job does **not** provision the security group. 
A security group whose SOA is in **on-premises** and some **user members** have SOA in **cloud** while others have SOA **on-premises** | Security group whose SOA is on-premises | Some users have SOA in cloud while some have SOA on-premises | **Entra to AD (AAD2ADGroup provisioning)** | The job does **not** provision the security group. 
A security group whose SOA is in **on-premises** and **all user members** have SOA **on-premises** | Security group whose SOA is on-premises | Users whose SOA is on-premises | **AD to Entra (AD2AADprovisioning)** | The job provisions the security group with all its member references (member users). 
A security group whose SOA is in **on-premises** and **all user members** have SOA in **cloud** | Security group whose SOA is on-premises | Users whose SOA is in cloud | **AD to Entra (AD2AADprovisioning)** | The job provisions the security group with all its member references (member users). So member references whose SOA is converted to cloud for these on-prem groups will also be synced. 
A security group whose SOA is in **on-premises** and **some user members** have SOA in **cloud** while others have SOA **on-premises** | Security group whose SOA is on-premises | Some users have SOA in cloud while some have SOA on-premises | **AD to Entra (AD2AADprovisioning)** | The job provisions the parent group with all its member references (member users). So member references whose SOA is converted to cloud for these on-prem groups will also be synced.
A security group whose SOA is in **on-premises** and has **no user members** | Security group whose SOA is on-premises | No user members | **AD to Entra (AD2AADprovisioning)** | The job provisions the security group (empty membership). 
A security group whose SOA is in **cloud** and **all user members** have SOA **on-premises** | Security group whose SOA is cloud | Users whose SOA is on-premises | **AD to Entra (AD2AADprovisioning)** | The job does **not** provision the security group. 
A security group whose SOA is in **cloud** and **all user members** have SOA in **cloud** | Security group whose SOA is cloud | Users whose SOA is in cloud | **AD to Entra (AD2AADprovisioning)** | The job does **not** provision the security group. 

MODIFIED docs/identity/hybrid/connect/how-to-connect-password-hash-synchronization.md

Modified by Nuno Alexandre on Dec 5, 2025 7:46 PM
📖 View on learn.microsoft.com

+3 / -1 lines changed

Commit: Learn Editor: Update how-to-connect-password-hash-synchronization.md

Changes:

Before

After

> [!NOTE]
> When you create a new user in Active Directory with the **User must change password at next logon** option selected, Microsoft Entra ID always configures that user’s cloud account to **force a password change at the first sign-in**. This happens **whether *ForcePasswordChangeOnLogOn* feature is enabled or not**, because initially new synced user objects have no password in Microsoft Entra ID, hence must be forced to set one before sign-in. The *ForcePasswordChangeOnLogOn* feature itself only affects admin-initiated password reset scenarios from on-premises, not the initial user object synchronization.
> If a user account was created in Active Directory with **“User must change password at next logon”** while both, the *ForcePasswordChangeOnLogOn* and PasswordHashSync features were disabled, that user receives an error "*Your account or password is incorrect*" when signing in (instead of a password-change prompt). To fix this issue, clear the **“User must change password at next logon”** checkbox for the user in Active Directory, then **select it again**. After the next synchronization, Microsoft Entra ID will prompt the user to update their password at sign-in as expected.
When **Password Hash Synchronization (PHS)** is enabled, each new account is still provisioned in Microsoft Entra ID without a password (because the initial object synchronization doesn’t include the user's password). However, the PHS process runs *frequently* (every 2 minutes) to sync password hashes from on-premises AD to the cloud. The moment a user’s password is synced to Microsoft Entra ID, the service will apply or skip the “*force password change on next sign-in*” flag based on whether the **UserForcePasswordChangeOnLogonEnabled** feature is turned on or off. In other words, *UserForcePasswordChangeOnLogonEnabled* only takes effect when PHS actually synchronizes the password to the cloud. However, when *UserForcePasswordChangeOnLogonEnabled* feature is not enabled, the sync client won't even attempt to sync any temporary passwords. Also, if PHS is not running, enabling or disabling this feature has no impact on user sign-in behavior. 
 
The following table illustrates the feature combinations and expected behaviors:

> [!NOTE]
> When you create a new user in Active Directory with the **User must change password at next logon** option selected, Microsoft Entra ID always configures that user’s cloud account to **force a password change at the first sign-in**. This happens **whether *ForcePasswordChangeOnLogOn* feature is enabled or not**, because initially new synced user objects have no password in Microsoft Entra ID, hence must be forced to set one before sign-in. The *ForcePasswordChangeOnLogOn* feature itself only affects admin-initiated password reset scenarios from on-premises, not the initial user object synchronization.
> If a user account was created in Active Directory with **“User must change password at next logon”** while both, the *ForcePasswordChangeOnLogOn* and PasswordHashSync features were disabled, that user receives an error "*Your account or password is incorrect*" when signing in (instead of a password-change prompt). To fix this issue, clear the **“User must change password at next logon”** checkbox for the user in Active Directory, then **select it again**. After the next synchronization, Microsoft Entra ID will prompt the user to update their password at sign-in as expected.
 
When **Password Hash Synchronization (PHS)** is enabled, each new account is still provisioned in Microsoft Entra ID without a password (because the initial object synchronization doesn’t include the user's password). However, the PHS process runs *frequently* (every 2 minutes) to sync password hashes from on-premises AD to the cloud. The moment a user’s password is synced to Microsoft Entra ID, the service will apply or skip the “*force password change on next sign-in*” flag based on whether the **UserForcePasswordChangeOnLogonEnabled** feature is turned on or off. In other words, *UserForcePasswordChangeOnLogonEnabled* only takes effect when PHS actually synchronizes the password to the cloud. However, when *UserForcePasswordChangeOnLogonEnabled* feature is not enabled, the sync client won't even attempt to sync any temporary passwords. Also, if PHS is not running, enabling or disabling *UserForcePasswordChangeOnLogonEnabled* feature has no impact on user sign-in behavior. 
 
The following table illustrates the feature combinations and expected behaviors:

MODIFIED docs/identity/monitoring-health/howto-configure-health-alert-notifications.md

Modified by Shannon Leavitt on Dec 5, 2025 11:18 PM
📖 View on learn.microsoft.com

+1 / -1 lines changed

Commit: Update docs/identity/monitoring-health/howto-configure-health-alert-notifications.md

Changes:

Before

After

To start receiving notifications, your application sends a `POST` request to the /`subscriptions` endpoint to subscribe to a specific resource, in this case, health monitoring alerts. Microsoft Graph then validates the request and confirms the subscription. Once the subscription is active, Microsoft Graph sends a notification to your designated endpoint whenever the subscribed resource is created. For more information, see [Microsoft Graph change notifications](/graph/change-notifications-overview).
 
> [!NOTE]
> If you see an error due to missing required Microsoft Graph permissions, see [Microsoft graph permissions](/graph/permissions-overview) to get more information about Microsoft Graph permissions.
 
After receiving a notification, you should investigate the alert either through the Microsoft Entra admin center or through the Microsoft Graph API. If you need to assess the alert's impact, we recommend either polling or introducing a short delay before calling the health monitoring alert API for impact assessment data to be available. For more information, see [How to investigate health scenario alerts](howto-investigate-health-scenario-alerts.md).

To start receiving notifications, your application sends a `POST` request to the /`subscriptions` endpoint to subscribe to a specific resource, in this case, health monitoring alerts. Microsoft Graph then validates the request and confirms the subscription. Once the subscription is active, Microsoft Graph sends a notification to your designated endpoint whenever the subscribed resource is created. For more information, see [Microsoft Graph change notifications](/graph/change-notifications-overview).
 
> [!NOTE]
> If you see an error due to missing required Microsoft Graph permissions, see [Microsoft Graph permissions](/graph/permissions-overview).
 
After receiving a notification, you should investigate the alert either through the Microsoft Entra admin center or through the Microsoft Graph API. If you need to assess the alert's impact, we recommend either polling or introducing a short delay before calling the health monitoring alert API for impact assessment data to be available. For more information, see [How to investigate health scenario alerts](howto-investigate-health-scenario-alerts.md).

MODIFIED docs/identity/conditional-access/troubleshoot-conditional-access.md

Modified by John Flores on Dec 5, 2025 4:20 PM
📖 View on learn.microsoft.com

+1 / -1 lines changed

Commit: [Feedback items] December 2025

Changes:

Before

After

If you're locked out because of an incorrect setting in a Conditional Access policy:
 
- Check if there are other admins in your organization who aren't blocked yet. An admin with access can disable the policy that's affecting your sign-in.
- If no admin in your organization can update the policy, submit a support request. Microsoft support reviews and, after confirming, updates the Conditional Access policies that prevent access.
 
## Next steps

If you're locked out because of an incorrect setting in a Conditional Access policy:
 
- Check if there are other admins in your organization who aren't blocked yet. An admin with access can disable the policy that's affecting your sign-in.
- If no admin in your organization can update the policy, [submit a support request](../../fundamentals/how-to-get-support.md#open-a-support-request). Microsoft support reviews and, after confirming, updates the Conditional Access policies that prevent access.
 
## Next steps

MODIFIED docs/identity/conditional-access/policy-block-by-location.md

Modified by John Flores on Dec 5, 2025 4:00 PM
📖 View on learn.microsoft.com

+1 / -1 lines changed

Commit: [Feedback items] December 2025

Changes:

Before

After

Under **Include**, select **Selected networks and locations**
Select the blocked location you created for your organization.
Click **Select**.
Under **Access controls** > select **Block Access**, and click **Select**.
Confirm your settings and set **Enable policy** to **Report-only**.
Select **Create** to create to enable your policy.
 

Under **Include**, select **Selected networks and locations**
Select the blocked location you created for your organization.
Click **Select**.
Under **Access controls** > **Grant**, select **Block access**, then select **Select**.
Confirm your settings and set **Enable policy** to **Report-only**.
Select **Create** to create to enable your policy.
 

MODIFIED docs/identity/monitoring-health/reference-sla-performance.md

Modified by YalingQing on Dec 5, 2025 5:16 AM
📖 View on learn.microsoft.com

+1 / -1 lines changed

Commit: Learn Editor: Update reference-sla-performance.md

Changes:

Before

After

| August    | 99.999% | 99.999% | 99.999% | 99.999% | 99.999% |
| September | 99.999% | 99.998% | 99.999% | 99.999% | 99.999% |
| October   | 99.999% | 99.999% | 99.999% | 99.998% | 99.999% |
| November  | 99.998% | 99.999% | 99.999% | 99.998% |         |
| December  | 99.978% | 99.999% | 99.999% | 99.998% |         |
 
<a name='how-is-azure-ad-sla-measured-'></a>

| August    | 99.999% | 99.999% | 99.999% | 99.999% | 99.999% |
| September | 99.999% | 99.998% | 99.999% | 99.999% | 99.999% |
| October   | 99.999% | 99.999% | 99.999% | 99.998% | 99.999% |
| November  | 99.998% | 99.999% | 99.999% | 99.998% | 99.999% |
| December  | 99.978% | 99.999% | 99.999% | 99.998% |         |
 
<a name='how-is-azure-ad-sla-measured-'></a>

📋 Microsoft Entra Documentation Changes

📊 Summary

📝 Modified Documentation Files