Authentication and authorization in Samba 4

Volker Lendecke is one of the first contributors to Samba, having submitted his first patches in 1994. In addition to developing other important file-sharing tools, he's heavily involved in development of the winbind service, which is implemented in winbindd. Although the core Active Directory (AD) domain controller (DC) code was written by his colleague Stefan Metzmacher, winbind is a crucial component of Samba's AD functionality. In his information-packed talk at FOSDEM 2018, Lendecke said he aimed to give a high-level overview of what AD and Samba authentication is, and in particular the communication pathways and trust relationships between the parts of Samba that authenticate a Samba user in an AD environment.

AD has been Microsoft's central user database since the days of Windows 2000. Before that, NT 4 had a flat user database. It had a GUI limit of 40,000 users and was clumsy to use when you got anywhere near that limit, but it worked. Microsoft moved to LDAP as the database and Kerberos as the authentication protocol, and AD was born.

The LDAP database is multi-master replicated, and suffers from all the problems that multi-master replication brings. The database itself has a highly-specific LDAP schema with custom extensions; native AD has a lot of internal magic and validity checks to ensure that the requirements of that schema are met at all times.

Authentication is challenge-response based, which is something he came back to in more detail later. AD also contains a DNS server element, and Microsoft used a standards-based approach to doing domain controller lookups using SRV records. AD allows trust relationships to be set up between domains. Lendecke noted that while it's typical for academic deployments to have a single domain across the entire university, in corporate environments it's quite common to find complex trust relationships between dozens or even hundreds of domains.

Samba started in the 1990s as a compatible file server for DEC PATHWORKS. It implements many protocols used by Microsoft: SMB for file sharing, SMB and DCE/RPC for print services, RPC for user database services, and Kerberos, LDAP, and DNS for the domain controller element. It is an NT 4-compatible domain controller, and both an AD domain controller and domain member, the latter being important in making AD user and group information available to Unix.

To avoid doubt going forward, Lendecke reminded attendees of the distinction between authentication (proving who you are) and authorization (having proven who you are, establishing what you are allowed to do). In AD, authorization is largely handled by group memberships: a user is usually a member of a large number of groups, each membership permitting access to a different set of resources.

Authentication

Lendecke then looked at different ways of authenticating by password, comparing the Unix transmit-the-password approach of FTP/telnet/SSH-by-password with Microsoft's challenge-response model. The critical distinction he sees is that, in the former cases, the password is transmitted from client to server, whether dangerously in plaintext (as FTP and telnet do) or safely under cover of an encrypted channel (as SSH does). This means that the server never needs to keep the password stored in plaintext. The password can be stored in an unrecoverable (hashed, salted) form, because the server will temporarily have the plaintext password offered by the client to salt and hash for comparison and verification.

In a challenge-response world, a nonce is transmitted from server to client. Both sides perform a similar operation on the nonce based on the password, then the client transmits its result to the server for validation. This requires the server to store the user password (or an equivalent) in plaintext for the long term. Lendecke notes that this allows the authentication server to impersonate any of its users to other machines, which is not true in a Unix world. He clearly prefers the Unix approach ("I always have to think very hard to make sure that Kerberos is actually safe").

In pre-AD Microsoft days, this authentication was accomplished by Microsoft's Challenge-Response Authentication Protocol. Lendecke noted this protocol completely deserved its acronym (CRAP) in the old OS/2 days, though by the days of NTLM v2 it had become quite good. Nevertheless, under this regime every single authentication event required communication with a domain controller. For certain workflows like HTTP authentication (with many short-lived requests), this could put a lot of load on the DC.

Under AD, authentication happens through Kerberos, which is a cryptographically secured ticket-based system. When you authenticate, the server gives you a signed ticket that you can then present to other servers when you want access to services. Those servers can verify your ticket without recourse to the DC. This means greatly reduced load on the DC, but the downside is that the protocol is extremely picky. Lendecke noted that all clocks must be in sync (though he accepted that is mostly solved these days), and that the DC must be contacted by its hostname. If you contact it by IP address, by a hostname mapped via CNAME, use a local /etc/hosts entry, or your DNS gets corrupted, Kerberos just doesn't work. Finally, under AD, NTLM must always be available as a fallback method in case Kerberos is not working. In response to an audience observation, Lendecke said he is often surprised by how many sites do not, in fact, have working Kerberos, but simply don't know it because everything is kept working by old-style NTLM authentication.

The presentation then turned to roles in authentication. Obviously, users have passwords and use them for authentication. But machines have passwords too, which they use to prove that they've been joined to the domain by an administrator. They can also use the DC's knowledge of these to validate the DC's identity: trust can be established in both directions. So, said Lendecke, enter Samba winbind, which is the daemon that is responsible for all of the traffic that he'd been discussing.

Winbind connects to the domain controller. In multi-site deployments it is important to be talking to a DC on the local area network, if one is available, rather than one on the far side of a high-latency link. The knowledge of which DCs are local is contained in the AD, but Lendecke said that it can be surprisingly complex to establish which is the best DC to talk to. Having selected an appropriate DC, winbind establishes an authenticated, encrypted channel to it for authorization purposes.

Lendecke noted that part of the protocol involves machines regularly updating their machine passwords, for security, and how complex that can be in a multi-master replicated environment. If the DC to which a machine has just given its new password dies without passing that on to the other DCs, or if the password change is accepted by all the DCs but the write of the new machine password to local disk fails, the machine will fall off the domain. AD implements a number of checks to prevent that from happening for Microsoft machines, so winbind has to as well.

Winbind provides an external interface through /tmp/.winbindd/pipe. This interface is extremely simple — some would say too simple — it has fixed-size requests (e.g. usernames can't exceed 256 bytes, but who cares, said Lendecke) and it just works. Samba provides PAM and NSS modules for hooking your Unix authentication to AD via winbind, for those who wish to do so. Lendecke noted that a design principle of winbind is that it tries to do exactly what Windows does and nothing else. That is all anyone can rely on, because anything else they try to do might break.

Authorization

Having discussed authenticating the user, Lendecke moved onto authorization. As he said earlier, access to files and other resources is primarily determined by the user's membership in groups. Because in AD (and unlike Unix) groups can themselves be members of other groups, this membership is a complex calculation. It is determined by the AD DC, and only when a user successfully authenticates. Any attempt to determine this important list of group memberships at any other time is prone to break.

This means, he said later, that while user foo authenticating and then doing id will see their list of groups, "sudo id foo" does not work and never can. It is simply not possible to calculate the list of group memberships reliably at any time other than when the user authenticates with their own password, not least because Windows doesn't calculate the list at any other time. As he'd said, Samba cannot reliably do anything that Windows doesn't do. People who don't get this are working under what Lendecke finds is a common misunderstanding.

So winbind handles authentication and authorization. But it also handles the mapping of Windows UIDs (which it calls Security IDs or SIDs, but these are fundamentally just rather oddly encoded 128-bit UIDs) to Unix 32-bit UIDs. There are an awful lot of different ways to do this mapping; Lendecke wishes that Unix supported 128-bit UIDs, because it would relieve winbind of having to do it. He noted he could give an entire talk about the remapping process — a talk that I would very much like to hear. Winbind also provides NSS information such as home directory and login shell to Unix.

Winbind's ability to do this depends on it being able to talk to the DC. It can talk to the controllers of the domain of which it is a member because it has a set of machine credentials that enable this. But given the inter-domain trust relationships that he mentioned earlier, it will need information from other trusted domains, and it has no credentials with which to get it. This means winbind must ask its DCs to get the information, which first means enumerating the trusted domains.

In the old NT 4 days this was simple, because only direct non-transitive trust relationships were allowed. But now trust relationships are transitive — if domain A trusts domain B, and domain B independently trusts domain C, then domain A effectively trusts domain C. Domain A's winbind daemons will need its DCs to access information from domains B and C. This is not simple, and has some hard-to-diagnose failure modes that can arise from things like misconfigured DNS and badly-configured firewalls sitting between different domains' DCs.

Finally, he reviewed winbind's NSS contribution. If Samba is going to handle authenticating users under Unix, it will have to provide Unix with the data that /etc/passwd and /etc/group have traditionally provided: a Unix UID, a primary GID and supplementary Unix group memberships, a home directory, a login shell, and so on. Most of these things do not normally exist inside AD, though with the Services For Unix (SFU) schema extension there is a place for them, and winbind will pass them back into Unix. Every user can now have an AD-stored Unix UID different from their Windows SID, and (as of Samba 4.6) an AD-stored Unix primary group different from their Windows primary group (which in most cases is simply, and somewhat unhelpfully, "Domain Users").

A video of the talk can be seen at the FOSDEM site. It's a dense talk, but for anyone who's trying to support a Windows network with free software, it's a highly useful one. At FOSDEM it is a frequent complaint at that the room is too small for the demand, but for the Samba talks (including the two covered in a previous article) demand was extremely high: by the end, there were many more people queuing outside the room for seats as there were seats inside the room. If it were possible to get a bigger room for these talks next year, that would be good, for I got the feeling the time has very much come for talks of this sort.

[We would like to thank LWN's travel sponsor, the Linux Foundation, for travel assistance to Brussels for FOSDEM.]