πŸ“‹ Microsoft Entra Documentation Changes

Daily summary for changes since August 18th 2025, 8:13 PM PDT

Report generated on August 19th 2025, 8:13 PM PDT

πŸ“Š Summary

34
Total Commits
0
New Files
10
Modified Files
1
Deleted Files
17
Contributors

πŸ“ Modified Documentation Files

Modified by barclayn on Aug 19, 2025 10:19 AM
πŸ“– View on learn.microsoft.com
+19 / -19 lines changed
Commit: updating alt text
Changes:
Before
After
 
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/#view/Microsoft_AAD_IAM/GroupsManagementMenuBlade) and in the left-hand navigation pane, select theβ€―**Groups**β€―tab and then **All groups**.
 
:::image type="content" source="Media/bulk-operations/groups-management-page.png" alt-text="Screenshot of the Microsoft Entra ID Groups management page showing the all groups view.":::
 
2. Select **Download groups**.
 
:::image type="content" source="Media/bulk-operations/download-groups-button.png" alt-text="Screenshot of the Download groups button in the Microsoft Entra ID Groups interface.":::
 
3. Enter a filename and select **Start bulk operation**.
 
:::image type="content" source="Media/bulk-operations/download-filename-dialog.png" alt-text="Screenshot of the download filename dialog box for bulk groups download.":::
 
4. Select the **Click here to view the status of each operation** link to navigate to the **Bulk operations** blade.
 
:::image type="content" source="Media/bulk-operations/success-notification.png" alt-text="Screenshot of the success notification message for bulk groups download operation.":::
 
5. Select the filename to download the CSV file containing all groups with the specified columns.
 
 
 
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/#view/Microsoft_AAD_IAM/GroupsManagementMenuBlade) and in the left-hand navigation pane, select theβ€―**Groups**β€―tab and then **All groups**.
 
:::image type="content" source="Media/bulk-operations/groups-management-page.png" alt-text="Screenshot of the Microsoft Entra admin center Groups blade showing the All groups list with column headers and actions.":::
 
2. Select **Download groups**.
 
:::image type="content" source="Media/bulk-operations/download-groups-button.png" alt-text="Screenshot of the Groups page with the Download groups button highlighted in the toolbar.":::
 
3. Enter a filename and select **Start bulk operation**.
 
:::image type="content" source="Media/bulk-operations/download-filename-dialog.png" alt-text="Screenshot of the Download groups dialog prompting for a filename before starting the bulk operation.":::
 
4. Select the **Click here to view the status of each operation** link to navigate to the **Bulk operations** blade.
 
:::image type="content" source="Media/bulk-operations/success-notification.png" alt-text="Screenshot of a success notification confirming the bulk groups download was submitted with a link to view status.":::
 
5. Select the filename to download the CSV file containing all groups with the specified columns.
 
 
+14 / -14 lines changed
Commit: minor Acrolinx edits to improve score
Changes:
Before
After
Microsoft Entra pass-through authentication allows your users to sign in to both on-premises and cloud-based applications by using the same passwords. Pass-through Authentication signs users in by validating their passwords directly against on-premises Active Directory.
 
>[!IMPORTANT]
>If you are migrating from AD FS (or other federation technologies) to Pass-through Authentication, view [Resources for migrating applications to Microsoft Entra ID](~/identity/enterprise-apps/migration-resources.md).
>[!NOTE]
>If you deploying Pass Through Authentication with the Azure Government cloud, view [Hybrid Identity Considerations for Azure Government](./reference-connect-government-cloud.md).
 
Follow these instructions to deploy Pass-through Authentication on your tenant:
 
Ensure that the following prerequisites are in place.
 
>[!IMPORTANT]
>From a security standpoint, administrators should treat the server running the PTA agent as if it were a domain controller. The PTA agent servers should be hardened along the same lines as outlined in [Securing Domain Controllers Against Attack](/windows-server/identity/ad-ds/plan/security-best-practices/securing-domain-controllers-against-attack)
 
<a name='in-the-entra-admin-center'></a>
 
 
### In your on-premises environment
 
1. Identify a server running Windows Server 2016 or later to run Microsoft Entra Connect. If not enabled already, [enable TLS 1.2 on the server](./how-to-connect-install-prerequisites.md#enable-tls-12-for-azure-ad-connect). Add the server to the same Active Directory forest as the users whose passwords you need to validate. It should be noted that installation of Pass-Through Authentication agent on Windows Server Core versions is not supported.
Microsoft Entra pass-through authentication allows your users to sign in to both on-premises and cloud-based applications by using the same passwords. Pass-through Authentication signs users in by validating their passwords directly against on-premises Active Directory.
 
>[!IMPORTANT]
>If you're migrating from AD FS (or other federation technologies) to Pass-through Authentication, view [Resources for migrating applications to Microsoft Entra ID](~/identity/enterprise-apps/migration-resources.md).
>[!NOTE]
>If you're deploying Pass Through Authentication with the Azure Government cloud, view [Hybrid Identity Considerations for Azure Government](./reference-connect-government-cloud.md).
 
Follow these instructions to deploy Pass-through Authentication on your tenant:
 
Ensure that the following prerequisites are in place.
 
>[!IMPORTANT]
>From a security standpoint, administrators should treat the server running the PTA agent as if it were a domain controller. The PTA agent servers should be hardened along the same lines as outlined in [Securing Domain Controllers Against Attack](/windows-server/identity/ad-ds/plan/security-best-practices/securing-domain-controllers-against-attack)
 
<a name='in-the-entra-admin-center'></a>
 
 
### In your on-premises environment
 
1. Identify a server running Windows Server 2016 or later to run Microsoft Entra Connect. If not enabled already, [enable TLS 1.2 on the server](./how-to-connect-install-prerequisites.md#enable-tls-12-for-azure-ad-connect). Add the server to the same Active Directory forest as the users whose passwords you need to validate. It should be noted that installation of Pass-Through Authentication agent on Windows Server Core versions isn't supported.
Modified by Sumeet Mittal on Aug 19, 2025 4:25 PM
πŸ“– View on learn.microsoft.com
+6 / -8 lines changed
Commit: Update how-to-enable-multi-geo.md
Changes:
Before
After
:::image type="content" source="media/how-to-enable-multi-geo/multi-geo-support-diagram.svg" alt-text="Diagram that illustrates how Multi-Geo support routes traffic with Microsoft Entra private network connectors.":::
 
## Enable multi-Geo capability
To enable the multi-Geo capability for Microsoft Entra Private Access, complete the following steps. This procedure involves creating connector groups in different geographic regions, installing connectors, and adding application segments to the connector groups.
 
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as a [Global Secure Access Administrator](../identity/role-based-access-control/permissions-reference.md#global-secure-access-administrator).
1. Browse to **Applications** > **Enterprise applications** > **Private Network connectors**.
1. Create two connector groups, each associated with a different geographic region.
1. Select **+ New Connector Group**.
1. In the **New Connector Group** pane, enter a name for the connector group.
1. Under Advanced settings, select the optimized **country/region** for the connector group. The region you select determines the backend that the connector group connects to.
1. Repeat steps **a** - **c** for the second connector group.
1. Install a connector in each region. These connector installations require working with an admin in the associated region. For more information, see [How to configure private network connectors for Microsoft Entra Private Access and Microsoft Entra application proxy](how-to-configure-connectors.md).
1. Add an application segment to each of the connector groups.
1. Browse to **Global Secure Access** > **Applications** > **Enterprise applications** > **Network access properties**.
1. Select **+ Add application segment**.
1. Select the application segment you want to add to the connector group.
1. Select **Save**.
1. Repeat steps **a** - **d** for the second connector group.
1. After about 30 minutes, the multi-Geo configuration takes effect and traffic begins flowing.
:::image type="content" source="media/how-to-enable-multi-geo/multi-geo-support-diagram.svg" alt-text="Diagram that illustrates how Multi-Geo support routes traffic with Microsoft Entra private network connectors.":::
 
## Enable multi-Geo capability
To enable the multi-Geo capability for Microsoft Entra Private Access, complete the following steps. This procedure involves creating connector group in different geographic region, installing connectors, and adding application segments to the connector group.
 
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as a [Global Secure Access Administrator](../identity/role-based-access-control/permissions-reference.md#global-secure-access-administrator).
1. Browse to **Applications** > **Enterprise applications** > **Private Network connectors**.
1. Create a connector group, associate it with a geographic region of your choice.
1. Select **+ New Connector Group**.
1. In the **New Connector Group** pane, enter a name for the connector group.
1. Under Advanced settings, select the optimized **country/region** for the connector group. The region you select determines the backend that the connector group connects to.
1. Install a connector. The connector installation require working with an admin in the associated region. For more information, see [How to configure private network connectors for Microsoft Entra Private Access and Microsoft Entra application proxy](how-to-configure-connectors.md).
1. Add an application segment to the connector group.
1. Browse to **Global Secure Access** > **Applications** > **Enterprise applications** > **Network access properties**.
1. Select **+ Add application segment**.
1. Select the application segment you want to add to the connector group.
1. Select **Save**.
1. After about 30 minutes, the multi-Geo configuration takes effect and traffic begins flowing.
 
> [!NOTE]
+13 / -0 lines changed
Commit: Update entitlement-management-access-package-approval-policy.md
Changes:
Before
After
 
After you configure requestor information in your access package's policy, can view the requestor's responses to the questions. For guidance on seeing requestor information, see [View requestor's answers to questions](entitlement-management-request-approve.md#view-requestors-answers-to-questions).
 
## Next steps
 
- [Change lifecycle settings for an access package](entitlement-management-access-package-lifecycle-policy.md)
 
 
 
 
 
 
 
 
 
 
 
 
 
 
After you configure requestor information in your access package's policy, can view the requestor's responses to the questions. For guidance on seeing requestor information, see [View requestor's answers to questions](entitlement-management-request-approve.md#view-requestors-answers-to-questions).
 
## Configure whether requestors can see approver details (preview)
 
You can control whether requestors see approver details for pending access package requests in the My Access portal. You can set this at the access package level or at the tenant level (default for all packages). The access package setting overrides the tenant setting when explicitly set to Yes or No.
 
1. When creating a new access package or editing a policy for an existing access package, under **Approval** expand **Advanced request settings**.
 
1. Set Show approver details on pending access package requests (preview) to one of the following:
- Yes – All users in scope of this access package will see the approver’s name and email address on their pending requests in My Access.
- No – Users won’t see any approver information for this access package.
- Default – Inherit the tenant-level setting.
 
[!IMPORTANT] If the access package setting is set to Yes or No, it overrides the tenant-level setting. If it’s set to Default, it respects the tenant-level setting.
 
## Next steps
 
- [Change lifecycle settings for an access package](entitlement-management-access-package-lifecycle-policy.md)
Modified by myra-ramdenbourg on Aug 19, 2025 7:03 PM
πŸ“– View on learn.microsoft.com
+12 / -0 lines changed
Commit: Update entitlement-management-request-access.md
Changes:
Before
After
 
1. Select **Request history** to confirm the request was canceled.
 
## Next steps
 
- [Approve or deny access requests](entitlement-management-request-approve.md)
 
 
 
 
 
 
 
 
 
 
 
 
 
1. Select **Request history** to confirm the request was canceled.
 
## View approver information for pending requests
 
If the access package is configured to display approver details, you can view who your approver is for any pending requests.
 
**Prerequisite role:** Requestor
 
1. In the My Access portal, select **Request history** to see a list of your requests and the status.
 
1. Select the **View** link for the request that is pending approval.
 
1. In the request details pane, select **Details** under pending approval. The approver information will be displayed if the access package policy allows it.
 
## Next steps
 
- [Approve or deny access requests](entitlement-management-request-approve.md)
+2 / -7 lines changed
Commit: updates
Changes:
Before
After
ms.service: entra-id
ms.subservice: managed-identities
ms.topic: reference
ms.date: 07/29/2025
---
 
# Managed identities glossary
**Azure Instance Metadata Service (IMDS)**
: A REST endpoint available to all VMs created through Azure Resource Manager. IMDS provides access to managed identity tokens without requiring credentials.
 
**Azure Resource Manager (ARM)**
: The deployment and management service for Azure that provides a management layer for creating, updating, and deleting resources.
 
## B
 
**Blast Radius**
: The scope of impact when a security incident or misconfiguration occurs. Regional isolation helps reduce the blast radius by limiting managed identity usage to a single region.
 
## C
 
ms.service: entra-id
ms.subservice: managed-identities
ms.topic: reference
ms.date: 08/19/2025
---
 
# Managed identities glossary
**Azure Instance Metadata Service (IMDS)**
: A REST endpoint available to all VMs created through Azure Resource Manager. IMDS provides access to managed identity tokens without requiring credentials.
 
**Azure Resource Manager**
: The deployment and management service for Azure that provides a management layer for creating, updating, and deleting resources.
 
## C
 
**Conditional Access for Workload Identities**
 
 
 
 
+3 / -3 lines changed
Commit: Aug 19 ready to publish
Changes:
Before
After
description: This article tracks the changes in each released version of the Global Secure Access client for macOS.
ms.service: global-secure-access
ms.topic: reference
ms.date: 08/05/2025
ms.author: jayrusso
author: HULKsmashGithub
manager: dougeby
:::image type="content" source="media/reference-macos-client-release-history/macos-client-download-screen.png" alt-text="Screenshot of the Client download screen with the Download Client button highlighted.":::
 
## Version 1.1.25070402
Released for download on August 14, 2025.
### Other changes
- Bug fix: Fixes a compatibility issue with macOS 26.
> [!IMPORTANT]
- Enhanced telemetry for better supportability and monitoring.
- Miscellaneous bug fixes and improvements.
### Known issues
- There's a known compatibility issue with macOS 26 that causes the device to lose connectivity. A new client version compatible with macOS 26 is set to release in August 2025. You need to deploy that version before upgrading to macOS 26.
 
## Version 1.1.25060400
description: This article tracks the changes in each released version of the Global Secure Access client for macOS.
ms.service: global-secure-access
ms.topic: reference
ms.date: 08/19/2025
ms.author: jayrusso
author: HULKsmashGithub
manager: dougeby
:::image type="content" source="media/reference-macos-client-release-history/macos-client-download-screen.png" alt-text="Screenshot of the Client download screen with the Download Client button highlighted.":::
 
## Version 1.1.25070402
Released for download on August 19, 2025.
### Other changes
- Bug fix: Fixes a compatibility issue with macOS 26.
> [!IMPORTANT]
- Enhanced telemetry for better supportability and monitoring.
- Miscellaneous bug fixes and improvements.
### Known issues
- Client version **1.1.25070401** has a known compatibility issue with macOS 26 that causes the device to lose connectivity. To maintain compatibility with macOS 26, upgrade to and deploy client version **1.1.25070402** before upgrading to macOS 26.
 
## Version 1.1.25060400
+2 / -2 lines changed
Commit: updates
Changes:
Before
After
ms.service: entra-id
ms.subservice: managed-identities
ms.topic: overview
ms.date: 07/29/2025
ms.author: shermanouko
ms.reviewer: ryanwi
 
 
At a high level, there are two types of identities: human and machine/non-human identities. Machine / non-human identities consist of device and workload identities. In Microsoft Entra, workload identities are applications, service principals, and managed identities.
 
A managed identity is an identity that can be assigned to an Azure compute resource (Virtual Machine (VM), Virtual Machine Scale Set (VMSS), Service Fabric Cluster, Azure Kubernetes cluster) or any App hosting platform supported by Azure. Once a managed identity is assigned on the compute resource, it can be authorized, directly or indirectly, to access downstream dependency resources, such as a storage account, SQL database, CosmosDB, and so on. Managed identity replaces secrets such as access keys or passwords. In addition, managed identities can replace certificates or other forms of authentication for service-to-service dependencies.
 
The following video shows how you can use managed identities:
 
ms.service: entra-id
ms.subservice: managed-identities
ms.topic: overview
ms.date: 08/19/2025
ms.author: shermanouko
ms.reviewer: ryanwi
 
 
At a high level, there are two types of identities: human and machine/non-human identities. Machine / non-human identities consist of device and workload identities. In Microsoft Entra, workload identities are applications, service principals, and managed identities.
 
A managed identity is an identity that can be assigned to an Azure compute resource (Azure Virtual Machine, Azure Virtual Machine Scale Set, Service Fabric Cluster, Azure Kubernetes cluster) or any App hosting platform supported by Azure. Once a managed identity is assigned on the compute resource, it can be authorized, directly or indirectly, to access downstream dependency resources, such as a storage account, SQL database, Cosmos DB, and so on. Managed identity replaces secrets such as access keys or passwords. In addition, managed identities can replace certificates or other forms of authentication for service-to-service dependencies.
 
The following video shows how you can use managed identities:
 
+1 / -1 lines changed
Commit: leftnavedits4
Changes:
Before
After
To assign a user account to an enterprise application:
 
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Cloud Application Administrator](~/identity/role-based-access-control/permissions-reference.md#cloud-application-administrator).
1. Browse to **Entra ID** > **Enterprise apps** > **All applications**. For example, the application that you created in the previous quickstart named **Microsoft Entra SAML Toolkit 1**.
1. In the left pane, select **Users and groups**, and then select **Add user/group**.
 
:::image type="content" source="media/add-application-portal-assign-users/assign-user.png" alt-text="Assign user account to an application in your Microsoft Entra tenant." lightbox="media/add-application-portal-assign-users/assign-user.png":::
To assign a user account to an enterprise application:
 
1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com) as at least a [Cloud Application Administrator](~/identity/role-based-access-control/permissions-reference.md#cloud-application-administrator).
1. Browse to **Entra ID** > **Enterprise apps**. For example, select the application that you created in the previous quickstart named **Microsoft Entra SAML Toolkit 1**.
1. In the left pane, select **Users and groups**, and then select **Add user/group**.
 
:::image type="content" source="media/add-application-portal-assign-users/assign-user.png" alt-text="Assign user account to an application in your Microsoft Entra tenant." lightbox="media/add-application-portal-assign-users/assign-user.png":::
+1 / -1 lines changed
Commit: Update use-scim-to-provision-users-and-groups.md
Changes:
Before
After
|--|--|--|--|
|Username and password (not recommended or supported by Microsoft Entra ID)|Easy to implement|Insecure - [Your Pa$$word doesn't matter](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/your-pa-word-doesn-t-matter/ba-p/731984)|Not supported for new gallery or non-gallery apps.|
|Long-lived bearer token|Long-lived tokens don't require a user to be present. They're easy for admins to use when setting up provisioning.|Long-lived tokens can be hard to share with an admin without using insecure methods such as email. |Supported for gallery and non-gallery apps. |
|OAuth authorization code grant|Access tokens have a shorter life than passwords, and have an automated refresh mechanism that long-lived bearer tokens don't have. A real user must be present during initial authorization, adding a level of accountability. |Requires a user to be present. If the user leaves the organization, the token is invalid, and authorization needs to be completed again.|Supported for gallery apps, but not non-gallery apps. However, you can provide an access token in the UI as the secret token for short term testing purposes. Support for OAuth code grant on non-gallery is in our backlog, in addition to support for configurable auth / token URLs on the gallery app.|
|OAuth client credentials grant|Access tokens have a shorter life than passwords, and have an automated refresh mechanism that long-lived bearer tokens don't have. Both the authorization code grant and the client credentials grant create the same type of access token, so moving between these methods is transparent to the API. Provisioning can be automated, and new tokens can be silently requested without user interaction. ||Supported for gallery apps, but not non-gallery apps. However, you can provide an access token in the UI as the secret token for short term testing purposes. Support for OAuth client credentials grant on non-gallery is in our backlog.|
 
> [!NOTE]
|--|--|--|--|
|Username and password (not recommended or supported by Microsoft Entra ID)|Easy to implement|Insecure - [Your Pa$$word doesn't matter](https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/your-pa-word-doesn-t-matter/ba-p/731984)|Not supported for new gallery or non-gallery apps.|
|Long-lived bearer token|Long-lived tokens don't require a user to be present. They're easy for admins to use when setting up provisioning.|Long-lived tokens can be hard to share with an admin without using insecure methods such as email. |Supported for gallery and non-gallery apps. |
|OAuth authorization code grant|Access tokens have a shorter life than passwords, and have an automated refresh mechanism that long-lived bearer tokens don't have. A real user must be present during initial authorization, adding a level of accountability. |Requires a user to be present. If the user leaves the organization, the token is invalid, and authorization needs to be completed again.|Supported for gallery apps and non-gallery apps.|
|OAuth client credentials grant|Access tokens have a shorter life than passwords, and have an automated refresh mechanism that long-lived bearer tokens don't have. Both the authorization code grant and the client credentials grant create the same type of access token, so moving between these methods is transparent to the API. Provisioning can be automated, and new tokens can be silently requested without user interaction. ||Supported for gallery apps, but not non-gallery apps. However, you can provide an access token in the UI as the secret token for short term testing purposes. Support for OAuth client credentials grant on non-gallery is in our backlog.|
 
> [!NOTE]

πŸ—‘οΈ Deleted Documentation Files

DELETED docs/fundamentals/scenario-azure-first-sap-identity-integration.md
Deleted by John Flores on Aug 19, 2025 5:49 PM
πŸ“– Was available at: https://learn.microsoft.com/en-us/entra/fundamentals/scenario-azure-first-sap-identity-integration
-264 lines removed
Commit: [SAP] Move article to SAP directory in azure-docs-pr