Section 5.1. Enabling Domain Controller Functions


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.

Samba domain member server computers must maintain local Linux user accounts as well as Samba passwords (or defer to a domain controller for the latter). Thus, the administration benefits of a domain configuration are somewhat lower for Samba than for Windows SMB/CIFS serversat least, unless you take additional steps. As described in Chapter 7, you can configure Linux to use an NT domain controller for the Linux account database. This can be more effort to set up but will reduce long-term administrative effort if your network hosts several Samba servers or if you want to integrate Linux and Windows accounts into one system. Alternatively, you can point the global add user script parameter to a script that creates an account for users who are authenticated by the domain controller but who don't already have local accounts. For instance, setting add user script = useradd -m %u in the [global] section of smb.conf may do the trick, although you may want to write a script that does more than this.


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.


security = User

This parameter, described in Chapter 3, sets the local authentication system. Because the domain controller serves as an authentication tool for other servers, user-level security is appropriate for the domain controller. Setting this parameter incorrectly causes the domain controller to function incorrectly.


encrypt passwords = Yes

You must tell Samba to use encrypted passwords; if you don't, it won't be able to parse the encrypted password exchange initiated by domain member servers. On a domain controller, this setting also requires you to maintain a local encrypted password database, as described in the next section.


passdb backend

This parameter specifies how Samba is to store its password database. The default value, smbpasswd, is simple and easy to administer compared to the alternatives, but it tends to be slow. This speed problem is extremely minor for networks with a few dozen, or even over a hundred, users. If your network has many hundreds or thousands of users, though, you may want to look into alternatives, such as TDbsam and ldapsam. These alternatives also support additional features, such as the ability to deliver time-based restrictions on user access. These alternatives require additional configuration, though, and such configuration is beyond the scope of this book.


domain logons = Yes

This parameter is the defining one for a domain controller; it tells Samba to accept remote logon requests. The default value is No, so be sure to change it on your domain controller. Conversely, be sure not to change it on domain member servers and clients.

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.

Because most domain controllers also take on name server and master browser duties, you must also set smb.conf parameters related to these functions, as described later in this chapter.


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:


Adding users

If you add users on a regular basis, you can write a simple shell script that adds both Linux and Samba accounts at once. Something as simple as Example 5-1 might serve well. This example requires you to type users' passwords twice, though, at least if they should have access to the server system both through Samba and through some other means. A more complex script can disable the Linux account for non-Samba logins, prompt for a password and deliver it to both useradd and smbpasswd, or otherwise work in a way that's suitable for your network.

Example 5-1. Sample script for adding Linux and Samba users
#!/bin/bash useradd -m $1 passwd $1 smbpasswd -a $1


Deleting users

As with adding users, you should be sure to delete both the Samba and the Linux accounts when you do this. If you forget to delete the Linux account, users who should no longer have access to the server might be able to get in. A simple script that calls userdel and smbpasswd with appropriate options can help on this score.


Changing user passwords

You can enable users to change their passwords several ways. One grants users shell access to the Linux domain controller, in which case they can call smbpasswd themselves. If users shouldn't have shell access to the server, access to another Linux system can do as well; passing the -r parameter and a machine name causes smbpasswd to change the password on the specified remote system. Setting users' login shells to smbpasswd is another way to let them change their passwords; they can log in using Secure Shell (SSH), Telnet, or even console access, and they'll immediately be prompted to change their passwords. The Samba Web Administration Tool (SWAT) is another way to enable users to change their passwords. When users access this server with a web browser, they can change their Samba passwords. SWAT doesn't support encryption, though, which is a potentially important limitation.


Synchronizing Linux and Samba passwords

Keeping Linux and Samba passwords synchronized can be a tricky proposition. Setting the global Samba unix password sync parameter to Yes can help. This setting requires one of two additional options, though. One is the pam password change parameter, which should be set to Yes. Instead of setting pam password change = Yes, you can set passwd program to specify the local password-changing program, and set passwd chat to a chat script that controls the password-changing exchange.

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.

Technically, machine trust accounts are required only by servers; however, many Windows NT/200x/XP systems configured as clients try to use these accounts when you log onto them. Thus, you may need to create these accounts for all your Windows systems.


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.

For added security, comment out the admin users line when you don't need it, and specify an account you don't normally use for this purpose. That way, the risks of system compromise due to a compromise of this account are minimized. You can reduce the risk of using the root account if you employ that approach, using different Samba and Linux passwords for root.


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.

The roaming profile share is optional. Although some documentation refers to the netlogon share as required, in practice, the domain controller can function without one. These shares both provide functionality that's important for some domains, though.


5.1.5.1 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.

5.1.5.2 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.

Samba servers can also join domains, as described in Chapter 3. To use a domain controller as a way to control non-Samba access to a Linux system, consult Chapter 7.


5.1.6.1 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:

  1. Open the Network item in the Control Panel. Windows displays a Network dialog box.

  2. Select the Client for Microsoft Networks item in the Network dialog box and click Properties. Windows displays a Client for Microsoft Networks Properties dialog box, as shown in Figure 5-3.

    Figure 5-3. The Windows 9x/Me Client for Microsoft Networks Properties dialog box


  3. Check the "Log on to Windows NT domain" check box.

  4. Enter the name of your NT domain in the Windows NT domain field.

  5. Click OK in the two open dialog boxes. Windows will inform you that it must reboot in order to implement the changes.

  6. Allow Windows to reboot, or do so yourself. When the system starts up again, you should see a new logon dialog box, similar to the one shown in Figure 5-4.

    Figure 5-4. In a domain configuration, Windows 9x/Me provides a three-field logon dialog box


    Configuring Windows 9x/Me systems as just described doesn't improve security or change the system's logon procedures. It does, however, tell the Windows client to use a domain logon script, if you've configured your domain controller to provide one. It also enables the client to use roaming profiles, although extra configuration steps are required to actually use them.

  7. Double-click the Passwords item in the Control Panel. Windows displays the Passwords Properties dialog box.

  8. Click the User Profiles tab in the Passwords Properties dialog box.

  9. Click the Users Can Customize Their Preferences... radio button in the Passwords Properties dialog box. This action tells Windows to store different desktops for each user. In a domain configuration in which the domain controller supports roaming profiles, these are stored on the domain controller.

  10. Click OK. Windows informs you that it must reboot. Do so.

  11. When Windows starts up again and you log on, the system tells you that you haven't logged on before. Click Yes to tell Windows to create the roaming profile.

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:

  1. Open the Network icon in the Control Panel. The result is the Network dialog box.

  2. Click the Access Control tab in the Network dialog box.

  3. Click the User-Level Access Control radio button.

  4. Enter the name of your domain in the "Obtain List of Users and Groups From" field.

  5. Click OK in the Network dialog box. Windows displays a dialog box warning that you'll need to reconfigure your shared directories.

  6. Click Yes in the warning dialog box. You'll then be asked to restart the computer. Do so.

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.

5.1.6.2 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:

  1. Log onto the Windows system as Administrator. Don't open any shares on the domain controller.

  2. Open the System object in the Control Panel. Windows should display the System Properties dialog box.

  3. Click the tab called Network Identification or Computer Name, depending on the version of Windows you're running.

  4. Click the Properties or Change button. Windows should display the Identification Changes or Computer Name Changes dialog box shown in Figure 5-5.

    Figure 5-5. Windows NT/200x/XP lets you set the computer's name and its workgroup or domain affiliation in a single dialog box


  5. If it's not already set, enter the computer's NetBIOS name in the "Computer name" field.

  6. Click Domain in the "Member of area," and enter the name of the NT domain. If the computer is configured as a member of a workgroup of the same name as the domain you enter, Windows may complain. If this happens, try changing the workgroup name to a fictitious one, reboot, and start again.

  7. Click OK in the Identification Changes dialog box. Windows opens a dialog box asking for a username and password.

  8. Enter the username of the administrative user you specified with admin users on the Samba domain controller, along with the associated password. After you do this, you should see a message welcoming you to the domain and a notice that you must reboot the computer.

  9. Dismiss the dialog boxes, and reboot the computer.

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:

  1. Right-click My Computer on the desktop or in the Start menu and select Properties from the resulting context menu. The System Properties dialog box should appear in response.

  2. In Windows 2000, select the User Profiles tab. In Windows 2003 or XP, select the Advanced tab and then click the Settings button in the User Profiles area. The result is a User Profiles dialog box or tab, as shown in Figure 5-6.

    Figure 5-6. The Windows NT/200x/XP User Profiles selection dialog


  3. Double-click the line for the account you want to modify. (Figure 5-6 shows just one account, for Administrator on NESSUS.) A Change Profile Type dialog box appears, enabling you to select a roaming or a local profile.

  4. Click the profile type you want to set in the Change Profile Type dialog box, and then click OK in all the open dialog boxes.



    Linux in a Windows World
    Linux in a Windows World
    ISBN: 0596007582
    EAN: 2147483647
    Year: 2005
    Pages: 152

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net