AD Authentication Failures

Question

SQL Error: 

Message Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication. 

Message SSPI handshake failed with error code 0x80090311, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The operating system error code indicates the cause of failure. No authority could be contacted for authentication.

 

Answer 1

Hello,

The error you’re seeing Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication combined with SSPI handshake failed with error code 0x80090311 indicates that the SQL Server cannot establish a Kerberos/NTLM security context because the domain controller is unreachable or the trust relationship is broken. The specific OS error No authority could be contacted for authentication confirms that the client or server cannot reach a domain controller to validate the credentials.

This typically occurs in one of three scenarios. First, the SQL Server is joined to a domain but the client machine is not, or they are in different domains without a trust relationship. Second, the machine is domain‑joined but cannot contact a domain controller due to DNS misconfiguration, firewall rules, or replication issues. Third, the SPN (Service Principal Name) for SQL Server is missing or misregistered, which prevents Kerberos from completing the SSPI handshake.

To resolve it, start by confirming that both the SQL Server and the client are joined to the same domain or to trusted domains. Run nltest /dsgetdc:<domain> from both sides to verify that they can locate a domain controller. Check DNS resolution: the SQL Server must resolve the domain controllers via its configured DNS servers, not external DNS. If you see failures, adjust the DNS settings to point to your AD DNS.

If domain connectivity is fine, check the SPNs. Use setspn -L <SQLServiceAccount> to list the SPNs registered for the SQL Server service account. For Kerberos to work, you need entries like MSSQLSvc/<hostname>:1433 and MSSQLSvc/<FQDN>:1433. If they are missing, register them with setspn -A. Without valid SPNs, Kerberos fails and the SSPI handshake error appears.

If you cannot guarantee domain connectivity, switch the connection string to use SQL authentication instead of Integrated Security. That bypasses SSPI entirely. But if you require Integrated Security, you must fix the domain trust and SPN registration.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

Domic Vo.

Answer 2

The errors indicate Windows (Integrated) authentication to SQL Server is failing because the security subsystem can’t contact a domain controller or validate the Windows principal.

Key points from the messages:

• "Login failed. The login is from an untrusted domain and cannot be used with Integrated authentication" (Error 18452) means the Windows login can’t be validated. Common causes:
  • The login is a SQL login but the instance is configured for Windows-only authentication.
  • The SQL login doesn’t exist when using SQL authentication.
  • The login uses Windows authentication but the account is from an untrusted or unreachable domain.
  • Cross-domain trust or SPN visibility issues.
• "SSPI handshake failed with error code 0x80090311" and "No authority could be contacted for authentication" indicate directory services / LSASS / domain controller connectivity problems.

Recommended troubleshooting and fixes:

1. Validate authentication mode and login type

• If using SQL authentication:
  • Confirm SQL Server is in Mixed Authentication mode.
  • Confirm the SQL login exists on the instance.
• If using Windows authentication:
  • Confirm the user is logged on to the correct domain.
  • Confirm the Windows login or group is created in SQL Server and has appropriate permissions.

2. Check domain trust and “untrusted domain” conditions

• Error 18452 occurs when the Windows principal cannot be verified, often because:
  • The domain is not trusted by the SQL Server’s domain.
  • Cross-domain group membership or trust configuration is incorrect.
• For cross-domain scenarios:
  • Ensure proper trust between domains.
  • Ensure users from a remote domain belong to a group in the SQL Server domain, and avoid relying on domain-local groups in a different domain for SQL access.
  • Review selective authentication settings on trusts; if selective authentication is misconfigured, users may be blocked from authenticating to resources in the remote domain.

3. Investigate LSASS / domain controller connectivity (0x80090311)

• Error 0x80090311 means no authority (DC/LSASS) could be contacted for authentication.
• Typical causes:
  • LSASS is unresponsive on the SQL Server or client.
  • The machine cannot reach a domain controller (network, DNS, firewall, or DC outage).
• Actions:
  • Check system and security event logs on both client and SQL Server around the time of failures for Kerberos, LSA, Netlogon, or AD-related errors.
  • Work with domain administrators to resolve any DC or AD issues found.

4. Verify SPN and Kerberos configuration

• Misconfigured or missing SPNs can cause SSPI and “untrusted domain” errors.
• On a domain controller or management workstation, use:
  • setspn -Q to query specific SPNs.
  • setspn -L <AccountName> to list SPNs on the SQL Server service account.
• Ensure the SQL Server service SPNs are correctly registered on the right account and visible across trusted domains.

5. Address LSASS-specific issues

• If LSASS is intermittently unresponsive:
  • Treat this as a Windows/AD issue: investigate LSASS performance, antivirus interference, or DC latency.
  • For consistent LSASS failures, follow guidance for local security subsystem errors and verify SPN registration and DC health.

6. For intermittent failures

• If the issue is sporadic:
  • Review SQL connectivity ring buffer to see where time is spent (network vs SSPI vs SQL performance).
  • Check for slow or overloaded domain controllers causing timeouts.
  • Ensure connection pooling is used in applications to reduce authentication load on LSASS/DCs.

7. DC selection issues (for empty/failed logins)

• When SQL logs show “Login failed for user ''” with SSPI errors and 0x80090311/0x80090304, SQL may be unable to contact a working DC.
• Possible remediation:
  • Take the problematic DC offline or use NLTEST to switch DCs:
    • NLTEST /SC_QUERY:<Domain> to see current secure channel.
    • NLTEST /SC_RESET:<Domain>\<DCName> to reset to a specific DC.
  • Then re-test authentication.

In summary, resolve this by:

1. Confirming correct authentication mode and login configuration in SQL Server.
2. Ensuring proper domain trust and that the user’s domain is trusted and reachable.
3. Checking LSASS and domain controller connectivity (event logs, network, DNS).
4. Verifying SPN and Kerberos configuration with setspn.
5. Adjusting DC usage with NLTEST if a specific DC is failing.

---

References:

• MSSQLSERVER_18456
• Local security subsystem errors in SQL Server
• Consistent authentication issues in SQL Server
• Troubleshoot Active Directory authentication for SQL Server on Linux and containers
• Intermittent or periodic authentication issues in SQL Server
• MSSQLSERVER_18452
• The audit for this user shows success, but when using SSMS, the error that is received is 18456 and he cannot sign in - Microsoft Q&A
• How to fix ODBC test result failed - Microsoft Q&A
• KB5065426 Security update - SQL Server Failover cluster (AlwaysOn) problems - Microsoft Q&A
• Problem with SQL server login - Microsoft Q&A
• Cannot connect to SQL Server - Microsoft Q&A