Authentication to Samba as a PDC

Samba is a suite of tools that helps Linux pretend to be a Windows machine, at least for authentication and file and print services. That is, you can run Samba on a Linux machine and share files to Windows clients or run Samba on a Linux machine and grab files on an existing Windows server.

Samba takes its clever name from the protocol that's used under the hood for file transfers: Server-Message-Block, or SMB. Samba isn't just available for Linux; it's available for a litany of non-Windows operating systemsbe sure to check out www.samba.org for the complete list.

We'll be exploring Samba backward and forward in the upcoming chapters in this book. In this chapter, you'll perform just one major magic trick with Samba: you'll make it look, act, and quack like a Windows NT 4 PDC (Primary Domain Controller) and authenticate your Windows ducklings, er, clients.

Note 

It is also possible to authenticate Linux clients directly to a Samba PDC (or NT 4 PDC). We don't cover that in this chapter. However, we do have a related sidebar in Chapter 3, "Making Linux Clients Authenticate to a PDC." In general, however, authenticating Linux clients to a Samba PDC doesn't make sense. That's because complete Unix user and group ID information is more easily available from NIS or LDAP, running on the very same Linux server.

Before we go on and you fall in love with Samba, here are the two major shortcomings (as we see it) to making your Linux servers pretend to be NT 4:

• No Active Directory-based Group Policy for Windows 2000, Windows XP, and Windows 2003 clients. For us, this is a showstopper in a production environment. Group Policy is a major force in Windows managementand with a bajillion Windows clients out thereso not being able to use Group Policy to manage your Windows clients puts a damper on Samba's usefulness as a Domain Controller.

• While you can make Samba server pretend to be both a NT 4 PDC (which you'll do here) and NT 4 BDC (which we're not going to show at all), there are real issues:

  • Samba cannot be the BDC of a real NT 4 PDC.

  • Samba cannot be a BDC when the domain is Active Directory. Not even when the Active Directory is in "mixed mode," which would normally allow NT 4.0 BDCs!

  In other words, Samba can only be a BDC when the PDC is a Samba server. This is a real drag, as it makes branch office deployments of Samba when the main office is Active Directory a real challenge. Samba 3.0's maximal usefulness as a Domain Controller can be seen in Figure 2.15. This diagram is for example; this isn't how we're going to configure it.

Figure 2.15: Here's how Samba might integrate into your environment.

In essence, while pretending to be a Domain Controller, Samba 3 is capable of one thing: pretending to be NT 4. While this might be sufficient for older Windows clients and any kind of Linux client, the loss of enterprise-quality identity management is painful. That is, having "pockets" of micro-directories in your enterprise is a hassle you don't need. However, depending on what you need to do with it, Samba might just be the ticket, so we'll present it here.

Note 

We'll also be exploring Samba in Chapter 4 as a file server. Indeed, it can integrate quite nicely with existing Active Directory and can be a very useful additional free file server when you need it.

Samba is capable of operating as a fully functional Windows NT 4-style PDC. Before you use it as such, however, you should ask yourself a question: in what kind of repository do you want to store the actual accounts? You have oodles of options pick one:

• smbpasswd files: similar to classic Linux /etc/passwd files.

• tbdsam databases: Samba's own "Trivial DataBase" format, introduced with Samba 3. x . Reasonably fast but not suitable for replication, so this is a good choice only when a single domain controller is sufficient.

• LDAP repositories: use ldapsam as the access mechanism.

• MySQL repositories: use mysqlsam as the access mechanism.

• Xmlsam repositories: use a text-based file with XML content.

With so many choices, what's best?

Option 1: tdbsam (can be easier) smbpasswd and tbdsam are easiest to set up. Neither even tries to replace /etc/passwd . Instead, they extend it. The smbpasswd back end uses a smbpasswd file that adds a Windows password hash but doesn't extend /etc/passwd further than that. However, smbpasswd has fallen out of favor, and tdbsam is becoming more popular. This is because smbpasswd does not scale well to large numbers of users and does not provide for storage of additional Windows-specific information about users, groups, or computers. The tdbsam back end, on the other hand, is powerful enough to store all the information you might need for a real domain controller if you're working in a vacuum with just one domain controller, that is. tdbsam is not recommended for more than 250 users, according to the Samba development team. And using tdbsam doesn't provide a way to build Linux-based BDCs for your Linux-based PDC, so it doesn't scale very well. It also can't build on your existing work with LDAP for Linux client authentication. However, if you're flipping through this book and you're in a hurry to build a stand-alone PDC, tdbsam is likely to be your choice. However, bear in mind that certain projects later in the book will only work by going forward with the LDAP option.

Option 2: OpenLDAP (more robust and scalable) You can store the accounts in OpenLDAP or another LDAP server with the ldapsam Samba back end. Since LDAP databases are easy to replicate, it is possible to build BDCs when you choose this method, and OpenLDAP is a genuine database built for lots and lots of accounts. Also, if you've been following along up until this point, you've already built an OpenLDAP database and you can leverage that work. That is, you can make the OpenLDAP database the place where the accounts live for Samba, and those same accounts are already valid for your Linux LDAP clients . We strongly recommend LDAP for large deployments.

In the next two big sections, we'll examine both methods . But, then, we'll configure the robust LDAP method. In real life, you wouldn't do both on the same server, so don't do so here. Our suggestion is to pick a method (Option 1 or Option 2) and stick with it.

Note 

In this book, we're not going to be discussing the other three possible ways to configure Samba account databases. That is, we're not going to cover smbpasswd files, MySQL repositories (via mysqlsam ), or Xmlsam repositories. If these options interest you, you can check out www.samba.org/samba/docs/man/Samba-HOWTO-Collection/ . This is also a useful guide for the myriad of options you can stick in a smb.conf file (explored in a moment.) Unlike many Samba HOWTOs on the Net, this official HOWTO stays reasonably up to date with changes in the Samba 3. x series.

Option 1: Samba Storing Accounts in tdbsam

The Samba project has its own simple database format, called TDB. tdbsam is the name of the Samba back-end module that allows TDB to be used as a repository for user accounts.

If you're gung-ho about using the tdbsam back end, we've got a how-to on our website at www.winlinanswers.com/ for how to do this. However, for this book, we recommend you stick with ldapsam as the back-end and continue on by implementing Option 2, below. Doing a good job with tdbsam is nearly as much work, especially if you already built an LDAP authentication system earlier in this chapter. And the end result doesn't scale well, or integrate as well with certain aspects of the e-mail system we'll build in Chapter 6.

Option 2: Samba Storing Accounts in OpenLDAP

In this section, you'll set up a Samba PDC to use an LDAP database back end for better scalability.

Note 

In practice, you'd use either the tdbsam or LDAP as the back-end. So if you've already gone up to our website, and used the downloadable documentation to implement the tdbsam back end, no need to proceed here.

If you want to use the more robust LDAP, doing so is easier than you might think, thanks to the work you already did earlier in this chapter to enable LDAP authentication for Unix clients. You can reuse all of that work as part of your Samba PDC. In other words, you'll be using your LDAP server as a back end to store the actual account information, as shown in Figure 2.16. As an added benefit, Linux clients can continue to authenticate directly to the LDAP server using the same accounts that are valid on Windows workstations.

Figure 2.16: Internal architecture of your Samba PDC

The same "LDAP Users and Groups" Webmin module you used earlier can also be used to administer Samba domain accounts! In fact, LDAP accounts you already created can be "upgraded" to allow Samba authentication. But first, there are a few housekeeping chores you must attend to.

In the previous section, you built a complete authentication system based on a popular LDAP server called OpenLDAP. Additionally, to make sure your passwords weren't being sent around in the clear, you used SSL encryption based on certificates issued by a Certification Authority so your clients and your OpenLDAP server could securely communicate.

Adjusting the Firewall to Allow Samba Traffic

Much like LDAP, Samba is compatible with Fedora's standard firewall software, but it is necessary to open up a few additional ports. Specifically , you must open ports 137 (for NetBIOS browsing), 138 (for NetBIOS name service), 139 (for file and printer sharing), and 445 (for Windows 2000, XP, and Windows Server 2003 without the NetBIOS helper). To do so, follow these steps:

1. From the "Applications" menu, select System Settings Security Level.

2. If "Disable firewall" is selected, change the setting to "Enable firewall."

3. Add the following to the end of the current contents of the "other ports" list:

    137:udp, 138:udp, 139:tcp, 445:tcp 

4. Click "OK" to complete the process.

Directly authenticating users to LDAP is a reasonable solution for Linux-based networks. If you also have Windows, you can certainly use the pGina plug-in for Windows workstations, but you don't need to with Samba. Samba can act as a PDC, and use your OpenLDAP server as an accounts repository. Why bother? Because a Samba PDC pretends to be a Windows NT 4.0 PDC and therefore you needn't modify any Windows clients to authenticate right to it. There's no need to reconfigure every Windows client with, say, pGina to make the magical connection. All the client workstations need to do is join the Samba domainexactly as they would join an NT 4 domain.

Adding samba.schema to OpenLDAP

To store Windows account information in OpenLDAP, you need a slightly enhanced set of structure and syntax definitionsa different schema. For instance, in the Samba/Windows world, each account contains a flag that indicates whether an account is a user account (for a person) or machine account (for a workstation). Unix accounts make no operational distinction between users and workstations, so the OpenLDAP schema files do not contain an attribute for the associated flag.

Out of the box, OpenLDAP knows how to handle Linux accounts because there's a convenient definition of what a Linux account looks like. This is contained within the file /etc/openldap/schema/nis.schema . You told OpenLDAP to use this definition via an include directive in the /etc/openldap/slapd.conf file. In other words, you taught OpenLDAP how to handle Unix accounts. Now you need to tell it how to handle Windows accounts.

OpenLDAP doesn't include an out-of-the-box schema that defines the additional characteristics that make Windows accounts different. Fortunately, however, the Samba software does include a ready-to-go samba.schema file. Once plugged into your OpenLDAP server's /etc/openldap/schema directory, your existing OpenLDAP server will be ready to rock for Windows accounts.

Nothing's easy. Things are complicated just a little bit by the fact that the samba.schema file is in the Samba documentation directory and there is a Samba documentation directory for each version of Samba that has previously been installed. When you updated your packages in Chapter 1, you most likely wound up with at least two Samba documentation directories: one for the version that came on the CD and one for the latest official version from Fedora. As of this writing, the current version is version 3.0.10, which places the Samba documentation in the /usr/share/doc/samba-3.0.10 directory. Your Samba version is most likely more recent than ours.

Use the ls -d command to list all of the Samba documentation directories, making it easy to pick out the newest version.

Tip 

The -d option for the ls command specifies that directories should be listed by name only, without descending to list their contents.

To take care of these tasks , just follow these steps:

1. Add the following line to /etc/openldap/slapd.conf , immediately following the last include line already present:

    include         /etc/openldap/schema/samba.schema 

2. Locate your Samba documentation directory:

    ls -d /usr/share/doc/samba-* 

   Make note of the most recent version number if you see more than one, and substitute that version for 3.0.10 in the step that follows .

3. Copy the samba.schema file from the Samba documentation directory to /etc/openldap/schema:

    cp /usr/share/doc/samba-3.0.10/LDAP/samba.schema /etc/openldap/schema 

Speeding Up Samba/OpenLDAP Performance

Performance is also important. The OpenLDAP server can always answer any query by searching through its entire database, one item at a time. But if you have a bajillion accounts in your OpenLDAP database, it makes sense to perform an index ahead of time.

index directives in /etc/openldap/slapd.conf already speed up requests such as "give me the account object for the username fred ." But Samba may also need to look up a workstation quickly by its SID (security identifier). To all this, you'll add an index directive to speed up such common Windows requests.

Add the following additional line to / etc/openldap/slapd.conf , following the last index line already present in that file:

 index sambaSID,sambaPrimaryGroupSID,sambaDomainName     eq 

Restarting OpenLDAP with the Samba Changes

You can now restart the OpenLDAP service with these changes by executing the following command at the terminal prompt as root:

 service ldap restart 

"Glue" for Samba and LDAP: The smbldap-tools

Samba ships with the built-in capability to consult an LDAP database for user authenticationbut there's more to operating a full-fledged PDC than simply fielding ongoing user authentication requests.

For a Windows workstation to be happy, it has to be a member of a domain. It doesn't have to be a Windows domainit can be a Samba domain pretending to be a Windows domain. But in either case, the Windows machine must be able to join the domain in the usual Windows way without the manual intervention of an administrator on the server itself. Additionally, a domain administrator might also want to create and administer user accounts via Windows-based domain administration tools, and the PDC should handle these requests correctly as well.

You would think that these capabilities would be built right into the Samba package. But they're not. The authors of Samba followed a very Unix philosophy: each program should do one job well. Samba's primary job is to speak "Windows." Its secondary job is to interface with other programs that do things like managing accounts and storing directory information. You're using LDAP to ultimately store your accounts, but others may choose completely different back ends. Since Samba doesn't implement the back-end, it must provide a way to specify programs that should be run to carry out each of the back-end tasks when they are needed.

Since LDAP is the back end, you can take advantage of a ready-made suite of programs for those back-end tasks. Implemented as a collection of scripts written in the Perl programming language, the smbldap-tools suite provides the necessary "glue" between Samba and LDAP. While the name "tools" might suggest programs that the administrator runs personally , for the most part this is not the case. Most of the smbldap-tools are meant to be run automatically by Samba. For instance, every time an administrator sits down at a workstation and joins that workstation to the domain, Samba automatically starts up the command smbldap-adduser with a special -w option that specifies a workstation account is being added rather than a regular user account. That tool then adds an object representing the new workstation in the LDAP database. Without the ability to do this, a Samba server can't accommodate adding a new workstation or other administrative tasks in the standard Windows way using tools Windows administrators are familiar with. You would constantly need manual administrator interaction on the server itselfnot to mention that the standard Windows dialog boxes to join a domain wouldn't work. And that's no fun. Hence, you'll employ the smbldap-tools to make sure all of the standard Windows dialogs for administering a domain work properly with your Samba domain.

Preparing for the smbldap-tools Installation

While a copy of these scripts is included with Samba, the latest and greatest version is maintained by the generous folks at Idealx , who offer the tools at http://samba.idealx.org . We recommend you use the latest version directly from Idealx; our instructions are based the latest version we could get a hold of.

To obtain and install the smbldap-tools , just follow these steps:

1. Access the URL http://samba.idealx.org/dist/ .

2. Download the latest version in .tar.gz format. You'll see an example of the right file in Figure 2.17. As of this writing, the latest version is smbldap-tools-0.8.6.tgz. (An rpm file is available, but we cannot recommend using it because of dependency error messages that could not be satisfactorily resolved with the rpm command as of this writing. In other words, we couldn't get it to work properly.)

3. Copy this file to /usr/local/src on LinServ1 . If you download the file to a Windows machine, we suggest copying the file to LinServ1 using the free, user-friendly "WinSCP" Windows scp program (available from http://winscp. sourceforge .net ).

4. Change the directory with the cd /usr/local/src command.

5. A .tgz file is a file that has been "tarred," meaning that many files have been accumulated together into a single archive, and then " gzipped ," a Unix file format closely related to the .zip format common on Windows systems. To unpack the contents of the file and change the current directory to the newly unpacked directory, you can use the tar command. Pass three options, z , x , and f . z indicates that the input file is gzipped, x indicates that files should be extracted (read) from the input file, and f indicates that input is from a file rather than from an old-fashioned backup tape drive:

    tar -zxf smbldaptools-0.8.6.tgz cd smbldaptools-0.8.6 

   See the ".tar.gz, gzip, gunzip, and tar" sidebar for more information about gzip, gunzip, and tar.

Figure 2.17: Downloading this latest version of the smbldap-tools

.tar.gz, gzip, gunzip, and tar

The Linux/Unix philosophy generally calls for simple utilities that do a single job well. This is why data compression and the archive creation were traditionally handled by two different tools in the Linux world.

gunzip filename.gz is the reverse of gzip filename . While gzip filename produces a compressed file called filename.gz, gunzip filename.gz restores the original and deletes the compressed version. Unlike .zip, .gz is a simple container format for a single file only.

tar -xf filename.tar is the reverse of tar -cf filename.tar [filename list] . While tar -cf filename.tar [filename list] builds a new .tar archive containing all of the specified files, including subdirectories of any directories in the list, tar -xf filename.tar extracts and restores all of the files found in the .tar file. Unlike gzip and gunzip, tar -cf and tar -xf do not delete the original files or the .tar file, respectively.

In recent years , the z option was added to tar as a convenience; it automatically invokes gunzip on the fly to take care of unzipping compressed data before extracting files from the archive. When the z option is used, the .tar.gz or .tgz file is not replaced with a .tar file. Instead, tar skips ahead to extracting the actual contents of the archive.

 

Teaching Samba How to Encrypt Passwords

The latest versions of the smbldap-tools can encrypt Samba passwords directly, which is a nice performance boost over previous versions that relied on a separate program to do this. However, since the smbldap-tools are written in the Perl programming language, you need to install the optional "Crypt::SmbHash" Perl module to make this feature work. Fortunately, the Perl community maintains a central repository of such modules called the CPAN (Comprehensive Perl Archive Network).

Fedora includes a helpful up2date-like tool called cpan for installing the latest versions of such modules, and it provides a fairly painless way to install any widely recognized enhancement for Perl. You can learn more about Perl by visiting www.perl.org . For more information about CPAN, see www.cpan.org .

To install the "Crypt::SmbHash" Perl module:

1. Execute the cpan command:

    cpan 

   If you have never used cpan before on LinServ1 , you may be asked if you wish to manually configure it. You can answer no to this prompt; the automatic configuration is quite effective.

2. When the cpan> prompt appears, enter the following command to install the "Crypt::SmbHash" Perl module:

    install Crypt::SmbHash 

3. When the cpan> prompt returns, quit cpan with this command:

    quit 

Installing the smbldap-tools on Your System

You're nearly ready to install the smbldap-tools utility programs. Before you do, you'll need to change two settings in a Perl source code file that all of those utilities share in common, smbldap_tools.pm .

Don't panic when you open the file. Although this file contains Perl programming language code, you don't need to know Perl to understand what needs to be changed. All you need to do is open the file with your preferred text editor, locate two directory names that are set incorrectly for your system, and fix them.

Then, since the file contains Perl code that is used by more than one Perl program, you will install it in a place where all of the smbldap-tools utilities (and any other interested Perl programs) can find it. Once you do this, all of the smbldap-tools will be able to easily learn where their configuration files are. For the record, the standard directory for such things is /usr/lib/perl5/site_perl , a directory deliberately set aside for Perl libraries and modules like smbldap_tools.pm that are not part of cpan.

To make the necessary changes we described, you copy the tools to the /usr/local/sbin directory. For the record, this directory is the standard location for utilities intended for the root user but not part of the standard Fedora distribution.

To customize and install the smbldap-tools :

1. Recall that you used the cd command to enter the directory smbldaptools-0.8.6 . To perform the copy, enter the following command

    cp smbldap-* /usr/local/sbin 

2. Edit the file smbldap_tools.pm . Near the top of this file, you'll find these two settings:

    my $smbldap_conf = "/etc/smbldap-tools/smbldap.conf"; my $smbldap_bind_conf = "/etc/smbldap-tools/smbldap_bind.conf"; 

   Make sure the directory names in the quotation marks are exactly as shown. If not, change them to match the preceding code. This ensures that the utilities can find their configuration files properly.

3. Install the smbldap_tools.pm file where Perl scripts can automatically find it:

    cp smbldap_tools.pm /usr/lib/perl5/site_perl 

That's it for installation! Time to move on to the configuration files.

Configuring the smbldap-tools

Now it's time to create the configuration files for the smbldap-tools . These contain the information that the smbldap-tools must know in order to communicate with your LDAP database. For instance, just like any other LDAP client, the smbldap-tools must know what host the LDAP server runs on, what port number it responds on, whether to use SSL encryption, and so forth. In addition, the smbldap-tools must have the right credentials to make changes to the LDAP database because the smbldap-tools carry out administrative tasks, such as creating new account objects.

The smbldap-tools include a pair of sample configuration files. They're great and you'll leverage them as a starting point, but you'll modify them to work with your particular LDAP configuration.

We'll do it in two steps:

1. Copy in the provided sample files.

2. Modify those sample files that will teach smbldap-tools about your OpenLDAP configuration.

Copying in the Sample smbldap-tools Configuration Files

To set up the configuration files, first carry out the following preparatory steps, continuing to work in a terminal window while logged on as root.

1. cd to the directory where you untarred the smbldap-tools :

    cd /usr/local/src/smbldaptools-0.8.6 

2. To create the configuration file directory, use mkdir :

    mkdir /etc/smbldap-tools 

3. Copy the provided configuration files to this directory:

    cp *.conf /etc/smbldap-tools 

Now you're ready to edit the smbldap-tools configuration files, giving the tools critical information they need to access and administer the LDAP database.

smbldap.conf : smbldap-tools Settings

There are essentially two categories of settings found inside smbldap.conf .

One category of settings tells the software where the LDAP sever is, on what port it responds to connections, whether to use SSL, what certificate authorities to trust, and so on. The smbldap.conf file spices this up a little by allowing for the possibility of separate LDAP servers. In large environments, you might have one LDAP server just for write requests and a whole bunch of additional LDAP servers just for read requests. The configuration file calls these servers master and slave . The distinction is somewhat similar to that between a Windows PDC and a Windows BDC, but for the sake of example we'll keep things simple. That is, you've only got one LDAP server, which will provide for both read and write requests, so you'll set the "master" and "slave" options exactly the same . For instance, set masterLDAP to linserv1.corp.com and masterPort to 389 (the standard TCP port number for LDAP), and set slaveLDAP and slavePort the same wayagain, you do not have a separate LDAP server just for read requests.

The second type of setting in smbldap.conf has to do with the way various Windows logon issues should be handled. For instance, should a particular home directory on the server be mapped as a network drive? Should a special Windows batch file be executed on the workstation every time a user logs on? Since this chapter is concerned with authentication, we'll expand on these settings later and use only safe default answers for now.

To set up smbldap.conf for your environment:

1. Open /etc/smbldap-tools/smbldap.conf in a text editor.

2. Set the LDAP server host and port options as follows:

    slaveLDAP="linserv1.corp.com" slavePort="389" masterLDAP="linserv1.corp.com" masterPort="389" 

3. Turn on SSL encryption (also called TLS) when talking to the LDAP server:

    ldapTLS = "1" 

4. Tell the tools to always verify the LDAP server's certificate:

    verify = "require" 

5. Give the tools the location of the CA certificate:

    cafile="/usr/share/ssl/demoCA/cacert.pem" 

6. Set the LDAP suffix, just as in /etc/ldap.conf :

    suffix="dc=ldap,dc=corp,dc=com" 

7. Leave the following defaults for other options, most of which we'll discuss in later chapters:

    userSmbHome="" userProfile="" userScript="%U.cmd" mailDomain="corp.com" userHomeDrive="H:" 

The remaining options may be left unchanged, except for the SID option, which you'll change later when we've launched our Samba server and learned its unique Windows SID (security ID). Since the server doesn't actually have a SID until the Samba server runs for the first time, it makes sense to delay setting this option.

smbldap_bind.conf : Credentials for Talking to the LDAP Server

smbldap_bind.conf is another required file for Samba to talk to your LDAP server. It contains the credentials the LDAP server expects you to present before allowing you to read and write information. Just as in smbldap.conf , there are separate master and slave settings available for writing and reading. And as before, you will set them exactly the same, as you'll use the same LDAP server for reading and writing.

The masterDN option sets the distinguished name of the LDAP root user, which should match the rootDN option you previously set in /etc/openldap/slapd.conf . The masterPW option sets the password associated with the LDAP root user. The slaveDN and slavePW options will be set identical to these. Note that since this file must contain the root LDAP password, its permissions should be set carefully . Yes, you read that rightyou need to embed the sensitive LDAP password inside this file. To put a little bit of security upon it, you'll restrict access to who can read this file so you can sleep (at least a little better) at night.

To set up the LDAP credentials for the smbldap-tools :

1. Edit /etc/smbldap-tools/smbldap_bind.conf to match the following:

    slaveDN="cn=root,dc=ldap,dc=corp,dc=com" slavePw="p@ssw0rd" masterDN="cn=root,dc=ldap,dc=corp,dc=com" masterPw="p@ssw0rd" 

2. Set the permissions of /etc/smbldap-tools/smbldap_bind.conf so that only the root user can read the LDAP server password it contains:

    chmod a-rwx,o+r /etc/smbldap-tools/smbldap_bind.conf 

The smbldap-tools are now installed and configured. You're ready to use them to populate the LDAP database with essential Windows networking-related accounts and other settings.

Populating the LDAP Database with Samba Objects

Earlier you adjusted your LDAP schema to include the definitions of Samba objects. Now it's time to actually create common Samba objects that should be present on all Windows-compatible systems, such as the Administrator account. You'll also create the Computers organizational unit, which will store machine trust accounts for workstations that are members of the domain.

Conveniently, the smbldap-tools distribution comes with a command to do all of this for us! Execute the following command as root:

 /usr/local/sbin/smbldap-populate 

This command will warn you that the Users and Groups organizational units already exist; it may generate Perl programmer-oriented warnings as well, as shown next. Neither of these is cause for concern. These acceptable warning messages are shown below for your reference:

 Using builtin directory structure Use of uninitialized value in pattern match (m//) at /usr/local/sbin/smbldap- populate line 118. Use of uninitialized value in concatenation (.) or string at /usr/local/sbin/ smbldap-populate line 126. Use of uninitialized value in concatenation (.) or string at /usr/local/sbin/ smbldap-populate line 126. Use of uninitialized value in string at /usr/lib/perl5/site_perl/smbldap_ tools.pm line 169. Use of uninitialized value in string at /usr/lib/perl5/site_perl/smbldap_ tools.pm line 169. adding new entry: dc=ldap,dc=corp,dc=com failed to add entry: Already exists at /usr/local/sbin/smbldap-populate line 389, <GEN1> line 2. adding new entry: ou=Users,dc=ldap,dc=corp,dc=com failed to add entry: Already exists at /usr/local/sbin/smbldap-populate line 389, <GEN1> line 3. adding new entry: ou=Groups,dc=ldap,dc=corp,dc=com failed to add entry: Already exists at /usr/local/sbin/smbldap-populate line 389, <GEN1> line 4. 

You may wish to verify that the information was successfully added to the LDAP database. You can do so with the following command:

 ldapsearch -x  less 

Tip 

The less command will display another page of output every time you hit the space bar. When you reach the end of the output, press the q key to quit less .

You should see references to the Administrator and Nobody accounts as well as the Computers organizational unit. If not, double-check your slapd.conf file carefully and review any error messages not just shown that were received from smbldap-populate . Then restart the OpenLDAP server with the service ldap restart command and run smbldap-populate again.

There is one more critical object that must be created in the LDAP database. Most administrative tasks, including the joining of workstations to a domain, must be carried out by the administrative user. By convention, this user is named administrator in the Windows world. Samba conveniently remaps administrator to the root account via the file / etc/samba/ smbusers . But there's one catch: when LDAP is used as the password database, it isn't enough for root to exist only as a regular Unix account in the server's /etc/passwd file, root must also exist in the LDAP database. Otherwise , attempts to join the domain will fail with mysterious , unhelpful error messages.

Take care of this chore using the smbldap-passwd command:

 /usr/local/sbin/smbldap-passwd root 

Enter root's password correctly twice to confirm the change. In theory, you could now eliminate root's entry from /etc/passwd , but we strongly discourage you from doing so as the option of logging in locally as root is critical when LDAP servers behave badly .

Configuring Samba Itself

Now that the back-end LDAP database is ready to rock, you are at last ready to configure Samba itself! Samba is configured via the file /etc/samba/smb.conf . Although a stock version is provided with your Fedora system, we strongly recommend that you replace it with the version presented here and on our website.

In our examples, we have already made the changes necessary to accommodate operation as an NT primary domain controller rather than a simple workgroup server.

Web-Based Interfaces to Configure Samba: SWAT and Webmin

Editing the smb.conf file by hand isn't the only way to configure Samba. It's also possible to configure Samba using a Webmin module. In addition, the Samba team offers its own web-based user interface, SWAT.

So why are we editing smb.conf by hand? Because initial Samba configuration is a task we do only once. So we don't save much repetitive labor by doing it through a web-based interface. In addition, there is a compelling reason not to. Most of the Samba documentation, online and in print, discusses configuration file options by name. Understanding how these option names relate to text fields and radio buttons in a "friendly" web-based interface can be difficult. So if you have a problem and need support, you're going to need to understand the configuration files. That means it's best to speak the language from the beginning.

In later chapters, we will use Webmin's Samba Windows File Sharing module to speed up simpler and more repetitive tasks, like adding and modifying file shares. We chose to go with Webmin consistently throughout the book for simplicity.

Samba's SWAT interface does present options by their "real" names in the configuration file. But there isn't an enormous difference in convenience between SWAT and editing a text file, especially for the one-time task of initially setting up your configuration file. SWAT is definitely worth a look, though. You can learn more about it here: www.samba.org/samba/docs/man/swat.8.html

 

Tip 

Again, the best reference for smb.conf configuration files is "The Official Samba-3 HOWTO and Reference Guide," available at http://us1.samba.org/samba/docs/man/Samba-HOWTO-Collection .

A little later in the chapter, we'll give you the full configuration of our suggested smb.conf file, but before we present that, here's a breakdown of the decisions that went into each setting in our /etc/samba/smb.conf file, broken up into logical sections:

• Prologue

• Windows Networking Settings

• "Back End Database" LDAP Settings

• Logging Options: Where to Send the Bad News

Prologue In principle, smb.conf can have options in many different categories. In practice, all of the options we use fall into the global category. The first line of smb.conf informs Samba that we are about to list options in the global category, and should always be [global] .

Windows Networking Settings Options in this section have to do with Windows networking issues. What should the domain be called? What networks are allowed to connect to it? How should the Samba server it identify itself to workstations? Do you want the various behaviors associated with a PDC, as opposed to a BDC or mere workgroup server? Should encrypted passwords, required by out-of-the-box modern versions of Windows, be required by Samba? All of these questions are answered by the options in the following list.

• The workgroup option is used for both domains and simple workgroup servers. We set this to corp , the name we chose for our Windows NT-compatible Samba domain.

• The hosts allow option limits the IP addresses that are allowed to connect to the server. The syntax used here is simple: to allow all addresses in our class C local network, 192.168.2, we specify using the odd syntax of 192.168.2 . Similarly, to allow loopback connections from the server itself, we specify 127 . ( All IP addresses with the first byte set to 127 are reserved for a machine that wishes to talk to itself, although in practice only 127.0.0.1 is frequently used.) So, when typing in this particular line be sure to type it in exactly as shown. Specifically, you want to enter in 192.168.2(period)(space) 127(period).

• The server string option allows workstations to tell inquisitive users what server software is being used. We chose to proudly announce our Samba server, but you can choose a more or less interesting response if you prefer.

• The security option determines the type of security model used by Samba. For a domain controller, this option is set to user because our primary goal is user authentication.

• We set the encrypt passwords option to yes. This option is almost a historical footnote at this point. Prior to the release of Windows 98, Windows workstations were quite comfortable with keeping passwords as plain text on the server. With the arrival of Windows 98, unencrypted passwords began to require registry changes on each workstation. Since the release of Windows 98, encrypted passwords have moved from an option to a default to a requirement. This option should always be set to yes on a modern Samba server.

• min passwd length sets the minimum length of a password in characters. You may find that three characters is far too short. Feel free to set a higher minimum.

• domain logons is a crucial option for operation as a PDC or BDC: without it, the server would not accept logons from client workstations. We set this option to yes .

• domain maste r is another PDC-related option. In Windows, the PDC is the domainmaster browser. Setting this the same here would be a functional equivalent. The domain-master browser is responsible for combining browse lists from all of the Ethernet subnets involved that have Windows clients on them. Since this is how a real Windows PDC works, we set it to yes .

• preferred master indicates that the Samba server should be the Windows networking "master browser" for this local subnet. We set this option to yes . This does not guarantee that Samba will be the master; it only forces an "election" to choose a master browser at the time the Samba server starts up. It is not necessarily a problem for another server in the domain to be the master for the subnet on which our Samba domain master server is located. We just want to make sure one is chosen promptly at startup time. This option also implicitly turns on the local master option, which indicates that the server can be a Windows networking master browser for the local subnet.

• We set the wins support option to yes . This option specifies that the Samba server should act as a WINS (Windows Name Service) server. This allows Windows or Samba clients to register their IP addresses and have other clients look them up. It's a nice touch if no Windows server is already performing this chore. If this Samba server is the only server on the network, always set this option to yes . If there are multiple servers present, make sure only one is a WINS server.

"Back End Database" LDAP Settings What sort of database should you use to store passwords? For us, the answer is LDAP. Where is that database? How is it structured? Where should information about users, computers, groups, and Windows SIDs be kept? Should the LDAP connection be encrypted? In the following list, you see the options that resolve these questions.

• The passdb backend option specifies what sort of database should be used to store passwords, as well as the URI (Uniform Resource Identifier) where that database can be reached. We're using LDAP as a back-end repository, so our value for this setting begins with ldapsam: to specify the LDAP Samba back end. This is followed by ldaps://linserv1.corp.com/ , which is understood to mean that an LDAP server is listening on the encrypted LDAP-over-SSL port (636) on the server linserv1.corp.com .

• LDAP passwd sync is a necessity when working with encrypted passwords and using an LDAP back end, which we are. Recall that Unix and Windows use different techniques for encrypting passwords. Samba needs to store the new password in both formats. We set LDAP passwd sync to yes to accomplish this.

• The ldap ssl option specifies that our LDAP connection should be encrypted via SSL.

• The ldap admin dn option specifies the credentials of the LDAP root user, which Samba needs in order to change passwords, an administrative task that it performs directly. You have already seen other administrative tasks that are performed via the smbldap-tools .

• The ldap suffix option is identical in purpose to the suffix option in /etc/openldap/slapd.conf , as covered earlier, and we also set it to ldap suffix = dc=ldap,dc=corp,dc=com .

• ldap group suffix, ldap machine suffix , and ldap user suffix should specify three distinct LDAP organizational units (OUs) in order to avoid name collisions between users, groups and computers. We set them to Groups, Computers , and Users , respectively, matching the existing layout in our LDAP database.

• ldap idmap suffix can share the same organizational unit with ldap user suffix because Windows SIDs are not valid Windows usernames and vice versa. Since a Windows SID will never be the same as a Windows username, there's no risk of the one overwriting the other. The smbldap-tools were designed with this assumption in mind, so we'll follow Idealx's recommended practice by setting this to Users .

Logging Options: Where to Send the Bad News Options in this section are concerned with the logging of error messages, warnings, and diagnostic messages.

• The log level option determines how much information will be included in error log files (see the later section "If Samba Doesn't Work," for more information on how to take advantage of the error logs). We set this to 2 because it causes most useful debugging information to be logged without completely swamping the log file in detail.

• The closely related log file option determines where error messages, warnings, and diagnostic messages related to a particular workstation should be logged. Replacing the %m wildcard with the IP address of the workstation. /var/log/samba/%m.log is a good choice because /var/log/samba is the standard place to log Samba-related activity.

"Glue" Options: Connecting the smbldap-tools to Samba

The options in the preceding section allow Samba itself to talk to LDAP in order to verify and change passwords. As we've described, there are a bunch of additional administrative tasks that Samba doesn't do on its own. The Samba maintainers made a wise decision to break these tasks out, allowing the administrator to plug in tools of their own choosing.

We've already chosen the smbldap-tools , which do a comprehensive job of implementing all of these functions. There's a lot of "under the hood" stuff going on here. It should be noted that the smbldap-tools can be run manually or plugged into scripts of your own. This section provides a useful introduction to their capabilities.

For readability's sake, we chose not to use full paths in this section. All of the smbldaptools scripts are located in /usr/local/sbin/ , and that prefix does appear in the actual configuration file. You will also note wildcards such as %u and %g . Samba automatically replaces these with the actual user (%u) and group (%g) names involved in each request before executing the script in question.

• add user script is executed each time a new user should be added and should be set to smbldap-useradd -a -m '%u' . This instructs smbldap-useradd to add a new user.

  • The -a option specifies that a Windows account should be created.

  • The -m option indicates that a home directory should be created.

  • The '%u' option specifies the username specified by the Windows domain administrator who made the request. Placing %u between single quotes ensures that the Bash command shell does not try to misinterpret any special characters in the username with possibly unwanted consequences. Samba itself takes care of making sure there are no back- ticks (`) in the username that might otherwise ruin this security precaution.

• Similarly, delete user script is executed when a user should be removed. In this case, we use smbldap-userdel and pass it the name of the user to delete, again via the %u wildcard.

• add group script performs a similar task: adding a new group; smbldap- groupadd is used. The -p option indicates that a Windows group should be added, and the username is passed in the same way via '%u' .

• delete group script is similar to delete user script ; smbldap- groupdel is used. The username is passed in via '%u' .

• add user to group script takes care of adding a user to a group; the script smbldapgroupmod is used. The -m specifies that a user should be added to a group. The user and group names are then substituted in using the %u and %g wildcards.

• delete user from group script removes a user from a group. The script smbldap-groupmod is again used, but with different options. The -x option specifies that a user should be removed from a group, and the user and group names are again substituted in using the %u and %g wildcards.

• set primary group script sets the primary group for a user. This is the group that will initially own any files created by the user unless the user expressly specifies otherwise. The smbldap- usermod script is used, with the -g option specifying that the default group should be changed, and the group and usernames (in that order for this particular command) are substituted in using the %g and %u wildcards.

• add machine script runs every time a new workstation joins the domain. The smbldapuseradd script is used, but the -w option clarifies the situation by asking the script to add a workstation account rather than a regular user account.

Listing 2.1: /etc/samba/smb.conf

 [global] # Set our domain name workgroup = corp # Lock out people not on the local LAN. Optional. # Also allow local loopback (127.) hosts allow = 192.168.2. 127. #So, when typing in the hosts allow line (above), be sure to type it in exactly as shown. Specifically, you want to enter in 192.168.2(period)(space)127(period) # Identify our software server string = Samba Server # Security mode should be "user" for a domain controller security = user # We must encrypt passwords to talk to # modern versions of Windows # without registry hacks, and we want to #do that anyway encrypt passwords = yes # Set a reasonable minimum password length min passwd length = 3 # Crucial options to enable operation as a PDC domain logons = yes domain master = yes preferred master = yes wins support = yes #Talk to LDAP via SSL to obtain account information passdb backend = ldapsam:ldaps://linserv1.corp.com/ # Sync our passwords with the ldap database ldap passwd sync = yes ldap ssl = yes ldap admin dn = cn=root,dc=ldap,dc=corp,dc=com ldap suffix = dc=ldap,dc=corp,dc=com ldap group suffix = ou=Groups ldap machine suffix = ou=Computers ldap user suffix = ou=Users ldap idmap suffix = ou=Users #Scripts run to carry out domain administration tasks add user script = /usr/local/sbin/smbldap-useradd -a -m  '%u' delete user script = /usr/local/sbin/smbldap-userdel  '%u' add group script = /usr/local/sbin/smbldap-groupadd -p  '%g' delete group script = /usr/local/sbin/smbldap-groupdel  '%g' add user to group script = /usr/local/sbin/smbldap-groupmod -m '%u'  '%g' delete user from group script = /usr/local/sbin/smbldap-groupmod -x '%u'  '%g' set primary group script = /usr/local/sbin/smbldap-usermod -g '%g'  '%u' add machine script = /usr/local/sbin/smbldap-useradd -w  '%m' #Log enough information to debug problems but not so much as to swamp us log level = 2 # Log errors where Fedora normally does; one # log file per client IP address log file = /var/log/samba/%m.log 

 

Cluing Samba in to the LDAP Root Password

Once the Samba configuration file is ready, you need to make the Samba server aware of the root password for the LDAP database. This is because, while you leverage the smbldap-tools for most administrative tasks, Samba handles password changes internally. For historical reasons, this information is stored in a special file called secrets.tdb that Samba creates in /etc/samba . You do this task using the smbpasswd command and passing the -w option, which indicates that you want to set the password needed to make changes to the LDAP database:

 smbpasswd -w p@ssw0rd 

You should receive the following response:

 Setting stored password for "cn=root,dc=ldap,dc=corp,dc=com" in secrets.tdb 

To continue with Samba configuration, you must now launch the Samba server to determine its SID.

Launching the LDAP-Based Samba Server for the First Time

To start the Samba server and to ensure that it is restarted at the next reboot, enter the following commands as root. The first command ensures that the two Samba server daemons, smbd and nmbd , are always launched at boot time. The second launches the Samba servers now:

 chkconfig --add smb service smb start 

You can now determine the Windows SID (security identifier) of the server using the net command. As you may recall, the smbldap-tools need this information to operate correctly, and you were not able to add the SID option to smbldap.conf earlier because you had not yet generated a SID by starting Samba for the first time. To learn the server's SID, use the following command:

 net getlocalsid 

If your Samba server launched successfully, this should produce output similar to the following. Note that the name of your individual server appears rather than corp , the NT domain name you have chosen. This is not cause for concern.

 SID for domain LINSERV1 is: S-1-5-21-3084340505-2073876770-3452236727 

Now, edit the file /etc/smbldap-tools/smbldap.conf and change the SID setting to match what you received ( don't just copy our example):

 SID="YOURSIDGOESHERE" 

The smbldap-tools are now ready to handle administration requests such as joining a workstation to a domain.

Using Webmin to Administer LDAP User Accounts for Samba

You're nearly ready to join a true Windows client to your Samba domain! To make that truly useful, you'll first need to enable Samba login for each of your existing LDAP users and configure the Webmin LDAP Users and Groups to do so automatically for newly created users in the future.

Configuring the Webmin LDAP Users and Groups Module for Samba

Follow these steps:

1. Log into Webmin. Then click the "System" button, followed by the "LDAP Users and Groups" button.

2. You will note that the display now includes several new users, including the standard Windows account Administrator and the machine trust account linserv1$ . The Groups list has also been expanded quite a bit with a collection of standard Windows groups.

3. Click the "Module Config" link to access the Configuration page.

4. Set the "other objectClasses to add to new users" field to account sambaSamAccount , as shown in Figure 2.18. Note that this means that all newly created LDAP accounts will support Samba domain logins.

5. Scroll down to "Samba account options." To the right of "LDAP object class for Samba users," make sure "sambaSamAccount" is present. This is needed to allow upgrading existing accounts to Samba support.

6. To the right of "Domain SID for Samba3," paste in your SID as received from the net getlocalsid command.

7. Scroll to the end of the page and click "Save."

Figure 2.18: Webmin settings to support Samba accounts in LDAP Users and Groups

Now you're ready to upgrade your user accounts to support Samba.

Upgrading and Adding LDAP Samba-Enabled Accounts with Webmin

You'll also need to retrofit your existing LDAP users to support their new lives as Samba users. After you do that, we'll demonstrate how to add a new account with Samba support.

To upgrade an existing account from the "LDAP Users and Groups" main page, click the user " doctor1 ." On the page that follows, click the radio box next to "Normal password' and enter p@ssw0rd again in the field to the right of the radio box, as shown in Figure 2.19. This is necessary because Unix and Windows both encrypt passwords via a one-way function that does not allow the original password to be recovered. As a result, the Samba password database cannot be automatically populated using the existing LDAP-MD5 password. When upgrading to Samba, administrators have solved this problem by issuing new passwords to all users or by requiring each user to come to a central workstation and reset their password.

Figure 2.19: Upgrading an existing LDAP account to support Samba

Warning 

If you do not reset an existing user's password when adding Samba support to their account, they will not be able to authenticate from a Windows workstation.

Now, scroll down to "User capabilities" and press the radio button labeled "Yes" next to the "Samba login?" This allows doctor1 to authenticate from a Windows workstation. Scroll to the end of the page and click "Save." Repeat this process for doctor2, nurse1 , and nurse2 .

Adding a new account with Samba support is easy: just follow the same procedure described earlier in this chapter to add a new LDAP account. Thanks to your configuration changes, all new accounts will automatically support Samba. You can verify this by adding a doctor3 account.

That's ityour LDAP-based Samba PDC is ready to use! Continue with the next section to learn how to verify its operation.

Joining the Samba Server to its Own Domain

You now have a Samba PDC! Your first test will be a simple loopback test: joining the Samba server to its own domain. While not required for the server to function, this is a useful way to verify your work. To join the Samba PDC to its own domain, just follow these steps:

1. Join the server to its own domain with this command. Enter root's password when asked for it:

    net join 

2. You should receive a response similar to the following, after several seconds' delay:

    [2005/01/25 13:16:01, 0] utils/net_ads.c:ads_startup(186)  ads_connect: Confidentiality required Joined domain CORP. 

If Samba doesn't Work

If you run into trouble, here are some things to try.

Are all of your services properly started? Be sure to verify that the ldap (if you are using LDAP rather than tdbsam), smb , and winbind services have all been started without error messages. If you don't happen to have the output of your service ldap start and service smb start commands in your terminal window's scrollback, there is a convenient way to restart them. The restart option to the service command shuts down a service first, then starts it again:

 service ldap restart service smb restart 

If you forgot to start one or more of these, the service command will complain that the shutdown process failed. This, of course, you may safely ignore. However, if you receive a "FAILED" response for starting one or more of the services, you'll need to go back and review the relevant section of this chapter. If all of the services start successfully and you still can't join your own domain, carefully verify your work in smb.conf and make sure you created the root user in the LDAP database or tdbsam database as described earlier.

Did you check your log files? If the preceding suggestion doesn't resolve your problem, there are more sophisticated ways to learn what went wrong. Most Linux services, including those you're working with, log error messages and warnings via a central service called syslog. syslog, in its standard configuration on Fedora Linux, logs most error messages to the file /var/log/messages , rotating out the oldest contents of the file over time. It is also possible to configure syslog to log error messages from different services to different places and to ignore some messages entirely. Under Linux, syslog does the same job that the event log does under Windows.

The good news is that /var/log/messages is a simple text file. The bad news is that it can be very large. Fortunately, Linux offers a handy command to view only the last few lines of a text file, tail . By default, tail displays the last ten lines of a text file, for example:

 tail /var/log/messages 

You can also display a larger number of lines. To display 100 lines, just specify -100 as the first option. You can specify any desired number of lines in this way:

 tail -100 /var/log/messages 

Samba also logs error messages, warnings, and general diagnostic output in three additional locations:

 /var/log/samba/smbd.log /var/log/samba/xxx.xxx.xxx.xxx.log 

xxx.xxx.xxx.xxx should be replaced by the IP address of the workstation involved. Oddly enough, you may also see a log file with the hostname rather than the IP address of the workstation, so look for both. You can learn quite a bit by using the tail command on these files as well.

Did you Google? When all else fails, try searching Google for the error message you received. And this might seem ridiculously obvious, but we've done it ourselves : when pasting error messages into the Google search window, do not include any portions that are clearly unique to your network and circumstancesspecifically, your IP addresses, the current date and time, and the names of any workstations and servers involved will clearly not appear in any Samba discussion forums and FAQs on the Web. Searches that include such search terms will fail.

Using NT 4 Old-School Tools to Manage Samba Users and Computers

Remember, Samba is now set up to pretend to be an NT 4 Domain Controller. And, since monkey see, monkey do, you're in luck. That is, you can utilize the old-school Windows NT User Manager for Domains and Server Manager for Domains (seen in Figure 2.20) to manage your Users and Computers, respectively, in Samba (but only when it's a PDC). And thanks to our careful work in smb.conf, this works identically with your tdbsam -based Samba PDC and your LDAP-based Samba PDC.

Figure 2.20: The User Manager in Windows NT 4

Doing this is easy, but you have to get the toolsand you have to get the right version of the tools. Here's the deal: don't download them from Microsoft. Why? Because these updated tools, when run against Samba servers, don't work. Why not? I have no idea.

Instead, the correct course of action is to find an old NT 4 Server CD-ROM and rip out the tools by hand. The files will be in the i386 directory in compressed format. All you need to do is use the expand command on two files: usrmgr.ex_ and svrmgr. For example, you'll type:

 expand usrmgr.ex_ c:\usrmgr.exe expand srvmgr.exe c:\srvmgr.exe 

When you do, you'll have two uncompressed and ready-to-run files in your c:\ directory. Once you run them on your Windows machine, you'll be able to manage your Samba domain just like in the NT 4 days! We got files work that were a usrmgr.exe of size 299,280 (date 7/26/1996) and a svrmgr.exe 211,216 (date 7/26/1996).

Tip 

One weird byproduct about these tools is that after you, say, delete a user using svrmgr.exe , you might not immediately see the update without pressing F5 for a refresh. When you do, you should see your change reflected.

Joining a Windows Workstation to the Domain

You're just one step away from successfully authenticating a Windows user via your Samba PDC! First, you'll need to join a Windows workstation to the domain.

On a Windows XP machine, you'll do this by right-clicking "My Computer" and selecting "Properties." Then, on the "Computer Name" tab, click the "Change" button. Select the "Domain" radio button and enter the name of the Samba domain CORP .

When prompted, enter administrative credentials: administrator for the username and p@ssw0rd for the password. When you do, you'll be rewarded as shown in Figure 2.21.

Figure 2.21: Here you can join the Samba CORP domain.

Logging into a Windows Workstation via Samba PDC Authentication

Now you're ready to log in! Just log out of your XP workstation and log back in with the username doctor1 and the password p@ssw0rd . After a few moments, a desktop for doctor1 should appear in the usual fashion. Congratulations! In the next chapter, we'll extend the usefulness of authenticating in this manner by adding shared home directories that allow users to access the same files regardless of which workstation they have chosen to work with.

Checkout: To Create a Linux PDC

Here's a review of what you accomplished:

• You made a choice about how to create your Linux PDC: to either use the tdbsam "trivial database" back end to store user accounts, or to leverage OpenLDAP.

• On our website ( www.WinLinAnswers.com ), we have steps which allow you to use tdbsam to hold your accounts. If you chose this route for your Samba PDC, you:

  • Configured Webmin's Samba module to correctly edit user and group information in a way that is compatible with tdbsam

  • Configured the Samba server to operate as a PDC and use the tdbsam database as a back end in which to store account information

  • Installed change-group-membership.pl , a Perl script that can correctly change group membership settings for users in response to requests from the NT administration tools on Windows clients

  • Using Webmin, upgraded existing Linux accounts to support Samba authentication and set up automatic synchronization so that future accounts will automatically be Samba-enabled

• If you leveraged the existing OpenLDAP server configuration by following our steps in this book, you:

  • Expanded the database schema to support Windows account information needed by Samba

  • Configured Samba to build efficient indexes for Windows SIDs (security identifiers)

  • Installed and configured the smbldap-tools , which provide the necessary "glue" to allow Samba to carry out domain administration tasks when a Windows domain administrator remotely requests it (such as doing the dirty work when a new workstation joins the domain)

  • Populated the LDAP database with standard Windows networking objects, such as the Administrator account

  • Configured the Samba server to operate as a PDC and use the LDAP database as a back end in which to store account information

  • Configured the Samba server to use the smbldap-tools for administration tasks

  • Using Webmin, upgraded your LDAP user accounts to support Samba authentication

• In both scenarios, you:

  • Joined your own Linux PDC to its own corp domain

  • Joined a Windows workstation to the corp domain

  • Successfully logged into the corp domain from the Windows workstation