User Authentication with Microsoft Entra ID¶
Our Microsoft authentication authority lets you log users in at the agent against Microsoft Entra ID (formerly Azure Active Directory). Our integration means that you can:
- Apply Conditional Access to user logins.
- Use any MFA mechanism supported by Azure for authentication.
- Log users in via their existing domain-joined credentials on Windows devices if you are using AD Sync.
- Audit user login events through Microsoft's tooling.
- Use your existing Security Groups to segment network access.
Azure Tenant ID¶
When defining your Trust Requirement, you should provide the Azure Tenant ID, which indicates which Azure tenant the authenticating user must exist in.
You can get your Tenant ID from the Azure Portal:
Security Group¶
In addition to generally requiring authentication via your tenant, you can also specify an Entra ID Security Group Object Id. Users must then be a member of that security group in order to meet the trust requirement.
Using security groups, you can create finely-grained connectivity rules that map your user security assignments to the resources they can access.
The Security Group ID is the "Object ID" in Azure for that group:
Requirements¶
To use Entra ID group membership with Enclave Trust Requirements, ensure that your security groups are correctly configured in Entra ID to be compatible with third-party applications.
Many customers manage a mix of security groups, from on-premises Active Directory to Microsoft 365 Groups and native Entra ID security groups. However, not all can be used for authorisation with third-party applications.
| Group Type | Supports Third-Party Authorisations |
|---|---|
| Entra ID Security Group | Yes, can be used directly with Enclave Trust Requirements. |
| Active Directory Universal Security Group | Yes, but the groups must be synced to Entra ID using Azure AD Connect. |
| Active Directory Local/Global Group | No, must be converted to a Universal Security Group in on-premise Active Directory before syncing, or created as new Entra ID Security Group. |
| Microsoft 365 Group | No, either add the Microsoft 365 Group to an Entra ID Dynamic Membership Group, or create a mirrored Entra ID Security Group with the same members. |
Token Refresh¶
An Entra ID user may be granted system access through Azure Conditional Access or Privileged Identity Management (PIM) policies to block access from less trusted locations, force users to reauthenticate periodically or enforce device security compliance posture via InTune.
Enclave will re-evaluate group membership each time we receive a new access token from your Azure tenant. This happens whenever the current access token expires: the agent silently redeems its refresh token shortly before expiry, and Entra ID evaluates group membership afresh when it issues the replacement token.
The default access token lifetime is a randomised value between 60 and 90 minutes, assigned when the token is issued. If needed, a token lifetime policy can reduce this to as little as 10 minutes. Token lifetime policies are managed through Microsoft Graph or Microsoft Graph PowerShell (there is no portal UI for them), and can be set as an organisation default in your tenant or scoped to the Enclave application. A shorter token lifetime only increases the frequency of silent refreshes; it does not make users sign in again.
Time-limited group membership (PIM)¶
If you grant group membership on a time-limited basis, for example with PIM for Groups, be aware that a token carries a snapshot of the user's groups taken at the moment the token is issued. Entra ID does not revoke a token when a PIM activation expires, and there is no per-claim expiry inside the token, so membership changes only take effect when the next token is issued. This works in both directions:
- After a user activates their membership, their existing token still lacks the group claim; access begins at the next token refresh. Users can sign out of Enclave and sign back in to force a new token immediately.
- After the activation expires, the user's current token still carries the group claim; access continues until that token expires and the silent refresh produces a token without it.
When the refreshed token no longer carries the required group claim, the trust requirement stops being met and tunnels authorised by the affected policies are closed. The user still shows as signed in, because their authentication remains valid; only the group condition has lapsed. See User shows as signed in but tunnel is down for how this appears on the affected system.
To keep this overhang short relative to your PIM activation window, reduce the access token lifetime for the Enclave app integration; both activation and expiry then take effect within one token lifetime.
Having problems? Contact us at support@enclave.io or visit our support options.
Last updated September 1, 2026