Strange Login Failure
-
I have a newly installed SQL Server 2000 instance on a Windows 2000 Server machine, installed under the administrator account on Kong.
SQL Server is configured for Windows authentication.
The database is configured with only TCPIP.
I have added two users, jcc\tom and jcc\keith (me).
Tom is able to create an ODBC connection from his workstation with no problem. The SQL/Server log entry is:
2004-02-25 13:08:17.60 logon Login succeeded for user 'JCC\tom'. Connection: Trusted.
When I (jcc\keith) attempt to create an ODBC connection from my workstation, the SQL/Server log entry is:
2004-02-25 13:33:08.90 logon Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection.
I think that both accounts have the same rights in W2K and roles in the database, but something must be different.
Anyone have suggestions about what might cause this?
Thanks,
Keith
Cordially,Keith W. Hare
-
the workstation used for keith does not belong to the DOMAIN where SS is!
-- join to the domain and you should be happy
HTH
* Noel -
The workstation used for keith is a member of the domain.
Cordially,Keith W. Hare
-
Ok,
Let start from the beginin:
1. Check This
2. How are you creating the ODBC Connection?
3. What tool(s) are you using on the client?
* Noel -
Check that the ODBC connection is configured to use Window Auth. I believe it is from this message you are posting.
It is a windows credentials not being passed through problem. Has the user which fails logged off and back on recently?
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com -
The ODBC connection is configured to use Windows Authorization.
I agree that it is an issue with Windows credentials not being passed through, but I don't yet understand why.
I have logged the failing user name off and on multiple times.
Keith
Cordially,Keith W. Hare
-
THE ODBC DSN was created at System level or at user level?
What OS on the Client?
* Noel -
I have tried creating the ODBC DSN at both the system and user level with the same lack of results.
The client OS is W/XP Pro, with service pack1 and all of the latest security patches.
On the client system WS1, I log into a local account, WS1\keith, which has the same password as the domain account JCC\keith.
Another user, Tom, on WS2, logs into the local account WS2\tom, which has the same password as the domain account JCC\tom, and is successful.
If I log into a third machine, WS3, using the domain login JCC/keith, I am able to create and connect through an ODBC DSN.
So, for some reason, the windows credentials are not being passed for WS1\keith while they are for WS2\tom.
I have also tried local accounts for keith on two additional machines with the same lack of success.
Keith
Cordially,Keith W. Hare
-
what OS in WS2?
* Noel -
All client machines are WXP Pro with service pack 1 and the latest security patches.
Cordially,Keith W. Hare
-
Can you ping to the server with server name and Have you tried to connect with ip address from your machine?
Check MDAC version on your machine. Try to upgrade it to MDAC 2.7 SP2.
-
if you use WSXXX\Uname you are NOT Logged in the DOMAIN you are logged on your LOCAL systems SQL Server DOESN'T Know the SID of your LOCAL account even if it has the Same password than the Domain Counter Part.
What is really strange is that you can connect using WS2\tom some how the SID got Right in SQL SERVER (as long as SQL Server is only a member server)
MY suggestion is LOG IN THE DOMAIN (JCC) ALWAYS from any machine and you won't have problems and if you want to follow the WS path use SQL Standard authentication instead!
If the SS is also a DC the you can log in using the WS account
* Noel -
Have you changed a server or workstation name recently?
Frequently, DNS or Active Directory problems cause the error you are receiving.
From a command prompt, type: ping -a <yourServerName> and verify that you get the correct IP address for the server.
Also, type nbtstat -c to list the remote machine name cache. Verify that all the entries are correct.
You can clear the cache with nbtstat -R
If you don't have the Windows 2000 Resource Kit already installed, you can download the SETSPN.EXE utility from Microsoft at:
http://www.microsoft.com/windows2000/techinfo/reskit/tools/existing/setspn-o.asp
Execute setspn -L and verify the results.
Mike
-
As noeld said, your WSxx accounts will never get authenticated. Tom was able to signon because he had some other service that did logon the JCC domain (probably a server share or mapped drive?) Keith did not have an active domain logon, so that ODBC had no domain account to try.
Even when "logged on" a single account during the workstation signon process, you can have multiple accounts you may be running under. You can logon multiple domains, or with multiple accounts, under different processes (using, for example, net use, or runas, or internet browsers). I believe that SQL Server will attempt to use any and all of these names that are currently active when using Windows Authentication.
For example, I am a consultant that works for several clients during the week. I logon my notebook with a local account, and my notebook is not attached to any domain. When I try to connect to SQL Server at a client site (either in an application or using Ent Mgr), it cannot know my domain account for that site to use. However, once I run a net use command to log onto a domain resource, it now has an identity to try, and SQL Windows authentication will work. I keep several scripts for network resources for each site I go to, just for this purpose.
Mark -
Try creating an alias for the server under "Client Network Utility". I have gotten this same error and solved it by switching to named pipes but an alias my work as well if you don't care to use named pipes.
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply