Directories, accounts, and authentication
Now that we have a PDC configuration file in place, it's time to finish up the remaining server-side administrative items; namely, creating the requisite directories required by the shares in
smb.conf, setting the appropriate permission on these directories, and adding the necessary user/machine accounts.
But first, let's create two groups to help manage the domain:
[root@phoenix root]# group -g 200 admins [root@phoenix root]# group -g 201 machines
The first command creates the admin group with a GID of 200 (chosen so as to not conflict with any other existing groups); the second creates a machine group with a GID of 201. The first group will contain users who are allowed to administer certain aspects of the PDC. The second group is a convenient way to organize the machine accounts we'll be creating shortly.
Now that the above groups are in place, we can go ahead and create the two required directories and set the correct ownership.
[root@phoenix root]# mkdir -m 0775 /home/netlogon [root@phoenix root]# chown root.admins /home/netlogon [root@phoenix root]# mkdir /home/samba /home/samba/profiles [root@phoenix root]# chmod 1757 /home/samba/profiles
Setting the correct permissions and ownership on the above directories is a critical step in securing your server. Don't forget, when a client logs onto the server, any file in the
/home/netlogon directory named (in our example configuration)
netlogon.bat will be automatically downloaded and executed. It doesn't take a brain surgeon to see how easy it would be to write a destructive script or plant a trojan on every client on your network. The "chown" command set on the
/home/samba/profiles is equally important to user security. In effect, this command sets the directory permission such that root owns everything down to the "profiles" branch of the tree, and the user owns everything below that (the directory created to hold their profile and all the information it contains). This mean a user cannot "climb out" of their profile directory and accidently (or intentionally) mess with any other user's files.
Double-check that you've typed in the above commands exactly as shown -- this step is an important one.
Now that Samba is configured and the required directories are in place, it's time to add user and machine accounts to the domain. Unfortunately, this is a rather complex topic, and once understood, a bit of a tedious process. The crux of the problem lies in the fact that Windows passwords and UNIX/Linux passwords are different beasts. The "bridge" between the two incompatible formats is the Samba password file (in our compiled example,
/etc/samba/smbpasswd). The Samba password file, however, demands a corresponding UNIX account on the same machine. So what we end up with, is two kinds of accounts (user and machine) in two different passwords files (UNIX and Samba, or
The user accounts are self-explanatory and easy to grasp. Machine accounts--which also require entries in both the UNIX and Samba password files--are known as trust accounts (in Windows parlance, computer accounts). When a trust or machine account is created, a "secret" is automatically generated (similar in concept to a unique machine name/password combination). This secret is used as a means of secure communication between the client and the domain controller, and to prevent an unauthorized machine with the same NetBIOS name from joining the domain and gaining access to data stored there.
Here's where things get a little tricky. Windows NT/2000/XP clients fully support the concept of trust accounts; Windows 9x/ME clients do not. As a matter of fact, the only concept of domains supported by Windows 9x/ME is the logon mechanism whereby the client will download a system policy if there is one present, and store a profile on the server. Windows 9x/ME has no concept of machine trust or security, which makes it remarkably easy to "spoof" a domain controller into accepting a logon from a Win9X machine that is not who it claims to be. That's why Windows 9x/ME clients are particularly unsuited to domain-type networks. Now that we have that little bit of trivia out of the way, let's move on to creating machine or trust accounts on the PDC. There are two methods available:
- Manual creation where both the UNIX and Samba passwords are added "by hand".
- Automatic creation via an "add user" script in the
As noted, Samba will not allow you to add an entry to the smbpasswd file (user or machine) unless there is a existing UNIX account for that user. So the first step is to create an entry for the client in
[root@phoenix root]# /usr/sbin/useradd -g machines -d /dev/null -c "machine id" -s /bin/false machine_name$ [root@phoenix root]# passwd -l machine_name$ Changing password for user machine_name$ Locking password for user machine_name$
The first command creates the user machine_name (don't forget the dollar-sign; it's required and identifies the entry as a trust account)), as a member of the group machines (
-g), with no home directory (
-d /dev/null), a descriptive entry (
-c; for example, "Tom's Notebook"), and no shell access (
-s /bin/false). The second command creates a "secret" for the machine to authenticate against.
With the UNIX account created, we can now add the machine to
/etc/samba/smbpasswd as shown below:
[root@phoenix root]# smbpasswd -a -m machine_name Added user machine_name$
Two things to note in the above command: One, if you installed Samba under
/usr/local/samba, you'll probably have to provide the complete path (ie,
/usr/local/samba/bin/smbpasswd). Two, when entering the machine_name, do not append a dollar-sign; it's not required with smbpasswd.
WARNING: Once a trust account has been created on the PDC, it's good policy to connect the client ASAP (which, in effect, changes the machine "password" and syncs the secret between the server and the client). Until the client formally connects to the PDC, the domain is vulnerable to another machine connecting with the same NetBIOS name.
The second approach to creating machine/trust account on the PDC is to allow Samba to create them as needed when the client first joins the domain. This little bit of magic is accomplished by adding an
add user script option to
smb.conf. This creates the UNIX trust account, and tells Samba to automatically create a corresponding entry in smbpasswd. The following is an example of an entry based on a Redhat distribution:
[global] ... add user script = /usr/sbin/useradd -d /dev/null -g machines -s /bin/false -M %u ...
The important thing to note in the above command is that the command to add users may vary across operating systems and/or distributions, so tweak accordingly.
The last piece of information we need to provide the PDC is a means of authenticating users. As discussed at the beginning of this section, this is accomplished by adding user accounts to both
/etc/samba/smbpasswd. Unfortunately, there are no cute configuration options to automate this process (a shell script might ease the tedium). Here are the three commands necessary to create the two required user accounts:
[root@phoenix root]# useradd leah [root@phoenix root]# passwd leah New password: Retype new password: passwd: all authentication tokens updated successfully [root@phoenix root]# smbpasswd -a leah New SMB password: Retype new SMB password: Added user leah.
Note that you'll need to create a root user account in order to join Windows NT/2000 machines to the domain. Treat the password you use with the same care and security as you would the UNIX root password; it has all the same authority.
TIP: I make it a policy to make UIDs the same for all systems on my network; it saves a whole bunch of authentication issues down the road. I also make sure that every user has only one password--that is, I use the same password for UNIX and Samba. Again, it makes for easy system and user management.
The last topic of this section is password synchronization. One of the challenges with using Samba is trying to keep user passwords in sync between UNIX and Samba. There is another way of accomplishing this other than going to a backend user-management system like LDAP or NIS. The options statements below will allow a user to change their Samba password from a Windows client, which will in turn update their UNIX password to match the new Samba entry. If the UNIX password is changed, however, the same technique does not work in reverse; the Samba password will have to be manually sync'd.
[global] ... ;sync UNIX passwords unix password sync = yes passwd program = /usr/bin/passwd %u passwd chat = *New*UNIX*password* %n\n *Retype*new*UNIX*password* %n\n *Enter* new*UNIX*password* %n\n *Retype*new*UNIX*password* %n\n *passwd: *all* authentication*tokens*updated*successfully* ...
About the only thing that bears mentioning in the above statements is that the
passwd chat option, despite how it might display here, is entered on one line. Note also that some options use "password" and others use "passwd".
Configuration of the Samba PDC is complete. The only thing left to do is join the clients to the domain.