The Light Directory Access Protocol (LDAP) defines a standard method for accessing and updating information in a directory (a database) either locally or remotely in a client-server model. The LDAP method is exploited by a cluster of hosts to allow centralized security authentication as well as access to user and group information. This functionality is intended to be used in a clustering environment to keep authentication, user, and group information common across the cluster.
The LDAP exploitation of the security subsystem is implemented as the LDAP authentication load module. It is conceptually similar to the other load modules such as NIS, DCE, and Kerberos 5. The load modules are defined in the /usr/lib/security/methods.cfg file. The implementation of the LDAP authentication load module is at a low level and is handled by the libraries.
Once the LDAP authentication load module is enabled to serve user and group information, most high-level APIs, commands, and system management tools work in their usual manner. An -R flag is introduced for most high-level commands to work through different load modules. For example, to create an LDAP user named joe from a client machine, use the following command:
mkuser -R LDAP joe
The client system checks whether the user is an LDAP user through the user's SYSTEM attribute in the /etc/security/user file. If the user's SYSTEM is set to LDAP, that user can only authenticate through LDAP. If the SYSTEM attribute in the default stanza is set to LDAP, then all users who do not have a SYSTEM attribute set are considered LDAP users. The LDAP keyword can be used with other SYSTEM attribute values as described in Security Administration. The client side communicates to the server through the secldapclntd daemon. The daemon accepts requests from applications (through the library APIs), queries the LDAP server, and returns data to the application. The secldapclntd daemon is also responsible for caching.
To set up a system as an LDAP security information server that serves authentication, user, and group information through LDAP, the LDAP server and client packages must be installed. The LDAP server must be configured as a client as well as a server. A DB2 database is also required by the LDAP server. If the Secure Socket Layer (SSL) is required, then the GSKit must be installed. The system administrator must create a key using the ikeyman command. The certificate of the server key must be carried to the clients.
The mksecldap command can be used to set up an LDAP security information server. It sets up a database named ldapdb2, populates the database with the user and group information from the local host, and sets the ldap server administrator DN (distinguished name) and password. Optionally, it can set up SSL for client/server communication. Then mksecldap loads a server plugin (libsecldap.a) and starts the LDAP server process (slapd). The mksecldap command also adds an entry into the /etc/inittab file to start the LDAP server at every reboot. The entire LDAP server setup is done through the mksecldap command, which updates the slapd.conf file (SecureWay Directory Version 3.1) or slapd32.conf file (SecureWay Directory Version 3.2). There is no need to configure the LDAP web management interface.
All the user and group information is stored under an AIX tree (suffix). The default suffix is 'cn=aixsecdb'. The mksecldap command accepts a user-supplied suffix through the -d flag. If the user-supplied suffix does not have 'cn=aixsecdb' as its first RDN (Relative Distinguished Name), the mksecldap command prefixes the user-supplied suffix with 'cn=aixsecdb'. This AIX tree is ACL (Access Control List) protected. A client must bind as the LDAP server administrator to be able to access the AIX tree.
The mksecldap command works even if an LDAP server has been setup for other purposes, for example, for blue page information. In this case, mksecldap adds the AIX tree and populates it with the AIX security information to the existing database. This tree is ACL-protected independently from other trees. In this case, the LDAP server works as usual, in addition to it also serves as an AIX LDAP Security Server. It is strongly recommended that you backup your existing database before running the mksecldap command to setup the security server to share the same database.
After the LDAP security information server is successfully set up, the same host must be set up as a client.
If the LDAP security information server setup is not successful, you can undo the setup by running the mksecldap command with the -U flag. This restores the slapd.conf (or slapd32.conf) file to its pre-setup state. Run the mksecldap command with the -U flag after any unsuccessful setup attempt before trying to run the mksecldap command again. Otherwise, residual setup information might remain in the configuration file and cause a subsequent setup to fail. As a safety precaution, the undo option does not do anything to the database or to its data, because the database could have existed before the mksecldap command was run. You must remove any database manually if it was created by the mksecldap command. If the mksecldap command has added data to a pre-existing database, you must decide what steps to recover from a failed setup attempt.
For more information on setting up a LDAP security information server, refer the mksecldap command documentation.
Each client must have the LDAP client package installed. If the SSL is required, the GSKit must be installed, a key must be created, and the LDAP server SSL key certificate must be added to this key.
The mksecldap command can be used to set up the client. To have this client contact the LDAP security information server, the server name must be supplied during setup. The server's administrator domain name and password are also needed for client access the AIX tree on the server. The mksecldap command saves the server administrator domain name, password, server name, AIX tree domain name on the server, and the SSL key path and password to the /etc/security/ldap/ldap.cfg file.
Multiple servers can be supplied to the mksecldap command during client setup. In this case, the client contacts the servers in the supplied order and establishes connection to the first server that the client can successfully bind to. If bad connection occurs between the client and the server, a reconnection request is tried using the same logic. The Security LDAP exploitation model does not support referral. It is important that the replicate servers are kept synchronized.
The client communicates to the LDAP security information server through a client side daemon (secldapclntd). If the LDAP load module is enabled on this client, high-level commands eventually find this daemon through the library APIs. The daemon queries the server and returns the information back to the caller.
Other fine-tuning options can be supplied to the mksecldap command during client setup, such as settings for the number of threads used by the daemon, the cache entry size, and the cache expiration timeout. These options are for experienced users only. For most environments, the default values are sufficient.
A comma-seperated user list can be supplied to the mksecldap command during client setup. These users' SYSTEM attributes are set to LDAP. Once this is done, these users can only authenticate through the LDAP load module. Note that the mksecldap command does not add these users to the LDAP security information server to avoid duplicate user IDs in the LDAP database. It is recommended that you use the mkuser command with -R LDAP flag to create these users on an LDAP server.
In the final steps of the client setup, the mksecldap command starts the client-side daemon and adds an entry in the /etc/inittab file so the daemon starts at every reboot. You can check whether the setup is successful by checking the secldapclntd process. Provided that the LDAP security information sever is setup and running, this daemon will be running if the setup was successful.
You can manage users and groups on an LDAP security information server from any LDAP client by using high-level commands. An -R flag added to most of the high-level commands can manage users and groups using LDAP as well as other authentication load modules such as DCE, NIS, and Kerberos 5. For more information concerning the use of the -R flag, refer to each of the user or group management commands.
To enable a user to authenticate through LDAP, run the chuser command to change the user's SYSTEM attribute value to LDAP. By setting the SYSTEM attribute value according the defined syntax, a user can be authenticated through more than one load module (for example, compat and LDAP). For more information on setting users' authentication methods, refer to Security Administration and the SYSTEM attribute syntax defined in the /etc/security/user file.
A user can be made a LDAP user at client setup time by running the mksecldap command with the -u flag in either of the following forms:
Alternatively, you can enable all LDAP users, whether they are defined locally or not, to authenticate through LDAP on a local host by modifying the "default" stanza of the /etc/security/user file to use "LDAP" as its value. All users that do not have a value defined for their SYSTEM attribute must follow what is defined in the default stanza. For example, if the default stanza has 'SYSTEM = "compat"' , changing it to 'SYSTEM = "compat OR LDAP"' allows authentication of these users either through AIX or LDAP. Changing the default stanza to 'SYSTEM = "LDAP"' enables these users to authenticate exclusively through LDAP. Those users who have a SYSTEM attribute value defined are not affected by the default stanza.
IBM SecureWay Directory version 3.2 provides a default server audit logging functionality. Once enabled, this default audit plugin logs LDAP server activities to a log file. Refer to the LDAP documentation in the Packaging Guide for LPP Installation for more information on this default audit plugin.
For your convenience, an LDAP security information server auditing functionality has been implemented in AIX 5.1 and later, called the LDAP security audit plugin. It is independent of the IBM SecureWay Directory default auditing service, so you can enable either or both of these auditing subsystems. The AIX audit plugin records only those events that update or query the AIX security information on an LDAP server. It works within the framework of AIX system auditing.
To accomodate LDAP, the following audit events have been added to the /etc/security/audit/event file:
An ldapserver audit class definition is also created in the /etc/security/audit/config file that contains all of the above events.
To audit the LDAP security information server, add the following line to each user's stanza in the /etc/security/audit/config file:
ldap = ldapserver
Because the LDAP security information server audit plugin is implemented within the frame of the AIX system auditing, it actually is part of the AIX system auditing subsystem. You can enable or disable the LDAP security information server audit using system audit commands, such as 'audit start' or 'audit shutdown'. All audit records are added to the system audit trails, which can be reviewed by using the auditpr command. For more information, refer to the Auditing Overview.