📋 Microsoft Entra Documentation Changes

Daily summary for changes since May 31st 2026, 11:50 PM PDT

Report generated on June 1st 2026, 11:50 PM PDT

📊 Summary

23
Total Commits
0
New Files
11
Modified Files
0
Deleted Files
11
Contributors

📝 Modified Documentation Files

Modified by Vimala Ranganathan on Jun 1, 2026 6:39 PM
📖 View on learn.microsoft.com
+6 / -2 lines changed
Commit: Update Seamless SSO encryption type guidance with July 2026 changes
Changes:
Before
After
>[!IMPORTANT]
> The `AZUREADSSOACC` computer account needs to be strongly protected for security reasons. Only Domain Admins should be able to manage the computer account. Ensure that Kerberos delegation on the computer account is disabled, and that no other account in Active Directory has delegation permissions on the `AZUREADSSOACC` computer account.. Store the computer account in an Organization Unit (OU) where they are safe from accidental deletions and where only Domain Admins have access. The Kerberos decryption key on the computer account should also be treated as sensitive. We highly recommend that you [roll over the Kerberos decryption key](how-to-connect-sso-faq.yml) of the `AZUREADSSOACC` computer account at least every 30 days.
 
>[!IMPORTANT]
> Seamless SSO supports the `AES256_HMAC_SHA1`, `AES128_HMAC_SHA1` and `RC4_HMAC_MD5` encryption types for Kerberos. It is recommended that the encryption type for the `AzureADSSOAcc$` account is set to `AES256_HMAC_SHA1`, or one of the AES types vs. RC4 for added security. The encryption type is stored on the `msDS-SupportedEncryptionTypes` attribute of the account in your Active Directory. If the `AzureADSSOAcc$` account encryption type is set to `RC4_HMAC_MD5`, and you want to change it to one of the AES encryption types, please make sure that you first roll over the Kerberos decryption key of the `AzureADSSOAcc$` account as explained in the [FAQ document](how-to-connect-sso-faq.yml) under the relevant question, otherwise Seamless SSO will not happen.
 
Once the set-up is complete, Seamless SSO works the same way as any other sign-in that uses integrated Windows authentication (IWA).
 
 
 
 
 
>[!IMPORTANT]
> The `AZUREADSSOACC` computer account needs to be strongly protected for security reasons. Only Domain Admins should be able to manage the computer account. Ensure that Kerberos delegation on the computer account is disabled, and that no other account in Active Directory has delegation permissions on the `AZUREADSSOACC` computer account.. Store the computer account in an Organization Unit (OU) where they are safe from accidental deletions and where only Domain Admins have access. The Kerberos decryption key on the computer account should also be treated as sensitive. We highly recommend that you [roll over the Kerberos decryption key](how-to-connect-sso-faq.yml) of the `AZUREADSSOACC` computer account at least every 30 days.
 
> [!IMPORTANT]
> Seamless SSO supports the following Kerberos encryption types: `AES256_HMAC_SHA1`, `AES128_HMAC_SHA1`, and `RC4_HMAC_MD5`. For enhanced security, Microsoft recommends configuring the `AzureADSSOAcc$` account to use `AES256_HMAC_SHA1` or another AES-based encryption type instead of RC4. The configured encryption type is stored in the `msDS-SupportedEncryptionTypes` attribute of the account in Active Directory Domain Services (AD DS).
>
> Starting with the July 2026 Windows Server update, the default Kerberos encryption type in AD DS will change from RC4 to AES-256. Organizations that continue to use RC4 may experience authentication or Seamless SSO issues after this update is applied. To help ensure uninterrupted SSO access, Microsoft recommends migrating the `AzureADSSOAcc$` account to AES-256 as soon as possible.
>
> If the `AzureADSSOAcc$` account is currently configured to use `RC4_HMAC_MD5` and you plan to switch to an AES-based encryption type, you must first roll over the Kerberos decryption key for the `AzureADSSOAcc$` account, as described in the [FAQ documentation](how-to-connect-sso-faq.yml). Failing to roll over the key before changing the encryption type can prevent Seamless SSO from functioning correctly.
 
Once the set-up is complete, Seamless SSO works the same way as any other sign-in that uses integrated Windows authentication (IWA).
 
+6 / -1 lines changed
Commit: Add temporary notice for erroneous WCF V1 'Deprecating soon' label AB#583992
Changes:
Before
After
title: How to configure Global Secure Access web content filtering
description: "Control internet access based on website categories, URLs, and FQDNs. Configure granular, user-aware filtering policies using security profiles and Conditional Access."
ms.topic: how-to
ms.date: 05/29/2026
ms.subservice: entra-internet-access
ai-usage: ai-assisted
---
 
# How to configure Global Secure Access web content filtering
 
## Overview
 
Web content filtering empowers you to implement granular Internet access controls for your organization based on website categorization.
 
 
 
 
 
title: How to configure Global Secure Access web content filtering
description: "Control internet access based on website categories, URLs, and FQDNs. Configure granular, user-aware filtering policies using security profiles and Conditional Access."
ms.topic: how-to
ms.date: 06/01/2026
ms.subservice: entra-internet-access
ai-usage: ai-assisted
---
 
# How to configure Global Secure Access web content filtering
 
<!-- TEMPORARY NOTICE: Remove this IMPORTANT alert after the erroneous "Deprecating soon" label on Web Content Filtering Policy (V1) is fixed in the Microsoft Entra admin center. Tracking with PM Michael Aldridge / engineering. -->
 
> [!IMPORTANT]
> You might see a red **Deprecating soon** label next to **Web Content Filtering Policy (V1)** in the Microsoft Entra admin center. This label is displayed in error. Your existing web content filtering policies aren't affected, continue to work as configured, and no action is required at this time. This article is updated when the display issue is resolved.
 
## Overview
 
Web content filtering empowers you to implement granular Internet access controls for your organization based on website categorization.
+2 / -2 lines changed
Commit: Remove private_key_jwt references from OIDC federation docs
Changes:
Before
After
> [!NOTE]
> To federate with a Microsoft Entra ID tenant, see [Add a Microsoft Entra ID tenant as an OpenID Connect identity provider](how-to-entra-id-federation-customers.md). OIDC federation also isn't compatible with the [Invite external user (preview)](/entra/external-id/customers/concept-supported-features-customers#identity-providers-and-authentication-methods) feature.
 
- **Client ID** and **Client Secret** are the identifiers your identity provider uses to identify the registered application service. Provide a client secret if you select `client_secret` authentication. If you select `private_key_jwt`, the public key needs to be provided in the OpenID provider metadata (well-known endpoint), retrievable via the property `jwks_uri`.
- **Client Authentication** is the type of client authentication method to be used to authenticate with your identity provider using the token endpoint. `client_secret_post`, `client_secret_jwt`, and `private_key_jwt` authentication methods are supported.
 
> [!NOTE]
> Due to possible security problems, the `client_secret_basic` client authentication method isn't supported.
> [!NOTE]
> To federate with a Microsoft Entra ID tenant, see [Add a Microsoft Entra ID tenant as an OpenID Connect identity provider](how-to-entra-id-federation-customers.md). OIDC federation also isn't compatible with the [Invite external user (preview)](/entra/external-id/customers/concept-supported-features-customers#identity-providers-and-authentication-methods) feature.
 
- **Client ID** and **Client Secret** are the identifiers your identity provider uses to identify the registered application service. Provide a client secret when you select a `client_secret`-based authentication method.
- **Client Authentication** is the type of client authentication method to be used to authenticate with your identity provider using the token endpoint. `client_secret_post` and `client_secret_jwt` authentication methods are supported. Although the admin center UI might display `private_key_jwt` as an option, this method isn't currently supported and shouldn't be selected.
 
> [!NOTE]
> Due to possible security problems, the `client_secret_basic` client authentication method isn't supported.
Modified by Janice Ricketts on Jun 1, 2026 2:06 PM
📖 View on learn.microsoft.com
+2 / -2 lines changed
Commit: Update links to Private Access Sizing Planner
Changes:
Before
After
 
| Check | Role | Automated by | Procedure | What to do if it fails |
| --- | --- | --- | --- | --- |
| Connector resource utilization trend | Network Ops L2 | Azure Monitor alert ([Playbook 5](#playbook-5-connector-group-capacity-alert)) | Review the week's alert history for sustained trends, not isolated spikes. | If any host trends above 70% CPU or 80% memory, plan to add a connector. Use the [Private Access Sizing Planner](https://github.com/FranckhDev/GSA-Private-Access-Sizing-Planner). |
| Policy efficacy digest | IAM Admin | [Playbook 9: Weekly policy-efficacy digest](#playbook-9-weekly-policy-efficacy-digest) (email) | Review the weekly digest of top denied apps/users. | Adjust policies for persistent false positives. Investigate repeated unauthorized access attempts. |
| Configuration backup compliance | Network Ops L2 | [Playbook 3](#playbook-3-weekly-configuration-backup) + `Test-GsaBackupCompliance.ps1` | Backup compliance script runs after Playbook 3 and alerts if files are missing or stale. | Troubleshoot the runbook or script. Manually export via Graph API as a fallback. |
| Alert noise ratio | SOC | `Test-GsaAlertNoiseRatio.ps1` scheduled weekly | Script reports analytic-rule-to-incident ratio per Private Access rule. | Tune high-noise rules. Close the loop with Sentinel tuning recommendations. |
<!-- Configure the CPU and memory thresholds in Azure Monitor metric alerts on each connector host virtual machine (VM) as described in [Playbook 5: Connector group capacity alert](#playbook-5-connector-group-capacity-alert); use the Sentinel integration in this guide for log collection, incident correlation, and workflow automation, not for the host metric thresholds themselves. -->
 
> [!TIP]
> Connector sizing depends on the host server specifications and workload. Use the [Private Access Sizing Planner](https://github.com/FranckhDev/GSA-Private-Access-Sizing-Planner) to estimate connector requirements based on your user counts and application patterns. For general connector architecture guidance, see [Understand the Microsoft Entra private network connector](/entra/global-secure-access/concept-connectors). As a starting point, a 4-vCPU / 16-GB RAM server can handle approximately 200–300 concurrent connections, but always validate with your own workload.
 
## Integration and automation
 
 
| Check | Role | Automated by | Procedure | What to do if it fails |
| --- | --- | --- | --- | --- |
| Connector resource utilization trend | Network Ops L2 | Azure Monitor alert ([Playbook 5](#playbook-5-connector-group-capacity-alert)) | Review the week's alert history for sustained trends, not isolated spikes. | If any host trends above 70% CPU or 80% memory, plan to add a connector. Use the [Private Access Sizing Planner](https://aka.ms/gsaPAPlanner). |
| Policy efficacy digest | IAM Admin | [Playbook 9: Weekly policy-efficacy digest](#playbook-9-weekly-policy-efficacy-digest) (email) | Review the weekly digest of top denied apps/users. | Adjust policies for persistent false positives. Investigate repeated unauthorized access attempts. |
| Configuration backup compliance | Network Ops L2 | [Playbook 3](#playbook-3-weekly-configuration-backup) + `Test-GsaBackupCompliance.ps1` | Backup compliance script runs after Playbook 3 and alerts if files are missing or stale. | Troubleshoot the runbook or script. Manually export via Graph API as a fallback. |
| Alert noise ratio | SOC | `Test-GsaAlertNoiseRatio.ps1` scheduled weekly | Script reports analytic-rule-to-incident ratio per Private Access rule. | Tune high-noise rules. Close the loop with Sentinel tuning recommendations. |
<!-- Configure the CPU and memory thresholds in Azure Monitor metric alerts on each connector host virtual machine (VM) as described in [Playbook 5: Connector group capacity alert](#playbook-5-connector-group-capacity-alert); use the Sentinel integration in this guide for log collection, incident correlation, and workflow automation, not for the host metric thresholds themselves. -->
 
> [!TIP]
> Connector sizing depends on the host server specifications and workload. Use the [Private Access Sizing Planner](https://aka.ms/gsaPAPlanner) to estimate connector requirements based on your user counts and application patterns. For general connector architecture guidance, see [Understand the Microsoft Entra private network connector](/entra/global-secure-access/concept-connectors). As a starting point, a 4-vCPU / 16-GB RAM server can handle approximately 200–300 concurrent connections, but always validate with your own workload.
 
## Integration and automation
 
+4 / -0 lines changed
Commit: Update howto-sspr-authenticationdata.md (#13242)
Changes:
Before
After
 
Some organizations prefer to bootstrap this process through synchronization of authentication data that already exists in Active Directory Domain Services. This synchronized data is made available to Microsoft Entra ID 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 prepopulate authentication contact information if you meet the following requirements:
 
* You formatted the data in your on-premises directory properly.
 
 
 
 
 
Some organizations prefer to bootstrap this process through synchronization of authentication data that already exists in Active Directory Domain Services. This synchronized data is made available to Microsoft Entra ID 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.
 
> [!IMPORTANT]
> Starting **July 6, 2026**, a registration campaign will prompt affected users to register methods ahead of enforcement. Ensure users have registered at least one method that satisfies your SSPR policy. For more information, see [How to manage authentication methods](how-to-authentication-methods-manage.md).
> Starting **September 7, 2026**, SSPR will only accept explicitly registered authentication methods. Directory-sourced properties — such as `mobilePhone`, `businessPhone`, and `otherMails` — that were never registered will no longer work for SSPR verification.
 
You can prepopulate authentication contact information if you meet the following requirements:
 
* You formatted the data in your on-premises directory properly.
Modified by Justinha on Jun 1, 2026 7:24 PM
📖 View on learn.microsoft.com
+1 / -1 lines changed
Commit: Add hybrid joined devices to supported soft delete types
Changes:
Before
After
During the preview, device soft delete is supported for the following device types:
 
- **Microsoft Entra joined devices** &mdash; Enterprise-managed devices directly joined to Microsoft Entra ID.
- **Microsoft Entra registered devices** &mdash; Personal or BYOD devices registered with a work or school account.
 
The following device types aren't currently supported for soft delete and are hard deleted immediately when removed:
 
- Microsoft Entra hybrid joined devices <!-- TODO: Confirm whether hybrid-joined device soft delete support is available at public preview. -->
- Devices without a recognized trust type, such as those created directly via Microsoft Graph API
- Certain specialty device types, including secure VMs with managed identities, non-persistent VDI instances, and printers
 
During the preview, device soft delete is supported for the following device types:
 
- **Microsoft Entra joined devices** &mdash; Enterprise-managed devices directly joined to Microsoft Entra ID.
- **Microsoft Entra hybrid joined devices** &mdash; Enterprise-managed devices joined to your on-premises Active Directory domain and registered with Microsoft Entra ID.
- **Microsoft Entra registered devices** &mdash; Personal or BYOD devices registered with a work or school account.
 
The following device types aren't currently supported for soft delete and are hard deleted immediately when removed:
 
- Devices without a recognized trust type, such as those created directly via Microsoft Graph API
- Certain specialty device types, including secure VMs with managed identities, non-persistent VDI instances, and printers
 
+1 / -1 lines changed
Commit: Date update
Changes:
Before
After
ms.service: entra-id
ms.subservice: conditional-access
ms.topic: concept-article
ms.date: 03/24/2026
ms.reviewer: kvenkit
ms.custom: sfi-image-nochange
ai-usage: ai-assisted
ms.service: entra-id
ms.subservice: conditional-access
ms.topic: concept-article
ms.date: 06/01/2026
ms.reviewer: kvenkit
ms.custom: sfi-image-nochange
ai-usage: ai-assisted
+1 / -1 lines changed
Commit: Date update
Changes:
Before
After
title: Plan Your Microsoft Entra Conditional Access Deployment
description: Plan your Conditional Access policies to balance security and productivity. Learn how to design and deploy effective policies for your organization.
ms.topic: how-to
ms.date: 03/24/2026
manager: martinco
ms.reviewer: joflore
ms.custom:
title: Plan Your Microsoft Entra Conditional Access Deployment
description: Plan your Conditional Access policies to balance security and productivity. Learn how to design and deploy effective policies for your organization.
ms.topic: how-to
ms.date: 06/01/2026
manager: martinco
ms.reviewer: joflore
ms.custom:
+1 / -1 lines changed
Commit: Date update
Changes:
Before
After
title: Best practices for Microsoft Entra roles
description: Best practices for using Microsoft Entra roles.
ms.topic: best-practice
ms.date: 03/30/2025
ms.reviewer: vincesm
ms.custom: it-pro, sfi-ga-nochange, sfi-image-nochange
ai-usage: ai-assisted
title: Best practices for Microsoft Entra roles
description: Best practices for using Microsoft Entra roles.
ms.topic: best-practice
ms.date: 06/01/2026
ms.reviewer: vincesm
ms.custom: it-pro, sfi-ga-nochange, sfi-image-nochange
ai-usage: ai-assisted
+1 / -1 lines changed
Commit: Date update
Changes:
Before
After
title: Overview of Microsoft Entra role-based access control (RBAC)
description: Learn how to understand the parts of a role assignment and restricted scope in Microsoft Entra ID.
ms.topic: overview
ms.date: 03/30/2025
ms.reviewer: abhijeetsinha
ms.custom: it-pro, has-azure-ad-ps-ref, azure-ad-ref-level-one-done, sfi-image-nochange
ai-usage: ai-assisted
title: Overview of Microsoft Entra role-based access control (RBAC)
description: Learn how to understand the parts of a role assignment and restricted scope in Microsoft Entra ID.
ms.topic: overview
ms.date: 06/01/2026
ms.reviewer: abhijeetsinha
ms.custom: it-pro, has-azure-ad-ps-ref, azure-ad-ref-level-one-done, sfi-image-nochange
ai-usage: ai-assisted
Modified by Vimala Ranganathan on Jun 1, 2026 2:53 PM
📖 View on learn.microsoft.com
+1 / -1 lines changed
Commit: Remove (Preview) tag from Entra ID federation article
Changes:
Before
After
 
#customer intent: As a developer, DevOps, or IT administrator, I want to learn how to add a Microsoft Entra ID tenant as an OpenID Connect identity provider in my external tenant.
---
# Add a Microsoft Entra ID tenant as an OpenID Connect identity provider (Preview)
 
[!INCLUDE [applies-to-external-only](../includes/applies-to-external-only.md)]
 
 
#customer intent: As a developer, DevOps, or IT administrator, I want to learn how to add a Microsoft Entra ID tenant as an OpenID Connect identity provider in my external tenant.
---
# Add a Microsoft Entra ID tenant as an OpenID Connect identity provider
 
[!INCLUDE [applies-to-external-only](../includes/applies-to-external-only.md)]