Share your story
The central voice for Linux and Open Source security news
Home News Topics Advisories HOWTOs Features Newsletters About Register

Sign up!
EnGarde Community
What is the most important Linux security technology?
Linux Events
Linux User Groups
Link to Us
Security Center
Book Reviews
Security Dictionary
Security Tips
White Papers
Featured Blogs
All About Linux
DanWalsh LiveJournal
Latest Newsletters
Linux Security Week: March 23rd, 2015
Linux Advisory Watch: March 20th, 2015
LinuxSecurity Newsletters
Choose Lists:
About our Newsletters
RSS Feeds
Get the LinuxSecurity news you want faster with RSS
Powered By

LDAP backends, objects and attributes

1.3. LDAP backends, objects and attributes

The LDAP server daemon is called Slapd. Slapd supports a variety of different database backends which you can use.

They include the primary choice BDB, a high-performance transactional database backend; LDBM, a lightweight DBM based backend; SHELL, a backend interface to arbitrary shell scripts and PASSWD, a simple backend interface to the passwd(5) file.

BDB utilizes Sleepycat Berkeley DB 4. LDBM utilizes either Berkeley DB or GDBM.

BDB transactional backend is suited for multi-user read/write database access, with any mix of read and write operations. BDB is used in applications that require:

  • Transactions, including making multiple changes to the database atomically and rolling back uncommitted changes when necessary.

  • Ability to recover from systems crashes and hardware failures without losing any committed transactions.

In this document I assume that you choose the BDB database.

To import and export directory information between LDAP-based directory servers, or to describe a set of changes which are to be applied to a directory, the file format known as LDIF, for LDAP Data Interchange Format, is typically used. A LDIF file stores information in object-oriented hierarchies of entries. The LDAP software package you're going to get comes with an utility to convert LDIF files to the BDB format

A common LDIF file looks like this:

dn: o=TUDelft, c=NL
o: TUDelft
objectclass: organization
dn: cn=Luiz Malere, o=TUDelft, c=NL
cn: Luiz Malere
sn: Malere
objectclass: person

As you can see each entry is uniquely identified by a distinguished name, or DN. The DN consists of the name of the entry plus a path of names tracing the entry back to the top of the directory hierarchy (just like a tree).

In LDAP, an object class defines the collection of attributes that can be used to define an entry. The LDAP standard provides these basic types of object classes:

  • Groups in the directory, including unordered lists of individual objects or groups of objects.

  • Locations, such as the country name and description.

  • Organizations in the directory.

  • People in the directory.

An entry can belong to more than one object class. For example, the entry for a person is defined by the person object class, but may also be defined by attributes in the inetOrgPerson, groupOfNames, and organization objectclasses. The server's object class structure (it's schema) determines the total list of required and allowed attributes for a particular entry.

Directory data is represented as attribute-value pairs. Any specific piece of information is associated with a descriptive attribute.

For instance, the commonName, or cn, attribute is used to store a person's name . A person named Jonas Salk can be represented in the directory as

cn: Jonas Salk

Each person entered in the directory is defined by the collection of attributes in the person object class. Other attributes used to define this entry could include:

givenname: Jonas
surname: Salk

Required attributes include the attributes that must be present in entries using the object class. All entries require the objectClass attribute, which lists the object classes to which an entry belongs.

Allowed attributes include the attributes that may be present in entries using the object class. For example, in the person object class, the cn and sn attributes are required. The description, telephoneNumber, seeAlso, and userpassword attributes are allowed but are not required.

Each attribute has a corresponding syntax definition. The syntax definition describes the type of information provided by the attribute, for instance:

  • bin binary.

  • ces case exact string (case must match during comparisons).

  • cis case ignore string (case is ignored during comparisons).

  • tel telephone number string (like cis but blanks and dashes `- ' are ignored during comparisons).

  • dn distinguished name.

Note: Usually objectclass and attribute definitions reside on schema files, on the subdirectory schema under the OpenLDAP installation home.



Latest Features
Peter Smith Releases Linux Network Security Online
Securing a Linux Web Server
Password guessing with Medusa 2.0
Password guessing as an attack vector
Squid and Digest Authentication
Squid and Basic Authentication
Demystifying the Chinese Hacking Industry: Earning 6 Million a Night
Free Online security course (LearnSIA) - A Call for Help
What You Need to Know About Linux Rootkits
Review: A Practical Guide to Fedora and Red Hat Enterprise Linux - Fifth Edition
Yesterday's Edition
OpenSSL Mystery Patch is No Heartbleed
Study: One-third of top websites vulnerable or hacked
Threat-sharing cybersecurity bill unveiled
Partner Sponsor

Community | HOWTOs | Blogs | Features | Book Reviews | Networking
 Security Projects |  Latest News |  Newsletters |  SELinux |  Privacy |  Home
 Hardening |   About Us |   Advertise |   Legal Notice |   RSS |   Guardian Digital
(c)Copyright 2015 Guardian Digital, Inc. All rights reserved.