5.1. Enabling Domain Controller Functions
Samba's domain control features enable it to provide authentication services for Windows 9x/Me, Windows NT/200x/XP, Linux, and various other operating systems. Used in this way, the domain controller client (which may itself be a server to other computers) uses the account database on the domain controller to authenticate users. In order to support this functionality, Samba requires that you set a few smb.conf parameters. This part of the domain controller configuration isn't the tough part, though; you must also maintain an encrypted password database for your users and also keep machine trust accounts, which enable Samba to authenticate the machines that are asking for authentication services. Many domain controllers also deliver a few special share types, which you might want to configure on your domain controller.
5.1.1. The Role of a Domain Controller
An NT domain controller serves as a backend for authentication requests directed at an SMB/CIFS server, as illustrated by Figure 5-1. Samba servers can actually take on the role of the NT domain controller, the SMB/CIFS server (a.k.a. the domain member server), or both systems. Linux or other Samba-using systems can also function as SMB/CIFS clients, as described in Chapter 6.
Figure 5-1. NT domain controllers regulate access to other servers' shares
Figure 5-1 most accurately depicts one of two major authentication methods supported by NT domain controllers and Samba. Specifically, this figure depicts pass-through authentication, which is used by Windows 9x/Me domain members and Samba file servers when you set security = Server in their smb.conf files. Even in this case, Figure 5-1 presents a simplified view of the exchanges involved. Windows NT/200x/XP computers and Samba servers configured with security = Domain use a more complex arrangement, known as NetLogon authentication, in which the domain member server contacts the domain controller and obtains enough information from the domain controller to authenticate users itself, using data from the domain controller, rather than a local password file. Both systems look the same to SMB/CIFS clients. In fact, from the client's point of view, these systems are also indistinguishable from one in which servers use local authentication databases.
Not all Windows networks use domain configurations. Simpler networks use workgroup configuration, which are essentially NT domains without domain controllers. Workgroups are easier to configure, but they're missing some of the features provided by domain controllers, such as the ability to use a central authentication database and to store local user configurations on a central server.
The advantage of a domain configuration, at least in terms of authentication, is that you need to maintain a user password database only on one system. Consider a network with half a dozen SMB/CIFS servers. If your users had to maintain separate passwords on all these servers, they'd either never change them or they'd forget all the different passwords. Your system administration task would also be more difficult in this case, because you'd need to explicitly create and delete accounts on all six servers. In a domain configuration, though, only one password database needs to be maintained, which greatly simplifies administration and users' own account maintenance tasks.
Frequently, the domain controller serves as a file and print server, in addition to functioning as a domain controller. This part of the Samba domain controller configuration is described in Chapter 4. It also delivers other NetBIOS functions on the LAN; specifically, it typically functions as a NetBIOS name server and as a domain master browser. These duties are described in Section 5.2 and Section 5.3.
5.1.2. Domain Controller Parameters
In order to function as a domain controller, Samba must be configured with certain options set in its smb.conf file's [global] section.
In addition to setting these parameters, you should be sure not to set the password server parameter. This parameter tells a Samba domain member server where the domain controller is, so it isn't needed for a domain controller. In fact, setting it can cause confusion because you're telling Samba to do two contradictory thingsfunction as a domain controller and function as a domain member server.
5.1.3. Maintaining the Password Database
Fortunately, maintaining the password database on a domain controller isn't much different from maintaining a password database on an isolated Samba server that uses local (user-level) authentication. This task is described in more detail in Chapter 3.
One point that deserves reiteration is that Samba's password database, whether for an isolated server or a domain controller, relies upon corresponding entries in an underlying Linux account database. Thus, you must maintain both Linux and Samba accounts on the system, and they must match. Normally this means that the usernames must be identical for both systems, although you can use the username map parameter and the mapping file to which it points to link together dissimilar usernames. This requirement also exists on Samba domain member servers, although you can use Winbind on them so that the domain controller provides the basis for the Linux accounts, if you like. (This topic is covered in Chapter 7.) Alternatively, domain member servers can set the add user script to add accounts automatically when the user authenticates and no matching Linux account exists. Windows servers can use the domain controller exclusively, as described in the Section 5.1.6.
Perhaps the toughest challenge in maintaining the password database relates to actual maintenanceadding and deleting users, enabling users to change their passwords, and so on. This task, although easy on a user-by-user basis, can become a time-consuming chore on larger networks. Fortunately, several procedures can help minimize the effort required to handle this task:
Example 5-1. Sample script for adding Linux and Samba users
#!/bin/bash useradd -m $1 passwd $1 smbpasswd -a $1
When creating or modifying Linux accounts, remember to consider Linux groups. Depending on your shares' security settings and your overall server security policy, you may need to specify particular groups for your users. This detail is highly site-specific, though. If you don't specify a group, chances are the group will be either users or a group created specifically for the user you've added, depending on your Linux distribution.
5.1.4. Configuring Machine Trust Accounts
As noted earlier, Samba supports two methods of interacting with domain member servers: pass-through authentication and NetLogon authentication. (Technically, systems that use pass-through authentication aren't domain member servers, but they fill the same role in the network as a whole, so I don't try to draw a distinction in this chapter.) Windows 9x/Me servers and Linux servers configured with security = Server use pass-through authentication. If your network contains nothing but such servers, you can safely skip this section. Windows NT/200x/XP servers and Samba servers configured with security = Domain, though, use the NetLogon authentication method. This method requires that servers have accounts on the domain controller. Thus, to support such servers, you must create appropriate accounts, which are known as machine trust accounts.
Like ordinary user accounts, machine trust accounts must exist both in the underlying Linux account database and in Samba. The Samba-side accounts are created in a semiautomated way once certain Samba options are set, though.
Typically, you create a special Linux group to hold the Linux-side machine trust accounts. For instance, you might call the group trust:
# groupadd trust
You should then create Linux-side accounts for all the domain member servers and any clients that you expect to require such accounts. These accounts are named after the computers' NetBIOS names, but they are in lowercase and with dollar signs ($) appended to the names. For instance, you'd create an account called tulip$ for the computer whose NetBIOS name is TULIP. These accounts would be members of the machine trust group you created. They can also be non-login accounts, so they can be configured to refuse logins. A command to add such an account might look like this:
# useradd -g trust -d /tmp -s /bin/false tulip$
This command creates a new account (tulip$) in the test group (-g test) using the /tmp directory as the account's home directory (-d /tmp) and /bin/false as the default shell (-s /bin/false). Some of these parameters, such as setting the default shell to /bin/false, provide an extra measure of security. Of course, you may want to tweak these options for your local system's requirements.
If you must add many machine trust accounts, you can streamline the process by placing the command in the [global] section of smb.conf, using the add machine script parameter:
add machine script = useradd -g trust -d /tmp -s /bin/false %u
This parameter enables Samba to create a machine trust account itself when a machine attempts to join the domain. The joining machine must present appropriate authentication first, thoughpresumably indicating that you or another authorized administrator is sitting at its console.
Once you add the Linux-side machine trust accounts, you should configure an administrative user. You can either add root to the list of Samba user accounts (a potentially risky proposition), or you can specify an administrative user with the admin users parameter in the [global] section of smb.conf: admin users = linnaeus. This user then has root privileges when accessing the server.
Once these tasks are accomplished, Samba begins accepting domain member server requests to be added to the domain. This process is described in Section 5.1.6, for Windows systems, and in Chapter 7, for Linux systems.
5.1.5. Common Domain Controller File Shares
NT domain controllers can and often do function as ordinary file and print servers, in addition to handling domain logons. If you want to configure home shares, file-exchange shares, and the like, consult Chapter 4. However, a couple of shares are common to domain controllers: domain logon shares and roaming profile shares. The former deliver domain logon scripts to clients, enabling you to provide consistent environments to all domain members. The latter enable you to store user desktop settings (icon placement, theme selections, and so on) on the domain controller, which can help provide users with consistent settings in environments in which users frequently move from one physical computer to another.
188.8.131.52 Configuring domain logon shares
A domain logon script is a Windows script (a.k.a. a batch file) that the Windows client retrieves and runs automatically when a user logs onto the computer. Clients retrieve these scripts from a share called NETLOGON, so if you want to use this feature, you must create this share:
[netlogon] comment = Network Logon Share path = /usr/share/samba/netlogon writeable = No write list = linnaeus
This share definition is fairly ordinary; it's a typical read-only file share, but with a user appointed with write privileges. The unusual feature of the share is actually defined in the [global] section of smb.conf, with a pointer to the logon script's filename:
logon script = LOGON.BAT
This line tells Samba to deliver the LOGON.BAT file from the NETLOGON share to clients when they log on. Note that you can use Samba's variables to deliver different logon scripts to different clients. For instance, specifying LOGON-%a.BAT tells Samba to deliver files with the clients' OS codes in the filenames, such as LOGON-Win95.BAT for Windows 9x/Me systems or LOGON-Win2K.BAT for Windows 2000 systems.
What should go in domain logon scripts, though? Anything you want. These scripts are Windows batch files, so you can run any command accessible on all the Windows client computers (or on any network share accessible to them). A simple example might set the systems' clocks and open users' home directories:
NET TIME \\TULIP /SET /YES NET USE M: \\TULIP\HOMES /YES EXPLORER M:
This example uses the NET command on Windows to set the time and mount the HOMES share from the TULIP server, then launch the Windows EXPLORER file manager on the share. You can do more or less, though; it's up to you.
184.108.40.206 Configuring roaming profiles
Normally, Windows stores users' preferences for user interface settings like icon placement and window themes on the local hard disk. This configuration works perfectly well on networks whose users generally have their own systems, such as office workers who have their own offices or cubicles. In other environments, though, users may regularly move from one computer to anotherfor instance, in a college computer center. In such cases, roaming profiles are handy. These enable users to store their personalized settings on the domain controller, so that they appear on whatever client they use, even if a user has never used a particular computer before.
Unfortunately, roaming profiles work slightly differently for Windows 9x/Me as opposed to Windows NT/200x/XP systems. (They're also completely unavailable for Windows XP Home systems, which technically can't participate in domains, although they can treat a domain as a workgroup.) To support Windows 9x/Me systems, Samba uses the global logon home parameter, which typically points to a subdirectory of the user's home directory:
logon home = \\%L\%U\.roamingprofile
This parameter specifies a Windows-style share locator (note the backslashes in the path). In this example, %L expands to the server's own name, and %U expands to the user's username; thus, this example should point to the .roamingprofile subdirectory in the user's home directory.
Windows NT/200x/XP requires a somewhat different definition. This is provided by a global parameter called logon path:
logon path = \\%L\PROFILES\%U\%a
This definition requires that a share called PROFILES exist on your server. The logon path includes the %a variable, which expands to the OS name, because Windows NT, 2000, and XP profiles aren't interchangeable. The profile share can be a fairly ordinary file-storage share, but for security purposes, it's best to set create mode and directory mode to fairly restrictive values:
[profiles] comment = NT Roaming Profiles directory = /usr/share/samba/profiles read only = No create mode = 0600 directory mode = 0700 browseable = No
The share directory itself (/usr/share/samba/profiles in this example) must be writeable to all users; if it's not, users can't create their roaming profiles. In theory, you can point Windows NT/200x/XP systems to a subdirectory of users' home shares; however, Windows NT/200x/XP doesn't always completely disconnect from shares when users log out, which can complicate such an arrangement.
5.1.6. Configuring Windows Clients and Servers as Domain Members
Configuring Samba as a domain controller won't do any good unless you also configure computers as members of the domain. In theory, only domain member servers need to be so configured; however, in practice, clients may need to be configured in this way, too. Precisely how you accomplish this goal varies with the OS you're using. In particular, Windows 9x/Me and Windows NT/200x/XP have different domain membership requirements and options.
220.127.116.11 Activating Windows 9x/Me domain membership
Ordinarily, when a Windows 9x/Me system is configured to use a workgroup, it presents a logon screen with a two-field logon prompt, as shown in Figure 5-2. This logon screen provides no real security, though; clicking Cancel bypasses the logon screen and gives you full local access to the computer. This screen merely provides a way for Windows to cache your username and password for network accesses. Switching to a domain configuration won't change this lack of security.
Figure 5-2. The Windows 9x/Me logon screen for a workgroup configuration
To reconfigure a Windows system with a workgroup-style logon to use a domain, follow these steps:
Ordinarily, Windows 9x/Me assigns passwords to any drives you share, using share-level security. Once you've configured a Windows 9x/Me system as a member of a domain, though, you can tell it to defer to the domain controller for authenticating its share access:
After making this change, you'll need to redo your sharing configuration. The changes add the ability to specify user-based access control, so you can grant or deny access to the share to particular users.
18.104.22.168 Activating Windows NT/200x/XP domain membership
Windows 9x/Me systems use the pass-through authentication protocol, whereas Windows NT/200x/XP uses NetLogon authentication. For this reason, Windows NT/200x/XP systems require that you prepare a machine trust account on the domain controller, as described in the earlier Section 5.1.4, before you add the computer to the domain. (Windows XP Home doesn't support domain configurations, though, so you can't configure it this way. You can only treat a domain as if it were a workgroup from Windows XP Home.) Once you've created domain trust accounts on the domain controller, you can add a computer to the domain as follows:
After you've made these changes and rebooted, Windows displays a new three-field logon window similar to the one shown in Figure 5-4. (Some versions of Windows NT/200x/XP differ in certain details; in fact, some hide the third logon field in an advanced options area.) Unlike the Windows 9x/Me logon screen, the Windows NT/200x/XP logon screen provides real security; you can't simply click Cancel to gain access to the computer without a password. You may want to bypass the domain authentication, though, and use the system's local account database. This is particularly handy when performing administrative tasks as the Administrator. To do so, select the computer's name rather than the domain name in the new Log On To field at the bottom of the logon prompt.
Windows should automatically use the domain controller for authentication when users try to access shares on a Windows NT/200x/XP server; thus, you shouldn't need to reconfigure the system to use the domain controller, as you do with Windows 9x/Me systems. Recent versions of Windows NT/200x/XP also use roaming profiles by default in a domain configuration. If you want to reconfigure a client to use local profiles instead, follow these steps: