9.2. Configuring a Samba PDC
To build a Samba Primary Domain Controller, it is best to begin with a working standalone file server. We assume the following configuration:
[global] netbios name = STORK workgroup = ORA security = user encrypt passwords = yes [public] path = /data/public read only = no
There are five minimum requirements that must be met by a Samba PDC:
Our initial smb.conf meets the first two requisites. The next step is to add a [netlogon] file share that emulates the NETLOGON service on Windows domain controllers. The share itself must be readable by all domain users, so that they can access items such as policy files and login scripts (covered later in this chapter), but should restrict write access solely to administrators. This example specifies the share as read only, but includes the ntadmin group in the write list; ntadmin is our primary group for systems administrators:
[netlogon] comment = Net Logon service path = /data/netlogon read only = yes write list = +ntadmin
Enabling the domain master parameter in the global section of smb.conf causes nmbd to register the DOMAIN<0x1b> name (ORA<0x1b> in our example). This name is used by Windows clients to locate the PDC for a domain. When searching for any domain controller, not necessarily just the PDC, a Windows client attempts to resolve the DOMAIN<0x1c> name. You can instruct nmbd to register this name (e.g., ORA<0x1c>) by setting the domain logons option in smb.conf. Our PDC's new global configuration looks like this:
[global] netbios name = STORK workgroup = ORA security = user encrypt passwords = yes ## enable PDC functionality domain master = yes domain logons = yes
It is not required that the PDC act as the local master browser, but most are configured to operate in this role as well. To achieve this, add the following browsing-related parameters to the global section. Review the previous chapter if you need a reminder regarding any of these three parameters.
os level = 33 preferred master = yes local master = yes
After making these changes, it is best to restart both smbd and nmbd. Wait approximately one minute for nmbd to complete its name registration process. Then use nmblookup to verify that both the 0x1c and 0x1b names have been claimed. It is normal to see more than one IP address when querying for the 0x1c name if you have one or more backup domain controllers configured on your network. In our case, we have only the PDC so far:
$ nmblookup 'ORA#1b' 'ORA#1c' querying ORA on 192.168.1.255 192.168.1.88 ORA<1b> querying ORA on 192.168.1.255 192.168.1.88 ORA<1c>
You can also verify the name registration in nmbd's logfile. A successful logon server (0x1c) registration generates a log entry like the following.
become_logon_server_success: Samba is now a logon server for workgroup ORA on subnet 192.168.1.88
When configured as the DMB, nmbd logs this message:
Samba server STORK is now a domain master browser for workgroup ORA on subnet 192.168.1.88
9.2.1. Setting Up Domain Joins
Now that you have a working Samba DC, the next step is to add Windows clients to the domain. Before moving to that topic, however, let's go over some background on computer accounts.
When joining a domain, the client establishes a password known only to itself and the domain controller. This password is called the machine trust account password and is used to prove the identity of the computer each time it contacts the DC (normally upon booting). For security purposes, hosts running Windows 2000 and later require that you provide credentials for an administrative account that can potentially create the new machine account and assign it a random password.
Originally, Windows NT 4.0 allowed an administrator to create the client's machine trust account in advance using the Server Manager application. This new account was then assigned a predefined password based on the machine name. Therefore any user who knew the name could then join a computer to the domain.
The goal, then, is to complete the following tasks:
18.104.22.168. Domain Admins
Domain Admins is a special group in Windows domains. The group's RID is always 512. When a Windows client joins a domain, it adds this domain group to its local Administrators group. The result is that members of Domain Admins automatically gain administrative privileges on all domain members. Samba honors membership in the Domain Admins group as well, by granting all Domain Admins the ability to manage the user rights assignments necessary to authorize users to join hosts to the domain.[*]
In order to create a group mapping entry for this special domain RID, you must first look up the SID of the ORA domain. You must be root for all the command examples in this section. Get the SID as follows:
# net getlocalsid ORA SID for domain ORA is: S-1-5-21-3489264249-1556752242-1837584028
Now append the Domain Admins RID to the domain SID and create a group mapping entry for it:
# net groupmap add sid=S-1-5-21-3489264249-1556752242-1837584028-512 \ ntgroup="Domain Admins" unixgroup=ntadmin Successfully added group Domain Admins to the mapping db
Now all members of the ntadmin Unix group will be seen as domain administrators by both Samba and Windows clients.
22.214.171.124. Required privileges
Samba uses the SeMachineAccountPrivilege right to authorize a user or group to join a computer to the domain. Now is a good time to review the "User Privilege Management" section in Chapter 5 if you need a refresher on the net rpc rights command. Remember that new privilege assignments, like membership in a new group, are not applied to the user's token until the next session.
The best way to manage user rights is to assign a privilege to a group and then add the appropriate users to that group. In order to grant and revoke privileges, you must connect either as root or a member of the Domain Admins group. Our examples connect using the account cindy, who is a member of Domain Admins.
When a client joins a Samba domain, it performs the network equivalent of running pdbedit -a machinename. Normally, this type of request must be executed as root. But you can create a group mapping entry and assign it the SeMachineAccountPrivilege privilege to make smbd perform the account creation for members of this group as root.
Create the Server Admins Windows group based on the Unix group srvadmin and grant then the powers to manage users. The following commands create the group mapping entry and then (using the cindy account) assign the "Add machines to domain" right to the group:
# net groupmap add unixgroup=srvadmin ntgroup="Server Admins" Successfully added group Server Admins to the mapping db # net rpc rights grant 'ORA\Server Admins' SeMachineAccountPrivilege \ -S stork -U cindy Password: <enter cindy's password> Successfully granted rights.
All Samba users must possess a matching Unix account. Therefore, Samba lets administrators create a matching Unix account at the time a host is joined to the domain. The add machine script option refers to an external utility that smbd invokes to generate the Unix account when it receives the network request to create a machine account. If the matching Unix account already exists, the script is ignored.
Because the process of creating users varies widely from one Unix platform to another, Samba does not include a default setting for this option. Usually it is possible to use some variant of a tool provided by the operating system.
The following example of a setting for add machine script comes from a Samba PDC running on Linux. The script invokes the useradd command to create the account referenced by the %u variable, assign its primary group membership to the hosts Unix group (which already exists), and set its login shell to /bin/false. Thanks to the login shell setting, the user cannot log in and cause any mischief on the Linux host; all she can do is access Samba files.
add machine script = /usr/sbin/useradd -g hosts -s /bin/false '%u'
Table 9-1 gives a summary of the new smb.conf option presented in this section. In the next section we'll test the new configuration.
126.96.36.199. Joining a Windows client
The best way to understand how domain joins and the add machine script work together is to actually join a client to our domain. We'll use a Windows XP Professional client in the following examples. Remember from Chapter 3 that Windows XP Home Edition has been crippled to remove its domain join capabilities.
Begin by navigating to the System Properties dialog box. You can access this in several ways, but the one that works most consistently is to run control.exe sysdm.cpl from a command prompt or from the Run . . . option in the Start Menu. In the properties window, navigate to the Computer Name tab (called Network Identification in Windows 2000) and select Change (Properties in Windows 2000). The dialog boxes should appear similar to Figure 9-1. Here you can change the client's machine name or domain membership.
Figure 9-1. Computer Name Changes dialog on Windows XP
After entering the domain name ORA and clicking OK, you will be presented with a dialog box requesting credentials to join the domain (Figure 9-2). Continue to use the account details for cindy, because she is also a member of the srvadmin Unix group, which was granted the rights necessary to join hosts to the domain.
Figure 9-2. Entering credentials to join the domain
The Windows client then contacts the Samba PDC and uses these credentials to send the request to create the machine account and sets its password. If all of this succeeds, you will be greeted with the success message shown in Figure 9-3: "Welcome to the ORA domain."
Figure 9-3. Welcome message upon successful registration
There are a couple of places where this process can fail. The most common errors are:
If you find an error not listed here, try increasing the Samba debug log levels to search for more clues and consider some of the techniques described in Chapter 12.
After a successful join and client reboot, you are able to select the domain when logging into the Windows console. Figure 9-4 displays the drop-down list of domains shown on our XP client. The local machine name MINK is present in the list, as is the ORA domain. The BOOKS domain is an Active Directory domain that is trusted by ORA. We examine domain trusts later in this chapter.
Figure 9-4. The Ctrl+Alt+Del logon dialog box showing a drop-down list of domains
9.2.2. Managing Users and Groups
The main purpose of a domain is to centralize authentication services. With this in mind, we turn our attention to users and groups. Traditionally, Windows administrators have used the User Manager for Domains application (sometimes referred to simply as usrmgr.exe ) to create, modify, and remove accounts within NT 4.0 domains. Windows NT 4.0 server administration tools such as usrmgr.exe can be found in the latest Windows NT 4.0 service pack from http://www.microsoft.com.
Enabling remote account management support in Samba requires a few additional configuration pieces. Samba divides responsibilities between the list of accounts in its own passdb and those underlying Unix users and groups to which the passdb entries correspond. Samba continues to manage its own account attributes, but smbd requires help to manage these Unix identities just as it did for machine accounts. This is achieved through a collection of scripts defined in the global section of smb.conf that allow Samba to perform the following actions:
You'll notice that there is no parameter for renaming groups. The name stored in the group mapping table is handled by Samba independently of the Unix group name. When renaming a group, only the group map entry is updated.
Similar to our earlier discussion regarding machine accounts, creating a user or group is very platform-specific. Therefore, you must find a solution that works for your server. Following is one example of how to set up these scripts on a Linux server. The following list of configuration parameters makes use of the tools in the pwdutils package included with Novell's SuSe Linux. However, such values should be portable across most Linux distributions. The %u and %g variables are expanded to the user and group names sent in the client's request.
[global] add user script = /usr/sbin/useradd -m '%u' delete user script = /usr/sbin/userdel '%u' rename user script = /usr/sbin/usermod -l '%unew' '%uold' add group script = /usr/sbin/groupadd '%g' delete group script = /usr/sbin/groupdel '%g' add user to group script = /usr/sbin/groupmod -A '%u' '%g' delete user from group script = /usr/sbin/groupmod -D '%u' '%g' set primary group script = /usr/sbin/usermod -g '%g' '%u'
These commands are fairly intuitive and do what you would expect. For example, useradd creates the Unix user, and usermod can be used to rename an account. More information on the specifics of useradd and other account management tools can be found in the server operating system's manpages.
Once this infrastructure is in place, any user possessing the SeAddUsersPrivilege on the server can create and modify accounts directly from a Windows desktop. Don't be confused by the name. This privilege that purports to "Add users and groups to the domain" can also modify existing accounts. The following command allows members of Server Admins to manage users and groups:
# net rpc rights grant 'ORA\Server Admins' SeAddUsersPrivilege \ -S stork -U cindy Password: <enter cindy's password> Successfully granted rights.
Commands that grant privileges are cumulative. You can review the list of privileges assigned to a user or group using the net rpc rights list command. The following command anonymously (through the -U% option) enumerates the rights possessed by the Server Admins group:
# net rpc rights list accounts 'ORA\Server Admins' -U% -S stork SeMachineAccountPrivilege SeAddUsersPrivilege
Now launch User Manager for Domains. You will be greeted with a list of users and groups and should be able to match the output from pdbedit -L -w to the list of users and the output from net groupmap list to the list of groups. Figure 9-5 shows the users and groups in the ORA domain. The following commands confirm that the list of accounts matches what is reported from Samba's own tools. The output has been trimmed to list solely the user and group names for easier reading. Also notice that the machine accounts (ones ending with a dollar sign) are not listed by User Manager, which filters them from the display.
# pdbedit -L -w | cut -d: -f 1 KNOT$ DORN$ POLE$ MINK$ jerry BOOKS$ lizard STORK$ cindy # net groupmap list | cut -d \( -f 1 Printer Admins staff Domain Users Server Admins helpdesk Administrators Linux Users Domain Admins Users
Figure 9-5. Users and groups in the ORA domain
You can launch the New User dialog from the the User menu. Figure 9-6 shows the creation of a new account named mark; Figure 9-7 illustrates how to manage mark's group membership.
Figure 9-6. Creating a new user named mark
Figure 9-7. Managing a user's group membership
After adding the new account, verify that it was created by examining /etc/passwd and Samba's passdb. The new Unix account should be present in the system passwd file:
$ grep mark: /etc/passwd mark:x:10026:1008::/home/mark:/bin/bash
The output from pdbedit also confirms the new Samba account:
# pdbedit -L -w mark mark:10026:01FC5A6BE7BC6929AAD3B435B51404EE:0CB6948805F797BF2A82807973B89537: [U]:LCT-44D8C4C1:
If you observe any failures in usrmgr.exe , the troubleshooting tips for resolving domain join failures, described in Chapter 10, apply to managing users. Verify that the connected user has been granted the appropriate level of privileges and scan the Samba logfiles for more information regarding the reason for the failure.
Table 9-2 provides a brief listing of the account management parameters introduced in this section.
9.2.3. User Profiles
User roaming profiles, sometimes called roving profiles, provide a way for a domain user to customize elements of his environment such as the desktop wallpaper, application defaults, and desktop shortcuts. Such profiles give users a more "at home" feeling when they move from machine to machine. Figure 9-8 displays the User Environment Profile setting dialog box provided by usrmgr.exe. With the exception of the Terminal Server settings, we'll discuss each one of these fields shortly.
Figure 9-8. The User Environment Profile dialog box in User Manager for Domains
Our focus is on making a Samba DC support Windows user profiles, not on Windows-specific tasks such as editing the registry or updating shortcuts. More information on these topics can be found in the plethora of currently available Windows administration books and online articles. A definitive guide to user profiles can be found in the white paper titled "Implementing Policies and Profiles for Windows NT 4.0," available through a search at http://www.microsoft.com.
First it is important to understand exactly what composes a user profile. Roughly speaking, a profile is a collection of application settings. Some of these settings may be stored in the user's registry hive (NTUSER.DAT), and others may be stored as files on disk. The following is a list of the top-level files and directories composing a Windows XP user profile:
$ ls -l total 880 drwx-----T+ 5 cindy helpdesk 4096 Aug 8 13:33 Application Data drwx-----T+ 2 cindy helpdesk 4096 May 21 20:52 Cookies drwx-----T+ 2 cindy helpdesk 4096 May 21 15:26 Desktop drwx-----T+ 3 cindy helpdesk 4096 Aug 6 16:32 Favorites drwx-----T+ 4 cindy helpdesk 4096 Aug 6 16:32 My Documents -rwx------ 1 cindy helpdesk 786432 Aug 8 14:20 NTUSER.DAT drwx-----T+ 2 cindy helpdesk 4096 May 21 15:26 NetHood drwx-----T+ 2 cindy helpdesk 4096 May 21 15:26 PrintHood drwx-----T+ 2 cindy helpdesk 4096 Aug 8 12:07 Recent drwx-----T+ 2 cindy helpdesk 4096 Aug 6 16:31 SendTo drwx-----T+ 3 cindy helpdesk 4096 May 21 15:26 Start Menu drwx-----T+ 2 cindy helpdesk 4096 May 21 20:42 Templates -rwx------ 1 cindy helpdesk 1024 Aug 8 14:20 ntuser.dat.LOG -rwx------ 1 cindy helpdesk 328 Aug 8 14:22 ntuser.ini
Storing per-user settings on a central file server can provide several benefits to administrators. For example, new machines can be deployed without worrying about having to transfer the user's customized environment from one host to another. If all of the user's documents and files are stored on a network file share as well, machines can practically be swapped out at will. Additionally, a profile can be updated while the user is offline and have the changes appear at the next logon. Useful examples of this are adding shortcuts to the Start Menu or editing application settings found in the NTUSER.DAT registry hive.
To support roaming profiles, your server needs to dedicate a file share to storing these per user settings, and you must inform the Windows clients of this share so that the user profile can be download at logon time. The following excerpt from smb.conf uses the logon path parameter to specify the location of the user's roaming profile.
The %U variable is used to separate profiles based on username. The %a variable is used to separate the profiles based on client OS. This is important, because a profile created by Windows 2000 may not be 100% compatible with one created by Windows XP. The [profile$] share is a normal file share. The trailing $ is included to prevent the share from being displayed by Windows client when browsing the server. You could have disabled the browseable parameter to achieve the same effect.
[global] logon path = \\STORK\profile$\%U\%a [profile$] comment = User roaming profiles path = /data/profiles read only = no inherit permissions = yes
Each user must be able to write to a subdirectory matching his login name in /data/profiles (i.e., /data/profiles/mark). One way to meet this requirement is to create the top-level directory before the user first logs on. It is also a good idea to prevent other users from accessing a profile other than their own. Run the following commands as root to create the necessary profile directory for the user mark:
# mkdir -p /data/profiles/mark # chown mark /data/profiles/mark # chmod 700 /data/profiles/mark
Windows itself will handle creating the directory based on the %a value. Here is the profile directory for a user who has logged on to clients running various operating systems:
$ ls -l total 16 drwx------ 14 cindy helpdesk 4096 Aug 6 21:18 Win2K drwx------ 13 cindy helpdesk 4096 Jul 22 10:23 Win2K3 drwx------ 15 cindy helpdesk 4096 Aug 6 17:29 WinNT drwx------ 13 cindy helpdesk 4096 Aug 8 12:02 WinXP
In addition to a roaming environment, it is beneficial to provide users with a private network file share in which to store data. Personal files, along with application settings, can then follow a user from machine to machine. Windows connects to the user's home directory automatically if you define the logon home parameter in smb.conf. The driver letter used by in the connection is controlled by the logon drive option. The following example connects the home directory (\\STORK\username) to the H: drive:
[global] logon home = \\STORK\%U logon drive = H: [homes] comment = Home directory for %U read only = no valid users = %S
You may wish to do more when a user logs on than just connect her to a home directory. The logon script parameter points to a Windows batch file that is run on the client when a user logs on. The script value is the DOS path to the batch file relative to the root of the [netlogon] share. For example, to run a script based on the user's primary group, set the following in smb.conf:
[global] logon script = %G.bat
For a user whose primary group is ntadmin, smbd will expand the %G before sending the UNC path \\stork\netlogon\ntadmin.bat to the client. Frequently, the logon script is configured to point to a master batch file that performs certain actions based on the user's group membership. The ifmember.exe tool included in the Windows Server 2003 resource kit allows you to test for membership in a group and perform a specific action if the test succeeds. Other more power-scripting languages such as Perl or Python may be used as well, but these must be invoked from the original batch file.
Table 9-3 summarizes the user profile parameters discussed in this section.
9.2.4. System Policies
A Windows NT 4.0 system policy file, usually named ntconfig.pol and stored in the [netlogon] share, is a collection of registry settings used to enforce specific settings on client machines and users or groups. NT 4.0 system policies are very different from AD Group Policy Objects. The latter is a feature of Active Directory and not supported by Samba's current domain controlling capabilities.
Figure 9-9 displays the Windows NT 4.0 Policy Editor (included in the latest Windows NT 4.0 Service Pack). The dialog box shows specific policy objects for the Server Admins group, the user mark, and the computer mink. If a user or host does not match any of the specific policies, the default user or default computer policy will be applied.
Figure 9-9. The User Environment Profile dialog box in User Manager for Domains
System policies are retrieved by the client as part of the user logon process. By default, the client searches the [netlogon] share for a file named ntconfig.pol and then attempts to merge this file with either the HKEY_LOCAL_MACHINE or the HKEY_CURRENT_USER registry hive, depending on the type of policy object.
You can accomplish a lot with system policies. Figure 9-10 illustrates a few user settings that can be managed via policy settings. This example highlights settings such as restricting screen locks and excluding certain directories from being synchronized as part of the user's roaming profile.
Figure 9-10. User system policy settings
The Microsoft white paper "Implementing Policies and Profiles for Windows NT 4.0," mentioned in the context of roaming user profiles, is also an excellent source of information for system policies. It might also be helpful to read MS Knowledge Base article 225087, "Writing Custom ADM Files for System Policy Editor."