I have SQL Server Express installed locally on a machine and it works most of the time but occasionally it fails to make a connection with this error:

Could not obtain information about Windows NT group/user 'MYDOMAIN\myUser', error code 0x6fd.

I'm at a loss for what to change. I can't guarantee the laptop can see the domain controller at all times because - well - it's a laptop! But it would seem that has no effect anyway (it works when disconnected from the network usually; it fails when connected sometimes).

Here's the SQL Server connection string:

Data Source=localhost\MYINSTANCE;Integrated Security=True;Initial Catalog=myDbName;Connection Timeout=15

What should I do?

I've tried moving it to a localdb and using SQL authentication to the SQL Server Express instance. Both ways STILL FAIL with the "could not obtain information..." message. They succeed if there is no network at all, but they all fail if there is a network that isn't the domain one. Not sure what the next move should be...

  • 3
    If it's just a local connection, can you use a SQL login instead? No need to mess with the domain in that case. – LowlyDBA Nov 13 '14 at 14:20
  • How much time elapses between you clicking connect and the error message? – Mister Magoo Nov 16 '14 at 23:05
  • I don't know. I'm getting automated reports in from users computers. What are you thinking? – noelicus Nov 17 '14 at 7:35
  • SQL login does not work - it's still moaning about the domain user. Same with a localdb on the local machine :( – noelicus Dec 12 '14 at 16:27
  • If "SQL Login does not work", then you are not doing it correctly. SQL Logins do NOT need to talk to the Domain Controller. Either you are not really doing a SQL Login, or your SQL Server has not been set to allow mixed mode authentication. – RBarryYoung Dec 12 '14 at 17:54

When your machine is not connected to the network, it uses the cached information for authentication purposes. This is how you can take the laptop home and log on with your domain account. If you created a login for a domain account while you weren't connected to the domain and then they tried to log in with that account, it would fail because that information doesn't exist on your laptop and it can't reach the domain to authenticate the credentials.

When you are on the same network as the domain, your machine recognizes this and tries to communicate with the domain controller on regular intervals. When a communication failure occurs, your local machine is essentially orphaned at that time so any domain resources become unavailable until it can re-establish communication. If you disable your network connection and log off/on and then try I would bet it works fine. It might even work if just disable the network, I don't have a laptop to test this out on so I can't say with certainty. This is based on my understanding of Active Directory and experience so it might not be 100% accurate but it is definitely what I have observed. Like John M suggested, you might want to use a sql login since you are having problems.

|improve this answer|||||
  • I have tried SQL login and I have the same problem. Same with a localdb database. Because the user is still an AD user which can't communicate with the server it still throws a wobbly. – noelicus Dec 12 '14 at 16:26
  • You have to have an actual SQL Login to do that, you can't take your AD user account and use the SQL Login option in management studio. For instance you could try the sa account. This all assumes that you have changed the server authentication to SQL Server and Windows Authentication mode on the SQL Server, since the default is Windows Authentication mode. – Your_comment_is_not_funny Dec 12 '14 at 19:24
  • Your AD account was created essentially: CREATE LOGIN [YOUR\LOGIN] FROM WINDOWS whereas a sql login is: CREATE LOGIN [YOUR_LOGIN] WITH PASSWORD = 'A_PASSWORD' If I try to login using YOUR\LOGIN and your domain password using SQL authentication, it won't work because your domain password isn't stored inside the system tables. In fact, that doesn't work even when you are on the domain because that login is designated at a windows login and it is looking for a SQL login. A look at sys.server_principals will show you the logins and types. – Your_comment_is_not_funny Dec 12 '14 at 19:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.