YoLinux LDIF Tutorial: slapd.conf LDIF - OpenLDAP V2.x


There are two versions of Open LDAP (V2 and the older V1.x) and the two are configured differently. This tutorial covers the configuration of the newer/current Open LDAP Version 2.x (Red Hat 7.x and later).

This example supports two domains and uses two databases (one for each domain) and uses multiple groups within an organization. The inetOrgPerson object class is used for address book entries, which is ideal for linking with e-mail clients such as Netscape Messenger.

Related YoLinux Tutorials:

°LDAP server configuration

°LDAP client authentication

°LDAP bind authentication

°Extending LDAP an schema

°LDAP schema for MS/Outlook

°AWebDap: LDAP web interface

°YoLinux Tutorials Index




Free Information Technology Magazines and Document Downloads
TradePub link image


   

    Bookmark and Share


Advertisements




Example:

  • slapd.conf:

    File: /etc/openldap/slapd.conf (RPM: openldap-2.x...)

        include         /etc/openldap/schema/core.schema                 - Required
        include         /etc/openldap/schema/cosine.schema               - Recomended: Cosine, Internet X.500
        include         /etc/openldap/schema/inetorgperson.schema        - Recomended
        #include         /etc/openldap/schema/nis.schema                 - NIS (Network Information Services), Sun NFS support.
        #include         /etc/openldap/schema/redhat/rfc822-MailMember.schema
        #include         /etc/openldap/schema/redhat/autofs.schema
        #include         /etc/openldap/schema/redhat/kerberosobject.schema
    
        # Specify first database
    
        database        ldbm                        - Define the database to be used by LDAP. Each database definition begins with a database statement.
                                                    [Tutorial Update]: This tutorial defines the use of ldbm. Many are now recomending the bdb database.
        suffix          "o=domain-name"             - Specify organization
                                                    [Tutorial Update]: Use only one suffix as of OpenLDAP 2.1.2.13. Previously two were defined in this example.
        rootdn          "cn=Manager,o=domain-name"  - LDAP Administrator login name
        rootpw          supersecretpw               - LDAP Administrator login password
        directory       /var/lib/ldap/domain-name   - Location of database files
        defaultaccess   read
        schemacheck     on                          - Leave on
        lastmod         on
        index   cn,sn,st                   pres,eq,sub
    
        # Specify other databases
    
        database        ldbm                        - Many now use bdb
        suffix          "o=domain-2"
    rootdn "cn=Admin-2,o=domain-2"
    rootpw supersecretpw-2
    directory /var/lib/ldap/domain-2 ... ..

    Alternate style:

       suffix          "dc=ldap,dc=domain-name,dc=org"
    Note: As of OpenLDAP 2.1.2.13, the default configuration will allow only one suffix to be defined for each bdb database. The C preprocessor directive #define BDB_MULTIPLE_SUFFIXES (file: servers/slapd/back-bdb/init.c) may be used if you want to compile in multiple suffix support. If you use it, subtree indexing will slow down by factor of 2. The use of suffixAlias is no longer supported by default in version 2.1.13.

    Directives:

    Global Directives Argument
    argsfile filename
    (Full path of filename with slapd command line arguments)
    defaultsearchbase dn
    (Default base to use when client submits a non-base search)
    defaultaccess none
    auth
    compare
    search
    read (default)
    write
    access to <what> [ by <who> <accesslevel> <control> ]+
    disallow none (default)
    bind_v2
    bind_anon
    bind_anon_cred
    bind_anon_dn
    bind_simple
    bind_krbv4
    tls_authc
    idletimeout number-of-seconds
    (Deafault 0 disables this feature)
    timelimit Max-seconds-to-spend-on-search
    (Default 3600)
    sizelimit Max-number-of-items-to-return-from-search
    (Default 500 entries)
    include name-of-file
    loglevel -1 (enable all debugging LOG_LOCAL4)
    0 (no debugging)
    1 (trace function calls)
    2 (debug packet handling)
    4 (heavy trace debugging)
    8 (connection management)
    16 (print out packets sent and received )
    32 (search filter processing )
    64 (configuration file processing )
    128 (access control list processing)
    256 (LDAP Default: stats log connections/operations/results)
    512 (stats log entries sent)
    1024 (print communication with shell backends)
    2048 (print entry parsing debugging)
    referal URL of LDAP server
    password-hash {SSHA} (default)
    {SHA}
    {SMD5}
    {MD5}
    {CRYPT}
    User password hash. See:OpenLDAP password FAQ
    schemacheck on (default)
    off
    objectclass ( <oid> NAME name DESC description ... )
    OpenLDAP V2.0 uses LDAPv3 syntax. See RFC 2252 (Attribute Syntax Definitions: See sections 4.4, 7)
    or
    list of objectclasses
    attributetype See list of attributes in RFC 2252 (Attribute Syntax Definitions. See sections 4.2, 5)
    or
    list of attributes

    Global directives apply to everything globally including backend databases.

    General Backend Directives Argument
    database ldbm (Berkeley or GNU DBM compatible backend database)
    shell (External program used for backend database)
    passwd (See: OpenLDAP.org /etc/passwd backend FAQ)
    sql
    (Marks the beginning of a new database instance definition and directives)
    lastmod on (default)
    off
    readonly on
    off (default)
    replica host=hostname...
    (Requires slurpd)
    replog filename
    (Used in conjuction with slurpd)
    rootdn dn
    (Identify the LDAP entry for the privileged Sysadmin for this database)
    rootpw password-for-rootdn
    {crypt}ijFYNcSNctBYg
    (Plain or encrypted)
    suffix dn suffix
    (Root of LDAP tree for this database definition. Typically the domain. i.e. dc=your-domain,dc=com)
    updatedn dn
    (Used for a slave server in conjunction with slurpd)
    updateref URL
    (Used in conjunction with slurpd and database replication)

    Backend directives are specific to the database (backend) used.

    LDBM Specific Backend Directives Argument
    cachesize integer
    (Default 1000 entries)
    dbcachesize integer
    (Default 100000K)
    dbnolocking no arguments used by this directive
    directory Unix-directory-path
    (Red Hat Default: /var/lib/ldap)
    index
    directive Comparason-operation
    default
    attribute
    object,attribute
    pres
    eq (equal)
    approx
    sub (substring)
    subinitial
    subany
    subfinal
    mode integer
    (Default: 0600)

    Notes:

    • For a full list of directives see:
    • [Potential Pitfall]: Beware of the defaults used. If your are running a large database of more than 500 entries you MUST set values such as sizelimit to larger values.
    • This file contains the LDAP admin password thus this file should NOT be world readable!! Note that Red Hat 7.x/8.0 with Open LDAP 2.x used the user id "ldap" under which to run the slapd daemon. Thus this file should be owned and readable by user "ldap".
    • If adding "Object Classes" or "Data Attributes" add your own includes. You can also add new definitions directly to the end of this file (slapd.conf).
    • If a line begins with a white space, it is considered a continuation of the previous line.
    • Alternate style: directory /var/lib/ldap/your-domain.org
      If you are supporting multiple domains you may want to place the databases in a unique directory.
    • A blank space separates the directive and the argument. If blanks are part of the argument, then the argument is defined in quotes.
    • This tutorial did not cover the use of Transport Layer Security, (TLS) directives as e-mail clients do not support these advanced features yet. These features enable the use of SSL, keys and certificates.

  • Object Class Definitions: List of Objectclasses

    The simplest LDAP configurations uses a pre-existing object class, typically inetOrgPerson. This object inherits and thus includes the data attributes from the object organizationalPerson which in turn inherits from the person object. See RFC 2798 for the definition of inetOrgPerson. It is a BAD idea to edit/modify a pre-defined object definition.

    Create a new custom object by extending the inetOrgPerson schema - YoLinux TUTORIAL

    Note: If using a pre-defined object and you are NOT defining a new custom object, then this section is NOT relevant!

  • Attribute Definitions: List of LDAP attributes
    These definitions reside at the end of the slapd.conf or in include files of their own. Note that the attributes are defined before being used in object definitions.

    Create a new custom object by extending the inetOrgPerson schema - YoLinux TUTORIAL

    Note: If using a pre-defined object or a new object which uses existing attribute definitions, then this is NOT necessary. You will NOT have to define a new attribute and thus this section will NOT be relevant!

    Partial List of data types used as attributes: (full list in RFC 2252 or see OIDs)

    Name OID
    Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3
    audio 1.3.6.1.4.1.1466.115.121.1.5
    binary (BER/DER data) 1.3.6.1.4.1.1466.115.121.1.5
    boolean 1.3.6.1.4.1.1466.115.121.1.7
    Country String 1.3.6.1.4.1.1466.115.121.1.11
    distinguishedName (DN) 1.3.6.1.4.1.1466.115.121.1.12
    directoryString (UTF-8 string) 1.3.6.1.4.1.1466.115.121.1.15
    Fax Telephone Number 1.3.6.1.4.1.1466.115.121.1.22
    IA5String (ASCII) 1.3.6.1.4.1.1466.115.121.1.26
    Integer 1.3.6.1.4.1.1466.115.121.1.27
    JPEG 1.3.6.1.4.1.1466.115.121.1.28
    Name and Optional UID (DN plus UID) 1.3.6.1.4.1.1466.115.121.1.34
    Numeric String 1.3.6.1.4.1.1466.115.121.1.36
    OID (object identifier) 1.3.6.1.4.1.1466.115.121.1.38
    Octet String 1.3.6.1.4.1.1466.115.121.1.40
    Postal Address 1.3.6.1.4.1.1466.115.121.1.41
    Printable String 1.3.6.1.4.1.1466.115.121.1.44
    Telephone Number 1.3.6.1.4.1.1466.115.121.1.50
    LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54
    LDAP Schema Definition 1.3.6.1.4.1.1466.115.121.1.56
    LDAP Schema Description 1.3.6.1.4.1.1466.115.121.1.57

  • LDIF file: Defining Data for the LDAP database: domain-name.ldif

    This example uses the object class inetOrgPerson which is ideal for use with address books in e-mail clients.
        dn: dc=ldap,dc=domain-name,dc=org    - First define the LDAP domain
        objectClass: top
        objectClass: dcObject
        objectClass: organization
        dc: domain-name
        o: domain-name
        description: Full Company Name Domain

    dn: o=domain-name - Define the LDAP root objectClass: top objectClass: organization o: domain-name description: Full Company Name dn: cn=AdminManager,o=domain-name - Data entries for the system administrator for the domain as defined in the file: slapd.conf objectClass: organizationalRole cn: AdminManager description: LDAP Directory Administrator dn: ou=MemberGroupA,o=domain-name ou: MemberGroupA - Use name of your group or department objectClass: top objectClass: organizationalUnit description: Members of MemberGroupA dn: ou=MemberGroupB,o=domain-name ou: MemberGroupB objectClass: top objectClass: organizationalUnit description: Members of MemberGroupB dn: cn=Larry Anderson,ou=MemberGroupA,o=domain-name cn: Larry Anderson - Yes it is mentioned in the dn statement but it is repeated here objectClass: top These objectclass statements MUST go here for Open LDAP objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson mail: LAnderson@isp.com givenname: Larry sn: Anderson ou: MemberGroupA - Yes it is mentioned in the dn statement but it is repeated here street: 14 Cherry St. l: Dallas st: TX postalCode: 76888 telephoneNumber: (800)555-1212 homephone: 800-555-1313 facsimileTelephoneNumber: 800-555-1414 seeAlso: http://www.domain-name.org - slapadd freaks on the ":" and I could not add this entry so DO NOT ADD THIS LINE!!! # JPEG photo from file jpegPhoto:< file:///path/to/file.jpeg - I did not try this yet. dn: cn=Moe Anderson,ou=MemberGroupA,o=domain-name cn: Moe Anderson - cn is required by definition of person object sn: Anderson - sn is required by definition of person object objectClass: top - All three objectclass statements are required. top is required by definition of person object objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson mail: MAnderson@isp.com givenname: Moe ou: MemberGroupA street: 15 Cherry St. l: Dallas st: TX postalcode: 76888 pager: 800-555-1319 homePhone: 800-555-1313 mobile: 800-555-1318 dn: cn=Curley Anderson,ou=MemberGroupB,o=domain-name cn: Curley Anderson objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson mail: CAnderson@isp.com givenname: Curley sn: Anderson ou: MemberGroupB street: 16 Cherry St. l: Dallas st: TX postalcode: 76888 pager: 800-555-1319 homePhone: 800-555-1313 mobile: 800-555-1318

If creating a new attribute or object definition see:

If defining a new object or attribute you must apply for an object ID (OID) see:

OpenLDAP 2.x enhances LDAP but also restrains the LDAP administrator by formalizing the generation of a new object or attribute. You have to register for an OID branch in the OID heirarchy for your organization. Then you must assign internal OID's under your root heirarchy and define the object or attribute. The OpenLDAP documentation strongly suggests against making up a number. (OpenLDAP 1.2 does not use OID's). The OpenLDAP organization has reserved a subset of it's OID allocation for experimentation. This would be the OID's 1.3.6.1.4.1.4203.666.X.X. They have used some of them so check their site to avoid conflicts. (Where X.X = 1.1 to 1.5 are being used)


Using LDAP Address Directory with Netscape Messenger:

Use the following settings:

  • LDAP Server: localhost or the server's network name. i.e. ldap.domain-name.com
  • Server Root: o=domain-name
  • Port Number: 389 (Default LDAP port)

See: links to e-Mail client configuration tutorials for detailed information.

Note on searches: A search using the "Server Root" of o=domain-name allows the searches to include all groups (also called Organizational Units (ou)). If all searches are to be within your department, one can narrow the focus of the "Server Root". i.e. ou=GroupName,o=domain-name. Seaches will then be limited to the group.


LDAP V2.x Links:

OpenLDAP.org web site:

LDAP - Schema links:

Also see:
  • RFC 2256 - User Schema for use with LDAPv3
  • RFC 2252 - Attribute Syntax definitions
  • RFC 2247 - Using Domains in LDAP/X.500 Distinguished Names
  • RFC 2253 - UTF-8 String Representation of Distinguished Names

Return to YoLinux LDAP Tutorial

Copyright © 2000, 2001, 2003 by Greg Ippolito