Chapter 4. Windows NT Domains

Modifying smb.conf

First you will need to start with an smb.conf file that correctly configures Samba for workgroup computing, such as the one we created in Chapter 2, and insert the following lines into the [global] section:

[global]
    ; use the name of your Samba server instead of toltec
    ; and your own workgroup instead of METRAN
    netbios name = toltec
    workgroup = METRAN
    encrypt passwords = yes
        
    domain master = yes
    local master = yes
    preferred master = yes
    os level = 65

    security = user
    domain logons = yes
    
    ; logon path tells Samba where to put Windows NT/2000/XP roaming profiles
    logon path = \\%L\profiles\%u\%m
    logon script = logon.bat

    logon drive = H:
    ; logon home is used to specify home directory and
    ; Windows 95/98/Me roaming profile location
    logon home = \\%L\%u\.win_profile\%m
    
    time server = yes

    ; instead of jay, use the names of all users in the Windows NT/2000/XP
    ; Administrators group who log on to the domain
    domain admin group = root jay

    ; the below works on Red Hat Linux - other OSs might need a different command
    add user script = /usr/sbin/useradd -d /dev/null -g 100 -s /bin/false -M %u

And after the [global] section, add these three new shares:

[netlogon]
    path = /usr/local/samba/lib/netlogon
    writable = no
    browsable = no

[profiles]
    ; you might wish to use a different directory for your
    ; Windows NT/2000/XP roaming profiles
    path = /home/samba-ntprof
    browsable = no
    writable = yes
    create mask = 0600
    directory mask = 0700

[homes]
    read only = no
    browsable = no
    guest ok = no
    map archive = yes

Now for the explanation. If you are comparing this example to the configuration file presented in Chapter 2, you will notice that the first three parameter settings are similar. We start out in the [global] section by setting the NetBIOS name of the Samba server. We are using the default, which is the DNS hostname, but are being explicit because the NetBIOS name is used in UNCs that appear later in smb.conf. The next two lines, setting the workgroup name and choosing to use encrypted passwords, are identical to our smb.conf file from Chapter 2. However, things are now a little different: even though it still reads "workgroup", we are actually setting the name of the domain. For a workgroup, using encrypted passwords is optional; when using a domain, they are required.

The next four lines set up our Samba PDC to handle browsing services. The line domain master = yes causes Samba to be the domain master browser, which handles browsing services for the domain across multiple subnets if necessary. Although it looks very similar, local master = yes does not cause Samba to be the master browser on the subnet, but merely tells it to participate in browser elections and allow itself to win. (These two lines are yet more default settings that we include to be clear.) The next two lines ensure that Samba wins the elections. Setting the preferred master parameter makes Samba force an election when it starts up. The os level parameter is set higher than that of any other system, which results in Samba winning that election. (At the time of this writing, an os level of 65 was sufficient to win over all versions of Windows—but make sure no other Samba server is set higher!) We make sure Samba is both the domain and local master browser because Windows NT/2000 PDCs always reserve the domain master browser role for themselves and because Windows clients require things to be that way to find the primary domain controller. It is possible to allow another computer on the network to win the role of local master browser, but having the same server act as both domain and local masters is simpler and more efficient.

The next two lines in the [global] section set up Samba to handle the actual domain logons. We set security = user so that Samba will require a username and password. This is actually the same as in the workgroup setup we covered in Chapter 1 and Chapter 2 because it is the default. The only reason we're including it explicitly is to avoid confusion: another valid setting is security = domain, but that is for having another (Windows or Samba) domain controller handle the logons and should never be found in the smb.conf of a Samba PDC. The next line, domain logons = yes, is what tells Samba we want this server to handle domain logons.

Defining a logon path is necessary for supporting roaming profiles for Windows NT/2000/XP clients. The UNC \\%L\profiles\%u refers to a share held on the Samba server where the profiles are kept. The variables %L and %u are replaced by Samba with the name of the server and the username of the logged on user, respectively. The section in smb.conf defining the [profiles] share contains the definition of exactly where the profiles are kept on the server. We'll get back to this topic a bit later in this chapter.

The logon script = logon.bat line specifies the name of an MS-DOS batch file that will be executed when the client logs on to the domain. The path specified here is relative to the [netlogon] share that is defined later in the smb.conf file.

The settings of logon drive and logon home have a couple of purposes. Setting logon drive = H: allows the home directory of the user to be connected to drive letter H on the client. The logon home parameter is set to the location of the home directory on the server, and again, %u is replaced at runtime by the logged on user's username. The home directory is used to store roaming profiles for Windows 95/98/Me clients. These parameters tie into the [homes] share that we are adding, as we will explain a bit later.

Setting time server = yes causes Samba to advertise itself as a time service for the network. This is optional.

The domain admin group parameter exists as a short-term measure in Samba 2.2 to give Samba a list of users who have administrative privileges in the domain. The list should contain any Samba users who log on from Windows NT/2000/XP systems and are members of the Administrators or Domain Admins groups, if roaming profiles are to work correctly.

The last parameter to add to the [global] section is add user script, and you will need it only if one or more of your clients is a Windows NT/2000/XP system. We will tell you more about this in Section 4.2 later in this chapter.

The rest of the additions to smb.conf are the definitions for three shares. The [netlogon] share is necessary for Samba to handle domain logons because Windows clients need to connect to it during the logon process and will fail if the share does not exist. Other than that, the only function of [netlogon] is to be a repository for logon scripts and system-policy files, which we shall cover in detail later in this chapter. The path to a directory on the Samba server is given, and because the clients only read logon scripts and system-policy files from the share, the writable = no definition is used to make the share read-only. Users do not need to see the share, so we set browsable = no to make the share invisible.

The [profiles] share is needed for use with Windows NT/2000/XP roaming profiles. The path points to a directory on the Samba server where the profiles are kept, and in this case, the clients must be able to read and write the profile data. The create mask (read and write permitted for the owner only) and directory mask (read, write, and search permitted for the owner only) are set up such that a user's profile data can be read and written only by the user and not accessed or modified by anyone else.

The [homes] share is necessary for our definitions of logon drive and logon home to work. Samba uses the [homes] share to add the home directory of the user (found in /etc/passwd ) as a share. Instead of appearing as "homes", the share will be accessible on the client through a folder having the same name as the user's username. We will cover this topic in more detail in Chapter 9.

At this point, you might want to run testparm to check your smb.conf file.

Creating Directories on the Samba Server

The [netlogon] and [profiles] shares defined in our new smb.conf file reference directories on the Samba server, and it is necessary to create those directories with the proper permissions:

# mkdir /usr/local/samba/lib/netlogon
# chmod 775 /usr/local/samba/lib/netlogon
# mkdir /home/samba-ntprof
# chmod 777 /home/samba-ntprof

The directory names we use are just examples. You are free to choose your own.

Restarting the Samba Server

At this point, the only thing left to do is restart the Samba server, and the changes will be put into effect:

# /etc/rc.d/init.d/smb restart

(or use whatever method works on your system, as discussed in Chapter 2.) The server is now ready to accept domain logons.

Windows 95/98/Me

To enable domain logons with Windows 95/98/Me, open the Control Panel and double-click the Network icon. Then click Client for Microsoft Networks, and click the Properties button. At this point, you should see a dialog box similar to Figure 4-1. Select the Logon to Windows Domain checkbox at the top of the dialog box, and enter the name of the domain as you have defined it with the workgroup parameter in the Samba configuration file. Then click OK, and reboot the machine when asked.

Figure 4-1. Configuring a Windows 95/98 client for domain logons

WARNING

If Windows complains that you are already logged into the domain, you probably have an active connection to a share in the workgroup (such as a mapped network drive). Simply disconnect the resource temporarily by right-clicking its icon and choosing the Disconnect pop-up menu item.

When Windows reboots, you should see the standard logon dialog with an addition: a field for a domain. The domain name should already be filled in, so simply enter your password and click the OK button. At this point, Windows should consult the primary domain controller (Samba) to see if the password is correct. (You can check the log files if you want to see this in action.) If it worked, congratulations! You have properly configured Samba to act as a domain controller for Windows 95/98/Me machines, and your client is successfully connected.

User-Level Security for Windows 95/98/Me

Now that you have a primary domain controller to authenticate users, you can implement much better security for shares that reside on Windows 95/98/Me systems.[3] To enable this functionality, open the Control Panel, double-click the Network icon, and click the Access Control tab in the dialog box. The window should now look like Figure 4-2.

Figure 4-2. Setting user-level access control

Click the User-level access control radio button, and type in the name of your domain in the text area. Click the OK button. If you get the dialog box shown in Figure 4-3, it means that shares are already on the system.

Figure 4-3. Error dialog while changing to user-level access control

In that case, you might want to cancel the operation and make a record of each of the computer's shares, making it easier to re-create them, and then redo this part. (To get a list of shares, open an MS-DOS prompt window and run the net view \\computer_name command.) Otherwise, you will get a message asking you to reboot to put the change in configuration into effect.

After rebooting, you can create shares with user-level access control. To do this, right-click the folder you wish to share, and select Sharing.... This will bring up the Shared Properties dialog box, shown in Figure 4-4.

Figure 4-4. The Shared Properties dialog

Click the Shared As: radio button, and give the share a name and comment. Then click the Add... button, and you will see the Add Users dialog box, shown in Figure 4-5.

Figure 4-5. The Add Users dialog

What has happened is that Windows has contacted the primary domain controller (in this case, Samba) and requested a list of domain users and groups. You can now select a user or group and add it to one or more of the three lists on the righthand side of the window—for Read Only, Full Access, or Custom Control—by clicking the buttons in the middle of the window. When you are done, click the OK button. If you added any users or groups to the Custom Control list, you will be presented with the Change Access Rights dialog box, shown in Figure 4-6, in which you can specify the rights you wish to allow. Then click the OK button to close the dialog box.

Figure 4-6. The Change Access Rights dialog

You are now returned to the Shared Properties dialog box, where you will see the Name: and Access Rights: columns filled in with the permissions that you just created. Click the OK button to finalize the process. Remember, you will have to perform these actions on any folders that you had previously shared using share-level security.

Windows NT 4.0

To configure Windows NT for domain logons, log in to the computer as Administrator or another user in the Administrators group, open the Control Panel, and double-click the Network icon. If it isn't already selected, click on the Network Identification tab.

Click the Change... button, and you should see the dialog box shown in Figure 4-7. In this dialog box, you can choose to have the Windows NT client become a member of the domain by clicking the checkbox marked Domain: in the Member of box. Then type in the name of the domain to which you wish the client to log on; it should be the same as the one you specified using the workgroup parameter in the Samba configuration file. Click the checkbox marked Create a Computer Account in the Domain, and fill in "root" for the text area labeled User Name:. In the Password: text area, fill in the root password you gave smbpasswd for creating computer accounts.

Figure 4-7. Configuring a Windows NT client for domain logons

WARNING

If Windows complains that you are already logged in, you probably have an active connection to a share in the workgroup (such as a mapped network drive). Disconnect the resource temporarily by right-clicking its icon and choosing the Disconnect pop-up menu item.

After you press the OK button, Windows should present you with a small dialog box welcoming you to the domain. Click the Close button in the Network dialog box, and reboot the computer as requested. When the system comes up again, the machine will automatically present you with a logon screen similar to the one for Windows 95/98/Me clients, except that the domain text area has a drop-down menu so that you can opt to log on to either the local system or the domain. Make sure your domain is selected, and log on to the domain using any Samba-enabled user account on the Samba server.

WARNING

Be sure to select the correct domain in the Windows NT logon dialog box. Once it is selected, it might take a moment for Windows NT to build the list of available domains.

After you enter the password, Windows NT should consult the primary domain controller (Samba) to see if the password is correct. Again, you can check the log files if you want to see this in action. If it worked, you have successfully configured Samba to act as a domain controller for Windows NT machines.

Windows 2000

To configure Windows 2000 for domain logons, log in to the computer as Administrator or another user in the Administrators group, open the Control Panel, and double-click the System icon to open the System Properties dialog box. Click the Network Identification tab, and then click the Properties button. You should now see the Identification Changes dialog box shown in Figure 4-8.

Figure 4-8. The Identification Changes dialog

Click the radio button labeled "Domain:" and fill in the name of your domain in the text-entry area. Then click the OK button. This will bring up the Domain Username and Password dialog box. Enter "root" for the username. For the password, use the password that you gave to smbpasswd for the root account.

WARNING

If Windows complains that you are already logged in, you probably have an active connection to a share in the workgroup (such as a mapped network drive). Disconnect the resource temporarily by right-clicking its icon and choosing the Disconnect pop-up menu item.

After you press the OK button, Windows should present you with a small dialog box welcoming you to the domain. When you click the OK button in this dialog box, you will be told that you need to reboot the computer. Click the OK button in the System Properties dialog box, and reboot the computer as requested. When the system comes up again, the machine will automatically present you with a Log On to Windows dialog box similar to the one shown in Figure 4-9.

Figure 4-9. The Windows 2000 logon window

If you do not see the Log on to: drop-down menu, click the Options << button and it will appear. Select your domain, rather than the local computer, from the menu.

WARNING

Be sure to select the correct domain in the logon dialog box. Once it is selected, it might take a moment for Windows to build the list of available domains.

Enter the username and password of any Samba-enabled user in the User name: and Password: fields, and either press the Enter key or click the OK button. If it worked, your Windows session will start up with no error dialogs.

Windows XP Home

You have our condolences if you are trying to use the Home edition of Windows XP in a domain environment! Microsoft has omitted support for Windows NT domains from Windows XP Home, resulting in a product that is ill-suited for use in a domain-based network.

On the client side, Windows XP Home users cannot log on to a Windows NT domain. Although it is still possible to access domain resources, a username and password must be supplied each time the user connects to a resource, rather than the "single signon" of a domain logon. Domain features such as logon scripts and roaming profiles are not supported.

As a server, Windows XP Home cannot join a Windows NT domain as a domain member server. It can serve files and printers, but only using share-mode ("workgroup") security. It can't even use user-mode security, as Windows 95/98/Me can.

Considering these limitations, we do not recommend Windows XP Home for any kind of local area network computing.

Windows XP Professional

To configure Windows XP Professional for domain logons, log in to the computer as Administrator or another user in the Administrators group, open the Control Panel in Classic View, and double-click the System icon to open the System Properties dialog box. Click the Computer Name tab and then click the Change... button. You should now see the Computer Name Changes dialog box shown in Figure 4-10.

Figure 4-10. The Computer Name Changes dialog

Click the radio button labeled "Domain:", and fill in the name of your domain in the text-entry area. Then click the OK button. This will bring up the Domain Username and Password dialog box. Enter "root" for the username. For the password, use the password that you gave to smbpasswd for the root account.

WARNING

If Windows complains that you are already logged in, you probably have an active connection to a share in the workgroup (such as a mapped network drive). Disconnect the resource temporarily by right-clicking its icon and choosing the Disconnect pop-up menu item.

After you press the OK button, Windows should present you with a small dialog box welcoming you to the domain. When you click the OK button in this dialog box, you will be told that you need to reboot the computer to put the changes into effect. Click the OK buttons in the dialog boxes to close them, and reboot the computer as requested. When the system comes up again, the machine will automatically present you with a Log On to Windows dialog box similar to the one shown in Figure 4-11.

Figure 4-11. The Windows XP logon window

If you get a dialog box at this point that tells you the domain controller cannot be found, the solution is to change a registry setting as follows.

Open the Start Menu and click the Run... menu item. In the text area in the dialog box that opens, type in "regedit" and click the OK button to start the Registry Editor. You will be editing the registry, so follow the rest of the directions very carefully. Click the "+" button next to the HKEY_LOCAL_MACHINE folder, and in the contents that open up, click the "+" button next to the SYSTEM folder. Continue in the same manner to open CurrentControlSet, then Services, then Netlogon. (You will have to scroll down many times to find Netlogon in the list of services.) Then click the Parameters folder, and you will see items appear in the right side of the window. Double-click "requiresignorseal", and a dialog box will open. In the Value data: text area, change the "1" to a "0" (zero), and click the OK button, which modifies the registry both in memory and on disk. Now close the Registry Editor and log off and back on again.

If you do not see the Log on to: drop-down menu, click the Options << button and it will appear. Select your domain from the menu, rather than the local computer.

WARNING

Be sure to select the correct domain in the logon dialog box. Once it is selected, it might take a moment for Windows to build the list of available domains.

Enter the username and password of any Samba-enabled user in the User name: and Password: fields, and either press the Enter key or click the OK button. If it worked, your Windows session will start up with no error dialogs.

Creating a Logon Script

In our smb.conf file, we have the line:

logon script = logon.bat

This defines the location and name of the logon script batch file on the Samba server. The path is relative to the [netlogon] share, defined later in the file like this:

[netlogon]
    path = /usr/local/samba/lib/netlogon
    writable = no
    browsable = no

With this example, the logon script is /user/local/samba/lib/netlogon/logon.bat. We include the directives writable = no, to make sure network clients cannot change anything in the [netlogon] share, and also browsable = no, which keeps them from even seeing the share when they browse the contents of the server. Nothing in [netlogon] should ever be modified by nonadministrative users. Also, the permissions on the directory for [netlogon] should be set appropriately (no write permissions for "other" users), as we showed you earlier in this chapter.

Notice also that the extension of our logon script is .bat. Be careful about this—an extension of .cmd will work for Windows NT/2000/XP clients, but will result in errors for Windows 95/98/Me clients, which do not recognize .cmd as an extension for batch files.

Because the logon script will be executed on a Windows system, it must be in MS-DOS text-file format, with the end of line composed of a carriage return followed by a linefeed. The Unix convention is a newline, which is simply a linefeed character, so if you use a Unix text editor to create your logon script, you must somehow make it use the appropriate characters. With vim (a clone of the vi editor that is distributed with Red Hat Linux), the method is to create a new file and use the command:

:se ff=dos

to set the file format to MS-DOS style before typing in any text. With emacs, the same can be done using the command:

^X Enter f dos Enter

where ^X is a Control-X character and Enter is a press of the Enter key. Another method is to create a Unix-format file in any text editor and then convert it to MS-DOS format using the unix2dos program:

$ unix2dos unix_file >logon.bat

If your system does not have unix2dos, don't worry. You can implement it yourself with the following two-line Perl script:

#!/usr/bin/perl
open FILE, $ARGV[0];
while (<FILE>) { s/$/\r/; print }

Or, you can use Notepad on a Windows system to write your script and then drag the logon script over to a folder on the Samba server. In any case, you can check the format of your script using the od command, like this:

$ od -c logon.bat

You should see output resembling this:

0000000   n  e  t     u  s  e      T   :    \  \  t  o  l
0000020   t  e  c  \  t  e  s  t  \r  \n
0000032

The important detail here is that at the end of each line is a \r \n, which is a carriage return followed by a linefeed.

Our example logon script, containing a single net use command, was created and set up in a way that allows it to be run successfully on any Windows client, regardless of which Windows version is installed on the client and which user is authenticating or logging on to the domain. But what if we need to have different users, computers, or Windows versions running different logon scripts?

One method is to use variables inside the logon script that cause commands to be conditionally executed. For details on how to do this, you can consult a reference on batch-file programming for MS-DOS and Windows NT command language. One such reference is Windows NT System Administration, published by O'Reilly.

Windows batch-command language is very limited in functionality. Fortunately, Samba also supports a means by which customization can be handled. The smb.conf file contains variables that can be used to insert (at runtime) the name of the server (%L), the username of the person who is accessing the server's resources (%u), or the computer name of the client system (%m). To give an example, if we set up the path to the logon script as:

logon script = %u/logon.bat

we would then put a directory for each user in the [netlogon] share, with each directory named the same as the user's username, and in each directory we would put a customized logon.bat file. Then each user would have his own custom logon script. We will give you a better example of how to do this kind of thing in the next section, Section 4.5.

TIP

For more information on Samba configuration file variables, such as the %L, %u, and %m variables we just used, see Chapter 6 and Appendix B.

When modifying and testing your logon script, don't just log off of your Windows session and log back on to make your script run. Instead, restart (reboot) your system before logging back on. Because Windows often keeps the [netlogon] share open across logon sessions, the reboot ensures that Windows and Samba have completely released and reconnected the [netlogon] share, and the new version of the logon script is being run while logging on.

More information regarding logon scripts can be found in the O'Reilly book, Managing Windows NT Logons.