Skip to main content

If you don't have an IBM ID and password, register here.

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. This profile includes the first name, last name, and display name you identified when you registered with developerWorks. Select information in your developerWorks profile is displayed to the public, but you may edit the information at any time. Your first name, last name (unless you choose to hide them), and display name will accompany the content that you post.

All information submitted is secure.

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

Using Samba as a PDC

Tom Syroid is a contract writer for Studio B Productions, a literary agency based in Indianapolis, IN specializing in computer-oriented publications. Topics of interest/specialty include *NIX system security, Samba, Apache, and Web database applications based on PHP and MySQL. He has experience administering and maintaining a diverse range of operating systems including Linux (Red Hat, OpenLinux, Mandrake, Slackware, Gentoo), Windows (95, 98, NT, 2000, and XP), and AIX (4.3.3 and 5.1). He is also the co-author of Outlook 2000 in a Nutshell (O'Reilly & Associates) and OpenLinux Secrets (Hungry Minds). Tom lives in Saskatoon, Saskatchewan with his wife and two children. Hobbies include breaking perfectly good computer installations and then figuring out how to fix them, gardening, reading, and building complex structures out of Lego with his kids. Questions, comments, and errata submissions are welcome; you can either e-mail the author directly (dwcomments@syroidmanor.com.

Summary:  Open-source Samba turns a UNIX or Linux system into a file and print server for Microsoft Windows network clients. Tom Syroid dishes up a juicy tutorial that shows you how to configure Samba as the primary domain controller on an xSeries server.

Date:  03 Apr 2002
Level:  Introductory

Comments:  

Directories, accounts, and authentication

Creating the PDC administrative directories

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.


Authentication: user and machine accounts

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 /etc/passwd and /etc/samba/smbpasswd, respectively).

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 smb.conf.

Machine accounts: the manual approach

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 /etc/passwd:

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


Machine accounts: an automated approach

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.


Adding user accounts

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/passwd and /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.


Keeping user accounts in sync

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.

3 of 8 | Previous | Next

Comments



Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=AIX and UNIX
ArticleID=105868
TutorialTitle=Using Samba as a PDC
publish-date=04032002
author1-email=dwcomments@syroidmanor.com
author1-email-cc=

Tags

Help
Use the search field to find all types of content in My developerWorks with that tag.

Use the slider bar to see more or fewer tags.

Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).

My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).

Use the search field to find all types of content in My developerWorks with that tag. Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere). My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).