Why am I getting a SSPI error in SSMS when accessing a server on a different domain using the servername but it works OK using IP Address

Question

When using SSMS on domain A with a domain A account, I connect to a server in (trusted) domain B using the IP address all good.
When using SSMS on domain A with a domain A account, I connect to a server in (trusted) domain B using the servername or fully qualified servername I get a SSPI error.

Things I have checked:
The SPN is all good.
I can ping the servername from the client and it fully resolves fine.
I can also run a PS test connection OK on 389.
Local Hosts file entry makes no difference.
No blockages on firewall ports that we can see.
I can connect using SQL auth to the servername, it's just a Windows domain account issue.

Answer 1

Hi @Saransvan ,

Please check that there is not a SQL Alias present in the machine's SQL client configuration, usually, SSPI is a general error, there are various reasons for the error, this is may a DNS issue, try to flush DNS cache

-------------

If the answer is the right solution, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

It's not a regular DNS issue as I can resolve via ping nslookup etc as I stated, tested that fully. No alias.

I think it's a trust issue - anyone any ideas?

Answer 3

I don't think this is the right answer, but try checking Trust Server Certificate, see below. (I would expect a different error message, it this was the issue.)

PS A DNS issue as suggested by Yufei sounds like a less likely reason to me. That would suggest that the name you use actually points to a different server, and you have an SSPI issue on that server. Certainly a bit far-fetched.

Answer 4

Hi, thanks those who tried to help. Got to the bottom of it in the end.
The domain (B) with the issue also has a parent, and although we weren't interested in anything in the parent, it seems that SQL needs to check it anyway.
So we added an additional DNS conditional forwarder and that resolved the problem, we can now connect by name.