SQL connection failed with SSMS on workgroup when using FQDN

Question

SQL connection failed with SSMS on workgroup when using FQDN

matteu31 512

Hello,

When I try to connect locally (or remotely) with SSMS on my SQL server with hostname "localhost" or "hostname" it works fine.

However, if I try with "hostname.domain.com" it doesn't work I have error 18452 (Login failed. The login is from an untrusted domain and cannot be used with Windows authentication).

Can you explain me if I can solve it or it's by design ?

0 comments

Answer accepted by question author

Rukshan edirisinghe 0

Hi@matteu31 ,

Short answer: this is expected behavior for Windows Authentication in a workgroup when you connect by FQDN, and yes it can be worked around.

Why it happens: connecting by "localhost" or "hostname" uses NTLM, which works locally in a workgroup. When you connect by "hostname.domain.com", the client instead tries to get a Kerberos ticket for that name. Kerberos needs a domain controller and a registered SPN, and your server is in a workgroup with neither, so authentication can't validate your Windows principal, and you get 18452 (untrusted domain / unrecognized principal). Error 18452 specifically means the login uses Windows Authentication, but Windows can't verify the account, which is exactly the workgroup case.

Ways to solve it:

Use SQL Server Authentication for the FQDN connection. Enable Mixed Mode on the server, create a SQL login, and connect with that instead of Windows auth. This is the clean fix in a workgroup and removes the Kerberos dependency entirely.

Keep using Windows auth by connecting with the hostname or IP instead of the FQDN, so it stays on NTLM. For remote machines, this requires the same username and password to exist as a local account on both the client and the server (workgroup NTLM pass-through).

So it's not a bug. Windows auth over an FQDN relies on domain infrastructure that doesn't exist in a workgroup. Use SQL auth for FQDN, or stick to hostname/IP with a mirrored local account for Windows auth.

Erland Sommarskog 136.6K Reputation points MVP Volunteer Moderator

2026-08-22T12:15:03.5533333+00:00

When you connect by "hostname.domain.com", the client instead tries to get a Kerberos ticket for that name. Kerberos needs a domain controller and a registered SPN, and your server is in a workgroup with neither

So why then did it work for me? I definitely do not have a domain controller - unless this is a function in my router that I am unaware of.

2 additional answers

Your answer

Erland Sommarskog 136.6K Reputation points MVP Volunteer Moderator

2026-08-22T12:15:03.5533333+00:00

When you connect by "hostname.domain.com", the client instead tries to get a Kerberos ticket for that name. Kerberos needs a domain controller and a registered SPN, and your server is in a workgroup with neither

So why then did it work for me? I definitely do not have a domain controller - unless this is a function in my router that I am unaware of.

Answer 1

AFAIK, that's by design. As per https://learn.microsoft.com/en-us/sql/relational-databases/errors-events/mssqlserver-18452-database-engine-error?view=sql-server-ver17 this behavior is expected when you use the SQL Server's FQDN with Windows Authentication.

The hostname can work because Windows can establish the connection using local/workgroup credentials. When you specify hostname.domain.com, Windows Authentication attempts to authenticate the Windows identity against the domain associated with that FQDN. A workgroup computer does not have the domain trust relationship required for that authentication, so SQL Server receives credentials that cannot be validated and returns 18452.

You can obviously work around this by using hostname, SQL Server Authentication, if enabled and permitted, or by running SSMS under domain credentials from the workgroup computer, for example with runas /netonly using a domain account. The latter should allow you to use remote Windows authentication with domain credentials even though the workstation itself remains in the workgroup.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

matteu31 512 Reputation points

2026-08-21T21:15:14.93+00:00

Hello,

Thanks for your answer.

I saw this article too yes, I would like to get a "deeper answer" thant what it's in it ^^.

In my setup, it's when I use Veeam. Veeam (linux machine) is in workgroup, and I have a SQL server in workgroup too.

I give Veeam local account from SQL server but it doesn't connect when using FQDN.

I saw I can use SQL auth but not allowed here.

You confirm me it's normal I can't use FQDN on this scenario and I will just use the "workarround" known as use the netbios name.

Answer 2

Erland Sommarskog 136.6K MVP Volunteer Moderator

Windows authentication in workgroups are always problematic, since there is no AD to talk to. As you may know, the only way authentication can work is that username and password are the same. That is not what you are running into here. But it could be something else that is also due to the lack of an AD controller to broker things.

I will need to confess that I don't know how you can connect a computer in a workgroup to a domain, so I cannot set up a test.

But thinking aloud. You have logged on to COMPUTER1, and you are now connecting to COMPUTER2.domain.com, and these two names are not in the same domain. But if you would instead log on to COMPUTER1.domain.com, maybe it would work. Not that I know how you would do that in Windows...

matteu31 512 Reputation points

2026-08-21T20:41:25.2866667+00:00

Hello,

Thanks for your answer.

I mean, you can reproduce it easely :)

You build a windows server on workgroup and create DNS record to it on your domain zone.

The server is not domain joined but you can resolve it with your DNS and not netbios resolution.

Just keep it simple and try it locally :)

if you enter "localhost" on SSMS it works.

If you enter "computer" it works

If you enter "computer.domain.com" it doesn't work.

I hope you understand what I mean because english is not my first language :)
Erland Sommarskog 136.6K Reputation points MVP Volunteer Moderator

2026-08-21T20:58:30.3866667+00:00

You build a windows server on workgroup and create DNS record to it on your domain zone.

Domain zone? I'm not sure that I know what that is or if I have one.But I went into my router and set up a domain name. Then I tried to connect to an SQL Server on my desktop from my laptop, both by computer name alone and with FQDN. Both worked. I think that this is because I set this up in the router, the laptop also picked up the domain name, so that it matched the desktop.

In this case, both computers are running Windows 11. I have Windows servers on VMs, but they are not known to the router.
matteu31 512 Reputation points

2026-08-21T21:07:31.1233333+00:00

If your domain is domain.lan

That means you have a DNS server hosting the domain.lan zone.

I just create a record on that DNS zone (domain.lan) and I call it computer.

Then I can resolve computer.domain.lan

You can try to ping computer.domain.lan to be sure it resolves first.

My setup is SQL 2022 and SSMS 2022 with "default" configuration.
Erland Sommarskog 136.6K Reputation points MVP Volunteer Moderator

2026-08-21T21:17:14.66+00:00

Yeah, I guess that this is what I did when configured a domain in my router. And as I said, I was able to connect with COMPUTER.sommarskog.com. So the answer to your original question is: Yes, it is possible connect with FQDN in a workgroup, but you need to set up the domain so that both computers understand that they are part of the domain.