We will add the following: Use high number ranges, such as starting at By setting the uid and gid values in ldap high, you also allow for easier control of what can be done with a local user vs a ldap one.
More on that later. Here are a few examples. It will first need to be converted to LDIF format. It is not trivial to remove a schema from the slapd-config database. Practice adding schemas on a test system. Before adding any schema, you should check which schemas are already installed shown is a default, out-of-the-box output: Determine the index of the schema: An index is contained within braces: Use slapcat to perform the conversion: Finally, use ldapadd to add the new schema to the slapd-config DIT: Refer to the appropriate client-side documentation for details.
Logging Activity logging for slapd is indispensible when implementing an OpenLDAP-based solution yet it must be manually enabled after software installation. Otherwise, only rudimentary messages will appear in the logs. Logging, like any other slapd configuration, is enabled via the slapd-config database.
OpenLDAP comes with multiple logging subsystems levels with each one containing the lower one additive. A good level to try is stats. The slapd-config man page has more to say on the different subsystems. Create the file logging.
While in this verbose mode your host's syslog engine rsyslog may have a hard time keeping up and may drop messages: In such an environment, it is standard practice to build redundancy high availability into LDAP to prevent havoc should the LDAP server become unresponsive.
This is done through LDAP replication. Replication is achieved via the Syncrepl engine. This allows changes to be synchronized using a Consumer - Provider model. The specific kind of replication we will implement in this guide is a combination of the following modes: This has the Provider push changed entries to the Consumer as soon as they're made but, in addition, only actual changes will be sent, not entire entries.
Provider Configuration Begin by configuring the Provider. Add indexes to the frontend db. TRUE syncrepl Provider for primary db dn: TRUE accesslog overlay definitions for primary db dn: Consumer Configuration And now configure the Consumer.
Install the software by going through Installation. Make sure the slapd-config database is identical to the Provider's. In particular, make sure schemas and the databse suffix are the same.
Each consumer should have at least one rid Add the new content: The two databases suffix: Once the output Every time a change is done in the provider, this value will change and so should the one in the consumer s. But, you will know it is progressing since the consumer's contextCSN will be steadly increasing. If the consumer's contextCSN is missing or does not match the provider, you should stop and figure out the issue before continuing.
Try checking the slapd syslog and the auth log files in the provider to see if the consumer's authentication requests were successful or its requests to retrieve data they look like a lot of ldapsearch statements return no errors.
To test if it worked simply query, on the Consumer, the DNs in the database: Access Control The management of what type of access read, write, etc users should be granted to resources is known as access control. The configuration directives involved are called access control lists or ACL. When we installed the slapd package various ACL were set up automatically. We will look at a few important consequences of those defaults and, in so doing, we'll get an idea of how ACLs work and how they're configured.
The ACLs belonging to the latter act as defaults in case those of the former do not match. The frontend database is the second to be consulted and the ACL to be applied is the first to match "first match wins" among these 2 ACL sources.
Anonymous 'auth' access is provided to the userPassword attribute so that users can authenticate, or bind. Perhaps counter-intuitively, 'by anonymous auth' is needed even when anonymous access to the DIT is unwanted, otherwise this would be a chicken and egg problem: The by self write ACL grants write access to the userPassword attribute to users who authenticated as the dn where the attribute lives.
In other words, users can update the userPassword attribute of their own entries. The userPassword attribute is otherwise unaccessible by all other users, with the exception of the rootDN, who always has access and doesn't need to be mentioned explicitly. In order for users to change their own password, using passwd or other utilities, the user's own shadowLastChange attribute needs to be writable. All other directory users get to read this attribute's contents.
To force authentication during a bind request you can alternatively or in combination with the modified ACL use the 'olcRequire: As previously mentioned, there is no administrative account "rootDN" created for the slapd-config database. There is, however, a SASL identity that is granted full access to it.
See the previous command for an example. You must use sudo to become the root identity in order for the ACL to match. This means you must use the ldapi URI format. A succinct way to get all the ACLs is like this: See the man page for slapd. Since slapd is compiled using the gnutls library, we will use the certtool utility to complete these tasks. Install the gnutls-bin and ssl-cert packages: Naming the certificate and key for the host and service that will be using them will help keep things clear.
Create the server's certificate: Create the file certinfo. You should have just: Replication and TLS If you have set up replication between servers, it is common practice to encrypt StartTLS the replication traffic to prevent evesdropping. This is distinct from using encryption with authentication as we did above. In this section we will build on that TLS-authentication work. The assumption here is that you have set up replication between Provider and Consumer according to Replication and have configured TLS for authentication on the Provider by following TLS.
As previously stated, the objective for us with replication is high availablity for the LDAP service. In addition to this, however, we want to encrypt replication traffic.
What remains to be done is to create a key and certificate for the Consumer and then configure accordingly. On the Provider, Create a holding directory which will be used for the eventual transfer and then the Consumer's private key: Now transfer the ldapssl directory to the Consumer. Here we use scp adjust accordingly: Modify the existing olcSyncrepl attribute by tacking on some TLS options. In so doing, we will see, for the first time, how to change an attribute's value s. Also note the LDIF syntax for changing the values of an attribute 'replace'.
On Ubuntu, this has been traditionally accomplished by installing the libnss-ldap package. This package will bring in other tools that will assist you in the configuration step.
Install this package now: If you make a mistake you can try again using: If your server requires options not covered in the menu edit this file accordingly. You should now be able to log in using LDAP-based credentials. LDAP clients will need to refer to multiple servers if replication is in use. An alternative to the libnss-ldap package is the libnss-ldapd package.
This, however, will bring in the nscd package which is problably not wanted. Simply remove it afterwards. User and Group Management The ldap-utils package comes with enough utilities to manage the directory but the long string of options needed can make them a burden to use. The ldapscripts package contains wrapper scripts to these utilities that some people find easier to use.
The scripts are now ready to help manage your directory. Here are some examples of how to use them: Create a new user: