📋 Microsoft Entra Documentation Changes

manager: mwongerapk

ms.service: entra-id

ms.topic: how-to

ms.date: 07/24/2025

ms.subservice: hybrid

ms.author: jomondi

Microsoft Entra Connect provides three options for application and certificate management:

 

- [Managed by Microsoft Entra Connect (default)](#managed-by-microsoft-entra-connect-default)

- [Bring Your Own Certificate (BYOC)](#bring-your-own-certificate)

 

> [!NOTE]

>

> This role also grants the ability to manage application credentials. User assigned to this role can add credentials to an application (notably the Connect Sync) and use those credentials to impersonate the application's identity. This might be an elevation of privilege over what the user can do via their role assignments.

 

 

:::image type="content" source="media/authenticate-application-id/auth-1.png" alt-text="Diagram that shows authentication with application ID." lightbox="media/authenticate-application-id/auth-1.png":::

 

For example, when a Microsoft Entra ID-joined Windows client accesses a file share or application over the internet, Microsoft Entra ID can issue the necessary Kerberos tickets as a KDC associated with the resource.

 

 

**Enhanced security with modern credentials support**: Users can sign in by using passwordless methods such as Windows Hello for Business or FIDO2 security keys, yet still access on-premises resources that have Kerberos protections. This ability enables multifactor authentication (MFA) and passwordless authentication to reduce the risks associated with password theft and phishing attacks.

 

 

Upon successful authentication, Microsoft Entra ID issues a PRT that contains user and device information. Alongside the PRT, Microsoft Entra ID issues a Cloud TGT for the realm `KERBEROS.MICROSOFTONLINE.COM`.

 

 

#### Cloud TGT issuance

 

 

The Cloud TGT that Microsoft Entra ID issues:

 

- On-premises domain controllers must be patched to support Kerberos Cloud Trust.

- Ensure line of sight between client devices and domain controllers for ticket exchange.

 

After you create the access package, you can directly assign specific internal and external users to it. If you specify an external user, a guest user account is created in your directory. For information about directly assigning a user, see [View, add, and remove assignments for an access package](~/id-governance/entitlement-management-access-package-assignments.md).

 

 

## Specify approval settings

 

 

You can always either enable, or disable, email notifications in the future after you finish creating the access package.

 

 

 

 

 

 

 

Applications using the Microsoft Entra identity platform can [expose APIs for other client applications to call](../../identity-platform/quickstart-configure-app-expose-web-apis.md#register-the-web-api). The application with the API can expose OAuth scopes for those API calls. The tool's service principal can be consented permission to those scopes, allowing it to call the APIs.

 

For more information on consenting an agent identity or service principal, see [admin consent for application permissions](grant-admin-consent.md#grant-admin-consent-for-application-permissions-using-microsoft-graph-api).

 

## Assigning an agent identity to an application role

 

Once these applications, users, role assignments, and grants are in place in the tenant, then an agent that needs a SAML assertion for authenticating to the enterprise application can:

 

In that request, the `client_id` is the agent identity ID, the `scope` is `api://AzureADTokenExchange/.default`, the `grant_type` is `client_credentials`, the `client_assertion_type` is `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`, and the `client_assertion` is the agent identity blueprint token from step 1.

 

In this request, the `client_id` is the agent identity ID, the `scope` is the concatenation of `api://'`, the SAML helper application's application ID, and `/.default`, the `grant_type` is `user_fic`, the `client_assertion_type` is `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`, the `client_assertion` is the agent identity blueprint token, the `user_id` is the agent user object ID, and the `user_federated_identity_credential` is the agent identity token.

 

 

## Who can request access

 

1. After choosing who can get access and the scope you are able to specify who can request access to the access package. Here you can grant Self, Admin, or Manager the ability to request access to the access package.

 

You can always enable it in the future after you have finished creating the access package.

 

If you selected **None (administrator direct assignments only)** then the who can request access section boxes are not selectable.

 

 

1. Select **Next**.

 

- [Use sensitivity labels to protect content in Microsoft Teams, Microsoft 365 groups, and SharePoint sites](/purview/sensitivity-labels-teams-groups-sites)

- [Microsoft Defender for Cloud Apps](/defender-cloud-apps/session-policy-aad?branch=pr-en-us-2082#require-step-up-authentication-authentication-context)

- [Custom applications](~/identity-platform/developer-guide-conditional-access-authentication-context.md)

 

## Related content

 

- Windows Server 2019 or newer that are hybrid Microsoft Entra joined.

 

> [!NOTE]

 

### Supported applications

 

- Microsoft Entra groups deployed to a device with this policy don't apply to remote desktop connections. To control remote desktop permissions for Microsoft Entra joined devices, you need to add the individual user's SID to the appropriate group.

 

> [!IMPORTANT]

 

## Manage regular users

 

 

1. Select **New assignment** to open Add user to access package.

 

 

1. In the **Select policy** list, select a policy that the users' future requests and lifecycle will be governed and tracked by. If you want the selected users to have different policy settings, you can select **Create new policy** to add a new policy.

 

Creation of federated identity credentials is currently **not supported** on user-assigned managed identities created in the following regions:

 

- Malaysia South

 

Support for creating federated identity credentials on user assigned identities in these regions will be gradually rolled out.

Resources in this region which need to use federated identity credentials, can do so by leveraging a user assigned managed identity created in a supported region.