The Unix system administrator traditionally uses the NIS service for name resolution and data distribution in a network. The configuration data contained in the files in /etc and the directories group, hosts, mail, netgroup, networks, passwd, printcap, protocols, rpc, and services are distributed by clients all over the network. These files can be maintained without major effort because they are simple text files. The handling of larger amounts of data, however, becomes increasingly difficult due to nonexistent structuring. NIS is only designed for Unix platforms. This means it is not suitable as a centralized data administration tool in heterogeneous networks.

Unlike NIS, the LDAP service is not restricted to pure Unix networks. Windows servers (from 2000) support LDAP as a directory service. Application tasks mentioned above are additionally supported in non-Unix systems.

The LDAP principle can be applied to any data structure that should be centrally administered. A few application examples are:

This list can be extended because LDAP is extensible, unlike NIS. The clearly-defined hierarchical structure of the data eases the administration of large amounts of data, because it can be searched more easily.

To get a deep background knowledge on how an LDAP server works and how the data are stored, it is vital to understand the way the data are organized on the server and how this structure enables LDAP to provide fast access to the data you need. To successfully operate an LDAP setup, you also need to be familiar with some basic LDAP terminology. This section introduces the basic layout of an LDAP directory tree and provides the basic terminology used in an LDAP context. Skip this introductory section, if you already have some LDAP background knowledge and just want to learn how to set up an LDAP environment in SUSE Linux Enterprise.

An LDAP directory has a tree structure. All entries (called objects) of the directory have a defined position within this hierarchy. This hierarchy is called the directory information tree (DIT). The complete path to the desired entry, which unambiguously identifies it, is called distinguished name or DN. A single node along the path to this entry is called relative distinguished name or RDN. Objects can generally be assigned to one of two possible types:

The top of the directory hierarchy has a root element root. This can contain c (country), dc (domain component), or o (organization) as subordinate elements. The relations within an LDAP directory tree become more evident in the following example, shown in Figure 35.1, “Structure of an LDAP Directory”.

Figure 35.1. Structure of an LDAP Directory¶

The complete diagram is a fictional directory information tree. The entries on three levels are depicted. Each entry corresponds to one box in the picture. The complete, valid distinguished name for the fictional employee Geeko Linux, in this case, is cn=Geeko Linux,ou=doc,dc=example,dc=com. It is composed by adding the RDN cn=Geeko Linux to the DN of the preceding entry ou=doc,dc=example,dc=com.

The types of objects that should be stored in the DIT are globally determined following a scheme. The type of an object is determined by the object class. The object class determines what attributes the concerned object must or can be assigned. A scheme, therefore, must contain definitions of all object classes and attributes used in the desired application scenario. There are a few common schemes (see RFC 2252 and 2256). It is, however, possible to create custom schemes or to use multiple schemes complementing each other if this is required by the environment in which the LDAP server should operate.

Table 35.1, “Commonly Used Object Classes and Attributes” offers a small overview of the object classes from core.schema and inetorgperson.schema used in the example, including required attributes and valid attribute values.

Example 35.1, “Excerpt from schema.core ” shows an excerpt from a scheme directive with explanations (line numbering for explanatory reasons).

#1 attributetype (2.5.4.11 NAME ( 'ou' 'organizationalUnitName')
#2        DESC 'RFC2256: organizational unit this object belongs to'
#3        SUP name )

...
#4 objectclass ( 2.5.6.5 NAME 'organizationalUnit'
#5        DESC 'RFC2256: an organizational unit'
#6        SUP top STRUCTURAL
#7        MUST ou
#8 MAY (userPassword $ searchGuide $ seeAlso $ businessCategory 
    $ x121Address $ registeredAddress $ destinationIndicator 
    $ preferredDeliveryMethod $ telexNumber 
    $ teletexTerminalIdentifier $ telephoneNumber 
    $ internationaliSDNNumber $ facsimileTelephoneNumber 
    $ street $ postOfficeBox $ postalCode $ postalAddress 
    $ physicalDeliveryOfficeName
    $ st $ l $ description) )
...

The attribute type organizationalUnitName and the corresponding object class organizationalUnit serve as an example here. Line 1 features the name of the attribute, its unique OID (object identifier) (numerical), and the abbreviation of the attribute.

Line 2 gives a brief description of the attribute with DESC. The corresponding RFC on which the definition is based is also mentioned here. SUP in line 3 indicates a superordinate attribute type to which this attribute belongs.

The definition of the object class organizationalUnit begins in line 4, like in the definition of the attribute, with an OID and the name of the object class. Line 5 features a brief description of the object class. Line 6, with its entry SUP top, indicates that this object class is not subordinate to another object class. Line 7, starting with MUST, lists all attribute types that must be used in conjunction with an object of the type organizationalUnit. Line 8, starting with MAY, lists all attribute types that are permitted in conjunction with this object class.

A very good introduction to the use of schemes can be found in the documentation of OpenLDAP. When installed, find it in /usr/share/doc/packages/openldap2/admin-guide/index.html.

YaST includes a module to set up LDAP-based user management. If you did not enable this feature during the installation, start the module by selecting Network Services+LDAP Client. YaST automatically enables any PAM and NSS related changes as required by LDAP and installs the necessary files.

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

passwd: compat
group: compat

passwd_compat: ldap
group_compat: ldap

35.3.2. Configuring the LDAP Client¶

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 35.3.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 35.3.2.2, “Configuring the YaST Group and User Administration Modules”.

35.3.2.1. Basic Configuration¶

The basic LDAP client configuration dialog (Figure 35.2, “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 35.2. 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 35.3. YaST: Advanced Configuration¶

To modify data on the server as administrator, click Advanced Configuration. The following dialog is split in two tabs. See Figure 35.3, “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 35.3.2.2, “Configuring the YaST Group and User Administration Modules”.

35.3.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 35.4. YaST: Module Configuration¶

The dialog for module configuration (Figure 35.4, “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 35.5. 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.

The actual registration of user and group data differs only slightly from the procedure when not using LDAP. The following brief instructions relate to the administration of users. The procedure for administering groups is analogous.

Figure 35.6. YaST: Additional LDAP Settings¶

The initial input form of user administration offers LDAP Options. This gives the possibility to apply LDAP search filters to the set of available users or go to the module for the configuration of LDAP users and groups by selecting LDAP User and Group Configuration.

To browse the LDAP directory tree and all its entries conveniently, use the YaST LDAP Browser:

More complex subjects, like SASL configuration or establishment of a replicating LDAP server that distributes the workload among multiple slaves, were intentionally not included in this chapter. Detailed information about both subjects can be found in the OpenLDAP 2.2 Administrator's Guide.

The Web site of the OpenLDAP project offers exhaustive documentation for beginning and advanced LDAP users:

Printed literature about LDAP:

The ultimate reference material for the subject of LDAP is the corresponding RFCs (request for comments), 2251 to 2256.