What is linux ldap server
The Lightweight Directory Access Protocol (LDAP) is a set of protocols designed to access and maintain information directories. LDAP can be used for user and group management, system configuration management, address management, and more. This chapter provides a basic understanding of how OpenLDAP works and how to manage LDAP data with YaST.
In a network environment it is crucial to keep important information structured and to serve it quickly. A directory service—like the common yellow pages, keeps information available in a well-structured and readily-searchable form.
Ideally, a central server stores the data in a directory and distributes it to all clients using a well-defined protocol. The structured data allow a wide range of applications to access them. A central repository reduces the necessary administrative effort. The use of an open and standardized protocol like LDAP ensures that as many different client applications as possible can access such information.
A directory in this context is a type of database optimized for quick and effective reading and searching:
To make multiple concurrent reading accesses possible, the number of updates is usually very low. The number of read and write accesses is often limited to a few users with administrative privileges. In contrast, conventional databases are optimized for accepting the largest possible data volume in a short time.
When static data is administered, updates of the existing data sets are very rare. When working with dynamic data, especially when data sets like bank accounts or accounting are concerned, the consistency of the data is of primary importance. If an amount should be subtracted from one place to be added to another, both operations must happen concurrently, within one transaction , to ensure balance over the data stock. Traditional relational databases usually have a very strong focus on data consistency, such as the referential integrity support of transactions. Conversely, short-term inconsistencies are usually acceptable in LDAP directories. LDAP directories often do not have such strong consistency requirements as relational databases.
The design of a directory service like LDAP is not laid out to support complex update or query mechanisms. All applications are guaranteed to access this service quickly and easily.
4.1 LDAP versus NIS #
Unix system administrators traditionally use NIS (Network Information Service) for name resolution and data distribution in a network. The configuration data contained in the files group , hosts , mail , netgroup , networks , passwd , printcap , protocols , rpc , and services in the /etc directory is distributed to 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, and 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. The application tasks mentioned above are additionally supported in non-Unix systems.
The LDAP principle can be applied to any data structure that needs to be centrally administered. A few application examples are:
Replacement for the NIS service
Mail routing (postfix, sendmail)
Address books for mail clients, like Mozilla, Evolution, and Outlook
Administration of zone descriptions for a BIND9 name server
User authentication with Samba in heterogeneous networks
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, as it can be searched more easily.
4.2 Structure of an LDAP Directory Tree #
To get background knowledge on how a LDAP server works and how the data is stored, it is vital to understand the way the data is organized on the server and how this structure enables LDAP to provide fast access to the data. 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 with respect to LDAP. 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 Server . Read on at Section 4.3, “Configuring an LDAP Server with YaST” or Section 4.7, “Manually Configuring an LDAP Server”.
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 the distinguished name or DN. A single node along the path to this entry is called relative distinguished name or RDN.
The relations within an LDAP directory tree become more evident in the following example, shown in Figure 4.1, “Structure of an LDAP Directory”.
FigureВ 4.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 image. 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 .
Источник
OpenLDAP Server
The Lightweight Directory Access Protocol, or LDAP, is a protocol for querying and modifying a X.500-based directory service running over TCP/IP. The current LDAP version is LDAPv3, as defined in RFC4510, and the implementation used in Ubuntu is OpenLDAP.»
The LDAP protocol accesses directories. A common mistake is to call a directory an LDAP directory, or LDAP database, but it’s really so common, and we all know what we are talking about, that it’s ok. Here are some key concepts and terms:
A directory is a tree of data entries that is hierarchical in nature and is called the Directory Information Tree (DIT).
An entry consists of a set of attributes.
An attribute has a key (a name/description) and one or more values.
Every attribute must be defined in at least one objectClass.
Attributes and objectclasses are defined in schemas (an objectclass is actually considered as a special kind of attribute).
Each entry has a unique identifier: its Distinguished Name (DN or dn). This, in turn, consists of a Relative Distinguished Name (RDN) followed by the parent entry’s DN.
The entry’s DN is not an attribute. It is not considered part of the entry itself.
The terms object, container, and node have certain connotations but they all essentially mean the same thing as entry, the technically correct term.
For example, below we have a single entry consisting of 11 attributes where the following is true:
DN is “cn=John Doe,dc=example,dc=com”
RDN is “cn=John Doe”
parent DN is “dc=example,dc=com”
The above entry is in LDIF format (LDAP Data Interchange Format). Any information that you feed into your DIT must also be in such a format. It is defined in RFC2849.
Such a directory accessed via LDAP is good for anything that involves a large number of access requests to a mostly-read, attribute-based (name:value) backend, and that can benefit from a hierarchical structure. Examples include an address book, company directory, a list of email addresses, and a mail server’s configuration.
Installation
This guide will use a database suffix of dc=example,dc=com.
Proceed with the install of the server and the main command line utilities:
If you want to change your DIT suffix, now would be a good time, because changing it discards your existing one. To change the suffix, run the following command:
To switch your DIT suffix to dc=example,dc=com, for example, so you can follow this guide more closely, answer example.com when asked about the DNS domain name.
Throughout this guide we will issue many commands with the LDAP utilities. To save some typing, we can configure the OpenLDAP libraries with certain defaults in /etc/ldap/ldap.conf :
Adjust for your server name and directory suffix
Post-install Inspection
The packaging of slapd is designed to be configured within the service itself by dedicating a separate DIT for that purpose. This allows one to dynamically configure slapd without the need to restart the service or edit config files. This configuration database consists of a collection of text-based LDIF files located under /etc/ldap/slapd.d , but these should never be edited directly. This way of working is known by several names: the slapd-config method, the RTC method (Real Time Configuration), or the cn=config method. You can still use the traditional flat-file method (slapd.conf) but it’s not going to be covered in this guide.
Right after installation, you will get two databases, or suffixes: one for your data, based on your host’s domain (dc=example,dc=com), and one for your configuration, with its root at cn=config. To change the data on each we need different credentials and access methods:
dc=example,dc=com: the administrative user for this suffix is cn=admin,dc=example,dc=com and its password is the one selected during the installation of the slapd package
cn=config: the configuration slapd itself is stored under this suffix. Changes to it can be made by the special DN gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth. This is how the local system’s root user (uid=0/gid=0) is seen by the directory when using SASL EXTERNAL authentication through the ldapi:/// transport via the /run/slapd/ldapi unix socket. Essentially what this means is that only the local root user can update the cn=config database. More details later.
This is what the slapd-config DIT looks like via the LDAP protocol (listing only the dns):
Explanation of entries:
cn=config: global settings
cn=module<0>,cn=config: a dynamically loaded module
cn=schema,cn=config: contains hard-coded system-level schema
cn=<0>core,cn=schema,cn=config: the hard-coded core schema
cn=<1>cosine,cn=schema,cn=config: the cosine schema
cn=<2>nis,cn=schema,cn=config: the nis schema
cn=<3>inetorgperson,cn=schema,cn=config: the inetorgperson schema
olcDatabase=<-1>frontend,cn=config: frontend database, default settings for other databases
olcDatabase=<0>config,cn=config: slapd configuration database (cn=config)
olcDatabase=<1>mdb,cn=config: your database instance (dc=example,dc=com)
This is what the dc=example,dc=com DIT looks like:
Explanation of entries:
dc=example,dc=com: base of the DIT
cn=admin,dc=example,dc=com: administrator (rootDN) for this DIT (set up during package install)
Notice how we used two different authentication mechanisms:
- -x: this is called a simple bind, and is essentially a plain text authentication. Since no binddn was provided (via -D), this became an anonymous bind. Without -x, the default is to use a SASL bind.
- -Y EXTERNAL: this is using a SASL bind (no -x was provided), and further specifying the EXTERNAL type. Together with -H ldapi:///, this uses a local unix socket connection
In both cases we only got the results that the server ACLs allowed us to see, based on who we are. A very handy tool to verify the authentication is ldapwhoami:
When you use simple bind (-x) and specify a binddn with -D as your authentication dn, the server will look for a userPassword attribute in that entry, and use that to verify the credentials. In this particular case above, we used the database rootDN entry, i.e., the actual administrator, and that is a special case whose password is set in the configuration when the package is installed.
A simple bind without some sort of transport security mechanism is clear text, meaning the credentials are transmitted in the clear. You should add TLS support to your OpenLDAP server as soon as possible.
Here are the SASL EXTERNAL examples:
When using SASL EXTERNAL via the ldapi:/// transport, the binddn becomes a combination of the uid and gid of the connecting user, followed by the suffix cn=peercred,cn=external,cn=auth. The server ACLs know about this, and grant the local root user complete write access to cn=config via the SASL mechanism.
Modifying/Populating your Database
Let’s introduce some content to our database. We will add the following:
a node called People (to store users)
a node called Groups (to store groups)
a group called miners
a user called john
Create the following LDIF file and call it add_content.ldif :
It’s important that uid and gid values in your directory do not collide with local values. You can use high number ranges, such as starting at 5000 or even higher.
Add the content:
We can check that the information has been correctly added with the ldapsearch utility. For example, let’s search for the john entry, and request the cn and gidnumber attributes:
Here we used an LDAP “filter”: (uid=john). LDAP filters are very flexible and can become complex. For example, to list the group names of which john is a member, we could use the filter:
That is a logical AND between two attributes. Filters are very important in LDAP and mastering their syntax will help a long way. They are used for simple queries like this, but can also select what content is to be replicated to a secondary server, or even in complex ACLs. The full specification is defined in RFC 4515.
Notice we set the userPassword field for the john entry to the cryptic value
Remember that simple binds are insecure and you should add TLS support to your server!
Modifying the slapd Configuration Database
The slapd-config DIT can also be queried and modified. Here are some common operations.
Adding an index
Use ldapmodify to add an “Index” to your <1>mdb,cn=config database definition (for dc=example,dc=com). Create a file, call it uid_index.ldif , with the following contents:
Then issue the command:
You can confirm the change in this way:
Change the rootDN password:
First, run slappasswd to get the hash for the new password you want:
Now prepare a changerootpw.ldif file with this content:
Finally, run the ldapmodify command:
We still have the actual cn=admin,dc=example,dc=com dn in the dc=example,dc=com database, so let’s change it too. Since this is a regular entry in this database suffix, we can use ldappasswd:
Adding a schema
Schemas can only be added to cn=config if they are in LDIF format. If not, they will first have to be converted. You can find unconverted schemas in addition to converted ones in the /etc/ldap/schema directory.
It is not trivial to remove a schema from the slapd-config database. Practice adding schemas on a test system.
In the following example we’ll add the password policy (ppolicy) schema. This schema exists in both converted (.ldif) and native (.schema) formats, so we don’t have to convert it and can use ldapadd directly:
If the schema you want to add does not exist in LDIF format, a nice conversion tool that can be used is provided in the schema2ldif package.
Logging
Activity logging for slapd is very useful 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 such configuration, is enabled via the slapd-config database.
OpenLDAP comes with multiple logging 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.ldif with the following contents:
Implement the change:
This will produce a significant amount of logging and you will want to throttle back to a less verbose level once your system is in production. While in this verbose mode your host’s syslog engine (rsyslog) may have a hard time keeping up and may drop messages:
You may consider a change to rsyslog’s configuration. In /etc/rsyslog.conf , put:
And then restart the rsyslog daemon:
Backup and Restore
Now we have ldap running just the way we want, it is time to ensure we can save all of our work and restore it as needed.
What we need is a way to backup the directory database(s), specifically the configuration backend (cn=config) and the DIT (dc=example,dc=com). If we are going to backup those databases into, say, /export/backup , we could use slapcat as shown in the following script, called /usr/local/bin/ldapbackup :
These files are uncompressed text files containing everything in your directory including the tree layout, usernames, and every password. So, you might want to consider making /export/backup an encrypted partition and even having the script encrypt those files as it creates them. Ideally you should do both, but that depends on your security requirements.
Then, it is just a matter of having a cron script to run this program as often as you feel comfortable with. For many, once a day suffices. For others, more often is required. Here is an example of a cron script called /etc/cron.d/ldapbackup that is run every night at 22:45h:
Now the files are created, they should be copied to a backup server.
Assuming we did a fresh reinstall of ldap, the restore process could be something like this:
This is a simplistic backup strategy, of course. It’s being shown here as a reference for the basic tooling you can use for backups and restores.
Источник
