Michael Tokarev
2022-Nov-25 08:14 UTC
[Samba] How does AD/SMB clients authenticate servers?
Hello! 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). Thanks, /mjt
On 11/25/22 03:14, Michael Tokarev via samba wrote:> Hello! > > 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). > > Thanks, > > /mjt >Yes, Samba has for years, even before AD was possible on Samba to use Kerberos to authenticate users and their machines. (Samba 3.x supported an Enhanced form of NT4 Domain that could have an OpenLDAP Backend, A Heimdal Kerberos realm, and a Samba Classic NT Domain all rolled into one, with multiple Primary Domain Controllers. It's a little outside the scope of your question. ?If you are asking if other services, such as Apache, DoveCot, and OpenSSH can use Kerberos from Samba 4.x to authenticate a Domain user, yes, they can. It provides a form of Single Sign on when this happens.
Kees van Vloten
2022-Nov-25 11:01 UTC
[Samba] How does AD/SMB clients authenticate servers?
On 25-11-2022 09:14, Michael Tokarev via samba wrote:> Hello! > > 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). > > Thanks, > > /mjt >SPN or UPN are Kerberos principals. You could say its acts as a user in Kerberos communication. The? encrypted password for this kind of user can be stored in the keytab. With that services can perform Kerberos communication with the KDC to authenticate their users (Kerberos is authentication only for authorization you need LDAP to verify group membership). Many services on Linux (and also on Windows) can be Kerberized. The advantage is that you get SSO without ever transferring a password over the wire. I am using this extensively in Apache for access to internal web-applications and also for Dovecot to get mail without storing the password in the mail-client but there are a lot more places where you can abandon password interaction. - Kees.