📋 Microsoft Entra Documentation Changes

Daily summary for changes since September 8th 2025, 8:00 PM PDT

Report generated on September 9th 2025, 8:00 PM PDT

📊 Summary

24
Total Commits
0
New Files
4
Modified Files
0
Deleted Files
9
Contributors

📝 Modified Documentation Files

+26 / -17 lines changed
Commit: Sep 09 finalized content per PM feedback. Ready to publish.
Changes:
Before
After
manager: dougeby
ms.service: global-secure-access
ms.topic: sample
ms.date: 09/08/2025
ms.reviewer: teresayao
 
#customer intent: As an admin, I want to automate the creation of TLS certificates using PowerShell so that I can streamline my testing process.
- Install OpenSSL for Windows or Linux.
 
> [!NOTE]
> While other tools might be available for certificate management, this sample code uses OpenSSL. OpenSSL is bundled with many Linux distributions, such as Ubuntu.
 
## Generate and sign TLS certificates
 
#
# Before you begin:
#
# - Make sure you are running PowerShell as an administrator
# - Make sure you run: Install-Module Microsoft.Graph.Beta -AllowClobber -Force
# Ensure Microsoft.Graph.Beta module is available
manager: dougeby
ms.service: global-secure-access
ms.topic: sample
ms.date: 09/09/2025
ms.reviewer: teresayao
 
#customer intent: As an admin, I want to automate the creation of TLS certificates using PowerShell so that I can streamline my testing process.
- Install OpenSSL for Windows or Linux.
 
> [!NOTE]
> While other tools might be available for certificate management, this sample code in this article uses OpenSSL. OpenSSL is bundled with many Linux distributions, such as Ubuntu.
 
## Generate and sign TLS certificates
 
#
# Before you begin:
#
# - Make sure you're running PowerShell as an administrator
# - Make sure you run: Install-Module Microsoft.Graph.Beta -AllowClobber -Force
# Ensure Microsoft.Graph.Beta module is available
Modified by Ortagus Winfrey on Sep 9, 2025 12:56 PM
📖 View on learn.microsoft.com
+6 / -6 lines changed
Commit: Updates
Changes:
Before
After
 
## How entitlement management can help
 
When using the [Microsoft Entra B2B](~/external-id/what-is-b2b.md) invite experience, you must already know the email addresses of the external guest users you want to bring into your resource directory and work with. Directly inviting each user works great when you're working on a smaller or short-term project and you already know all the participants, but this process is harder to manage if you have lots of users you want to work with, or if the participants change over time. For example, you might be working with another organization and have one point of contact with that organization, but over time more users from that organization will also need access.
 
With entitlement management, you can define a policy that allows users from organizations you specify to be able to self-request an access package. That policy includes whether approval is required, whether access reviews are required, and an expiration date for the access. In most cases, you want to require approval, in order to have appropriate oversight over which users are brought into your directory. If approval is required, then for major external organization partners, you might consider inviting one or more users from the external organization to your directory, designating them as sponsors, and configuring that sponsors are approvers - since they're likely to know which external users from their organization need access. Once you've configured the access package, obtain the access package's request link so you can send that link to your contact person (sponsor) at the external organization. That contact can share with other users in their external organization, and they can use this link to request the access package. Users from that organization who are already invited into your directory can also use that link.
 
 
- Make sure to exclude the Entitlement Management app from any Conditional Access policies that impact guest users. Otherwise, a Conditional Access policy could block them from accessing MyAccess or being able to sign in to your directory. For example, guests likely don't have a registered device, aren't in a known location, and don't want to re-register for multifactor authentication (MFA), so adding these requirements in a Conditional Access policy will block guests from using entitlement management. For more information, see [What are conditions in Microsoft Entra Conditional Access?](~/identity/conditional-access/concept-conditional-access-conditions.md).
 
- If the Conditional Access is blocking all cloud applications, in addition to excluding the Entitlement Management App, ensure that the *Request Approvals Read Platform* is also excluded in your Conditional Access policy. Start by confirming that you have the necessary roles: Conditional Access Administrator, Application Administrator, Attribute Assignment Administrator, and Attribute Definition Administrator. Then, create a custom security attribute with a suitable name and values. Locate the service principal for *Request Approvals Read Platform* in Enterprise Applications, and assign the custom attribute with the chosen value to this application. In your Conditional Access policy, apply a filter to exclude selected applications based on the custom attribute name and value assigned to *Request Approvals Read Platform*. For more details on filtering applications in Conditional Access policies, refer to : [Conditional Access: Filter for applications](../identity/conditional-access/concept-filter-for-applications.md)
 
:::image type="content" source="media/entitlement-management-external-users/exclude-app-guests.png" alt-text="Screenshot of exclude app options.":::
 
1. Browse to **ID Governance** > **Entitlement management** > **Control Configurations**.
 
1. Select **View settings** on the Lifecycle of external users setting card.
:::image type="content" source="media/entitlement-management-external-users/settings-external-users.png" alt-text="Screenshot of external settings for id governance.":::
 
1. On the settings page you will see a list of actions to take for external users onboarded via an access package once their last access package assignment expires. This includes options to **Remove external user**, **Block external user from signing in to directory**, and **Number of days before removing external user from directory**.
 
## How entitlement management can help
 
When using the [Microsoft Entra B2B](~/external-id/what-is-b2b.md) invite experience, you must already know the email addresses of the external guest users you want to bring into your resource directory and work with. Directly inviting each user works great when you're working on a smaller or short-term project and you already know all the participants. This process is harder to manage if you have lots of users you want to work with, or if the participants change over time. For example, you might be working with another organization and have one point of contact with that organization, but over time more users from that organization will also need access.
 
With entitlement management, you can define a policy that allows users from organizations you specify to be able to self-request an access package. That policy includes whether approval is required, whether access reviews are required, and an expiration date for the access. In most cases, you want to require approval, in order to have appropriate oversight over which users are brought into your directory. If approval is required, then for major external organization partners, you might consider inviting one or more users from the external organization to your directory, designating them as sponsors, and configuring that sponsors are approvers - since they're likely to know which external users from their organization need access. Once you've configured the access package, obtain the access package's request link so you can send that link to your contact person (sponsor) at the external organization. That contact can share with other users in their external organization, and they can use this link to request the access package. Users from that organization who are already invited into your directory can also use that link.
 
 
- Make sure to exclude the Entitlement Management app from any Conditional Access policies that impact guest users. Otherwise, a Conditional Access policy could block them from accessing MyAccess or being able to sign in to your directory. For example, guests likely don't have a registered device, aren't in a known location, and don't want to re-register for multifactor authentication (MFA), so adding these requirements in a Conditional Access policy will block guests from using entitlement management. For more information, see [What are conditions in Microsoft Entra Conditional Access?](~/identity/conditional-access/concept-conditional-access-conditions.md).
 
- If the Conditional Access is blocking all cloud applications, in addition to excluding the Entitlement Management App, ensure that the *Request Approvals Read Platform* is also excluded in your Conditional Access policy. Start by confirming that you have the necessary roles: Conditional Access Administrator, Application Administrator, Attribute Assignment Administrator, and Attribute Definition Administrator. Then, create a custom security attribute with a suitable name and values. Locate the service principal for *Request Approvals Read Platform* in Enterprise Applications, and assign the custom attribute with the chosen value to this application. In your Conditional Access policy, apply a filter to exclude selected applications based on the custom attribute name and value assigned to *Request Approvals Read Platform*. For more details on filtering applications in Conditional Access policies, refer to: [Conditional Access: Filter for applications](../identity/conditional-access/concept-filter-for-applications.md)
 
:::image type="content" source="media/entitlement-management-external-users/exclude-app-guests.png" alt-text="Screenshot of exclude app options.":::
 
1. Browse to **ID Governance** > **Entitlement management** > **Control Configurations**.
 
1. Select **View settings** on the Lifecycle of external users setting card.
:::image type="content" source="media/entitlement-management-external-users/settings-external-users.png" alt-text="Screenshot of external settings for ID governance.":::
 
1. On the settings page, you'll see a list of actions to take for external users onboarded via an access package once their last access package assignment expires. This includes options to **Remove external user**, **Block external user from signing in to directory**, and **Number of days before removing external user from directory**.
Modified by Philippe Signoret on Sep 9, 2025 8:38 PM
📖 View on learn.microsoft.com
+7 / -2 lines changed
Commit: Clarify that ignoring the port is only for localhost
Changes:
Before
After
1. `http` URI schemes are acceptable because the redirect never leaves the device. As such, both of these URIs are acceptable:
- `http://localhost/myApp`
- `https://localhost/myApp`
1. Due to ephemeral port ranges often required by native applications, the port component (for example, `:5001` or `:443`) is ignored for the purposes of matching a redirect URI. As a result, all of these URIs are considered equivalent:
- `http://localhost/MyApp`
- `http://localhost:1234/MyApp`
- `http://localhost:5000/MyApp`
- `http://localhost:8080/MyApp`
 
From a development standpoint, this means a few things:
 
* Do not register multiple redirect URIs where only the port differs. The login server picks one arbitrarily and uses the behavior associated with that redirect URI (for example, whether it's a `web`-, `native`-, or `spa`-type redirect).
 
This is especially important when you want to use different authentication flows in the same application registration, for example both the authorization code grant and implicit flow. To associate the correct response behavior with each redirect URI, the login server must be able to distinguish between the redirect URIs and can't do so when only the port differs.
* To register multiple redirect URIs on localhost to test different flows during development, differentiate them using the *path* component of the URI. For example, `http://localhost/MyWebApp` doesn't match `http://localhost/MyNativeApp`.
* The IPv6 loopback address (`[::1]`) isn't currently supported.
 
#### Prefer 127.0.0.1 over localhost
 
 
1. `http` URI schemes are acceptable because the redirect never leaves the device. As such, both of these URIs are acceptable:
- `http://localhost/myApp`
- `https://localhost/myApp`
 
1. Due to ephemeral port ranges often required by native applications, the port component (for example, `:5001` or `:443`) is ignored for the purposes of matching a localhost redirect URI. As a result, all of these URIs are considered equivalent:
- `http://localhost/MyApp`
- `http://localhost:1234/MyApp`
- `http://localhost:5000/MyApp`
- `http://localhost:8080/MyApp`
 
This is *only* true for localhost redirect URIs. In all other cases, the port component is *not* ignored when matching redirect URIs.
 
From a development standpoint, this means a few things:
 
* Do not register multiple localhost redirect URIs where only the port differs. The login server picks one arbitrarily and uses the behavior associated with that registered redirect URI (for example, whether it's a `web`-, `native`-, or `spa`-type redirect).
 
This is especially important when you want to use different authentication flows in the same application registration, for example both the authorization code grant and implicit flow. To associate the correct response behavior with each redirect URI, the login server must be able to distinguish between the redirect URIs and can't do so when only the port differs.
 
* To register multiple redirect URIs on localhost to test different flows during development, differentiate them using the *path* component of the URI. For example, `http://localhost/MyWebApp` doesn't match `http://localhost/MyNativeApp`.
 
+4 / -4 lines changed
Commit: Sep 09 finalized content per PM feedback. Ready to publish.
Changes:
Before
After
manager: dougeby
ms.service: global-secure-access
ms.topic: sample
ms.date: 09/08/2025
ms.reviewer: teresayao
 
#customer intent: As an admin, I want to automate the creation of TLS certificates using PowerShell so that I can streamline my testing process.
#
# Before you begin:
#
# - Make sure you are running PowerShell as an administrator
# - Make sure you run: Install-Module Microsoft.Graph.Beta -AllowClobber -Force
# - Make sure you have ADCS configured with a SubCA template and you have "<CAHostName>\<CACommonName>"
# Ensure Microsoft.Graph.Beta module is available
#ADCS settings
# Make sure you have ADCS configured with a SubCA template and you have "<CAHostName>\<CACommonName>"
$Template = "SubCA"
$CAConfig="enter <CACommonName> of your ADCS server"
 
# Check if the External Certificate Authority Certificates already exists
manager: dougeby
ms.service: global-secure-access
ms.topic: sample
ms.date: 09/09/2025
ms.reviewer: teresayao
 
#customer intent: As an admin, I want to automate the creation of TLS certificates using PowerShell so that I can streamline my testing process.
#
# Before you begin:
#
# - Make sure you're running PowerShell as an administrator
# - Make sure you run: Install-Module Microsoft.Graph.Beta -AllowClobber -Force
# - Make sure you have ADCS configured with a SubCA template and you have "<CAHostName>\<CACommonName>"
# Ensure Microsoft.Graph.Beta module is available
#ADCS settings
# Make sure you have ADCS configured with a SubCA template and you have "<CAHostName>\<CACommonName>"
$Template = "SubCA"
$CAConfig="<CACommonName> of your ADCS server"
 
# Check if the External Certificate Authority Certificates already exists