Error 18456 Login failed for user domain\user

We have an application that logs into our SQL Server 2000 using ODBC. All
service packs and critical updates are current on the server and clients.
SQL Server uses mixed authentification and runs under a domain account, the
users login with their domain\username, or at least they used to. Nobody
seems to know exactly when this stopped working, and of course, nobody said
anything until this week. Attempting to login now fails with error 18456
login failed for user domain\username. I've foolwed all the debugging info I
can find on Microsofts site. Running osql, I can log in using windows
authentification and SQL Server accounts with no problem. Trying to use
domain\username fails. I've been through everything from DNS to SQL Server
settings to client settings with no resolution. Anybody have an idea where
else to look?
Any hints would be greatly appreciated.
BruceHi Bruce,
Thank you for use the newsgroup and it is my pleasure to help you with you
issue.
From you information, you application, which used to work fine now got
error message
Could you check if the ODBC connection is made through the standard
security of SQL Server of trusted connection security? Is the SQL Server
authentication mode match the security option of ODBC connection? Could you
using the Query Analyzer to connect the SQL Server? That is, if you use the
standard security, such as use the account 'sa', when using 'sa' in Query
Analyzer, could it connect the SQL Server. When it is a Windows
authentication, when connect the SQL Server by Query Analyzer, you should
choose the Windows Authenticatin in the Query Analyzer.
Looking forward to your response. Thanks.
Best regards
Baisong Wei
Microsoft Online Support
----
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only. Thanks.|||Baisong:
Using Windows Authentification or Sql Server Authentification both work
fine.
If I'm logged into the domain I can run
osql -S SERVER -d Test -E
or
osql -S SERVER -d Test -U SA -P password
with no problem I can connect through Query analyzer either way.
if I try
osql -S SERVER -d Test -U domain\username -P password
it fails with the message Error 18456 Login failed for user domain\username.
The application we are using was working with the domain\username login, I
can't use Windows Integrated security with it, and I really do not want to
setup and manage 50+ SQL Server accounts. I am assuming that something has
changed in the authentification / delegation process and am working through
that now. As far as I can tell nothing has changed, but obviously something
has.
Any ideas would be appreciated.
Bruce
"Baisong Wei[MSFT]" <v-baiwei@.online.microsoft.com> wrote in message
news:EKzqmHs7DHA.1992@.cpmsftngxa07.phx.gbl...
> Hi Bruce,
> Thank you for use the newsgroup and it is my pleasure to help you with you
> issue.
> From you information, you application, which used to work fine now got
> error message
> Could you check if the ODBC connection is made through the standard
> security of SQL Server of trusted connection security? Is the SQL Server
> authentication mode match the security option of ODBC connection? Could
you
> using the Query Analyzer to connect the SQL Server? That is, if you use
the
> standard security, such as use the account 'sa', when using 'sa' in Query
> Analyzer, could it connect the SQL Server. When it is a Windows
> authentication, when connect the SQL Server by Query Analyzer, you should
> choose the Windows Authenticatin in the Query Analyzer.
> Looking forward to your response. Thanks.
> Best regards
> Baisong Wei
> Microsoft Online Support
> ----
> Get Secure! - www.microsoft.com/security
> This posting is provided "as is" with no warranties and confers no rights.
> Please reply to newsgroups only. Thanks.
>|||Hi Bruce,
Thank you for your update.
For the 'osql -S SERVER -d Test -U domain\username -P password' which
failed with the error message, could you check if it is a valid SQL Server
login? You could check it by unfolder the database, unfoulder the
'Security', then in the logins, is the above 'domain\username' in the
logins?
Looking forward to your response. Thanks.
Best regards
Baisong Wei
Microsoft Online Support
----
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only. Thanks.|||Yes, it is a valid login and the password is correct. The account also has
privledges (dbowner + our SQL_Admin role) to access the test database. It
works fine with Windows Integrated Security, so I don't think it is related
to SQL Server privledges, my guess is that something has changed in the
authentification authorization or delegation between the domain and the
server or the client.
The client computers are running MDAC 2.8 or 2.7RTM, and component checker
says they are current and all is well. Servers and clients are current on
patches, SQL Server is current. I've been throgh every article I can find on
MSDN that remotely deals with this error, and everything seems to check out.
I'm sure there is some little thing I'm overlooking, but I'm totally stumped
at this point.
Bruce
"Baisong Wei[MSFT]" <v-baiwei@.online.microsoft.com> wrote in message
news:ZZofg867DHA.2508@.cpmsftngxa07.phx.gbl...
> Hi Bruce,
> Thank you for your update.
> For the 'osql -S SERVER -d Test -U domain\username -P password' which
> failed with the error message, could you check if it is a valid SQL Server
> login? You could check it by unfolder the database, unfoulder the
> 'Security', then in the logins, is the above 'domain\username' in the
> logins?
> Looking forward to your response. Thanks.
> Best regards
> Baisong Wei
> Microsoft Online Support
> ----
> Get Secure! - www.microsoft.com/security
> This posting is provided "as is" with no warranties and confers no rights.
> Please reply to newsgroups only. Thanks.
>|||Bruce,
The exact same thing happen here - ODBC connections that had worked
stopped working. We THINK it was related to installing patches but not
the full SP3a running on SQL 2000. We know installing SP3a fixed it.
An easy test to see if it's the same problem - in the ODBC config, set
the server name servername.subdomain.domain.?, check with the network
people for the full name if you need to.
If it works then maybe install/reinstall SP3a on the server will help.
SQL DBA in Richmond, VA
PS - I know 4 locales that suddenly experienced this same problem.
Maybe triggered by Windows critical update?
*** Sent via Developersdex http://www.examnotes.net ***
Don't just participate in USENET...get rewarded for it!