Section 5.4. Samba Server Implementation

5.4. Samba Server Implementation

The network design shown in Figure 5.2 is not comprehensive. It is assumed that you will install additional file servers and possibly additional BDCs.

Figure 5.2. Network Topology 500 User Network Using ldapsam passdb backend

All configuration files and locations are shown for SUSE Linux 9.2 and are equally valid for SUSE Linux Enterprise Server 9. The file locations for Red Hat Linux are similar. You may need to adjust the locations for your particular Linux system distribution/implementation.


The following information applies to Samba-3.0.20 when used with the Idealx smbldap-tools scripts version 0.9.1. If using a different version of Samba or of the smbldap-tools tarball, please verify that the versions you are about to use are matching. The smbldap-tools package uses counter-entries in the LDAP directory to avoid duplication of the UIDs and GIDs that are issued for POSIX accounts. The LDAP rdn under which this information is stored are called uidNumber and gidNumber respectively. These may be located in any convenient part of the directory information tree (DIT). In the examples that follow they have been located under dn=sambaDomainName=MEGANET2,dc=abmas,dc=org. They could just as well be located under the rdn cn=NextFreeUnixId.

The steps in the process involve changes from the network configuration shown in Chapter 4, "The 500-User Office". Before implementing the following steps, you must have completed the network implementation shown in that chapter. If you are starting with newly installed Linux servers, you must complete the steps shown in Section 4.3.1 before commencing at Section 5.4.1.

5.4.1. OpenLDAP Server Configuration

Confirm that the packages shown in Table 5.2 are installed on your system.

Table 5.2. Required OpenLDAP Linux Packages

SUSE Linux 8.x

SUSE Linux 9.x

Red Hat Linux













Samba-3 and OpenLDAP will have a degree of interdependence that is unavoidable. The method for bootstrapping the LDAP and Samba-3 configuration is relatively straightforward. If you follow these guidelines, the resulting system should work fine.



Install the file shown in Example 5.4.2 in the directory /etc/openldap.


Remove all files from the directory /data/ldap, making certain that the directory exists with permissions:

root#  ls -al /data | grep ldap drwx------   2 ldap   ldap       48 Dec 15 22:11 ldap 

This may require you to add a user and a group account for LDAP if they do not exist.


Install the file shown in Example 5.4.1 in the directory /data/ldap. In the event that this file is added after ldap has been started, it is possible to cause the new settings to take effect by shutting down the LDAP server, executing the db_recover command inside the /data/ldap directory, and then restarting the LDAP server.


Performance logging can be enabled and should preferably be sent to a file on a file system that is large enough to handle significantly sized logs. To enable the logging at a verbose level to permit detailed analysis, uncomment the entry in the /etc/openldap/slapd.conf shown as "loglevel 256". Edit the /etc/syslog.conf file to add the following at the end of the file:

local4.*    -/data/ldap/log/openldap.log 

Note: The path /data/ldap/log should be set at a location that is convenient and that can store a large volume of data.

Example 5.4.1. LDAP DB_CONFIG File
set_cachesize       0 150000000 1 set_lg_regionmax    262144 set_lg_bsize        2097152 #set_lg_dir         /var/log/bdb set_flags           DB_LOG_AUTOREMOVE 

5.4.2. PAM and NSS Client Configuration

The steps that follow involve configuration of LDAP, NSS LDAP-based resolution of users and groups. Also, so that LDAP-based accounts can log onto the system, the steps ahead configure the Pluggable Authentication Modules (PAM) to permit LDAP-based authentication.

Since you have chosen to put UNIX user and group accounts into the LDAP database, it is likely that you may want to use them for UNIX system (Linux) local machine logons. This necessitates correct configuration of PAM. The pam_ldap open source package provides the PAM modules that most people would use. On SUSE Linux systems, the module also has the ability to redirect authentication requests through LDAP.

You have chosen to configure these services by directly editing the system files, but of course, you know that this configuration can be done using system tools provided by the Linux system vendor. SUSE Linux has a facility in YaST (the system admin tool) through yast authconfig tool for this.



Execute the following command to find where the nss_ldap module expects to find its control file:

root#  strings /lib/ | grep conf 

The preferred and usual location is /etc/ldap.conf.


On the server MASSIVE, install the file shown in Example 5.4.4 into the path that was obtained from the step above. On the servers called BLDG1 and BLDG2, install the file shown in Example 5.4.5 into the path that was obtained from the step above.


Edit the NSS control file (/etc/nsswitch.conf) so that the lines that control user and group resolution will obtain information from the normal system files as well as from ldap:

passwd:  files ldap shadow:  files ldap group:   files ldap hosts:   files dns wins 

Later, when the LDAP database has been initialized and user and group accounts have been added, you can validate resolution of the LDAP resolver process. The inclusion of WINS-based hostname resolution is deliberate so that all MS Windows client hostnames can be resolved to their IP addresses, whether or not they are DHCP clients.


Some Linux systems (Novell SUSE Linux in particular) add entries to the nsswitch.conf file that may cause operational problems with the configuration methods adopted in this book. It is advisable to comment out the entries passwd_compat and group_compat where they are found in this file.

Even at the risk of overstating the issue, incorrect and inappropriate configuration of the nsswitch.conf file is a significant cause of operational problems with LDAP.


For PAM LDAP configuration on this SUSE Linux 9.0 system, the simplest solution is to edit the following files in the /etc/pam.d directory: login, password, samba, sshd. In each file, locate every entry that has the entry and add to the line the entry use_ldap as shown for the login module in this example:

#%PAM-1.0 auth      requisite   nullok use_ldap #set_secrpc auth      required auth      required #auth     required auth      required auth      required account   required   use_ldap password  required     pam_pwcheck.s  nullok password  required   nullok use_first_pass \                                       use_authtok use_ldap session   required   none use_ldap # debug or trace session   required 

On other Linux systems that do not have an LDAP-enabled module, you must edit these files by adding the modules as shown here:

#%PAM-1.0 auth      required auth      required auth      sufficient auth      required   nullok try_first_pass #set_secrpc account   sufficient account   required password  required nullok password  required    use_first_pass use_authtok password  required   nullok use_first_pass use_authtok session   required   none # debug or trace session   required session   required session   optional 

This example does have the LDAP-enabled, but simply demonstrates the use of the module. You can use either implementation, but if the on your system supports LDAP, you probably want to use it rather than add an additional module.

5.4.3. Samba-3 PDC Configuration

Verify that the Samba-3.0.20 (or later) packages are installed on each SUSE Linux server before following the steps below. If Samba-3.0.20 (or later) is not installed, you have the choice to either build your own or obtain the packages from a dependable source. Packages for SUSE Linux 8.x, 9.x, and SUSE Linux Enterprise Server 9, as well as for Red Hat Fedora Core and Red Hat Enterprise Linux Server 3 and 4, are included on the CD-ROM that is included with this book.



Install the files in Example 5.4.6, Example 5.4.7, Example 5.5.3, and Example 5.5.4 into the /etc/samba/ directory. The three files should be added together to form the smb.conf master file. It is a good practice to call this file something like smb.conf. master and then to perform all file edits on the master file. The operational smb. conf is then generated as shown in the next step.


Create and verify the contents of the smb.conf file that is generated by:

root#  testparm -s smb.conf.master > smb.conf 

Immediately follow this with the following:

root#  testparm 

The output that is created should be free from errors, as shown here:

Load smb config files from /etc/samba/smb.conf Processing section "[accounts]" Processing section "[service]" Processing section "[pidata]" Processing section "[homes]" Processing section "[printers]" Processing section "[apps]" Processing section "[netlogon]" Processing section "[profiles]" Processing section "[profdata]" Processing section "[print$]" Loaded services file OK. Server role: ROLE_DOMAIN_PDC Press enter to see a dump of your service definitions 


Delete all runtime files from prior Samba operation by executing (for SUSE Linux):

root#  rm /etc/samba/*tdb root#  rm /var/lib/samba/*tdb root#  rm /var/lib/samba/*dat root#  rm /var/log/samba/* 


Samba-3 communicates with the LDAP server. The password that it uses to authenticate to the LDAP server must be stored in the secrets.tdb file. Execute the following to create the new secrets.tdb files and store the password for the LDAP Manager:

root#  smbpasswd -w not24get 

The expected output from this command is:

Setting stored password for "cn=Manager,dc=abmas,dc=biz" in secrets.tdb 


Samba-3 generates a Windows Security Identifier (SID) only when smbd has been started. For this reason, you start Samba. After a few seconds delay, execute:

root#  smbclient -L localhost -U% root#  net getlocalsid 

A report such as the following means that the domain SID has not yet been written to the secrets.tdb or to the LDAP backend:

[2005/03/03 23:19:34, 0] lib/smbldap.c:smbldap_connect_system(852)   failed to bind to server ldap:// with dn="cn=Manager,dc=abmas,dc=biz" Error: Can't contact LDAP server          (unknown) [2005/03/03 23:19:48, 0] lib/smbldap.c:smbldap_search_suffix(1169)   smbldap_search_suffix: Problem during the LDAP search:          (unknown) (Timed out) 

The attempt to read the SID will cause and attempted bind to the LDAP server. Because the LDAP server is not running, this operation will fail by way of a timeout, as shown previously. This is normal output; do not worry about this error message. When the domain has been created and written to the secrets.tdb file, the output should look like this:

SID for domain MASSIVE is: S-1-5-21-3504140859-1010554828-2431957765 

If, after a short delay (a few seconds), the domain SID has still not been written to the secrets.tdb file, it is necessary to investigate what may be misconfigured. In this case, carefully check the smb.conf file for typographical errors (the most common problem). The use of the testparm is highly recommended to validate the contents of this file.


When a positive domain SID has been reported, stop Samba.


Configure the NFS server for your Linux system. So you can complete the steps that follow, enter into the /etc/exports the following entry:

/home   *(rw,root_squash,sync) 

This permits the user home directories to be used on the BDC servers for testing purposes. You, of course, decide what is the best way for your site to distribute data drives, and you create suitable backup and restore procedures for Abmas I'd strongly recommend that for normal operation the BDC is completely independent of the PDC. rsync is a useful tool here, as it resembles the NT replication service quite closely. If you do use NFS, do not forget to start the NFS server as follows:

root#  rcnfsserver start 

Your Samba-3 PDC is now ready to communicate with the LDAP password backend. Let's get on with configuration of the LDAP server.

5.4.4. Install and Configure Idealx smbldap-tools Scripts

The Idealx scripts, or equivalent, are necessary to permit Samba-3 to manage accounts on the LDAP server. You have chosen the Idealx scripts because they are the best-known LDAP configuration scripts. The use of these scripts will help avoid the necessity to create custom scripts. It is easy to download them from the Idealx Web site[17]. The tarball may be directly downloaded[18] from this site also. Alternatively, you may obtain the smbldaptools-0.9.1-1.src.rpm[19] file that may be used to build an installable RPM package for your Linux system.

[17] <>

[18] <>

[19] <>


The smbldap-tools scripts can be installed in any convenient directory of your choice, in which case you must change the path to them in your smb.conf file on the PDC (MASSIVE).

The smbldap-tools are located in /opt/IDEALX/sbin. The scripts are not needed on BDC machines because all LDAP updates are handled by the PDC alone. Installation of smbldap-tools from the Tarball

To perform a manual installation of the smbldap-tools scripts, the following procedure may be used:



Create the /opt/IDEALX/sbin directory, and set its permissions and ownership as shown here:

root#  mkdir -p /opt/IDEALX/sbin root#  chown root:root /opt/IDEALX/sbin root#  chmod 755 /opt/IDEALX/sbin root#  mkdir -p /etc/smbldap-tools root#  chown root:root /etc/smbldap-tools root#  chmod 755 /etc/smbldap-tools 


If you wish to use the downloaded tarball, unpack the smbldap-tools in a suitable temporary location. Change into either the directory extracted from the tarball or the smbldap-tools directory in your /usr/share/doc/packages directory tree.


Copy all the smbldap-* and the files into the /opt/IDEALX/sbin directory, as shown here:

root#  cd smbldap-tools-0.9.1/ root#  cp smbldap-* *pm /opt/IDEALX/sbin/ root#  cp smbldap*conf /etc/smbldap-tools/ root#  chmod 750 /opt/IDEALX/sbin/smbldap-* root#  chmod 750 /opt/IDEALX/sbin/ root#  chmod 640 /etc/smbldap-tools/smbldap.conf root#  chmod 600 /etc/smbldap-tools/smbldap_bind.conf 


The smbldap-tools scripts master control file must now be configured. Change to the /opt/IDEALX/sbin directory, then edit the to affect the changes shown here:

... # ugly funcs using global variables and spawning openldap clients my $smbldap_conf="/etc/smbldap-tools/smbldap.conf"; my $smbldap_bind_conf="/etc/smbldap-tools/smbldap_bind.conf"; ... 


To complete the configuration of the smbldap-tools, set the permissions and ownership by executing the following commands:

root#  chown root:root /opt/IDEALX/sbin/* root#  chmod 755 /opt/IDEALX/sbin/smbldap-* root#  chmod 640 /opt/IDEALX/sbin/smb*pm 

The smbldap-tools scripts are now ready for the configuration step outlined in Section Installing smbldap-tools from the RPM Package

In the event that you have elected to use the RPM package provided by Idealx, download the source RPM smbldap-tools-0.9.1-1.src.rpm, then follow this procedure:



Install the source RPM that has been downloaded as follows:

root#  rpm -i smbldap-tools-0.9.1-1.src.rpm 


Change into the directory in which the SPEC files are located. On SUSE Linux:

root#  cd /usr/src/packages/SPECS 

On Red Hat Linux systems:

root#  cd /usr/src/redhat/SPECS 


Edit the smbldap-tools.spec file to change the value of the _sysconfig macro as shown here:

%define _prefix /opt/IDEALX %define _sysconfdir /etc 

Note: Any suitable directory can be specified.


Build the package by executing:

root#  rpmbuild -ba -v smbldap-tools.spec 

A build process that has completed without error will place the installable binary files in the directory ../RPMS/noarch.


Install the binary package by executing:

root#  rpm -Uvh ../RPMS/noarch/smbldap-tools-0.9.1-1.noarch.rpm 

The Idealx scripts should now be ready for configuration using the steps outlined in Section Configuration of smbldap-tools

Prior to use, the smbldap-tools must be configured to match the settings in the smb.conf file and to match the settings in the /etc/openldap/slapd.conf file. The assumption is made that the smb.conf file has correct contents. The following procedure ensures that this is completed correctly:

The smbldap-tools require that the NetBIOS name (machine name) of the Samba server be included in the smb.conf file.



Change into the directory that contains the script.

root#  cd /opt/IDEALX/sbin 


Execute the script as follows:

root#  ./ 

The interactive use of this script for the PDC is demonstrated here:

root# /opt/IDEALX/sbin/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=       smbldap-tools script configuration       -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Before starting, check . if your samba controller is up and running. . if the domain SID is defined (you can get it with the                                                   'net getlocalsid') . you can leave the configuration using the Crtl-c key combination . empty value can be set with the "." character -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Looking for configuration files... Samba Config File Location [/etc/samba/smb.conf] > smbldap-tools configuration file Location (global parameters)                         [/etc/opt/IDEALX/smbldap-tools/smbldap.conf] > smbldap Config file Location (bind parameters)                    [/etc/opt/IDEALX/smbldap-tools/smbldap_bind.conf] > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Let's start configuring the smbldap-tools scripts ... . workgroup name: name of the domain Samba act as a PDC   workgroup name [MEGANET2] > . netbios name: netbios name of the samba controler   netbios name [MASSIVE] > . 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:'\\MASSIVE\%U'   logon home (press the "." character if you don't want homeDirectory)                                                      [\\MASSIVE\%U] > . logon path: directory where roaming profiles are stored.                                             Ex:'\\MASSIVE\profiles\%U'   logon path (press the "." character                if you don't want roaming profile) [\\%L\profiles\%U] > . home directory prefix (use %U as username)                                             [/home/%U] > /data/users/%U . default users' homeDirectory mode [700] > . default user netlogon script (use %U as username)                                                  [scripts\logon.bat] >   default password validation time (time in days) [45] > 900 . ldap suffix [dc=abmas,dc=biz] > . ldap group suffix [ou=Groups] > . ldap user suffix [ou=People,ou=Users] > . ldap machine suffix [ou=Computers,ou=Users] > . 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=MEGANET2] > . ldap master server: IP adress or DNS name of the master                                                 (writable) ldap server   ldap master server [] > . ldap master port [389] > . ldap master bind dn [cn=Manager,dc=abmas,dc=biz] > . 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 [] > . ldap slave port [389] > . ldap slave bind dn [cn=Manager,dc=abmas,dc=biz] > . ldap slave bind password [] > . ldap tls support (1/0) [0] > . SID for domain MEGANET2: SID of the domain                       (can be obtained with 'net getlocalsid MASSIVE')   SID for domain MEGANET2                         [S-1-5-21-3504140859-1010554828-2431957765]] > . 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 [] > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= backup old configuration files:   /etc/opt/IDEALX/smbldap-tools/smbldap.conf->                         /etc/opt/IDEALX/smbldap-tools/smbldap.conf.old   /etc/opt/IDEALX/smbldap-tools/smbldap_bind.conf->                    /etc/opt/IDEALX/smbldap-tools/smbldap_bind.conf.old writing new configuration file:   /etc/opt/IDEALX/smbldap-tools/smbldap.conf done.   /etc/opt/IDEALX/smbldap-tools/smbldap_bind.conf done. 

Since a slave LDAP server has not been configured, it is necessary to specify the IP address of the master LDAP server for both the master and the slave configuration prompts.


Change to the directory that contains the smbldap.conf file, then verify its contents.

The smbldap-tools are now ready for use.

5.4.5. LDAP Initialization and Creation of User and Group Accounts

The LDAP database must be populated with well-known Windows domain user accounts and domain group accounts before Samba can be used. The following procedures step you through the process.

At this time, Samba-3 requires that on a PDC all UNIX (POSIX) group accounts that are mapped (linked) to Windows domain group accounts must be in the LDAP database. It does not hurt to have UNIX user and group accounts in both the system files as well as in the LDAP database. From a UNIX system perspective, the NSS resolver checks system files before referring to LDAP. If the UNIX system can resolve (find) an account in the system file, it does not need to ask LDAP.

Addition of an account to the LDAP backend can be done in two ways:

  • If you always have a user account in the /etc/passwd on every server or in a NIS(+) backend, it is not necessary to add POSIX accounts for them in LDAP. In this case, you can add Windows domain user accounts using the pdbedit utility. Use of this tool from the command line adds the SambaSamAccount entry for the user, but does not add the PosixAccount entry for the user.

    This is the least desirable method because when LDAP is used as the passwd backend Samba expects the POSIX account to be in LDAP also. It is possible to use the PADL account migration tool to migrate all system accounts from either the /etc/passwd files, or from NIS, to LDAP.

  • If you decide that it is probably a good idea to add both the PosixAccount attributes as well as the SambaSamAccount attributes for each user, then a suitable script is needed. In the example system you are installing in this exercise, you are making use of the Idealx smbldap-tools scripts. A copy of these tools, preconfigured for this system, is included on the enclosed CD-ROM under Chap06/Tools.

If you wish to have more control over how the LDAP database is initialized or if you don't want to use the Idealx smbldap-tools, you should refer to Chapter 15, "A Collection of Useful Tidbits", Section 15.5.

The following steps initialize the LDAP database, and then you can add user and group accounts that Samba can use. You use the smbldap-populate to seed the LDAP database. You then manually add the accounts shown in Table 5.3. The list of users does not cover all 500 network users; it provides examples only.

Table 5.3. Abmas Network Users and Groups

Account Name




Robert Jordan




Stanley Soroka




Christine Roberson




Mary Vortexis

















In the following examples, as the LDAP database is initialized, we do create a container for Computer (machine) accounts. In the Samba-3 smb.conf files, specific use is made of the People container, not the Computers container, for domain member accounts. This is not a mistake; it is a deliberate action that is necessitated by the fact that the resolution of a machine (computer) account to a UID is done via NSS. The only way this can be handled is using the NSS (/etc/nsswitch.conf) entry for passwd, which is resolved using the nss_ldap library. The configuration file for the nss_ldap library is the file /etc/ldap.conf that provides only one possible LDAP search command that is specified by the entry called nss_base_passwd. This means that the search path must take into account the directory structure so that the LDAP search will commence at a level that is above both the Computers container and the Users (or People) container. If this is done, it is necessary to use a search that will descend the directory tree so that the machine account can be found. Alternatively, by placing all machine accounts in the People container, we are able to sidestep this limitation. This is the simpler solution that has been adopted in this chapter.



Start the LDAP server by executing:

root# rcldap start Starting ldap-server                           done 


Change to the /opt/IDEALX/sbin directory.


Execute the script that will populate the LDAP database as shown here:

root# ./smbldap-populate -a root -k 0 -m 0 

The expected output from this is:

Using workgroup name from smb.conf: sambaDomainName=MEGANET2 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= => Warning: you must update smbldap.conf configuration file to : => sambaUnixIdPooldn parameter must be set    to "sambaDomainName=MEGANET2,dc=abmas,dc=biz" -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Using builtin directory structure adding new entry: dc=abmas,dc=biz adding new entry: ou=People,dc=abmas,dc=biz adding new entry: ou=Groups,dc=abmas,dc=biz entry ou=People,dc=abmas,dc=biz already exist. adding new entry: ou=Idmap,dc=abmas,dc=biz adding new entry: sambaDomainName=MEGANET2,dc=abmas,dc=biz adding new entry: uid=root,ou=People,dc=abmas,dc=biz adding new entry: uid=nobody,ou=People,dc=abmas,dc=biz adding new entry: cn=Domain Admins,ou=Groups,dc=abmas,dc=biz adding new entry: cn=Domain Users,ou=Groups,dc=abmas,dc=biz adding new entry: cn=Domain Guests,ou=Groups,dc=abmas,dc=biz adding new entry: cn=Domain Computers,ou=Groups,dc=abmas,dc=biz adding new entry: cn=Administrators,ou=Groups,dc=abmas,dc=biz adding new entry: cn=Print Operators,ou=Groups,dc=abmas,dc=biz adding new entry: cn=Backup Operators,ou=Groups,dc=abmas,dc=biz adding new entry: cn=Replicators,ou=Groups,dc=abmas,dc=biz 


Edit the /etc/smbldap-tools/smbldap.conf file so that the following information is changed from:

# Where to store next uidNumber and gidNumber available sambaUnixIdPooldn="cn=NextFreeUnixId,${suffix}" 

to read, after modification:

# Where to store next uidNumber and gidNumber available #sambaUnixIdPooldn="cn=NextFreeUnixId,${suffix}" sambaUnixIdPooldn="sambaDomainName=MEGANET2,dc=abmas,dc=biz" 


It is necessary to restart the LDAP server as shown here:

root#  rcldap restart Shutting down ldap-server                      done Starting ldap-server                           done 


So that we can use a global IDMAP repository, the LDAP directory must have a container object for IDMAP data. There are several ways you can check that your LDAP database is able to receive IDMAP information. One of the simplest is to execute:

root#  slapcat | grep -i idmap dn: ou=Idmap,dc=abmas,dc=biz ou: idmap 

If the execution of this command does not return IDMAP entries, you need to create an LDIF template file (see Example 5.5.5). You can add the required entries using the following command:

root#  ldapadd -x -D "cn=Manager,dc=abmas,dc=biz" \       -w not24get < /etc/openldap/idmap.LDIF 

Samba automatically populates this LDAP directory container when it needs to.


It looks like all has gone well, as expected. Let's confirm that this is the case by running a few tests. First we check the contents of the database directly by running slapcat as follows (the output has been cut down):

root#  slapcat dn: dc=abmas,dc=biz objectClass: dcObject objectClass: organization dc: abmas o: abmas structuralObjectClass: organization entryUUID: 5ab02bf6-c536-1027-9d29-b1f32350fb43 creatorsName: cn=Manager,dc=abmas,dc=biz createTimestamp: 20031217234200Z entryCSN: 2003121723:42:00Z#0x0001#0#0000 modifiersName: cn=Manager,dc=abmas,dc=biz modifyTimestamp: 20031217234200Z ... dn: cn=Domain Computers,ou=Groups,dc=abmas,dc=biz objectClass: posixGroup objectClass: sambaGroupMapping gidNumber: 553 cn: Domain Computers description: Netbios Domain Computers accounts sambaSID: S-1-5-21-3504140859-1010554828-2431957765-553 sambaGroupType: 2 displayName: Domain Computers structuralObjectClass: posixGroup entryUUID: 5e0a41d8-c536-1027-9d3b-b1f32350fb43 creatorsName: cn=Manager,dc=abmas,dc=biz createTimestamp: 20031217234206Z entryCSN: 2003121723:42:06Z#0x0002#0#0000 modifiersName: cn=Manager,dc=abmas,dc=biz modifyTimestamp: 20031217234206Z 

This looks good so far.


The next step is to prove that the LDAP server is running and responds to a search request. Execute the following as shown (output has been cut to save space):

root#  ldapsearch -x -b "dc=abmas,dc=biz" "(ObjectClass=*)" # extended LDIF # # LDAPv3 # base <dc=abmas,dc=biz> with scope sub # filter: (ObjectClass=*) # requesting: ALL # # dn: dc=abmas,dc=biz objectClass: dcObject objectClass: organization dc: abmas o: abmas # People, dn: ou=People,dc=abmas,dc=biz objectClass: organizationalUnit ou: People ... # Domain Computers, Groups, dn: cn=Domain Computers,ou=Groups,dc=abmas,dc=biz objectClass: posixGroup objectClass: sambaGroupMapping gidNumber: 553 cn: Domain Computers description: Netbios Domain Computers accounts sambaSID: S-1-5-21-3504140859-1010554828-2431957765-553 sambaGroupType: 2 displayName: Domain Computers # search result search: 2 result: 0 Success # numResponses: 20 # numEntries: 19 

Good. It is all working just fine.


You must now make certain that the NSS resolver can interrogate LDAP also. Execute the following commands:

root#  getent passwd | grep root root:x:998:512:Netbios Domain Administrator:/home:/bin/false root#  getent group | grep Domain Domain Admins:x:512:root Domain Users:x:513: Domain Guests:x:514: Domain Computers:x:553: 

This demonstrates that the nss_ldap library is functioning as it should. If these two steps fail to produce this information, refer to Section for diagnostic procedures that can be followed to isolate the cause of the problem. Proceed to the next step only when the previous steps have been successfully completed.


Our database is now ready for the addition of network users. For each user for whom an account must be created, execute the following:

root#  ./smbldap-useradd -m -a username root#  ./smbldap-passwd username Changing password for username New password : XXXXXXXX Retype new password : XXXXXXXX root#  smbpasswd username New SMB password: XXXXXXXX Retype new SMB password: XXXXXXXX 

where username is the login ID for each user.


Now verify that the UNIX (POSIX) accounts can be resolved via NSS by executing the following:

root#  getent passwd root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/bin/bash ... root:x:0:512:Netbios Domain Administrator:/home:/bin/false nobody:x:999:514:nobody:/dev/null:/bin/false bobj:x:1000:513:System User:/home/bobj:/bin/bash stans:x:1001:513:System User:/home/stans:/bin/bash chrisr:x:1002:513:System User:/home/chrisr:/bin/bash maryv:x:1003:513:System User:/home/maryv:/bin/bash 

This demonstrates that user account resolution via LDAP is working.


This step will determine whether or not identity resolution is working correctly. Do not procede is this step fails, rather find the cause of the failure. The id command may be used to validate your configuration so far, as shown here:

root#  id chrisr uid=1002(chrisr) gid=513(Domain Users) groups=513(Domain Users) 

This confirms that the UNIX (POSIX) user account information can be resolved from LDAP by system tools that make a getentpw() system call.


The root account must have UID=0; if not, this means that operations conducted from a Windows client using tools such as the Domain User Manager fails under UNIX because the management of user and group accounts requires that the UID=0. Additionally, it is a good idea to make certain that no matter how root account credentials are resolved, the home directory and shell are valid. You decide to effect this immediately as demonstrated here:

root#  cd /opt/IDEALX/sbin root#  ./smbldap-usermod -u 0 -d /root -s /bin/bash root 


Verify that the changes just made to the root account were accepted by executing:

root#  getent passwd | grep root root:x:0:0:root:/root:/bin/bash root:x:0:512:Netbios Domain Administrator:/root:/bin/bash 

This demonstrates that the changes were accepted.


Make certain that a home directory has been created for every user by listing the directories in /home as follows:

root#  ls -al /home drwxr-xr-x   8 root   root         176 Dec 17 18:50 ./ drwxr-xr-x  21 root   root         560 Dec 15 22:19 ../ drwx------   7 bobj   Domain Users     568 Dec 17 01:16 bobj/ drwx------   7 chrisr Domain Users     568 Dec 17 01:19 chrisr/ drwx------   7 maryv  Domain Users     568 Dec 17 01:27 maryv/ drwx------   7 stans  Domain Users     568 Dec 17 01:43 stans/ 

This is precisely what we want to see.


The final validation step involves making certain that Samba-3 can obtain the user accounts from the LDAP ldapsam passwd backend. Execute the following command as shown:

root#  pdbedit -Lv chrisr Unix username:        chrisr NT username:          chrisr Account Flags:        [U          ] User SID:             S-1-5-21-3504140859-1010554828-2431957765-3004 Primary Group SID:    S-1-5-21-3504140859-1010554828-2431957765-513 Full Name:            System User Home Directory:       \\MASSIVE\homes HomeDir Drive:        H: Logon Script:         scripts\login.cmd Profile Path:         \\MASSIVE\profiles\chrisr Domain:               MEGANET2 Account desc:         System User Workstations: Munged dial: Logon time:           0 Logoff time:          Mon, 18 Jan 2038 20:14:07 GMT Kickoff time:         Mon, 18 Jan 2038 20:14:07 GMT Password last set:    Wed, 17 Dec 2003 17:17:40 GMT Password can change:  Wed, 17 Dec 2003 17:17:40 GMT Password must change: Mon, 18 Jan 2038 20:14:07 GMT Last bad password   : 0 Bad password count  : 0 Logon hours         : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 

This looks good. Of course, you fully expected that it would all work, didn't you?


Now you add the group accounts that are used on the Abmas network. Execute the following exactly as shown:

root#  ./smbldap-groupadd -a Accounts root#  ./smbldap-groupadd -a Finances root#  ./smbldap-groupadd -a PIOps 

The addition of groups does not involve keyboard interaction, so the lack of console output is of no concern.


You really do want to confirm that UNIX group resolution from LDAP is functioning as it should. Let's do this as shown here:

root#  getent group ... Domain Admins:x:512:root Domain Users:x:513:bobj,stans,chrisr,maryv Domain Guests:x:514: ... Accounts:x:1000: Finances:x:1001: PIOps:x:1002: 

The well-known special accounts (Domain Admins, Domain Users, Domain Guests), as well as our own site-specific group accounts, are correctly listed. This is looking good.


The final step we need to validate is that Samba can see all the Windows domain groups and that they are correctly mapped to the respective UNIX group account. To do this, just execute the following command:

root#  net groupmap list Domain Admins (S-1-5-21-3504140859-...-2431957765-512) -> Domain Admins Domain Users (S-1-5-21-3504140859-...-2431957765-513) -> Domain Users Domain Guests (S-1-5-21-3504140859-...-2431957765-514) -> Domain Guests ... Accounts (S-1-5-21-3504140859-1010554828-2431957765-3001) -> Accounts Finances (S-1-5-21-3504140859-1010554828-2431957765-3003) -> Finances PIOps (S-1-5-21-3504140859-1010554828-2431957765-3005) -> PIOps 

This is looking good. Congratulations it works! Note that in the above output the lines were shortened by replacing the middle value (1010554828) of the SID with the ellipsis (...).


The server you have so carefully built is now ready for another important step. You start the Samba-3 server and validate its operation. Execute the following to render all the processes needed fully operative so that, on system reboot, they are automatically started:

root#  chkconfig named on root#  chkconfig dhcpd on root#  chkconfig ldap on root#  chkconfig nmb on root#  chkconfig smb on root#  chkconfig winbind on root#  rcnmb start root#  rcsmb start root#  rcwinbind start 


The next step might seem a little odd at this point, but take note that you are about to start winbindd, which must be able to authenticate to the PDC via the localhost interface with the smbd process. This account can be easily created by joining the PDC to the domain by executing the following command:

root#  net rpc join -S MASSIVE -U root%not24get 

Note: Before executing this command on the PDC, both nmbd and smbd must be started so that the net command can communicate with smbd. The expected output is as follows:

Joined domain MEGANET2. 

This indicates that the domain security account for the PDC has been correctly created.


At this time it is necessary to restart winbindd so that it can correctly authenticate to the PDC. The following command achieves that:

root#  rcwinbind restart 


You may now check Samba-3 operation as follows:

root#  smbclient -L massive -U%         Sharename       Type      Comment         ---------       ----      -------         IPC$            IPC       IPC Service (Samba 3.0.20)         accounts        Disk      Accounting Files         service         Disk      Financial Services Files         pidata          Disk      Property Insurance Files         apps            Disk      Application Files         netlogon        Disk      Network Logon Service         profiles        Disk      Profile Share         profdata        Disk      Profile Data Share         ADMIN$          IPC       IPC Service (Samba 3.0.20)         Server                Comment         ---------             -------         MASSIVE               Samba 3.0.20         Workgroup             Master         ---------             -------         MEGANET2              MASSIVE 

This shows that an anonymous connection is working.


For your finale, let's try an authenticated connection:

root#  smbclient //massive/bobj -Ubobj%n3v3r2l8 smb: \> dir   .                    D        0  Wed Dec 17 01:16:19 2003   ..                   D        0  Wed Dec 17 19:04:42 2003   bin                  D        0  Tue Sep  2 04:00:57 2003   Documents            D        0  Sun Nov 30 07:28:20 2003   public_html          D        0  Sun Nov 30 07:28:20 2003   .urlview             H      311  Fri Jul  7 06:55:35 2000   .dvipsrc             H      208  Fri Nov 17 11:22:02 1995          57681 blocks of size 524288. 57128 blocks available smb: \> q 

Well done. All is working fine.

The server MASSIVE is now configured, and it is time to move onto the next task.

5.4.6. Printer Configuration

The configuration for Samba-3 to enable CUPS raw-print-through printing has already been taken care of in the smb.conf file. The only preparation needed for smart printing to be possible involves creation of the directories in which Samba-3 stores Windows printing driver files.



Configure all network-attached printers to have a fixed IP address.


Create an entry in the DNS database on the server MASSIVE in both the forward lookup database for the zone and in the reverse lookup database for the network segment that the printer is to be located in. Example configuration files for similar zones were presented in Chapter 3, "Secure Office Networking", Example 3.3.12 and in Example 3.3.11.


Follow the instructions in the printer manufacturers' manuals to permit printing to port 9100. Use any other port the manufacturer specifies for direct mode, raw printing. This allows the CUPS spooler to print using raw mode protocols.


Only on the server to which the printer is attached, configure the CUPS Print Queues as follows:

root#  lpadmin -p printque     -v socket:// -E 

This step creates the necessary print queue to use no assigned print filter. This is ideal for raw printing, that is, printing without use of filters. The name printque is the name you have assigned for the particular printer.


Print queues may not be enabled at creation. Make certain that the queues you have just created are enabled by executing the following:

root#  /usr/bin/enable printque 


Even though your print queue may be enabled, it is still possible that it may not accept print jobs. A print queue will service incoming printing requests only when configured to do so. Ensure that your print queue is set to accept incoming jobs by executing the following commands:

root#  /usr/bin/accept printque 


Edit the file /etc/cups/mime.convs to uncomment the line:

application/octet-stream     application/vnd.cups-raw      0      - 


Edit the file /etc/cups/mime.types to uncomment the line:



Refer to the CUPS printing manual for instructions regarding how to configure CUPS so that print queues that reside on CUPS servers on remote networks route print jobs to the print server that owns that queue. The default setting on your CUPS server may automatically discover remotely installed printers and may permit this functionality without requiring specific configuration.


The following action creates the necessary directory subsystem. Follow these steps to printing heaven:

root#   mkdir  -p /var/lib/samba/drivers/{W32ALPHA,W32MIPS,W32X86,WIN40} root#   chown  -R root:root /var/lib/samba/drivers root#   chmod  -R ug=rwx,o=rx /var/lib/samba/drivers 

    Samba-3 by Example. Practical Exercises to Successful Deployment
    Samba-3 by Example: Practical Exercises to Successful Deployment (2nd Edition)
    ISBN: 013188221X
    EAN: 2147483647
    Year: 2005
    Pages: 142

    Similar book on Amazon © 2008-2017.
    If you may any questions please contact us: