[Samba] How does AD/SMB clients authenticate servers?

Michael Tokarev mjt at tls.msk.ru
Fri Nov 25 08:14:57 UTC 2022


Recently I learned about SPNs and its usage with AD and SMB network.

In a nutshell, if there's a SPN (service principal name) stored in an AD
for a given server (service) name, the clients (at least windows) will
check the server validity.  This means that it will not be (easily)
possible to substitute that service with something else, - say, to
impersonate the service.

For example, I wont be able to set up a name on my personal computer in
the network that will be the same as the name of a file server used
in this network, and "redirect" (steal) traffic from the official
server to my machine, returning, say, modified executables to hack
into other users machines.

As far as I can see, when contacting some name (say, as a file server),
windows client checks for the presence of an SPN in the AD with the
given name (eg, when contacting name "FS" as a file server, it checks
for FS/CIFS at DOMAIN.TLD principal in the AD, or something like this -
the exact detail is not important by now).  If found (and such record
is unique!), this SPN is used when contacting the server, and the
client expects the server to prove it is him using kerberos.  So my
"unauthorized" server will be detected easily (in order to add/modify
SPN records, one has to have administrative rights in the AD).

But if an SPN is not found, (windows) clients does not try to verify
the "validity" of the server, so any name for which SPN does not exist
can be used to access such server, and the server will not have to
"prove its validity" for this name.  Including, for example, accessing
a server by its IP address (unless there's ip.add.re.ss/CIFS at DOMAIN
SPN is registered, of course).

Does it look correct?

And does linux client (samba) uses SPNs to verify "server validity"
like this?

(and it seems my setup with the same name to mean different things
depending on the location based on overriding CNAMEs does not work
for this reason: validity of such server can't be verified, and the
clients can - in theory - be tricked to access wrong, malicious server
instead of the right one, unless I'll do it some other way).



More information about the samba mailing list