I have two SQL Server 2016 instances running on localhost, and I can connect to both with no issues (localhost and localhost\test) using windows authentication. However, if I specify the port explicitly in SSMS ("localhost,1433" or "localhost,1435", respectively), I receive the following error:

Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. (Microsoft SQL Server, Error: 18452)

I'm connecting to a local instance (it's not a domain PC, but it shouldn't matter) and I'm a local admin, so there are no permissions issues - when I connect without the port specified, I connect without any issues at all.

I've seen this error when connecting across domains or in a workgroup, but that's not what's happening here as I can connect if I remove the port number.

  • Did you check sqlservercentral.com/Forums/1889476/… – Md Haidar Ali Khan Apr 24 '18 at 4:46
  • @MdHaidarAliKhan The issue in the case was the SPN, something with Kerberos and domains. I'm dealing with a stand-alone server with a workgroup, and I'm accessing it locally (so there's no remote authentication involved). Thank you for the reference, though - at this point, I'll read anything! – SqlRyan Apr 24 '18 at 4:58
  • What type of account are you using to connect? Sql or windows? – Aaron Jul 23 '18 at 1:56
  • I am not sure what the reason for the denial authentication is, but I suspect the difference between specifying the port or not is that in case of specified port your connection uses TCP whereas in case without it uses a named pipe. For TCP it cannot rely on peer credentials from the socket. – eckes Jul 28 '19 at 13:32

So, we just had this problem, adding details in case it helps someone else and they don't spend time going down the rabbithole of Kerberos debugging like we did.

I don't have all the details because our next level tier fixed it, but apparently in our case since we had a cross-forest trust authentication, the issue was that we needed to grant the user's group "Allowed to Authenticate" permission on the server object they were trying to connect to, after that it worked fine.

we had a win2k16 server running Sql2017 in domain1, and users running win7 in domain2 with trusts setup between the two, this worked fine.

But when the users migrated to win10, they received the above error. Fix for us was granting 'allowed to authenticate' to the domain user group in domain2 on the server in domain1, then win10 worked fine.

If anyone knows why upgrading client OS makes any difference please let us know!


If you have named instances and don't want to declare your ports then you need to ensure that SQL Server Browser is running

By default this runs through port UDP 1434

Also try below steps if you are connecting using the port number

  • create manually a SPN for the SQL service (we use managed service accounts)

  • add a localhost entry in the host file

  • check that the TCP and Named Pipes protocols are enabled

  • check if firewalls are disabled on your local machine from where are you connecting, do you have all the AD User auth ports opened.

  • SQL Browser is running and I can connect when I provide the instance name ("localhost\test", or even connecting to the default instance via "localhost"). It's when I specify a port ("localhost,1433") when I get the error. It's not a firewall or port issue - I'd get a timeout if it was, but I'm getting an "untrusted domain" error instead. Removing the port and it connects without issue. – SqlRyan Apr 25 '18 at 5:10

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.