SQL “untrusted domain” error over VPN for one device only (Windows Auth)

The error indicates a Windows authentication problem between the client and SQL Server, not a generic connectivity issue. From the context, there are three main categories to focus on for a single-device, VPN-only scenario:

1. Local Security Subsystem (LSASS) / domain trust behavior on that device
2. Kerberos / SPN resolution over VPN
3. How the user account is resolved and authorized in SQL Server

Because admin domain credentials work but the user’s do not, the issue is likely with how the user’s Windows identity is being resolved or authenticated from that specific machine, not with SQL Server itself.

1. Check for LSASS / local security subsystem issues

The error text “The login is from an untrusted domain and cannot be used with Windows authentication” can be raised when the Local Security Authority Subsystem Service (LSASS) is unresponsive or cannot contact a domain controller:

• On the SQL Server, check the error log for entries like:
  • SSPI handshake failed with error code 0x80090311 or 0x80090304
  • Windows error codes:
    • 0x80090311: No authority could be contacted for authentication.
    • 0x80090304: The Local Security Authority cannot be contacted.

If these appear around the time this user connects, the problem is in the security subsystem path between the client and the DC.

Client-side checks:

• Confirm the VPN allows domain controller traffic (Kerberos/LDAP) from this device’s subnet.
• Compare this device’s network and VPN profile to a working device (same DNS servers, same domain suffix, same routing to DCs).
• If LSASS is stuck or misbehaving on the client, a reboot is required; if multiple users see similar issues after OS updates, restarting domain controllers has been shown to clear LSASS-related authentication issues.

Relevant guidance: Local security subsystem errors in SQL Server

2. Kerberos / SPN and name resolution

Kerberos problems can cause Windows authentication to fail and fall back to NTLM or fail outright. For this user’s device over VPN:

• Verify the application’s connection string uses the correct server name (prefer FQDN, not just NetBIOS). An incorrect DNS suffix or name can cause Kerberos to fail and lead to authentication errors.
• Ensure the Service Principal Name (SPN) for SQL Server is correctly registered and reachable from the VPN network. Use setspn -Q from an admin machine to validate SPNs for the SQL Server service account.
• If the SQL Server error log shows Cannot generate SSPI context for this client, follow the SPN troubleshooting guidance in the “consistent authentication issues” article.

Relevant guidance:

• “Explicit SPN is missing / misplaced / duplicated” and “Incorrect server name in connection string” under Consistent authentication issues in SQL Server

3. Domain / group resolution and SQL Server login mapping

The same error text also appears when SQL Server cannot resolve or authorize the Windows principal:

• If the login is from an untrusted domain or a cross-domain group cannot be resolved, SQL Server treats the principal as unrecognized.
• For cross-domain scenarios, users from a remote domain must belong to a group in the SQL Server domain; otherwise group membership cannot be enumerated.

Checks:

• On SQL Server, verify the user’s domain account or group appears under Security → Logins in SSMS and is not disabled.
• If access is via groups, run xp_logininfo 'DOMAIN\User' on SQL Server to confirm SQL Server can resolve the user and group membership. If this fails for the user but not for admin accounts, there may be group or trust resolution issues.
• Compare the user’s group memberships with a working user; if the user relies on a cross-domain group, confirm the group is in the SQL Server domain and that domain trust is configured correctly.

Relevant guidance:

• “Login is from an untrusted domain” and “No permissions for cross-domain groups” under Consistent authentication issues in SQL Server
• MSSQLSERVER_18456 for login failure diagnostics

4. Client-side items specific to this device

Given that other machines work over VPN, focus on differences on this device:

1. DNS and suffix search list
   • Ensure the device uses the same DNS servers and domain suffix as working devices so that the SQL Server FQDN and DCs resolve correctly.
2. Time synchronization
   • Kerberos requires time to be in sync. Confirm the device time is within the allowed skew of the domain controllers.
3. Credential handling
   • Clear any stored credentials for the SQL Server in Credential Manager and retry.
4. Security policies / Credential Guard
   • If Credential Guard or other security hardening is enabled only on this device, it can interfere with integrated authentication. The “Credential guard is enabled” scenario is listed as a potential cause of consistent authentication issues.
5. OS / update anomalies
   • If this device is on a different OS build or has recently received security updates affecting authentication, compare with a working device. In some environments, restarting domain controllers resolved widespread post-update authentication issues.

5. SQL Server error details

Finally, use the SQL Server error log to narrow down the cause:

• Look for Error 18456 entries corresponding to this user and note the state value. The state gives specific reasons for login failure; use the mapping in the MSSQLSERVER_18456 documentation to guide further troubleshooting.

Relevant guidance: MSSQLSERVER_18456

References:

• Consistent authentication issues in SQL Server
• Local security subsystem errors in SQL Server
• Intermittent or periodic authentication issues in SQL Server
• Troubleshoot Active Directory authentication for SQL Server on Linux and containers
• MSSQLSERVER_18456
• How to fix error || Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' || - Microsoft Q&A
• October update, Windows 11 24H2, issues authenticating - Microsoft Q&A