In previous chapters, we’ve focused on workgroup networking to keep things simple and introduce you to networking with Samba in the most painless manner we could find. However, workgroup computing has its drawbacks, and for many computing environments, the greater security and single logon of the Windows NT domain make it worthwhile to spend the extra effort to implement a domain.
In addition to the domain features of that we discussed in Chapter 1, having a domain makes it possible to use logon scripts and roaming profiles (also called roving profiles ). A logon script is a text file of commands that are run during startup, and a profile is a collection of information regarding the desktop environment, including the contents of the Start menu, icons that appear on the desktop, and other characteristics about the GUI environment that users are allowed to customize. A roaming profile can follow its owner from computer to computer, allowing her to have the same familiar interface appear wherever she logs on.
A Windows NT domain offers centralized control over the network. Policies can be set up by an administrator to define aspects of the users’ environment and limit the amount of control they have over the network and their computers. It is also possible for administrators to perform remote administration of the domain controllers from any Windows NT/2000/XP workstation.
Samba 2.2 has the ability to act as a primary domain controller, supporting domain logons from Windows 95/98/Me/NT/2000/XP computers and allowing Windows NT/2000/XP systems to join the domain as domain member servers. Samba can also join a domain as a member server, allowing the primary domain controller to be a Windows NT/2000 system or another Samba server.
Samba 2.2 does not support LDAP and Kerberos authentication of Active Directory, so it cannot act as a Windows 2000 Active Directory domain controller. However, Samba can be added to an Active Directory domain as a member server, with the Windows 2000 domain controllers running in either mixed or native mode. The Windows 2000 server (even if it is running in native mode) supports the Samba server by acting as a PDC emulator, using the Windows NT style of authentication rather than the Kerberos style.
If you’re adding a Samba server to a network that has already been set up, you won’t have to decide whether to use a workgroup or a domain; you will simply have to be compatible with what’s already in place. If you do have a choice, we suggest you evaluate both workgroup and domain computing carefully before rolling out a big installation. You will have a lot of work to do if you later need to convert one to the other. One last thought on this matter is that Microsoft is developing Windows in the direction of increased use of domains and is intending that eventually Windows networks be composed solely of Active Directory domains. If you implement a Windows NT domain now, you’ll be in a better position to transition to Active Directory later, after Samba has better support for it.
In this chapter, we cover various topics directly related to using Samba in a Windows NT domain, including:
Configuring and using Samba as the primary domain controller
Setting up Windows 95/98/Me systems to log on to the domain
Implementing user-level security on Windows 95/98/Me
Adding Windows NT/2000/XP systems to the domain
Configuring logon scripts, roaming profiles, and system policies
Adding a Samba server to a domain as a member server
Samba 2.2 is able to handle the most desired functions of a primary domain controller in a Windows NT domain, handling domain logons and authentication for accessing shared resources, as well as supporting logon scripts, roaming profiles, and system policies.
You will need to use at least Samba 2.2 to ensure that PDC functionality for Windows NT/2000/XP clients is present. Prior to Samba 2.2, only limited user authentication for NT clients was present.
In this section, we will show you how to configure Samba as a PDC for use with Windows 95/98/Me and Windows NT/2000/XP clients. The two groups of Windows versions interact differently within domains, and in some cases are supported in slightly different ways. If you know you are going to be using only Windows 95/98/Me or Windows NT/2000/XP, you can set up Samba to support only that group. However, there isn’t any harm in supporting both at the same time.
Samba must be the only domain controller for the domain. Make sure that a PDC isn’t already active, and that there are no backup domain controllers. Samba 2.2 is not able to communicate with backup domain controllers, and having domain controllers in your domain with unsynchronized data would result in a very dysfunctional network.
Although Samba 2.2 cannot function as, or work with, a Windows NT
BDC, it is possible to set up
another Samba server to act as a backup for a Samba PDC. For further
information, see the file
docs/htmldocs directory of the Samba
Configuring Samba to be a PDC is a matter of modifying the
smb.conf file, creating some directories, and
restarting the server.
First you will need to start with an
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] ; 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
[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
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.
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,
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
makes Samba force an election when it starts up. The
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
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
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
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,
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
%u are replaced by Samba
with the name of the server and the username of the logged on user,
respectively. The section in
[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
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
The settings of
home have a couple of
H: allows the home directory
of the user to be connected to drive letter H on the client. The
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
[homes] share that we are adding, as we
will explain a bit later.
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
The last parameter to add to the
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
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
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
no definition is used to make the share read-only.
Users do not need to see the share, so we set
no to make the share invisible.
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
mask (read and write
permitted for the owner only) and
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.
share is necessary for our
home to work. Samba uses
[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.
chmod 775 /usr/local/samba/lib/netlogon#
chmod 777 /home/samba-ntprof
The directory names we use are just examples. You are free to choose your own.
(or use whatever method works on your system, as discussed in Chapter 2.) The server is now ready to accept domain logons.
 When we include Windows XP in discussions of Windows NT domains in this book, we are referring to Windows XP Professional and not to the Home edition. The reason for this is explained in the section on Windows XP later in this chapter.