Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Okay, so here's the problem. I have an application I need to install and run locally for testing and debugging. The application has been designed to run on a domain and as such expects to log into the database using domain credentials.

I can't modify the section of code that handles the logins without a serious amount of work which I don't have time for this week, nor do I have any ability to add the machine hosting the database to the domain (contractors machines aren't allowed to be added to the domain under the I.T. policy).

So I'm in a bit of a bind. I cannot use the CREATE LOGIN [DOMAIN\User] From Windows routine as I get the following error:

Windows NT user or group 'DOMAIN\User' not found. Check the name again.

I can't just insert into the relevant security tables: sys.server_principals table, sys.SysLogins etc. because

Ad hoc updates to system catalogs are not allowed.

Is there any way I can back door my local SQL Server installation to accept these user credentials from the application without being attached to the domain?

Of course adding the machine to the domain and logging in as a domain user would resolve this issue in a couple of minutes, but political issues prevent that from happening.

share|improve this question
FROM WINDOWS requires that the login can be found and verified from Windows. If your SQL Server isn't on the domain, what is the point of adding a domain user? – Aaron Bertrand Oct 12 '13 at 0:33
@AaronBertrand perhaps I misunderstand what this is doing in SQL server, but the software application is attempting to log into SQL Server using Windows Authentication... unfortunately it's using a domain account and the SQL Server doesn't have access to the domain, so I'm attempting to hack in a temporary "fix" just so I can debug some issues... – BenAlabaster Oct 13 '13 at 16:57
Sorry but hacking in a temporary fix would defeat the whole purpose of security. If the app and/or SQL Server are located such that you can't reliably authenticate on the domain, stop using Windows auth. – Aaron Bertrand Oct 13 '13 at 19:11

You cannot actually login to SQL Server with any domain account. You can either pass a SQL Login with its password, or you can logon using "Windows Authentication". What the latter means is that the account that is executing the windows executable is passed to SQL Server to authenticate.

That means you just need to execute the app using a local machine account and add that account as a windows login to SQL Server.

If the application on the other hand is running on a domain computer and you just pointed it to use SQL Server on your machine, you are out of luck. However, if you were able to change the connection string to point to your machine, you should be able to just add a SQL Login to that same connection string.

share|improve this answer

Create a local windows user and add that local user to the SQL Server instance.

share|improve this answer
Would that work given that the app would be passing a domain identity, not a local user identity? – user29300 Oct 11 '13 at 21:37
Actually the error message says "Windows NT user or group... not found." But a local machine account is a Windows account which is in the ServerName domain and, if granted access, should be able to login to the SQL Server. – RLF Oct 11 '13 at 22:05

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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