End to end guide for writing a LDAP schema

Written by

LDAP has been protocol of choice for organizations who want to access information regarding their assets or people stored in their directory software. LDAP provides single sign-on feature which allows it's users to connect to the server once and then have access to all other services / information on the directory. LDAP have access control in form of ACL where roles and privileges of an user can be defined centrally. This allows LDAP to be used for authentication and authorization for virtually all internet services like VPN, SSH, SMTP, IMAP and workstation login.

To use LDAP effectively you might need to extend or create your own schema according to the need of your organization. An LDAP schema is a collection of attributes and objectClasses. Let's see what each of them means.

Schema element	Description
attribute	An attribute can be thought of as a placeholder for certain kind of data, like for example an email address. You may define it to be a string of characters or borrow it's definition from an already defined standard attribute. Attributes can be single valued i.e. they may not be repeated in an objectClass or multi-valued. Attributes also define whether it's data is searchable in a case sensitive or case insensitive manner or whether it should be an exact match or wildcard matches are possible.
objectClass	An objectClass is a collection of attributes to define an entity in the LDAP Directory Information Tree (DIT) like for example a printer. objectClasses may be structural or auxillary. An entity in the DIT must include one structural objectClass. Auxillary objectClass may be optionally included in an entity definition in the DIT. objectClasses also define which attributes are mandatory for the entity which includes the objectClass.

Schema element

Description

attribute

An attribute can be thought of as a placeholder for certain kind of data, like for example an email address. You may define it to be a string of characters or borrow it's definition from an already defined standard attribute. Attributes can be single valued i.e. they may not be repeated in an objectClass or multi-valued. Attributes also define whether it's data is searchable in a case sensitive or case insensitive manner or whether it should be an exact match or wildcard matches are possible.

objectClass

An objectClass is a collection of attributes to define an entity in the LDAP Directory Information Tree (DIT) like for example a printer. objectClasses may be structural or auxillary. An entity in the DIT must include one structural objectClass. Auxillary objectClass may be optionally included in an entity definition in the DIT. objectClasses also define which attributes are mandatory for the entity which includes the objectClass.

For you to define a new schema and load it in LDAP, you will need a number called the PEN or Private Enterprise Number. You may apply for a PEN using this link http://pen.iana.org/pen/PenApplication.page

PEN is necessary to define a new schema as all organizations who define their own schemas should have unique attributes and object classes and PEN helps to achieve the same. All attributes and object classes in LDAP are uniquely identified by an identifier called OID or object id. OID is written in hierarchial dotted decimal notation and PEN makes the OID unique for you. We will see with an example schema below.

#
# OID prefix: 1.3.6.1.4.1.<PEN>
#
# Attributes: 1.3.6.1.4.1.<PEN>.1.1
#

attributetype ( 1.3.6.1.4.1.<PEN>.1.1.1 NAME 'drupalUid'
    DESC 'User ID in Drupal CMS'
        EQUALITY integerMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.<PEN>.1.1.2 NAME 'drupalUsername'
        DESC 'Username in Drupal CMS'
        EQUALITY caseIgnoreIA5Match
        SUBSTR caseIgnoreIA5SubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{64} SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.<PEN>.1.1.3 NAME 'drupalRole'
        DESC 'User role as in Drupal CMS'
        EQUALITY caseIgnoreIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32} )

attributetype ( 1.3.6.1.4.1.<PEN>.1.1.4 NAME 'drupalStatus'
        DESC 'User status as in Drupal CMS'
        EQUALITY caseIgnoreIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{24} )

attributetype ( 1.3.6.1.4.1.<PEN>.1.1.5 NAME 'drupalEmail'
        DESC 'User email address as in Drupal CMS'
        SUP mail )

attributetype ( 1.3.6.1.4.1.<PEN>.1.1.6 NAME 'drupalGivenName'
        DESC 'User first name as in Drupal CMS'
        SUP givenName )

attributetype ( 1.3.6.1.4.1.<PEN>.1.1.7 NAME 'drupalSurname'
        DESC 'User surname as in Drupal CMS'
        SUP surname )

#
#
# Objects: 1.3.6.1.4.1.<PEN>.1.2
#

objectclass ( 1.3.6.1.4.1.<PEN>.1.2.1 NAME 'DrupalUser'
DESC 'Entry for Drupal CMS user attributes'
SUP top STRUCTURAL
MUST ( drupalUid $ drupalUsername $ drupalRole $ drupalStatus $ drupalEmail ) )

objectclass ( 1.3.6.1.4.1.<PEN>.1.2.2 NAME 'DrupalUserExtra'
DESC 'Extended attributes for Drupal user'
SUP top AUXILIARY
MAY ( drupalGivenName $ drupalSurname ) )

You may refer to OpenLDAP documentation for writing a schema using the folllowing link - http://www.openldap.org/doc/admin22/schema.html

I hope this will get you started to write your first own LDAP schema and learn more about it's use cases and benefits.

Credits and attributions

Photo credit - https://upload.wikimedia.org/wikipedia/commons/thumb/7/71/Database-openl...

Tags: