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

Question

I've just installed SQL Server 2008 Developer edition and I'm trying to connect using SQLCMD.exe, but I get the following error:

H:\>sqlcmd.exe -S ".\SQL2008"

Msg 18452, Level 14, State 1, Server DEVBOX\SQL2008, Line 1

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

The SQL Server instance is configured to use SQL Server and Windows Authentication mode. If I specify -U sa then I can log in successfully, but I'd like to use windows authentication. Connecting using SSMS with windows authentication seems to work fine.

Answer 1

I had this issue and it was because the machine running the application isnt trusted for delegation on the domain by active directory. If it is a .net app running under an application pool identity DOMAIN_application.environment for example.. the identity can't make calls out to SQL unless the machine is trusted.

Answer 2

You're not passing any credentials to sqlcmd.exe

So it's trying to authenticate you using the Windows Login credentials, but you mustn't have your SQL Server setup to accept those credentials...

When you were installing it, you would have had to supply a Server Admin password (for the sa account)

Try...

sqlcmd.exe -U sa -P YOUR_PASSWORD -S ".\SQL2008"

for reference, theres more details here ...

Answer 3

In my case, this error was caused by renaming my client machine. I used a new name longer than 13 characters (despite the warning), which resulted in the NETBIOS name being truncated and being different from the full machine name. Once I re-renamed the client to a shorter name, the error went away.

Answer 4

Just tried this:

H:>"C:\\Program Files\\Microsoft SQL Server\\90\\Tools\\Binn\\sqlcmd.exe" -S ".\\SQL2008" 1>

and it works.. (I have the Microsoft SQL Server\\100\\Tools\\Binn directory in my path).

Still not sure why the SQL Server 2008 version of SQLCMD doesn't work though..

Answer 5

Your error is quite literally saying "you're trying to use Windows Authentication, but your login isn't from a trusted domain". Which is odd, because you're connecting to the local machine.

Perhaps you're logged into Windows using a local account rather than a domain account? Ensure that you're logging in with a domain account that is also a SQL Server principal on your SQL2008 instance.

Answer 6

I was getting this error too, although my issue was that I kept switching between two corporate networks via my Virtual Machine, with different access credentials. I had to run the command prompt:

ipconfig /renew

After this my network issues were resolved and I could connect once again to SQL.

Answer 7

Just found this thread and posted an alternative answer (copied below) here: https://stackoverflow.com/a/37853766/1948625

Specifically on this question, if the dot " . " used in the -S value of the command line means the same as 127.0.0.1 , then it could be the same issue as the connection string of the other question. Use the hostname instead, or check your hosts file.

---

Old question, and my symptoms are slightly different, but same error. My connection string was correct (Integrated security, and I don't provide user and pwd) with data source set to 127.0.0.1 . It worked fine for years.

But recently I added a line in the static host file for testing purposes ( C:\\Windows\\System32\\drivers\\etc\\hosts )

127.0.0.1           www.blablatestsite.com

Removing this line and the error is gone.

I got a clue from this article ( https://support.microsoft.com/en-gb/kb/896861 ) which talks about hostnames and loopback.

Other possible fix (if you need to keep that line in the hosts file) is to use the hostname (like MYSERVER01 ) instead of 127.0.0.1 in the data source of the connection string.

Answer 8

Do you specify a user name and password to log on? What exactly is your complete command line?

If you're running on your own box, you can either specify a username/password, or use the -E parameter to log on with your Windows credentials (if those are permitted in your SQL server installation).

Marc