Any discussion about authentication is fruitless without including the topic of users. After all, the users are the ones being authenticated. As early as Chapter 2 we have seen some basic utilities that can be used to create a user account (i.e., the smbpasswd tool). However, we have not really talked about what the smbpasswd and similar utilities actually do. Here we break the discussion into two parts. We cover the various ways that user account information can be stored, followed by a explanation of the user management tools provided by Samba. First, we expand upon the discussion of Windows SIDs that we started in Chapter 1.

Security Identi?ers

A Windows security identifier (SID) is a collection of numbers combined into a binary blob that uniquely identifies an object such as a user, group, or computer. The common string representations of a SID is written as:

  S-1-5-21-3489264249-1556752242-1837584028-1003

It is impossible to determine what type of object the SID represents by its value alone. It could be a user or a group or something else. Windows (and Samba) provide calls to convert this SID to a name and to obtain its type.

The structure of a SID can be broken down into four parts:

1. The revision (S-1)
   
2. The number of authorities and subauthorities (5)
   
3. The top-level authority (21)
   
4. One or more subauthorities (3489264249-1556752242-1837584028-1003)

The last 32-bit number in the list of subauthorities is referred to as a relative identifier (RID). To be completely accurate, each 32-bit number of the subauthority list is a RID, but generally people use the term only to refer to the last number in the list. In this example, the RID is 1003.

Removing the RID from the original SID leaves us with an identifier that represents the SID’s security domain. A security domain is not necessarily the same thing as an authentication domain (as discussed in Chapter 1), although there is a relationship between the two. In our example, the security domain would be S-1-5-21-3489264249-1556752242-1837584028. Each Windows host has a machine SID that defines its local domain. On domain controllers, the domain SID is identical to the local machine SID.

You can view Samba’s local machine SID by logging on as root and running the net command from a shell prompt.

  root# net getlocalsid
  SID for domain RAIN is: S-1-5-21-3489264249-1556752242-1837584028

The concepts of local and foreign security domains do not neatly match up to Unix hosts, which have one authentication domain, based on an entry in /etc/passwd. Even when a network of hosts is configured to be part of an NIS domain (which should not be confused with a Microsoft domain), there is no distinction between users within the NIS map and those existing in the local /etc/passwd file.

From the Windows GUI, the distinction between local and remote domains can be seen from the initial logon box. Figure 5-1 shows the drop-down list of domains available when logging onto a Windows XP client. The local Administrator account is distinguished from the Administrator account in a foreign domain by prefacing the username with either the local machine’s name (LETTUCE\Administrator) or the name of the foreign domain (AD\Administrator). These are two different user accounts with different SIDs, even though they share the same login name of Administrator.

Figure 5-1.  Selecting the domain when logging onto a Windows XP client

In addition to the local machine security domain, all Windows and Samba hosts are expected to support the S-1-5-32 domain, which is called BUILTIN . Groups existing within this domain have predefined RIDs. For example, the BUILTIN\Administrators group has a SID of S-1-5-32-544 and the BUILTIN\Users group’s SID is S-1-5-32-545.

More information on SIDs and authentication domains is presented in Chapters 9 and 10.