include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/rfc2307bis.schema
include         /etc/openldap/schema/yast.schema

This first directive in slapd.conf, shown in Example 36.2, “slapd.conf: Include Directive for Schemes”, specifies the scheme by which the LDAP directory is organized. The entry core.schema is required. Additionally required schemes are appended to this directive. Find information in the included OpenLDAP documentation.

pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args

These two files contain the PID (process ID) and some of the arguments with which the slapd process is started. There is no need for modifications here.

# Sample Access Control
#       Allow read access of root DSE
# Allow self write access
#       Allow authenticated users read access
#       Allow anonymous users to authenticate
# access to dn="" by * read
  access to * by self write
              by users read
              by anonymous auth
#
# if no access controls are present, the default is:
#       Allow read by all
#
# rootdn can always write!

Example 36.4, “slapd.conf: Access Control” is the excerpt from slapd.conf that regulates the access permissions for the LDAP directory on the server. The settings made here in the global section of slapd.conf are valid as long as no custom access rules are declared in the database-specific section. These would overwrite the global declarations. As presented here, all users have read access to the directory, but only the administrator (rootdn) can write to this directory. Access control regulation in LDAP is a highly complex process. The following tips can help:

Example 36.5, “slapd.conf: Example for Access Control” shows an example of a simple access control that can be arbitrarily developed using regular expressions.

access to  dn.regex="ou=([^,]+),dc=example,dc=com" 
by dn.regex="cn=Administrator,ou=$1,dc=example,dc=com" write  
by user read 
by * none

This rule declares that only its respective administrator has write access to an individual ou entry. All other authenticated users have read access and the rest of the world has no access.

	Establishing Access Rules
If there is no access to rule or no matching by directive, access is denied. Only explicitly declared access rights are granted. If no rules are declared at all, the default principle is write access for the administrator and read access for the rest of the world.

Find detailed information and an example configuration for LDAP access rights in the online documentation of the installed openldap2 package.

Apart from the possibility to administer access permissions with the central server configuration file (slapd.conf), there is access control information (ACI). ACI allows storage of the access information for individual objects within the LDAP tree. This type of access control is not yet common and is still considered experimental by the developers. Refer to http://www.openldap.org/faq/data/cache/758.html for information.

database bdb
suffix "dc=example,dc=com" 
checkpoint      1024    5
cachesize       10000
rootdn "cn=Administrator,dc=example,dc=com" 
# Cleartext passwords, especially for the rootdn, should 
# be avoided.  See slappasswd(8) and slapd.conf(5) for details. 
# Use of strong authentication encouraged.
rootpw secret 
# The database directory MUST exist prior to running slapd AND 
# should only be accessible by the slapd/tools. Mode 700 recommended. 
directory /var/lib/ldap 
# Indices to maintain 
index   objectClass     eq
overlay ppolicy
ppolicy_default "cn=Default Password Policy,dc=example,dc=com"
ppolicy_hash_cleartext
ppolicy_use_lockout

Custom Access rules defined here for the database are used instead of the global Access rules.

Once the LDAP server is fully configured and all desired entries have been made according to the pattern described in Section 36.4, “Data Handling in the LDAP Directory”, start the LDAP server as root by entering rcldap start. To stop the server manually, enter the command rcldap stop. Request the status of the running LDAP server with rcldap status.

The YaST runlevel editor, described in Section 20.2.3, “Configuring System Services (Runlevel) with YaST”, can be used to have the server started and stopped automatically on boot and halt of the system. It is also possible to create the corresponding links to the start and stop scripts with the insserv command from a command prompt as described in Section 20.2.2, “Init Scripts”.

Once the configuration of your LDAP server in /etc/openldap/slapd.conf is correct and ready to go (it features appropriate entries for suffix, directory, rootdn, rootpw, and index), proceed to entering records. OpenLDAP offers the ldapadd command for this task. If possible, add the objects to the database in bundles for practical reasons. LDAP is able to process the LDIF format (LDAP data interchange format) for this. An LDIF file is a simple text file that can contain an arbitrary number of attribute and value pairs. Refer to the schema files declared in slapd.conf for the available object classes and attributes. The LDIF file for creating a rough framework for the example in Figure 36.1, “Structure of an LDAP Directory” would look like that in Example 36.7, “Example for an LDIF File”.

# The Organization
dn: dc=example,dc=com
objectClass: dcObject
objectClass: organization
o: Example dc: example

# The organizational unit development (devel)
dn: ou=devel,dc=example,dc=com
objectClass: organizationalUnit
ou: devel

# The organizational unit documentation (doc)
dn: ou=doc,dc=example,dc=com
objectClass: organizationalUnit
ou: doc

# The organizational unit internal IT (it)
dn: ou=it,dc=example,dc=com
objectClass: organizationalUnit
ou: it

	Encoding of LDIF Files
LDAP works with UTF-8 (Unicode). Umlauts must be encoded correctly. Use an editor that supports UTF-8, such as Kate or recent versions of Emacs. Otherwise, avoid umlauts and other special characters or use recode to recode the input to UTF-8.

Save the file with the .ldif suffix then pass it to the server with the following command:

ldapadd -x -D <dn of the administrator> -W -f <file>.ldif

-x switches off the authentication with SASL in this case. -D declares the user that calls the operation. The valid DN of the administrator is entered here just like it has been configured in slapd.conf. In the current example, this is cn=Administrator,dc=example,dc=com. -W circumvents entering the password on the command line (in clear text) and activates a separate password prompt. This password was previously determined in slapd.conf with rootpw. -f passes the filename. See the details of running ldapadd in Example 36.8, “ldapadd with example.ldif”.

ldapadd -x -D cn=Administrator,dc=example,dc=com -W -f example.ldif 

Enter LDAP password: 
adding new entry "dc=example,dc=com" 
adding new entry "ou=devel,dc=example,dc=com" 
adding new entry "ou=doc,dc=example,dc=com" 
adding new entry "ou=it,dc=example,dc=com"

The user data of individuals can be prepared in separate LDIF files. Example 36.9, “LDIF Data for Tux” adds Tux to the new LDAP directory.

# coworker Tux
dn: cn=Tux Linux,ou=devel,dc=example,dc=com
objectClass: inetOrgPerson
cn: Tux Linux
givenName: Tux
sn: Linux
mail: tux@example.com
uid: tux
telephoneNumber: +49 1234 567-8

An LDIF file can contain an arbitrary number of objects. It is possible to pass entire directory branches to the server at once or only parts of it as shown in the example of individual objects. If it is necessary to modify some data relatively often, a fine subdivision of single objects is recommended.

The tool ldapmodify is provided for modifying the data stock. The easiest way to do this is to modify the corresponding LDIF file then pass this modified file to the LDAP server. To change the telephone number of colleague Tux from +49 1234 567-8 to +49 1234 567-10, edit the LDIF file like in Example 36.10, “Modified LDIF File tux.ldif”.

# coworker Tux
dn: cn=Tux Linux,ou=devel,dc=example,dc=com 
changetype: modify
replace: telephoneNumber 
telephoneNumber: +49 1234 567-10

Import the modified file into the LDAP directory with the following command:

ldapmodify -x -D cn=Administrator,dc=example,dc=com -W -f tux.ldif

Alternatively, pass the attributes to change directly to ldapmodify. The procedure for this is described below:

Find detailed information about ldapmodify and its syntax in the ldapmodify man page.

OpenLDAP provides, with ldapsearch, a command line tool for searching data within an LDAP directory and reading data from it. A simple query would have the following syntax:

ldapsearch -x -b dc=example,dc=com "(objectClass=*)"

The -b option determines the search base—the section of the tree within which the search should be performed. In the current case, this is dc=example,dc=com. To perform a more finely-grained search in specific subsections of the LDAP directory (for example, only within the devel department), pass this section to ldapsearch with -b. -x requests activation of simple authentication. (objectClass=*) declares that all objects contained in the directory should be read. This command option can be used after the creation of a new directory tree to verify that all entries have been recorded correctly and the server responds as desired. Find more information about the use of ldapsearch in the corresponding man page (ldapsearch(1)).

Delete unwanted entries with ldapdelete. The syntax is similar to that of the other commands. To delete, for example, the complete entry for Tux Linux, issue the following command:

ldapdelete -x -D cn=Administrator,dc=example,dc=com -W cn=Tux \
Linux,ou=devel,dc=example,dc=com

Background knowledge of the processes acting in the background of a client machine helps you understand how the YaST LDAP client module works. If LDAP is activated for network authentication or the YaST module is called, the packages pam_ldap and nss_ldap are installed and the two corresponding configuration files are adapted. pam_ldap is the PAM module responsible for negotiation between login processes and the LDAP directory as the source of authentication data. The dedicated module pam_ldap.so is installed and the PAM configuration is adapted (see Example 36.11, “pam_unix2.conf Adapted to LDAP”).

auth:       use_ldap 
account:    use_ldap
password:   use_ldap 
session:    none

When manually configuring additional services to use LDAP, include the PAM LDAP module in the PAM configuration file corresponding to the service in /etc/pam.d. Configuration files already adapted to individual services can be found in /usr/share/doc/packages/pam_ldap/pam.d/. Copy appropriate files to /etc/pam.d.

glibc name resolution through the nsswitch mechanism is adapted to the employment of LDAP with nss_ldap. A new, adapted file nsswitch.conf is created in /etc with the installation of this package. Find more about the workings of nsswitch.conf in Section 30.7.1, “Configuration Files”. The following lines must be present in nsswitch.conf for user administration and authentication with LDAP. See Example 36.12, “Adaptations in nsswitch.conf”.

passwd: compat
group: compat

passwd_compat: ldap
group_compat: ldap

These lines order the resolver library of glibc first to evaluate the corresponding files in /etc and additionally access the LDAP server as sources for authentication and user data. Test this mechanism, for example, by reading the content of the user database with the command getent passwd. The returned set should contain a survey of the local users of your system as well as all users stored on the LDAP server.

To prevent regular users managed through LDAP from logging in to the server with ssh or login, the files /etc/passwd and /etc/group each need to include an additional line. This is the line +::::::/sbin/nologin in /etc/passwd and +::: in /etc/group.

After the initial adjustments of nss_ldap, pam_ldap, /etc/passwd, and /etc/group have been taken care of by YaST, you can simply connect your client to the server and let YaST manage users over LDAP. This basic setup is described in Section 36.6.2.1, “Basic Configuration”.

Use the YaST LDAP client to further configure the YaST group and user configuration modules. This includes manipulating the default settings for new users and groups and the number and nature of the attributes assigned to a user or a group. LDAP user management allows you to assign far more and different attributes to users and groups than traditional user or group management solutions. This is described in Section 36.6.2.2, “Configuring the YaST Group and User Administration Modules”.

36.6.2.1. Basic Configuration¶

The basic LDAP client configuration dialog (Figure 36.3, “YaST: Configuration of the LDAP Client”) opens during installation if you choose LDAP user management or when you select Network Services+LDAP Client in the YaST Control Center in the installed system.

Figure 36.3. YaST: Configuration of the LDAP Client¶

To authenticate users of your machine against an OpenLDAP server and enable user management via OpenLDAP, proceed as follows:

1. Click Use LDAP to enable the use of LDAP. Select Use LDAP but Disable Logins instead if you want to use LDAP for authentication, but do not want other users to log in to this client.

2. Enter the IP address of the LDAP server to use.

3. Enter the LDAP base DN to select the search base on the LDAP server. To retrieve the base DN automatically, click Fetch DN. YaST then checks for any LDAP database on the server address specified above. Choose the appropriate base DN from the search results given by YaST.

4. If TLS or SSL protected communication with the server is required, select LDAP TLS/SSL.

5. If the LDAP server still uses LDAPv2, explicitly enable the use of this protocol version by selecting LDAP Version 2.

6. Select Start Automounter to mount remote directories on your client, such as a remotely managed /home.

7. Select Create Home Directory on Login to have a user's home automatically created on the first user login.

8. Click Finish to apply your settings.

Figure 36.4. YaST: Advanced Configuration¶

To modify data on the server as administrator, click Advanced Configuration. The following dialog is split in two tabs. See Figure 36.4, “YaST: Advanced Configuration”.

1. In the Client Settings tab, adjust the following settings to your needs:

   1. If the search base for users, passwords, and groups differs from the global search base specified the LDAP base DN, enter these different naming contexts in User Map, Password Map, and Group Map.

   2. Specify the password change protocol. The standard method to use whenever a password is changed is crypt, meaning that password hashes generated by crypt are used. For details on this and other options, refer to the pam_ldap man page.

   3. Specify the LDAP group to use with Group Member Attribute. The default value for this is member.

2. In Administration Settings, adjust the following settings:

   1. Set the base for storing your user management data via Configuration Base DN.

   2. Enter the appropriate value for Administrator DN. This DN must be identical with the rootdn value specified in /etc/openldap/slapd.conf to enable this particular user to manipulate data stored on the LDAP server. Enter the full DN (such as cn=Administrator,dc=example,dc=com) or activate Append Base DN to have the base DN added automatically when you enter cn=Administrator.

   3. Check Create Default Configuration Objects to create the basic configuration objects on the server to enable user management via LDAP.

   4. If your client machine should act as a file server for home directories across your network, check Home Directories on This Machine.

   5. Use the Password Policy section to select, add, delete, or modify the password policy settings to use. The configuration of password policies with YaST is part of the LDAP server setup.

   6. Click Accept to leave the Advanced Configuration then Finish to apply your settings.

Use Configure User Management Settings to edit entries on the LDAP server. Access to the configuration modules on the server is then granted according to the ACLs and ACIs stored on the server. Follow the procedures outlined in Section 36.6.2.2, “Configuring the YaST Group and User Administration Modules”.

36.6.2.2. Configuring the YaST Group and User Administration Modules¶

Use the YaST LDAP client to adapt the YaST modules for user and group administration and to extend them as needed. Define templates with default values for the individual attributes to simplify the data registration. The presets created here are stored as LDAP objects in the LDAP directory. The registration of user data is still done with the regular YaST modules for user and group management. The registered data is stored as LDAP objects on the server.

Figure 36.5. YaST: Module Configuration¶

The dialog for module configuration (Figure 36.5, “YaST: Module Configuration”) allows the creation of new modules, selection and modification of existing configuration modules, and design and modification of templates for such modules.

To create a new configuration module, proceed as follows:

1. Click New and select the type of module to create. For a user configuration module, select suseuserconfiguration and for a group configuration choose susegroupconfiguration.

2. Choose a name for the new template. The content view then features a table listing all attributes allowed in this module with their assigned values. Apart from all set attributes, the list also contains all other attributes allowed by the current schema but currently not used.

3. Accept the preset values or adjust the defaults to use in group and user configuration by selecting the respective attribute, pressing Edit, and entering the new value. Rename a module by simply changing the cn attribute of the module. Clicking Delete deletes the currently selected module.

4. After you click Accept, the new module is added to the selection menu.

The YaST modules for group and user administration embed templates with sensible standard values. To edit a template associated with a configuration module, proceed as follows:

1. In the Module Configuration dialog, click Configure Template.

2. Determine the values of the general attributes assigned to this template according to your needs or leave some of them empty. Empty attributes are deleted on the LDAP server.

3. Modify, delete, or add new default values for new objects (user or group configuration objects in the LDAP tree).

Figure 36.6. YaST: Configuration of an Object Template¶

Connect the template to its module by setting the susedefaulttemplate attribute value of the module to the DN of the adapted template.

The default values for an attribute can be created from other attributes by using a variable instead of an absolute value. For example, when creating a new user, cn=%sn %givenName is created automatically from the attribute values for sn and givenName.

Once all modules and templates are configured correctly and ready to run, new groups and users can be registered in the usual way with YaST.