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. Note | 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 PackagesSUSE Linux 8.x | SUSE Linux 9.x | Red Hat Linux |
---|
nss_ldap | nss_ldap | nss_ldap | pam_ldap | pam_ldap | pam_ldap | openldap2 | openldap2 | openldap | openldap2-client | openldap2-client | |
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. OPENLDAP SERVER CONFIGURATION STEPS 1. | Install the file shown in Example 5.4.2 in the directory /etc/openldap.
| 2. | 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.
| 3. | 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.
| 4. | 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 pam_unix2.so 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. PAM AND NSS CLIENT CONFIGURATION STEPS 1. | Execute the following command to find where the nss_ldap module expects to find its control file:
root# strings /lib/libnss_ldap.so.2 | grep conf The preferred and usual location is /etc/ldap.conf.
| 2. | 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.
| 3. | 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.
Note | 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.
| 4. | 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 pam_unix2.so entry and add to the line the entry use_ldap as shown for the login module in this example:
#%PAM-1.0 auth requisite pam_unix2.so nullok use_ldap #set_secrpc auth required pam_securetty.so auth required pam_nologin.so #auth required pam_homecheck.so auth required pam_env.so auth required pam_mail.so account required pam_unix2.so use_ldap password required pam_pwcheck.s nullok password required pam_unix2.so nullok use_first_pass \ use_authtok use_ldap session required pam_unix2.so none use_ldap # debug or trace session required pam_limits.so On other Linux systems that do not have an LDAP-enabled pam_unix2.so module, you must edit these files by adding the pam_ldap.so modules as shown here:
#%PAM-1.0 auth required pam_securetty.so auth required pam_nologin.so auth sufficient pam_ldap.so auth required pam_unix2.so nullok try_first_pass #set_secrpc account sufficient pam_ldap.so account required pam_unix2.so password required pam_pwcheck.so nullok password required pam_ldap.so use_first_pass use_authtok password required pam_unix2.so nullok use_first_pass use_authtok session required pam_unix2.so none # debug or trace session required pam_limits.so session required pam_env.so session optional pam_mail.so This example does have the LDAP-enabled pam_unix2.so, but simply demonstrates the use of the pam_ldap.so module. You can use either implementation, but if the pam_unix2.so 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. CONFIGURATION OF PDC CALLED MASSIVE 1. | 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.
| 2. | 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 | 3. | 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/* | 4. | 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 | 5. | 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://massive.abmas.biz 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.
| 6. | When a positive domain SID has been reported, stop Samba.
| 7. | 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] <http://samba.idealx.org/index.en.html>
[18] <http://samba.idealx.org/dist/smbldap-tools-0.9.1.tgz>
[19] <http://samba.idealx.org/dist/smbldap-tools-0.9.1-1.src.rpm> Note | 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. 5.4.4.1 Installation of smbldap-tools from the Tarball To perform a manual installation of the smbldap-tools scripts, the following procedure may be used: UNPACKING AND INSTALLATION STEPS FOR THE SMBLDAP-TOOLS TARBALL 1. | 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 | 2. | 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.
| 3. | Copy all the smbldap-* and the configure.pl files into the /opt/IDEALX/sbin directory, as shown here:
root# cd smbldap-tools-0.9.1/ root# cp smbldap-* configure.pl *pm /opt/IDEALX/sbin/ root# cp smbldap*conf /etc/smbldap-tools/ root# chmod 750 /opt/IDEALX/sbin/smbldap-* root# chmod 750 /opt/IDEALX/sbin/configure.pl root# chmod 640 /etc/smbldap-tools/smbldap.conf root# chmod 600 /etc/smbldap-tools/smbldap_bind.conf | 4. | The smbldap-tools scripts master control file must now be configured. Change to the /opt/IDEALX/sbin directory, then edit the smbldap_tools.pm 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"; ... | 5. | 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 5.4.4.3.
| 5.4.4.2 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: INSTALLATION STEPS FOR SMBLDAP-TOOLS RPM's 1. | Install the source RPM that has been downloaded as follows:
root# rpm -i smbldap-tools-0.9.1-1.src.rpm | 2. | 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 | 3. | 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.
| 4. | 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.
| 5. | 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 5.4.4.3. 5.4.4.3 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. CONFIGURATION STEPS FOR SMBLDAP-TOOLS TO ENABLE Use 1. | Change into the directory that contains the configure.pl script.
root# cd /opt/IDEALX/sbin | 2. | Execute the configure.pl script as follows:
root# ./configure.pl The interactive use of this script for the PDC is demonstrated here:
root# /opt/IDEALX/sbin/configure.pl -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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 [massive.abmas.biz] > . 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 [massive.abmas.biz] > . 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 [] > abmas.biz -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 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.
| 3. | 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 GroupsAccount Name | Type | ID | Password |
---|
Robert Jordan | User | bobj | n3v3r2l8 | Stanley Soroka | User | stans | impl13dst4r | Christine Roberson | User | chrisr | S9n0nw4ll | Mary Vortexis | User | maryv | kw13t0n3 | Accounts | Group | Accounts | | Finances | Group | Finances | | Insurance | Group | PIOps | |
Note | 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. |
LDAP DIRECTORY INITIALIZATION STEPS 1. | Start the LDAP server by executing:
root# rcldap start Starting ldap-server done | 2. | Change to the /opt/IDEALX/sbin directory.
| 3. | 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 | 4. | 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" | 5. | It is necessary to restart the LDAP server as shown here:
root# rcldap restart Shutting down ldap-server done Starting ldap-server done | 6. | 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.
| 7. | 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.
| 8. | 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 # # abmas.biz dn: dc=abmas,dc=biz objectClass: dcObject objectClass: organization dc: abmas o: abmas # People, abmas.biz dn: ou=People,dc=abmas,dc=biz objectClass: organizationalUnit ou: People ... # Domain Computers, Groups, abmas.biz 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.
| 9. | 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 5.3.1.7 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.
| 10. | 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.
| 11. | 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.
| 12. | 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.
| 13. | 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 | 14. | 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.
| 15. | 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.
| 16. | 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?
| 17. | 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.
| 18. | 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.
| 19. | 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 (...).
| 20. | 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 | 21. | 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.
| 22. | 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 | 23. | 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.
| 24. | 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. PRINTER CONFIGURATION STEPS 1. | Configure all network-attached printers to have a fixed IP address.
| 2. | Create an entry in the DNS database on the server MASSIVE in both the forward lookup database for the zone abmas.biz.hosts 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.
| 3. | 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.
| 4. | Only on the server to which the printer is attached, configure the CUPS Print Queues as follows:
root# lpadmin -p printque -v socket://printer-name.abmas.biz:9100 -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.
| 5. | 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 | 6. | 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 | 7. | Edit the file /etc/cups/mime.convs to uncomment the line:
application/octet-stream application/vnd.cups-raw 0 - | 8. | Edit the file /etc/cups/mime.types to uncomment the line:
application/octet-stream | 9. | 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.
| 10. | 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 | |