LDAP-Based Authentication for Samba Install and Configure Samba As a Primary Domain Controller with LDAP on Linux

LDAP-based authentication for Samba Install and configure Samba as a primary domain controller with LDAP on Linux

Skill Level: Intermediate

Keith Robertson ([email protected]) Advisory software engineer IBM

31 Jan 2006

This tutorial shows you how to install and configure Samba as a primary domain controller with a secure LDAP-based authentication mechanism. The completed system boasts a secure file- and print-sharing setup, in addition to a robust LDAP server that could be used for purposes beyond those required by Samba. Additionally, Windows® clients can log on to your Samba server and have shared drives automatically mounted for them based on their group membership.

Section 1. Before you start

About this tutorial

This tutorial shows you how to install and configure Samba as a primary domain controller with a secure LDAP-based authentication mechanism. You get an overview of how LDAP integrates with Samba, and then you learn:

• How to install and configure LDAP (installing OpenLDAP and the IDEALX LDAP Samba toolkit; configuring OpenLDAP necessities, the slapd.conf file, the /etc/ldap.conf file, and the Pluggable Authentication Modules (PAM); and starting OpenLDAP) • How to install and configure Samba (installing and starting Samba and the Logon Profile Generator; creating the required directories and the shared drives; configuring the smb.conf file and setting the LDAP database-access password; populating the database; adding the PAM

and other users; adding Microsoft® Windows® workstations; and debugging the Samba installation if needed) • How to enable and test security for the system (the Transport Layer Security for OpenLDAP, PAM, and Samba) The completed system boasts a secure file- and print-sharing setup, in addition to a robust LDAP server that could be used for purposes beyond those required by Samba. Additionally, Windows clients are able to log on to your Samba server, which acts as a primary domain controller, and have shared drives automatically mounted for them based on their group membership.

Prerequisites

To get the most out of this tutorial, you should have moderate UNIX® or Linux® familiarity, as well as experience with basic IP networking concepts.

The Linux distribution is Fedora Core 3, but the setup described here works on other Linux distributions or UNIX variants such as AIX, Solaris, or HP-UX. All applications and utilities used in this tutorial are open source and are available from either your Linux vendor or the application vendor's home page. I recommend that you get a precompiled version (such as an RPM) from your Linux vendor's ftp mirror.

This tutorial uses the following software and explains how to download and install each as you go along. In other words, you do not need to install these components in advance:

• OpenSSL • OpenLDAP • Samba • Perl module Crypt::SmbHash • Perl module Digest::SHA1 • Perl module IO::Socket::SSL • Perl module Net::SSLeay • IDEALX Samba LDAP tools Specific versions of the various software components are indicated. You might have success with earlier versions of the software, but I cannot guarantee that they will work. In general, software that is newer than the versions described in this tutorial should work.

Tutorial network layout

The network described in this tutorial is intended to be small so that you can easily

duplicate the examples on a home or lab network. For this setup, I used a typical home broadband router with a built-in firewall. Figure 1 shows the physical network layout.

Figure 1. Tutorial network configuration

This Microsoft Windows network contains three classes of users: marketing, engineering, and management. Marketing and engineering each have a shared drive where users from each group may place files for others in that same group to see; however, members from one group cannot see files on the other group's shared drive. For example, a marketing employee may not view a file on the engineering drive. Management also has a shared drive that is visible only to managers. In addition, managers have special privileges so that they can see files from both marketing and engineering.

Section 2. Introducing LDAP

LDAP is a popular mechanism for authentication and for storage of personally identifiable information. It has several advantages over traditional flat-file-based authentication mechanisms like /etc/passwd. One of these advantages is that LDAP can be used to produce the Holy Grail of password management: a single sign-on. Single sign-on is available because software applications can authenticate remotely against a common LDAP-based user repository across a TCP/IP network. The LDAP method of authentication is in direct contrast to flat-file-based authentication schemes that are typically tied to a single machine and do not distribute well.

LDAP manages data in a directory information tree. This tree helps to organize data through categorization. Many LDAP servers use SQL databases to store their information because they are a natural fit. As with a traditional SQL database, LDAP uses schemas to define where data should be located and how data should be formatted. The use of schemas and the similarities with traditional SQL databases are key advantages of LDAP because they contribute greatly to its extensibility.

Integrating Samba with LDAP

There are three main integration points between Samba and an LDAP server:

• The first is the inclusion of Samba's schema into the LDAP server. • The second is configuring Samba to authenticate through the LDAP server. Authentication takes place with the help of Linux's PAM utility (Pluggable Authentication Modules). The PAM utility abstracts the process of authentication away from software applications running on Linux so that they do not have to understand the complexities of a particular authentication mechanism. As such, PAM gives software applications an enormous degree of flexibility because a software application can call one API for authentication and PAM decides if it should use flat file, LDAP, or some other mechanism for authentication.

• The third integration point involves a set of tools that aid in the management of Samba's LDAP directory information tree. This toolkit is produced by a third-party; however, it is covered under the GNU Public License.

Security

A key strength of LDAP is its use as an authentication mechanism for software applications that could be scattered across a network. A side effect of this strength is that passwords may flow across the network during the authentication phase and, as a result, could be intercepted. Fortunately, LDAP supports both SSL (Secure Sockets Layer) and TLS.

In this tutorial, the LDAP server is running on the same physical server as Samba; thus, there isn't much need for encryption. However, I demonstrate how to encrypt the channel between LDAP and Samba because it is relatively simple and necessary if you host Samba and LDAP on different machines.

This tutorial unfolds in two phases. The first phase details how to configure Samba and LDAP in an unsecured mode. Once the first phase is complete, encryption is enabled to secure the channel between Samba and the LDAP server. This two-phase approach makes it easier to install, configure, and diagnose problems in an unsecured mode.

Section 3. Configuring LDAP

Step 1. Installing OpenLDAP

To install OpenLDAP:

1. Check to see if your distribution has OpenLDAP installed. Issue the following command at a terminal: rpm -qa | grep ldap. If you do not get a response of openldap-2.2.13 or greater, then you should either upgrade or install anew (which is described next).

2. If you don't have OpenLDAP version 2.2.13 or greater, go to your distribution's mirror and download a binary package. In my case, I went to Fedora's mirror list and downloaded openldap-2.2.13-2.i386.rpm. Then I issued the following command: rpm -Uvh openldap-2.2.13-2.i386.rpm.

Step 2. Installing IDEALX's LDAP Toolkit for Samba

A toolkit from IDEALX is required to automate many of the important interactions between Samba and your LDAP server. Included in the toolkit from IDEALX are scripts that Samba automatically calls to add users, modify users, add machines, etc. The scripts are written in Perl and can also be used from the command line.

To install the IDEALX toolkit:

1. Go to IDEALX's home page and download version .0.9.1 or later of the toolkit (smbldap-tools-.0.9.1.tgz).

2. In a temporary directory, unpack the toolkit with this command: tar -zxf smbldap-tools-0.9.1.tgz.

3. Create a directory for the IDEALX scripts to live in. At the command prompt type: mkdir -p /var/lib/samba/sbin. Then type: chmod -R 755 /var/lib/samba.

4. Change into the directory created by the tar command. Type: cd smbldap-tools-0.9.1.

5. Copy the required scripts from the temporary directory to the permanent directory with this command: cp smbldap* configure.pl /var/lib/samba/sbin.

6. Set the correct ownership and permissions by changing into the /var/lib/samba/sbin directory and issuing these commands in order:

1. chmod 750 *

2. chmod 640 smbldap_bind.conf smbldap.conf smbldap_tools.pm

7. You can now safely remove the temporary directory.

The IDEALX toolkit requires some additional Perl modules that may not be installed on your system. This section shows you how to download and install them.

1. Download all of the requisite Perl modules from CPAN.org. Go to CPAN.org and type the following search strings into the search box. • Crypt::SmbHash • Digest::SHA1 • IO::Socket::SSL • Net::SSLeay Navigate from the results of each search directly to each module's home page where you will find a link to download the associated Perl module.

2. Un-tar and un-zip the downloaded Perl modules. Issue the following command in the directory where you saved the four downloaded modules: tar -zxvf *.gz.

3. Build and install each of the four modules. Change into each of the newly created directories and issue these commands as root.

1. perl Makefile.PL

2. make install

Step 3. Configure the schemas, directories, and keys needed by OpenLDAP

If you installed from an RPM, and your Linux distribution is Fedora, then you should have a directory called /etc/openldap. In this directory is OpenLDAP's primary configuration file, slapd.conf. Before you begin editing this file, you need to do some preliminary setup. OpenLDAP needs to be made aware of Samba's LDAP schema. To do this, you copy Samba's schema into /etc/openldap/schema:

1. Find Samba's schema. It should be located in the directory that Samba was installed in. To find it type: locate samba.schema.

2. Copy it into /etc/openldap/schema.

3. Set the correct permissions. Type: chmod 644 /etc/openldap/schema/samba.schema.

Create the directory for your LDAP database. In this tutorial, we give this directory the same name as our domain name.

1. Type: mkdir -p /var/lib/ldap/somedomain.com.

2. Set the correct permissions: chmod 700 /var/lib/ldap/somedomain.com.

3. Set the correct ownership. Fedora users should already have the user LDAP defined in /etc/passwd. If you are installing on a different distribution, you may need to create that user. Type: chown ldap:ldap /var/lib/ldap/somedomain.com.

Finally, create the encryption keys that OpenLDAP uses for TLS. To do this, you need OpenSSL. The vast majority of Linux distributions ship with OpenSSL; however, if you do not have it installed, get a copy from your vendor or Openssl.org.

This tutorial assumes that the user will not be using a commercial certificate authority (CA) such as Verisign, Thawte, etc. As such, you will need to become your own CA and sign the certificates used by your LDAP server. The steps below show how to become a CA and sign certificates.

1. If you haven't already done so, edit openssl.cnf to match your particular needs. Find the openssl.cnf file and type: locate openssl.cnf.

2. In the same directory as openssl.cnf, issue these commands as root. Listing 1. Becoming CA mkdir -p CA/certs CA/crl CA/newcerts CA/private chmod 700 CA/private touch CA/index.txt echo 01 > CA/serial

3. Open openssl.cnf in your favorite editor and change the following parameters to match your particular situation. Listing 2. Becoming CA, continued # The dir parameter is important because it tells # openssl where to find all necessary files used to # generate keys. dir = ./ # default_days defines the length of time your key is valid for. default_days = 3650 # default_bits is an indicator of the strength of your key. I elected # 1024 but you can choose more or less. default_bits = 1024 # The following parameters should be modified to fit your # organization. countryName_default = US stateOrProvinceName_default = North Carolina localityName_default = Raleigh 0.organizationName_default = somedomain.com

4. Create your CA certificate and key pair with the following command: openssl req -nodes -config openssl.cnf -new -x509 -keyout CA/private/cakey.pem -out CA/cacert.pem -days 3650.

5. Create the key pair for OpenLDAP with these commands:

1. openssl req -config openssl.cnf -nodes -new -keyout /etc/openldap/slapd-key.pem -out slapd.csr

2. openssl ca -config openssl.cnf -out /etc/openldap/slapd-cert.pem -in slapd.csr

3. chown root:ldap /etc/openldap/slapd-key.pem

4. chmod 640 /etc/openldap/slapd-key.pem

5. chmod 644 /etc/openldap/slapd-cert.pem

6. Copy your CA's certificate to the openldap configuration directory so that various applications can access it.

1. cp CA/cacert.pem /etc/openldap/

2. chmod 644 /etc/openldap/cacert.pem

Step 4. Configure slapd.conf

The executable supplied by OpenLDAP that corresponds to an actual LDAP server is called slapd. The slapd daemon reads all of its configuration information from slapd.conf. This section includes a sample slapd.conf that is annotated with comments. You must change all sections a denoted by a "# MODIFY" comment to fit your particular situation.

Before you begin editing, generate a password hash for the rootdn. Choose a password that is different from your Linux server's root password. You must use this password to make changes to your LDAP server's directory information tree.

1. From the command line type: slappasswd -h {SSHA} -s .

2. Save the output from this command, as you will need it next. It could look like: {SSHA}kCuJt72QLJ2O06nFUvdre97sHT0AxlH/.

If you installed a binary version of OpenLDAP on Fedora, slapd.conf should exist as /etc/openldap/slapd.conf. Modify it to suit your particular situation.

The contents of /etc/openldap/slapd.conf looks like this:

Listing 3. Contents of slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/samba.schema # -1 is all messages 296 is a good compromise for most debugging #loglevel -1 pidfile /var/run/slapd.pid argsfile /var/run/slapd.args # The following three lines are related to security. Leave them commented out now. # We uncomment them and enable security *after* we have successfully tested Samba with # LDAP in an unsecured configuration. Debugging is infinitely easier without encryption # enabled. #TLSCipherSuite HIGH #TLSCertificateFile /etc/openldap/slapd-cert.pem #TLSCertificateKeyFile /etc/openldap/slapd-key.pem database bdb # MODIFY # Modify suffix and rootdn to match your domain name. suffix "dc=somedomain,dc=com" rootdn "cn=Manager,dc=somedomain,dc=com" # MODIFY # Use the following to generate: # slappasswd -h {SSHA} -s rootpw {SSHA}kCuJt72QLJ2O06nFUvdre97sHT0AxlH/ # MODIFY # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended with an owner of ldap and a group of ldap directory /var/lib/ldap/somedomain.com # Indices to maintain for this database index objectClass eq index cn pres,sub,eq index sn pres,sub,eq index uid pres,sub,eq index displayName pres,sub,eq index uidNumber eq index gidNumber eq index memberUID eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index default sub # Access Control Entries # Note these ACEs are duplicated from the IDEALX smbldap usermanual with one exception # users can authenticate and change their password access to attrs=userPassword, sambaNTPassword,sambaLMPassword,sambaPwdLastSet,sambaPwdMustChange by dn="uid=samba,ou=Users,dc=somedomain,dc=com" write by self write by anonymous auth by * none # some attributes need to be readable anonymously so that 'id user' can answer correctly access to attrs=objectClass,entry,gecos,homeDirectory,uid,uidNumber,gidNumber,cn, memberUid by dn="uid=samba,ou=Users,dc=somedomain,dc=com" write by * read # somme attributes can be writable by users themselves access to attrs=description,telephoneNumber by dn="uid=samba,ou=Users,dc=somedomain,dc=com" write

by self write by * read # some attributes need to be writable for samba (this ACE modified from original to allow some unix commands to work) access to attrs=cn,sambaLMPassword,sambaNTPassword, sambaPwdLastSet,sambaLogonTime,sambaLogoffTime,sambaKickoffTime,sambaPwdCanChange, sambaPwdMustChange,sambaAcctFlags,displayName,sambaHomePath,sambaHomeDrive, sambaLogonScript,sambaProfilePath,description,sambaUserWorkstations,sambaPrimaryGroupSID, sambaDomainName,sambaSID,sambaGroupType,sambaNextRid,sambaNextGroupRid,sambaNextUserRid, sambaAlgorithmicRidBase,sambaLogonScript,loginShell by dn="uid=samba,ou=Users,dc=somedomain,dc=com" write by self read by * none # samba need to be able to create the samba domain account access to dn.base="dc=somedomain,dc=com" by dn="uid=samba,ou=Users,dc=somedomain,dc=com" write by * none # samba need to be able to create new users account access to dn="ou=Users,dc=somedomain,dc=com" by dn="uid=samba,ou=Users,dc=somedomain,dc=com" write by * none # samba need to be able to create new groups account access to dn="ou=Groups,dc=somedomain,dc=com" by dn="uid=samba,ou=Users,dc=somedomain,dc=com" write by * none # samba need to be able to create new computers account access to dn="ou=Computers,dc=somedomain,dc=com" by dn="uid=samba,ou=Users,dc=somedomain,dc=com" write by * none # this can be omitted but we leave it: there could be other branch # in the directory access to * by self read by * none

Step 5. Configure /etc/ldap.conf

The /etc/ldap.conf file is used by LDAP clients on the local system. These clients include PAM, the interface through which Samba authenticates with the LDAP server.

Sometimes there are multiple instances of ldap.conf on your system. Locate the one that PAM has been configured to use. To do this, type: strings /lib/libnss_ldap.so.2 | grep conf. Usually, the returned value is /etc/ldap.conf.

Edit ldap.conf in your favorite editor and insert the following text. Modify the sections denoted with a "# MODIFY" comment.

The contents of /etc/ldap.conf look like this:

Listing 4. Contents of /etc/ldap.conf ## IMPORTANT ## The /etc/ldap.conf file is used by PAM. There is another ldap.conf file in ## /etc/openldap. ## The file, /etc/openldap/ldap.conf, is used by ldap tools, such as ldapsearch. ## If you intend to use those tools you will need to add a TLS_CACERT directive to that ## file also. # Your LDAP server. Must be resolvable without using LDAP. # Multiple hosts may be specified, each separated by a # space. host 127.0.0.1 # MODIFY # The distinguished name of the search base.

base dc=somedomain,dc=com # MODIFY # The distinguished name to bind to the server with. # We will use the root dn until we can create a lesser privileged user. binddn cn=Manager,dc=somedomain,dc=com bindpw < use the password you created for Manager in "Step 4. Configure slapd.conf"> # MODIFY # Note: "ou=Users" and "ou=Groups" should match what # you entered in smb.conf for "ldap group suffix" # and "ldap user suffix" nss_base_passwd ou=Users,dc=somedomain,dc=com?one nss_base_passwd ou=Computers,dc=somedomain,dc=com?one nss_base_shadow ou=Users,dc=somedomain,dc=com?one nss_base_group ou=Groups,dc=somedomain,dc=com?one ssl no pam_password md5 # We need to tell PAM where the certificate used to authenticate the LDAP # server (i.e. is the LDAP server the one we think it is). tls_cacertfile /etc/openldap/cacert.pem # If you experience difficulty authenticating after enabling TLS, try uncommenting # the next line. You will know that you are having problems if you # issue "getent group" and do not see any of the MS Windows groups # that have been created in your LDAP database. # tls_checkpeer no

Step 6. Configure PAM

Configuring PAM can be tricky. I prefer to use the utility provided by my Linux vendor to do all of the dirty work for me. Fedora provides a command-line utility called authconfig that knows how to modify all of PAM's configuration files. Other Linux vendors have similar configuration utilities, so consult the documentation if you're not using Fedora.

1. Launch authconfig from the command line. Type: authconfig.

2. Edit the first screen as shown in Figure 2. Figure 2. authconfig screen 1

3. Edit the second screen as shown in Figure 3. Figure 3. authconfig screen 2

Step 7. Start OpenLDAP

Now it is time to start your LDAP server. Fedora users who installed from a binary RPM should be able to execute this command: /etc/init.d/ldap start.

Section 4. Configuring Samba

Now let's turn our attention to Samba -- installation, creating directories, and configuration.

Step 1. Installing Samba

To install Samba:

1. Check to see if your distribution already has Samba installed. Issue this command at a terminal: rpm -qa | grep samba. If you do not get a response of samba-3.0.14 or greater, then you should either upgrade or install anew (which is described next).

2. If you do not have Samba version 3.0.14 or greater, go to Samba's home page and download a binary package for your particular Linux distribution. The Samba suite is divided into four separate RPMs, all of which are extremely useful, and I recommend you install them all. However, if you are a minimalist, you should install the samba and samba-common packages only. Download the samba RPMs that you want and install them with this command: rpm -Uvh samba*.

Step 2. Create the requisite directories

You need to create some directories that Samba uses for runtime data.

1. mkdir -p /var/lib/samba/netlogon/scripts/ /var/lib/samba/printing/

2. chmod -R 755 /var/lib/samba/netlogon /var/lib/samba/printing

Step 3. Configure smb.conf

If you installed a binary version of Samba on Fedora, you should have a configuration directory called /etc/samba. This directory contains various files that are used by Samba's two daemons (smbd and nmbd). Samba's primary configuration file, smb.conf, is located in this directory. We change this file to reflect our Microsoft Windows network and we add hooks to make Samba aware of the LDAP backend. The file is shown below with comments.

Change all sections a denoted by a "# MODIFY" comment to fit your particular situation. Also, all of the directives in this configuration file are described in the Samba manual. You can view it by typing man smb.conf.

The contents of /etc/samba/smb.conf look like this:

Listing 5. Contents of /etc/samba/smb.conf # Global parameters [# Global parameters [global] # MODIFY workgroup = BIGTIME # MODIFY netbios name = linus # MODIFY server string = Linus Samba Server passdb backend = ldapsam:ldap://127.0.0.1/ # By default run with minimal logging. However, if you need to debug # 5 is a fairly verbose logging level. #log level = 5 log file = /var/log/samba/log.%m max log size = 50 time server = Yes add user script = /var/lib/samba/sbin/smbldap-useradd -a '%u' delete user script = /var/lib/samba/sbin/smbldap-userdel '%u' add group script = /var/lib/samba/sbin/smbldap-groupadd -p '%g' delete group script = /var/lib/samba/sbin/smbldap-groupdel '%g' add user to group script = /var/lib/samba/sbin/smbldap-groupmod -m '%u''%g' delete user from group script = /var/lib/samba/sbin/smbldap-groupmod -x '%u' '%g' set primary group script = /var/lib/samba/sbin/smbldap-usermod -g '%g' '%u' add machine script = /var/lib/samba/sbin/smbldap-useradd -w '%u' # Personally, I do not like roaming profiles because they take up too # much space on my server. As such, I disable roaming profiles by # setting the following two variables to null logon path = logon home = logon drive = H: domain logons = Yes preferred master = Yes domain master = Yes wins support = Yes # MODIFY ldap admin dn = cn=Manager,dc=somedomain,dc=com ldap group suffix = ou=Groups ldap idmap suffix = ou=Idmap ldap machine suffix = ou=Computers

ldap passwd sync = Yes # MODIFY ldap suffix = dc=somedomain,dc=com ldap user suffix = ou=Users idmap backend = ldap:ldap://127.0.0.1 idmap uid = 10000-20000 idmap gid = 10000-20000

# The next three blocks define the shared drives that we will be exposing. They are all # nearly identical. The important thing to note is that all files on these drives are # readable and writeable by any user in that group. [netlogon] path = /var/lib/samba/netlogon/scripts browseable = No root preexec = /var/lib/samba/netlogon/scripts/logon.pl %U %I # MODIFY [marketing] comment = Marketing material path = /home/marketing # Any files written to this drive will have this user group. Since this is a # *shared* drive all users should have permission to read/write/remove any file. # If you do not agree you will probably want to remove the "force group" line force group = marketing read only = No create mask = 0770 directory mask = 0770 browseable = No # MODIFY [engineering] comment = Common material path = /home/engineering path = /home/marketing # Any files written to this drive will have this user group. Since this is a # *shared* drive all users should have permission to read/write/remove any file. # If you do not agree you will probably want to remove the "force group" line force group = engineering read only = No create mask = 0770 directory mask = 0770 browseable = No # MODIFY [management] comment = Management Data path = /home/management path = /home/marketing # Any files written to this drive will have this user group. Since this is a # *shared* drive all users should have permission to read/write/remove any file. # If you do not agree you will probably want to remove the "force group" line force group = management read only = No create mask = 0770 directory mask = 0770

Step 4. Set Samba's password for accessing the LDAP database

Samba needs to know the rootdn's password so that is can both read and write to its schema within the LDAP server. Execute the following command to give Samba this password. You should use the same password as in Step 4. Configure slapd.conf: smbpasswd -w .

Samba should respond as follows: Setting stored password for "cn=Manager,dc=somedomain,dc=com" in secrets.tdb.

Step 5. Install the Logon Profile Generator

Your Samba server is configured to be a Microsoft Windows domain controller and as such, it can control what actions a Windows client takes when it logs on to your domain. These actions can include things like retrieving a stored roaming profile, mounting drives, and synchronizing with a time server.

Your Samba server does not store roaming profiles because these can take up quite a bit of space; however, each Microsoft Windows client that logs in to your domain is forced to mount drives and synchronize with a time server.

In this step you create a Perl script that generates a Windows batch file that is executed each time a user logs in to the BIGTIME domain. The batch file causes the user's Windows machine to automatically mount the drives that his security profile grants him access to. This action is useful for large organizations with many common drives and a diverse security policy. The location and execution of this batch script are defined by two parameters in the netlogon section of smb.conf: path and root preexec.

Do these steps to install the Perl logon script:

1. cd /var/lib/samba/netlogon/scripts

2. Create a file called logon.pl and fill it with the contents shown in Listing 6.

3. chmod 755 /var/lib/samba/netlogon/logon.pl

The contents of the Perl logon script, /var/lib/samba/netlogon/logon.pl, looks like:

Listing 6. Contents of Perl logon script #!/usr/bin/perl use strict; # Set the permissions on any file we create to 640 (i.e. -rw-r--r--) umask(022); my $NETLOGON_DIR = "/var/lib/samba/netlogon/scripts"; my $LOG_DIR = "/var/log/samba"; my $SERVERNAME = "linus"; ## You will need to modify this hash to match your mountpoints. my %MOUNTPOINTS = ( "engineering" => "NET USE W: \\\\$SERVERNAME\\engineering \/YES\r\n", "marketing" => "NET USE W: \\\\$SERVERNAME\\marketing \/YES\r\n", "management" => "NET USE W: \\\\$SERVERNAME\\management \/YES\r\n" ); ## Make sure that there is a user name and that it contains a valid ## user name string (i.e. no invalid chars). if ($#ARGV != 1 || $ARGV[0] =~ /[^a-zA-Z0-9-_]/) { exit(1); } # Make sure that the user exists and log attempts with invalid IDs my $uid = getpwnam($ARGV[0]); if ($uid == /[^0-9]/){ my $now = localtime;

open LOG, ">>$LOG_DIR/log.netlogon"; print LOG "$now"; print LOG " - Error: Unknown user $ARGV[0] logged into $SERVERNAME from $ARGV[1]\n"; close LOG; exit(1); } # Log the logon attempt my $now = localtime; open LOG, ">>$LOG_DIR/log.netlogon"; print LOG "$now"; print LOG " - User $ARGV[0] logged into $SERVERNAME from $ARGV[1]\n"; close LOG;

## Create a custom logon batch file. open FH, ">$NETLOGON_DIR/$ARGV[0].cmd"; # Turn echo off print FH "\@ECHO OFF\r\n"; # Synchronize time between Windows client and Linux server. print FH "NET TIME \\\\$SERVERNAME \/SET \/YES\r\n"; foreach my $key (keys(%MOUNTPOINTS)) { if (isMember($ARGV[0], $key)) { # Put mount points in file print FH "$MOUNTPOINTS{$key}"; } } close FH;

# Checks to see if the given user is a member of # the given group. # Returns 1 if true and 0 otherwise. sub isMember{ my ($user, $group) = @_; my ($name, $passwd, $gid, $members) = getgrnam($group); my @members = split /\s+/, $members; for(@members){ if ($user eq $_) { return 1; } } return 0; }

Step 6. Start Samba

Now it is time to start your Samba server. Fedora users who installed from a binary RPM should be able to execute the following command: /etc/init.d/samba start.

Step 7. Populate the LDAP database

Now it is time to populate the LDAP database with your Samba schema and some initial values. For this task, use the handy IDEALX scripts. Begin by executing a configuration script, /var/lib/samba/sbin/configure.pl. The configuration script creates two files, smbldap_bind.conf and smbldap.conf, which contain important environment variables used by all of the scripts in the IDEALX toolkit.

1. Type: cd /var/lib/samba/sbin/.

2. Edit smbldap_tools.pm and make the following changes to the variables smbldap_conf and smbldap_bind_conf. • my $smbldap_conf="/var/lib/samba/sbin/smbldap.conf"; • my $smbldap_bind_conf="/var/lib/samba/sbin/smbldap_bind.conf";

3. Launch the configuration utility by typing: ./configure.pl

4. You will now be prompted with a series of questions; sample output is shown in Listing 7. In general, you should be able to simply press the return key to the queries; however, here are some important things to know. • The password hash is case sensitive and should match the hash algorithm you specified in ldap.conf's pam_password variable (see Step 5. Configure /etc/ldap.conf). • In this tutorial, there is no LDAP slave server, so use the same information as the master server. • The bind password requested by this script is the same password you used for the rootdn in Step 4. Configure slapd.conf.

The output from the configure.pl script looks like:

Listing 7. Output from the Perl configure script [root@linus sbin]# ./configure.pl If you need to change this, enter the full directory path, then press enter to continue. Smbldap-tools Configuration Directory Path [/etc/opt/IDEALX/smbldap-tools/] > /var/lib/samba/sbin -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Let's start configuring the smbldap-tools scripts ... . workgroup name: name of the domain Samba act as a PDC workgroup name [BIGTIME] > . netbios name: netbios name of the samba controler netbios name [linus] > . logon drive: local path to which the home directory will be connected (for NT Workstations). Ex: 'H:' logon drive [H:] > . logon home: home directory location (for Win95/98 or NT Workstation). (use %U as username) Ex:'\\linus\%U' logon home (press the "." character if you don't want homeDirectory) [\\linus\%U] > . . logon path: directory where roaming profiles are stored. Ex:'\\linus\profiles\%U' logon path (press the "." character if you don't want roaming profile) [\\linus\profiles\%U] > . . home directory prefix (use %U as username) [/home/%U] > . default users' homeDirectory mode [700] > . default user netlogon script (use %U as username) [%U.cmd] > "" default password validation time (time in days) [45] > . ldap suffix [dc=somedomain,dc=com] > . ldap group suffix [ou=Groups] > . ldap user suffix [ou=Users] > . ldap machine suffix [ou=Computers] > . Idmap suffix [ou=Idmap] > . sambaUnixIdPooldn: object where you want to store the next uidNumber and gidNumber available for new users and groups sambaUnixIdPooldn object (relative to ${suffix}) [sambaDomainName=BIGTIME] >

. ldap master server: IP adress or DNS name of the master (writable) ldap server ldap master server [127.0.0.1] > . ldap master port [389] > . ldap master bind dn [cn=Manager,dc=somedomain,dc=com] > . ldap master bind password [] > . ldap slave server: IP adress or DNS name of the slave ldap server: can also be the master one ldap slave server [127.0.0.1] > . ldap slave port [389] > . ldap slave bind dn [cn=Manager,dc=somedomain,dc=com] > . ldap slave bind password [] > . ldap tls support (1/0) [0] > 1 . How to verify the server's certificate (none, optional or require) [require] > . CA certificate file [/var/lib/samba/sbin//ca.pem] > /etc/openldap/cacerts/cacert.pem . certificate to use to connect to the ldap server [/var/lib/samba/sbin//smbldap-tools.pem] > . key certificate to use to connect to the ldap server [/var/lib/samba/sbin//smbldap-tools.key] > . SID for domain BIGTIME: SID of the domain (can be obtained with 'net getlocalsid linus') SID for domain BIGTIME [S-1-5-21-1030832020-2822878261-2997333186] > . unix password encryption: encryption used for unix passwords unix password encryption (CRYPT, MD5, SMD5, SSHA, SHA) [SSHA] > MD5 . default user gidNumber [513] > . default computer gidNumber [515] > . default login shell [/bin/bash] > . default skeleton directory [/etc/skel] > . default domain name to append to mail adress [] > somedomain.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= backup old configuration files: /var/lib/samba/sbin/smbldap.conf->/var/lib/samba/sbin/smbldap.conf.old /var/lib/samba/sbin/smbldap_bind.conf->/var/lib/samba/sbin/smbldap_bind.conf.old writing new configuration file: /var/lib/samba/sbin/smbldap.conf done. /var/lib/samba/sbin/smbldap_bind.conf done.

5. If you do not want password expiration enabled, you can disable it. To disable it, edit smbldap.conf and comment out the following line: defaultMaxPasswordAge="45".

6. Execute these three commands to set the proper permissions and ownership:

1. chown root:root smbldap.conf smbldap_bind.conf

2. chmod 644 smbldap.conf

3. chmod 600 smbldap_bind.conf

7. Initialize your Samba schema in the LDAP database. You will execute the IDEALX script, smbldap-populate, which will create a domain administrator, some necessary groups, and various other important schema elements. When you execute this script, you may notice warnings about uninitialized variables. If you do not want to see these warnings, you can edit all of the IDEALX scripts and replace all instances of "#!/usr/bin/perl -w" with "#!/usr/bin/perl". Sample output from smbldap-populate is shown in Listing 8. (Note: smbldap-populate may prompt you for a password for the domain administrator, which, by default, is named root. You should give this user a password that is different from the one used for the rootdn in Step 4. Configure slapd.conf and that is different from your Linux machine's root user.

Listing 8. Executing the IDEALX script, smbldap-populate [root@linus sbin]# ./smbldap-populate Populating LDAP directory for domain BIGTIME (S-1-5-21-1030832020-2822878261-2997333186) (using builtin directory structure) LDAP config host: 127.0.0.1 port: 389 version: 3 timeout: 60 adding new entry: dc=somedomain,dc=com adding new entry: ou=Users,dc=somedomain,dc=com adding new entry: ou=Groups,dc=somedomain,dc=com adding new entry: ou=Computers,dc=somedomain,dc=com adding new entry: uid=root,ou=Users,dc=somedomain,dc=com adding new entry: uid=nobody,ou=Users,dc=somedomain,dc=com adding new entry: cn=Domain Admins,ou=Groups,dc=somedomain,dc=com adding new entry: cn=Domain Users,ou=Groups,dc=somedomain,dc=com adding new entry: cn=Domain Guests,ou=Groups,dc=somedomain,dc=com adding new entry: cn=Domain Computers,ou=Groups,dc=somedomain,dc=com adding new entry: cn=Administrators,ou=Groups,dc=somedomain,dc=com adding new entry: cn=Account Operators,ou=Groups,dc=somedomain,dc=com adding new entry: cn=Print Operators,ou=Groups,dc=somedomain,dc=com adding new entry: cn=Backup Operators,ou=Groups,dc=somedomain,dc=com adding new entry: cn=Replicators,ou=Groups,dc=somedomain,dc=com adding new entry: cn=NextFreeUnixId,dc=somedomain,dc=com Please provide a password for the domain root: LDAP config host: 127.0.0.1 port: 389 version: 3 timeout: 60 Changing password for root New password : Retype new password :

Step 8. Create the shared drives

To create a shared drive for each of our three user groups (engineering, marketing, and management) use the smbldap-useradd utility. This utility creates a directory in /home that serves as a shared drive. You will also create an associated UNIX user group to use later to grant ordinary users permissions to the shared drive. Execute the following commands as root:

Listing 9. Creating UNIX group for permissions to shared drive cd /var/lib/samba/sbin ./smbldap-groupadd engineering ./smbldap-groupadd marketing ./smbldap-groupadd management ./smbldap-useradd -s /sbin/nologin -m -g engineering engineering ./smbldap-useradd -s /sbin/nologin -m -g marketing marketing ./smbldap-useradd -s /sbin/nologin -m -g management management

Note: The option -s /sbin/nologin is a security measure to prevent someone from logging into your Linux box with one of the three IDs.

Step 9a. Add the PAM user

For security reasons, you should force PAM to connect to your LDAP server with a DN that is not root (like cn=Manager,dc=somedomain,dc=com). A quick scan of

the ldap.conf file created in Step 5. Configure /etc/ldap.conf shows that PAM will attempt to connect to the LDAP with a dn of cn=Manager,dc=somedomain,dc=com. You will create a lesser privledged user (uid=samba,ou=Users,dc=somedomain,dc=com) in this step.

Issue this command to create the user samba: smbldap-useradd -s /bin/false -d /dev/null -P samba. When prompted for a password, give a unique password. When finished, update the binddn with uid=samba,ou=Users,dc=somedomain,dc=com and bindpw paramater in ldap.conf with the password you just gave.

Step 9b. Add some users

The next step is to add some users and assign each a security profile. This list identifies users and their assigned group:

• Marketing group: catbert • Management group: boss • Engineering group: dilbert, wally Next, create the users on your Linux system. This requires a two-step process for each user:

1. Create the user ID on the system.

2. Set the Samba password.

By default the smbldap-useradd script will attempt to create a home directory on your Linux system for each user. Disable this with the -a option. Issue these commands as root:

Listing 10. Disabling the -a option cd /var/lib/samba/sbin ./smbldap-useradd -a -G "Domain Users",engineering dilbert ./smbldap-passwd dilbert ./smbldap-useradd -a -G "Domain Users",engineering wally ./smbldap-passwd wally ./smbldap-useradd -a -G "Domain Users",marketing catbert ./smbldap-passwd catbert ./smbldap-useradd -a -G "Domain Users",marketing,management,engineering boss ./smbldap-passwd boss

Step 10. Add Microsoft Windows workstations to your domain

For this step, visit each workstation you plan to grant access. (The following steps are for Microsoft Windows XP Professional, but they apply to other Microsoft Windows variants.)

Log on to each Windows workstation as administrator and perform the following actions:

1. Go to the Control Panel and select System.

2. Select the Computer Name tab.

3. Click the button to rename this computer or join a domain.

4. A new window should appear. In this window, click the radio button for domain and enter BIGTIME as the domain. Click OK.

5. When prompted for a user ID and password, use root as the user ID and the password you gave in Step 7. Populate the LDAP database. You are prompted to reboot the workstation.

6. After rebooting, notice that the domain BIGTIME has been added to the Log on to: selection box. Before you can log on as one of the domain members you created in Step 9a. Add the PAM user, you should decide where they fit in this workstation's local security hierarchy. In this tutorial, we will add all Domain Users in the BIGTIME domain to the Power Users local group on this workstation. Follow these steps:

1. From the logon screen, select the option for (this computer) from the Log on to: selection box.

2. Now log on as a user with administrative privileges for this workstation.

3. After logging in, select Start.

4. Select Control Panel.

5. Select Administrative Tools.

6. Select Computer Management.

7. Navigate to Local Users and Groups.

8. Click on Groups.

9. Click on Power Users.

10. Click the Add button and make sure the box From this Location contains BIGTIME.

11. Click the Advanced button.

12. Click Find Now.

13. You will be prompted for the domain administrator's id and password. Enter root and the password from Step 7. Populate the LDAP database.

14. Select Domain Users and click OK until you are returned to the Computer Management window.

7. Enter any of the users you configured (boss, wally, catbert, or dilbert) and log on to that workstation.

8. The workstation should automatically mount the drives that the user is allowed to access based on his security profile.

9. Repeat steps 1-6 on every workstation in your network.

Step 11. Quick review

You should now have a fully functioning Samba server acting as a MS Windows Primary Domain Controller if everything went smoothly. If everything did not go smoothly, you should stop and debug before we complicate matters by enabling encryption in the next section. These diagnostic tests can assist you with debugging.

• Execute testparm /etc/samba/smb.conf. This will check your Samba server's configuration file for errors. • Ensure that your Linux box can resolve the group IDs of the Windows users you created in Step 9a. Add the PAM user (wally, dilbert, etc.). Execute groups wally. If you do not see engineering and Domain Users, you should verify that your modifications to ldap.conf are spelled correctly and match exactly with those in smb.conf and slapd.conf. • Examine your LDAP database with JXplorer. JXplorer is a graphical LDAP database browser that can help you understand how Samba interacts with the database. For example, if you were successful adding computers, groups, or users, you should see them in your LDAP server's directory information tree. • Look for problems in the logs. Examine the Samba's logs in /var/log/samba and OpenLDAP's logs in /var/log/slapd.

Section 5. Enabling security

Let's conclude with security issues. In this section, you enable the Transport Layer Security for OpenLDAP, PAM, and Samba, and test the configuration.

Step 1. Enable TLS for OpenLDAP

In this step, you will instruct your LDAP server to use the security certificates you generated in Step 3. Configure the schemas, directories, and keys needed by OpenLDAP. Simply open /etc/openldap/slapd.conf and uncomment these three lines:

Listing 11. Enabling TLS for OpenLDAP TLSCipherSuite HIGH TLSCertificateFile /etc/openldap/slapd-cert.pem TLSCertificateKeyFile /etc/openldap/slapd-key.pem

Step 2. Enable TLS for PAM

Now you need to instruct PAM to communicate with the LDAP server over an encrypted connection. Fedora users can launch authconfig and let the tool do all of the dirty work. Alternatively, you can simply edit /etc/ldap.conf and add this line ssl start_tls.

Some people may have trouble getting PAM to communicate with their LDAP server after enabing TLS. If you are unable to see the Windows groups you created in your LDAP database with getent group, try adding the following line at the end of your ldap.conf file: tls_checkpeer no.

Figure 4 shows the TLS being enabled through authconfig.

Figure 4. LDAP Authentication over TLS in authconfig

Listing 12 shows ldap.conf with TLS enabled.

Listing 12. ldap.conf with TLS enabled

## IMPORTANT ## The /etc/ldap.conf file is used by PAM. There is another ldap.conf file in ## /etc/openldap. ## The file, /etc/openldap/ldap.conf, is used by ldap tools, such as ldapsearch. ## If you intend to use those tools you will need to add a TLS_CACERT directive to that ## file also. # Your LDAP server. Must be resolvable without using LDAP. # Multiple hosts may be specified, each separated by a # space. host 127.0.0.1 # MODIFY # The distinguished name of the search base. base dc=somedomain,dc=com # MODIFY # The distinguished name to bind to the server with. # We will not be using the root dn. Instead we will create # lesser privileged user. binddn uid=samba,ou=Users,dc=somedomain,dc=com bindpw # MODIFY # Note: "ou=Users" and "ou=Groups" should match what # you entered in smb.conf for "ldap group suffix" # and "ldap user suffix" nss_base_passwd ou=Users,dc=somedomain,dc=com?one nss_base_passwd ou=Computers,dc=somedomain,dc=com?one nss_base_shadow ou=Users,dc=somedomain,dc=com?one nss_base_group ou=Groups,dc=somedomain,dc=com?one ssl start_tls pam_password md5 # We need to tell PAM where the certificate used to authenticate the LDAP # server (i.e. is the LDAP server the one we think it is). tls_cacertfile /etc/openldap/cacert.pem # If you experience difficulty authenticating after enabling TLS, try uncommenting # the next line. You will know that you are having problems if you # issue "getent group" and do not see any of the MS Windows groups # that have been created in your LDAP database. tls_checkpeer no

Step 3. Enable TLS for Samba

Finally, enable Samba to communicate with the LDAP server over TLS. To accomplish this, configure the IDEALX scripts to use TLS when communicating with the LDAP server. Make these modifications to /var/lib/samba/sbin/smbldap.conf:

Listing 13. Getting Samba to talk to LDAP server via TLS # Set this variable to 1 to enable TLS ldapTLS="1" # Require that the client (i.e. samba) verify the authenticity of the LDAP server verify="require" # You should have already created this certificate during the LDAP configuration phase. cafile="/etc/openldap/slapd-cert.pem"

You may have noticed that there are other options in the smbldap.conf file for authentication, clientcert and client key. These two options are for the truly paranoid and would allow the LDAP server to authenticate the client.

Step 4. Test the configuration

Now it is time to test the secured configuration. First restart your LDAP server and your Samba server as shown in Listing 14.

Listing 14. To test, restart LDAP and Samba servers /etc/init.d/ldap restart /etc/init.d/smb restart

To test a TLS security between Samba and LDAP:

1. Execute /var/lib/samba/sbin/smbldap-usershow dilbert. This should cause the IDEALX scripts to communicate with the LDAP server over a TLS connection and return all of the information the LDAP server has about the user dilbert.

2. Try to log in to the BIGTIME domain from a Windows workstation.

Resources

Learn • Read the tutorial "Linux-powered networking, Part 3: Integrate Linux and Windows with Samba" (developerWorks, December 2004); with the sample code and configuration files, use Samba to integrate your Linux and Windows networks. • The article "Common threads: Samba domain controller support" (developerWorks, August 2000) demonstrates how to use Samba's domain controller function to control a Windows NT® domain. • The three-part article series "Common threads: Introduction to Samba" (developerWorks, June and July 2000) is an excellent guide to installing and configuring Samba. • In the developerWorks Linux zone, find more resources for Linux developers. • Stay current with developerWorks technical events and Webcasts. Get products and technologies • Samba provides print and file services for SMB/CIFS clients. • Pick up the Samba LDAP toolkit. • Access the UNIX man pages for Samba. • OpenLDAP is an open source implementation of the Lightweight Directory Access Protocol. • Order the no-charge SEK for Linux, a two-DVD set containing the latest IBM trial software for Linux from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®. • With IBM trial software, available for download directly from developerWorks, build your next development project on Linux. Discuss • Check out developerWorks blogs and get involved in the developerWorks community.

About the author

Keith Robertson Keith Robertson is an Advisory Software Engineer at IBM in Research Triangle Park, NC. He is pursuing a master's degree in computer networking at North Carolina State University in Raleigh, NC. His background includes experience with networking technologies and software-development techniques. He has a working knowledge of low-level telecom networking protocols (such as SIP and MEGACO) and IP networking management protocols (such as SNMP and ICMP). He is also skilled at

C/C++ and the Java programming language. You can contact Keith at [email protected].

Trademarks

Linux is a trademark of Linus Torvalds in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. DB2, Lotus, Rational, Tivoli, and WebSphere are trademarks of IBM Corporation in the United States, other countries, or both. Microsoft, Windows, and Windows NT are trademarks of Microsoft Corporation in the United States, other countries, or both.