Microsoft Windows workstations users practice the browsing of network file and print resources as the natural way to achieve daily tasks, yet few are aware of how this works. The ability to browse network resources via the Microsoft Windows Explorer is an expected capability. When this ability is impaired, the user's frustration is readily elevated. What a user considers as simply the process of browsing is comprised of a large number of complex processes, all of which must function correctly so that the user can experience expected behavior.
The browsing of network resources is possible by way of creating:
- Special broadcast announcements made by Windows network clients and servers.
- Machines -- selected through an election mechanism and called browse masters -- on the network that listen for the special broadcast messages.
- Name resolution processes that permit the translation of a NetBIOS machine name to a TCP/IP address.
- Establishment of a connection to a Windows file share.
- All these mechanisms must work in harmony; otherwise, the expected user experience is lost.
The establishment of a connection is the vital step that enables access to a remote file. The Windows client provides a user name and password as part of the data request to create the network connection. The user name and password may both be empty (the null account), or the password may be empty (null password).
The use of the null account is common when creating a connection to the IPC$ share on a target Windows networking server like a Samba server. The IPC$ share is used by the network client to obtain the list of resources (shares and printers) that are available on the server. When a resource has been selected, a connection is created between the client and the server to enable the resource (share or printer) to be used by the network client. The connection request is refused if the credentials that are provided by the client are refused by the server.
This article is primarily concerned with the behavior of a Samba server and does not deal with Microsoft Windows network servers.
Samba authentication
The authentication methodology that is used by a Samba server depends on how it has been configured, as well as whether or not Winbind is in use. If Winbind is in use, smbd, the Samba process that performs all network connection handling, will ask Winbind to process the authentication request for the network connection setup request. If Winbind is able to perform authentication, handling it will return to the smbd process that called it either a pass or fail.
If Winbind is not able to resolve the validity of the network user's credentials or is not available -- for example, it is not running -- the responsibility for determining whether or not the network connection request should proceed is handled by smbd. In this case, smbd will attempt to look up the user in the passdb back end that has been specified in the smb.conf file. If the smb.conf file does not specify a passdb back end, smbd will use the default passdb back end (smbpassswd). The user name and password are validated against the encrypted credentials that are stored in this back-end database.
As I said earlier in this article, Samba has to deal with two dissimilar environments: the Unix or Linux host, where Samba runs as a service, and the Windows network of workstations and servers. Samba must obey the rules that are imposed by both environments. The authentication of Windows network operations requires access to the Microsoft encrypted passwords that are stored in Samba's own password back end.
Samba refers to this as part of the Samba security account manager (Samba SAM) data. The SAM information database (passdb back end) contains all the Windows-specific account information that is not used by the Unix/Linux environment.
User/group name and security identifier handling
When the connection to the share has been established, further access to shared network resources requires an user identifier (UID) and a group identifier (GID) on the Unix or Linux host server for the remote Windows user. This requires fully functional forward and reverse name to Unix or Linux identifier resolution. This requirement exists because a Unix or Linux host requires a UID and GID pair to determine access rights that are applicable to the remote Windows network user for all Unix file system access operations.
The windows user has the capacity to modify file security settings and access controls using the Windows Explorer. For this to function correctly, there needs to be a reliable and reproducible method for resolving user names to the matching Windows system identifier (SID). The reverse is also necessary. The Windows user SID is critical to the use of a tool, such as Windows Explorer, for the handling (setting and reporting) of file and directory security settings. This requires the ability to map a UID or a GID from the Unix/Linux file system to a unique Windows SID, and demands a consistent mapping of the Unix/Linux user name or group name to a Window user name or group name. The mapping must be unambiguous.
Every Microsoft Windows operating system has a unique machine security identifier (the machine SID). Likewise, a Microsoft Windows security domain also has its domain SID. User and group accounts that are created within either context are assigned a sequential security identifier that is relative to the security context. This identifier is known as the relative identifier (RID) and is added to the end of the SID for the security context within which it has been created. This means that when a user account is created for a user called adaniel on a collection of Windows NT/200x/XP machines, each account will have its own unique user SID. The user SID thus being made up of the machine SID concatenated to the user RID.
Windows accounts (user, group, machine, trust, etc.) are assigned a RID. This is done automatically as an account is created. Samba produces the RID algorithmically. The Unix operating system uses a separate name space for the UIDs and GIDs, but Windows allocates the RID from a single name space.
A Windows user and a Windows group cannot have the same RID. Just as the Unix user root has the UID=0, the Windows administrator has the well-known RID=500. The RID is concatenated to the Windows domain SID, so administrator account for a domain that has the above SID will have the user SID S-1-5-21-726309263-4128913605-1168186429-500. Outside of the well-known accounts that have a globally consistent RID, the RIDs are allocated starting at RID=1000. The RID is appended to the SID of the machine with the result that every account in the Windows networking world will have a globally unique security identifier.
In the Windows environment, user, group and trust accounts are all allocated a sequential number from the same name space (the RID). In the Unix/Linux environment, the UID and GID are independent entities providing each its own name space.
Samba obeys the security constraints that are normative to the host operating system on which it is running, as well as that of the Windows clients it serves. This means that the translation (or mapping) of Windows users and groups, Windows SIDs, Unix UIDs and GIDs, and Unix account names must be possible in a manner that is entirely unambiguous at all times. This is an important matter that Unix administrators often overlook.
Samba SAM information location
Information that is specific to the local Samba server is stored in the file /etc/samba/secrets.tdb. The domain SID, as well as the local server SID, is stored in this file. When Samba-3 is used with the LDAP passdb back end, the LDAP administrator password is also stored in the secrets file. When Samba is a domain member server, the domain membership account secret password is also stored in the secrets file.
Where the tdbsam passdb back end is used, user account information is stored in the (default) file called /etc/samba/passdb.tdb and contains the extended Samba SAM account information that can also be stored in an LDAP directory in the event that the ldapsam passdb back end is chosen.
Samba-3 can make concurrent use of multiple passdb back ends, making Samba-3 highly scalable, thereby permitting it to meet the needs of small, as well as very large, sites.
Unix groups can be made available to Windows users by creating a group mapping. The group mapping is part of the Samba SAM account information data and is stored either in the file /var/lib/samba/group_mapping.tdb (when using tdbsam) or in an LDAP directory (ldapsam).
User rights and privilege information, together with domain access controls, are stored in the file /var/lib/samba/account_policy.tdb. ACL access controls on shares are stored in the /var/lib/samba/share_info.tdb.
As of Samba version 3.0.21, the account policy information will be stored in the LDAP directory when the primary passdb back end specified is the ldapsam. Samba versions earlier than 3.0.21 did not replicate policy information via the LDAP directory, thus making it necessary to manage policy settings on all domain controllers. Version 3.0.21 automatically replicates policy information to all domain controllers (as happens with Windows NT4).
The tdb files store binary hashed data, the contents of which can be dumped to a plain ASCII format using the tdbdump utility. For example, the content of the secrets.tdb file can be exposed by executing:
linux:/etc/samba # tdbdump secrets.tdb
{
key = "SECRETS/SID/LINUX"
data =
"\01\04\00\00\00\00\00\05\15\00\00\000\DE\06\F4\FB\C0\AD\D3d\D7\1E\9C\00
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00"
}
Summary
This article has begun the process of untying the knot that protects those secrets of Samba domain administration. It has been established that the security identifiers differ greatly on Samba host platforms from that of the Microsoft Windows world. A brief explanation has been given to show how Samba manages security identifier interoperability.
The next article will compare Windows and Samba user rights and privilege management. Now that some of the darker secrets regarding Linux and Windows security identifiers have been covered, we are ready to move on to explore the tools that can be used to manage make efficient use of them.
Click here to go back to the introduction to this series.
No comments:
Post a Comment