locked
Error 18452 Login Failed with osql, but sqlcmd works fine RRS feed

  • Question

  • I'm troubleshooting a connection problem with an application that it is coded to use ODBC libraries. The following error is logged to the SQL 2008 trace logs

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

    While troubleshooting I discovered that if I use osql -S <server name> -E -d <database name>  I get the login failed error, but if I use sqlcmd instead of osql at the command line the connection works fine. I understand that sqlcmd uses OLEDB libraries to connect to the database, but what would cause ODBC to fail when using Windows authentication.  By the way if I create a DSN to the database in ODBC administrator and select the option to use SQL authentication I can connect to the database OK. It is just when I use Windows authentication. 

    Thanks

    Friday, June 18, 2010 12:20 AM

All replies

  • Can you paste here the full, complete Login Failed messages from the SQL Server ERRORLOG file? It is at (replace !INSTANCEID! with the appropriate value for your SQL Server instance): %programfiles%\Microsoft SQL Server\!INSTANCEID!\MSSQL\Log\ERRORLOG

     


    This post is provided 'as is' and confers no express or implied warranties or rights.
    Friday, June 18, 2010 4:41 PM
  • Hello,

    Here is an excerpt from the errorlog file

    Logon       Error: 17806, Severity: 20, State: 2.
    Logon       SSPI handshake failed with error code 0x80090302 while establishing a connection with integrated security; the connection has been closed. [CLIENT: xxx.xxx.xxx.xxx]
    Logon       Error: 18452, Severity: 14, State: 1.
    Logon       Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [CLIENT: xxx.xxx.xxx.xxx]

    I just realized that the error 17806 is being generated right before the error that I'm getting when trying to connect with osql. I've done some queries about that error and everything I have found so far points a problem the spn and that I should use the setspn tool to fix the problem, however I'm not entirely clear as to what the output from that tool should show in order to determine that is the problem. I also have some doubts about the problem is with the spn. Shouldn't I see the same problem using sqlcmd if the problem was the spn?

    Thank you!

    Friday, June 18, 2010 7:30 PM
  • # for hex 0x80090302 / decimal -2146893054
      SEC_E_UNSUPPORTED_FUNCTION                                     winerror.h
    # The function requested is not supported
    # as an HRESULT: Severity: FAILURE (1), FACILITY_SSPI (0x9), Code 0x302
    # for hex 0x302 / decimal 770

    What's your OS version?

    Thursday, June 24, 2010 9:59 PM
  • The OS is Windows 2003 SP2
    Friday, June 25, 2010 12:50 AM
  • This is extremely odd. That error should mean that the client driver got that "unsupported function" error from the base authentication libraries in Windows, but with the way the driver calls Windows, there is no way it should ever return that. The only way I can imagine that happening is if the Windows image of those base authentication libraries were corrupted, and I expect you would see serious failures everywhere if that were the case (least of all, the OLEDB connections shouldn't work any better, if that were it).

    Alternatively, it might be the ODBC libraries themselves that are corrupted... for starters, can you try uninstalling and reinstalling the SQL Server Native Client 10.0? And, can you try to set up the same client environment on another machine and see if you are able to reproduce the problem there?


    This post is provided 'as is' and confers no express or implied warranties or rights.
    Friday, June 25, 2010 4:57 PM
  • Since osql fails and sqlcmd works, I wonder if there are differences. Perhaps you are using TCP with one, and named pipes with the other? Perhaps the sqlcmd connected using NTLM instead of Kerberos? Check sys.dm_exec_connection for info about the sqlcmd connection.
    Rick Byham, Microsoft, SQL Server Books Online, Implies no warranty
    Friday, June 25, 2010 6:29 PM