none
SSPI handshake failed with error code 0x8009030c while establishing a connection with integrated security; the connection has been closed

    Question

  • Hi,

    We are getting the following error from Event Viewer.  We also see the similar error in SQL Server log.

    SSPI handshake failed with error code 0x8009030c while establishing a connection with integrated security; the connection has been closed.


    We are using jtds driver to connect from linux box to sql server 2008 and it is working fine with one user account(windows account).  When we use the other service account(windows account) to connect, we are getting the above error. 

    Here is connection url - :jtds:sqlserver://<hostname>:1433/<database name>;domain=<domain name>;useNTLMv2=true

    Could it blocked by any user rights?  What we need to check?

     

    Thanks.

    Thursday, September 01, 2011 6:28 PM

All replies

  • I know this is not your error, but this article has related troubleshooting ideas that might help How to troubleshoot the "Cannot generate SSPI context" error message http://support.microsoft.com/kb/811889
    Rick Byham, Microsoft, SQL Server Books Online, Implies no warranty
    Thursday, September 01, 2011 10:41 PM
  • Hi Rick,

     

    Thanks for your information.  Because of the problem is only showing on one account and not the other account, we are thinking it might relate to user rights which could block the account to accessing SQL Server.  Currently, we check the following rights won't be blocked in group/user level.

    • Act as part of operating system;
    • Log on as a batch job;
    • Log on as a service;
    • Replace a process level token;
    • Bypass  traverse checking;
    • Adjust memory quotas for process

    Are there more user rights need to check?  Any suggestions?

     

    Thanks.

    Friday, September 02, 2011 2:53 AM
  • Usually when I see SSPI (Security Support Provider Interface) I start thinking Kerberos errors. I'm not a Kerberos expert. You might be interested in Kerberos Interoperability Step-by-Step Guide for Windows Server 2003 http://social.technet.microsoft.com/wiki/contents/articles/kerberos-interoperability-step-by-step-guide-for-windows-server-2003.aspx which has a section on Non-Windows clients.

    As for your last question, about rights and permissions. There are tons of those. We don't have a good list for SQL Server 2008, something I have been trying to fix for SQL Server Code-named 'Denali'. SQL Server 2008 doesn't work quite the same way, but it uses the same sorts of rights and permissions. I suggest you look over the Denali list, for hints. The very long list is here Configure Windows Service Accounts and Permissions http://msdn.microsoft.com/en-us/library/ms143504(v=SQL.110).aspx


    Rick Byham, Microsoft, SQL Server Books Online, Implies no warranty
    Friday, September 02, 2011 4:01 PM
  • Hi Rick,

    Thanks for your reply.  The following is error messages with error code from SQL Server log.  Not sure it means something.


    Date                      x/xx/2011 12:49:51 AM

    Log                         SQL Server (Current - x/xx/2011 11:13:00 PM)

     

    Source                  Logon

     

    Message

    Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [CLIENT: xxxxxxxxxxx]

     

     

    Date                      x/xx/2011 12:49:51 AM

    Log                         SQL Server (Current - x/xx/2011 11:13:00 PM)

     

    Source                  Logon

     

    Message

    Error: 18452, Severity: 14, State: 1.

     

     

    Date                      x/xx/2011 12:49:51 AM

    Log                         SQL Server (Current - x/xx/2011 11:13:00 PM)

     

    Source                  Logon

     

    Message

    SSPI handshake failed with error code 0x8009030c while establishing a connection with integrated security; the connection has been closed. [CLIENT: xxxxxxxxxxx]

     

     

    Date                      x/xx/2011 12:49:51 AM

    Log                         SQL Server (Current - x/xx/2011 11:13:00 PM)

     

    Source                  Logon

     

    Message

    Error: 17806, Severity: 20, State: 2.

    Sunday, September 04, 2011 9:05 PM
  • Hi Rick,

     

    The service account which I referred from early mail.  It is not the account to run sql server or sql agent. It is just an account not for regular user.

     

    Thanks again.

    Sunday, September 04, 2011 9:08 PM
  • This looks like the problem is from the linux machine.  The domain the linux machine is running under is not a trusted domain.  Windows authentication cannot be performed when the domains are not trusted.


    Jeff Williams
    Monday, September 05, 2011 1:29 AM
  • Hi Jeff,

     

    Any suggestion on how to resolve it or if you know any tool can tell there is any problems?

     

    Thanks.

    Monday, September 05, 2011 7:42 PM
  • Is the linux machine in the same domain as the Windows machine?  If not, are the two domains defined as trusted - at least does the Windows domain trust the linux servers domain?

    If the linux machine is not part of the domain - there isn't anything you can do to fix the problem.  You cannot use Windows authentication between non-trusted domains, and if the other system is not on a domain you will not be able to use windows authentication either.

    There are ways you can get a process to authenticate on the domain - but I am not sure how to do that from linux.  For example, I can use ShellRunAs or RunAs from a command prompt in windows and specify the /netonly parameter to specify the domain credentials.  That will authenticate the process on the windows domain - and then windows authentication will work from that process.

     


    Jeff Williams
    Monday, September 05, 2011 10:01 PM
  • Hi Jeff,

     

    Thanks for your reply.  The weird part  is - one account is working fine but not the other account.  Could it possible these two accounts reside under different AD?

     

    Thanks.

    Tuesday, September 06, 2011 1:22 PM
  • Hi Jeff,

     

    Thanks for your reply.  The weird part  is - one account is working fine but not the other account.  Could it possible these two accounts reside under different AD?

     

    Thanks.


    This is something you need to determine.  If you have an AD account that can be used from that same linux box and it works correct, but a different AD account doesn't - then wouldn't that lead you to believe the problem is with the AD account?

    You need to identify the differences between the 2 different scenarios.  Are they both coming from the same machine, both connecting to the same instance of SQL Server, both AD accounts exactly the same?

    Find where the differences are and start looking there.

    The error you are getting is quite clear - it is stating that you cannot authenticate because that login is not from a trusted domain.  That tells me the issue is with how that service in linux is starting up - and the linux configuration.  But, that is just a guess...


    Jeff Williams
    Wednesday, September 07, 2011 1:38 AM
  • Hi Jeff,

    I understand there are differences between accounts but we cannot narrow down what exactly user rights could block the remote acessing from linux.  As you know, there are many possible user/group user rights security policies could cause this error message.  Both accounts are accessing the same instance using the same jdbc url from the same machine to the same sql server. 

    We already checked the followings user rights but look like we are still missing something.

    • Act as part of operating system;
    • Log on as a batch job;
    • Log on as a service;
    • Replace a process level token;
    • Bypass  traverse checking;
    • Adjust memory quotas for process

    Thanks.

     

     

    Wednesday, September 07, 2011 5:00 PM