2

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.

6
  • Did you check sqlservercentral.com/Forums/1889476/… Commented Apr 24, 2018 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
    Commented Apr 24, 2018 at 4:58
  • What type of account are you using to connect? Sql or windows?
    – Aaron
    Commented Jul 23, 2018 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
    Commented Jul 28, 2019 at 13:32
  • What happens if you specify the machine name Yourmachine,1433 Also why use TCP when you can use Shared Memory? Commented Aug 29, 2022 at 23:16

2 Answers 2

0

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!

-2

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 127.0.0.1 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.

1
  • 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
    Commented Apr 25, 2018 at 5:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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