User shows as signed in but tunnel is down¶

When a User Authentication trust requirement is configured with a security group condition, the Enclave desktop app may show the user as "Signed In" while peer connections remain down and no traffic flows. The enclave status CLI command provides more detailed information about which specific trust requirement conditions are not being met.

Symptoms¶

The Enclave desktop app (system tray) shows the user as Signed In and trust requirements appear as Met.
One or more peers show as Down in the desktop app with no traffic flowing.
Running enclave status on the affected system shows the peer state as Down, local trust requirement not met (or Down, remote trust requirement not met).
Running enclave status shows individual trust requirement conditions as not met, even though the user has successfully authenticated.
Removing the security group condition from the trust requirement restores connectivity.

Cause¶

A User Authentication trust requirement can have multiple conditions. For example, a trust requirement configured with Microsoft Entra ID may require both:

That the user authenticates against a specific Azure tenant, and
That the user is a member of a specific security group.

These conditions are evaluated independently by the Enclave platform. The user's authentication token (JWT) is acquired by the Enclave agent and forwarded to the Enclave platform for validation. The platform inspects the token's claims to determine whether each condition is satisfied.

When the tenant condition is met (the user successfully signs in) but the security group condition is not (the token does not contain the required group membership claim), the trust requirement as a whole is not met and traffic will not flow.

The Enclave desktop app displays the user as "Signed In" because the authentication flow itself was successful. The app deliberately presents the collated trust requirement status as "Met" when the user has signed in, because the user cannot resolve a missing group membership themselves; an administrator must address it. However, the underlying trust requirement remains unsatisfied and the policy will not permit traffic.

The enclave status CLI command does not apply this collation and will show the individual met/unmet state of each trust requirement condition, making it more useful for diagnosing this issue.

Resolution¶

Confirm the issue¶

Run enclave status on the affected system and look for peers showing as Down, local trust requirement not met or Down, remote trust requirement not met.
In the policy breakdown for the affected peer, look under Not Met Conditions for the specific trust requirement that is unsatisfied. The description will indicate which security group is required.
Alternatively, run enclave status --json to get machine-readable output. Look for entries in TrustRequirements where IsMet is false. The Description field will identify the unmet condition.

Investigate in your identity provider¶

The Enclave agent forwards the user's authentication token to the Enclave platform without inspecting it. The platform can only determine whether the required group membership claim is present in the token. It cannot determine why it is absent. The root cause will be in your identity provider's configuration.

For Microsoft Entra ID, common reasons a security group may not appear in the token include:

The user is not a member of the specified security group.
The group is a device group, not a user group. Enclave evaluates security group membership from the user's authentication token. Device groups are not included in user tokens, so a trust requirement referencing a device group (such as an Intune compliance-based dynamic group) will never be met.
The group type is not compatible with third-party authorisation. See the group type compatibility table for details.
The Object ID configured in the Enclave trust requirement does not match the actual group Object ID.
The group is a nested group and nested memberships are not being resolved.

Isolate and test¶

If you need to confirm that the security group condition is the cause without affecting the user's existing connectivity, you can test in isolation:

Create a new tag and assign the affected system to it.
Create a new trust requirement with the same identity provider but without the security group condition.
Create a new policy that references the new tag and the new trust requirement.
Check whether the trust requirement is met for the system under this isolated policy using enclave status.
If the trust requirement is now met and connectivity is established, the security group condition is confirmed as the cause. Investigate group membership in your identity provider.

This approach allows you to test trust requirement conditions without modifying the policies that govern the system's existing connectivity.

If the same trust requirement behaves differently for the same user across different devices, the issue is unlikely to be in Enclave. Enclave's trust requirement evaluation is based entirely on the claims present in the user's authentication token. It does not consider the device. However, your identity provider may apply device-level policies (such as Conditional Access or device compliance rules) that alter the contents of the token before Enclave receives it. If you observe device-dependent behaviour, investigate the identity provider's device policies.

Notes¶

The Enclave agent does not inspect the contents of authentication tokens. It acquires tokens via the configured identity provider and forwards them to the Enclave platform for validation. The platform evaluates the token's claims against the trust requirement conditions and returns a met/unmet result per condition. Neither the agent nor the platform can provide detailed diagnostics about why a particular claim is missing from a token. That information is only available from the identity provider.
The enclave status command always shows the individual met/unmet state of each trust requirement condition, making it the recommended tool for diagnosing trust requirement issues. The desktop app's "Signed In" status reflects only whether the authentication flow succeeded, not whether all trust requirement conditions are satisfied.

Having problems? Contact us at support@enclave.io or visit our support options.

Last updated July 29, 2026