LDAP-mini-HOWTO

1.1 Feedback

PLEASE REPORT ANY INACCURACIES IN THIS PAPER!!! I am human, and prone to making mistakes. If you find any, fixing them is of my highest interest. I will try to answer all e-mail, but I am busy, so don't get insulted if I don't.

My email address is mark at grennan dot com

1.2 Disclaimer

I AM NOT RESPONSIBLE FOR ANY DAMAGES INCURRED DUE TO ACTIONS TAKEN BASED ON THIS DOCUMENT. This document is meant as an introduction to how LDAP servers work. I am not, nor do I pretend to be, a expert. I am just some guy who has read to much and likes computers more than most people.  Please, I am writing this to help get people acquainted with this subject, and I am not ready to stake my life on the accuracy of what is in here.

1.3 Copyright

Unless otherwise stated, Linux HOWTO documents are copyrighted by their respective authors. Linux HOWTO documents may be reproduced and distributed in whole or in part, in any medium physical or electronic, as long as this copyright notice is retained on all copies. Commercial redistribution is allowed and encouraged; however, the author would like to be notified of any such distributions.

All translations, derivative works, or aggregate works incorporating any Linux HOWTO documents must be covered under this copyright notice. That is, you may not produce a derivative work from a HOWTO and impose additional restrictions on its distribution. Exceptions to these rules may be granted under certain conditions; please contact the Linux HOWTO coordinator.

In short, we wish to promote dissemination of this information through as many channels as possible. However, we do wish to retain copyright on the HOWTO documents, and would like to be notified of any plans to redistribute the HOWTOs.

If you have any questions, please contact Mark Grennan at Grennan dot Com.

1.4 My Reasons for Writing This

Someone needed to. This LDAP is great, very confusing and I can't find a good book on it at the local Barns & Nobel.

Also, if I don't write it down, I forget.  The last time I updated this howto it was because I needed to setup another LDAP and I was having trouble, as usual.  While I was digging through the OpenLsap.org web site I came across a HOWTO and noticed my name.?  I woundered how the website know it was me doing the search.  It didn't.  The link I found took me to my own website. I had not remembered I had written this.

1.5 TODO

Describe LDAP secutiry.
Describe how to replicate between servers.
Rewrite this document into the statandard SGML format.
Describe how to create a Meda-LDAP.

1.6 What is it?

LDAP (the Lightweight Directory Access Protocol)

A directory is a listing of information about objects arranged in some order that gives details about each object. Common examples are a city telephone directory and a library card catalog.

In computer terms, a directory is a specialized database, also called a data repository, that stores typed and ordered information about objects. Directories allow users or applications to find resources that have the characteristics needed for a particular task. For example, a directory of users can be used to look up a person's e-mail address or fax number. A directory could be searched to find a nearby PostScript color printer. Or a directory of application servers could be searched to find a server that can access customer billing information.
 
 

1.7 Why are you Interested?

LDAP is the newest protocol to attempt to centralize all of our directory e.g. employee information, network information, etc.) into a central open protocol. While others have come before it (NIS/NIS+,NDS, X.500), LDAP does seem to be poised to be the solution we have been looking for.

LDAP is becoming the repository of, Phone/Email Lists (ldap.yahoo.com), multi system logons (a replacement to YP and NIS), The Windows Registory in NT 5.0, and user's roming profiles (Active Badges).

LDAP had a low profile for a long time. The creation of Tim House and a team at the University of Michigan, it answered 5 million hits per day but remained a YAFLAEIP -- yet another four letter acronym ending in P. Worse, it was a subset of X.500, which is one of the most complex and impenetrable sets of specs ever produced by a standards body. When I visited the LDAP web site yesterday, its root level page showed only 146 hits since it was set up in December 1995.
 
 

1.8 Where did it come from?

In the 1970s, the integration of communications and computing technologies led to the development of new communication technologies. Many of the proprietary systems that were developed were incompatible with other systems. It became apparent that standards were needed to allow equipment and systems from different vendors to interoperate. Two independent major standardizations efforts developed to define such standards.

By 1988 the X.500 standard was created. X.500 organizes directory entries in a hierarchal name space capable of supporting large amounts of information. X.500 specifies that communication between the directory client and the directory server uses the directory access protocol (DAP). However, as an application layer protocol, the DAP requires the entire OSI protocol stack to operate. Supporting the OSI protocol stack requires more resources than are available in many small environments. Therefore, an interface to an X.500 directory server using a less resource-intensive or lightweight protocol was desired.

LDAP requires the lighter weight and more popular TCP/IP protocol stack rather than the OSI protocol stack. LDAP also simplifies some X.500 operations and omits some esoteric features.

Two precursors to LDAP appeared as RFCs issued by the IETF, Directory Assistance Service (RFC 1202) and DIXIE Protocol Specification (RFC 1249). These were both informational RFCs which were not proposed as standards. The directory assistance service (DAS) defined a method by which a directory client could communicate to a proxy on a OSI-capable host which issued X.500 requests on the client's behalf. DIXIE is similar to DAS, but provides a more direct translation of the DAP.

The first version of LDAP was defined in X.500 Lightweight Access Protocol (RFC 1487), which was replaced by Lightweight Directory Access Protocol (RFC 1777). LDAP further refines the ideas and protocols of DAS and DIXIE. It is more implementation neutral and reduces the complexity of clients to encourage the deployment of directory-enabled applications. Much of the work on DIXIE and LDAP was carried out at the University of Michigan, which provides reference implementations of LDAP and maintains LDAP-related Web pages and mailing lists (see A.2 The University of Michigan (UMICH)).
 
 

1.9 Read more about it.

Linux Directory Service
    http://www.rage.net/ldap/

The SLAPD and SLURPD Administrators Guide
    http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/

OpenLDAP and FreeRadius
    http://vuksan.com/linux/dot1x/802-1x-LDAP.html

IBM - Understanding LDAP
    http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg244986.pdf

The Open Source for LDAP software and information
    http://www.openldap.org/

And More:
    http://www.kingsmountain.com/ldapRoadmap.shtml
    http://www.yolinux.com/TUTORIALS/LinuxTutorialLDAP.html

2. Installing LDAP
This document is very RedHat or CentOS specific. More to the point, I'm using Centos 5.2. But I'm not saying you have to. But if you use what I'm using you should have an LDAP server runn in within 30 minutes.

2.1 Is LDAP already loaded?
Depending on your installation selections, you may have some LDAP conponents loaded already.  You can check with the command:

rpm -qa | grep ldap

          

If it is installed you should see this list of installed applications.

openldap-servers-2.3.27-8.el5_2.4

openldap-2.3.27-8.el5_2.4

nss_ldap-253-13.el5_2.1

python-ldap-2.2.0-2.1

openldap-clients-2.3.27-8.el5_2.4

To install these use:

yum install openldap openldap-clients openldap-servers

2.2 Who are you?
The hardest thing to do may be to deside who you are and how you fit into the world.  This goes for LDAP too. What is your top level  descriptor? Your rootdn. Are you the only LDAP you will ever have?  Are you an o=  or a dc=?Don't ring your hands over this dission.  If you get it wrong it can be fixed.

There are two basic ways to go.  The simplest is to place your self in the world based on your Internet domain. In my case I am dc=grennan, dc=com (grennan.com).  You may be creating a department server for your orginazation so you may have an addional level.  If so just add another dc= to the list.

If you are creating your LDAP as a phone book or a email directory you may want to use and orginazational view like ou=personal,o=home4humanity.  Or, maybe you want a geographic view like ou=finance,o=goverment,st=Oklahoma,c=US.

You can build your own using:

l=    Location
ou=   Organisational Unit
o=    Organisation
dc=   Domain Component
st=   State
c=    Country

For the purpose of this document I am going to use dc=grennan,dc=com.

2.3 Edit the file /etc/openldap/slapd.conf
The only thing that must be edited are suffix, rootdn and the two rootpw lines.

Suffix is the high level descriptor you selected above.  The rootdn is who (the user) that owns the server and should start with cn=. The first root password (rootpw) line should be set to secret.  You can generate an encrypted password for the second rootpw line using the command:

slappasswd

Just cut and paste the output of the slappasswd command into the second rootpw line.

Here is an example of the RedHat slapd.conf:

# $OpenLDAP: pkg/ldap/servers/slapd/slapd.conf,v 1.8.8.7 2001/09/27 20:00:31 kurt Exp $
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema
include         /etc/openldap/schema/redhat/rfc822-MailMember.schema
include         /etc/openldap/schema/redhat/autofs.schema
include         /etc/openldap/schema/redhat/kerberosobject.schema

# Define global ACLs to disable default read access.
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
# referral       ldap://root.openldap.org

# It's nice to know what the running process ID is.
# the standard location to store this is /var/run
# You can use this in a number of ways like "kill 'cat /var/run/slapd.pid'"
pidfile         //var/run/slapd.pid
argsfile        //var/run/slapd.args

#Create a replication log in /var/lib/ldap for use by slurpd.
#replogfile     /var/lib/ldap/master-slapd.replog

# Load dynamic backend modules:
# modulepath    /usr/sbin/openldap
# moduleload    back_ldap.la
# moduleload    back_ldbm.la
# moduleload    back_passwd.la/
# moduleload    back_shell.la
#
# The next two lines allow use of TLS for connections using a dummy test
# certificate, but you should generate a proper certificate by changing to
# /usr/share/ssl/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it.
# TLSCertificateFile /usr/share/ssl/certs/slapd.pem
# TLSCertificateKeyFile /usr/share/ssl/certs/slapd.pem
#
# Sample Access Control
#       Allow read access of root DSE
#       Allow self write access
#       Allow authenticated users read access
#       Allow anonymous users to authenticate
#
#access to dn="" by * read
#access to *
#       by self write
#       by users read
#       by anonymous auth
#
#
# if no access controls are present, the default is:
#       Allow read by all
#
# rootdn can always write!

#######################################################################
# ldbm database definitions
#######################################################################

database        ldbm
suffix          "dc=grennan,dc=com"
#suffix         "o=My Organization Name,c=US"
rootdn          "cn=Manager,dc=grennan,dc=com"
#rootdn         "cn=Manager,o=My Organization Name,c=US"
# Cleartext passwords, especially for the rootdn, should
# be avoided.  See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw          secret
rootpw          {SSHA}MRNBda83kd9f7d7did902mLA1x0AVOWMRBua
# The database directory MUST exist prior to running slapd AND 
# should only be accessible by the slapd/tools. Mode 700 recommended.
directory       /var/lib/ldap
# Indices to maintain
index   objectClass,uid,uidNumber,gidNumber,memberUid   eq
index   cn,mail,surname,givenname                       eq,subinitial
# Replicas to which we should propagate changes
#replica host=ldap-1.example.com:389 tls=yes
#       bindmethod=sasl saslmech=GSSAPI
#       authcId=host/ldap-master.example.com@EXAMPLE.COM
          

2.4 Edit the file /etc/openldap/ldap.conf
This file is very simple. Just add the IP of your server (the localhost in this case) and the your 'Base' suffix.

# $OpenLDAP: pkg/ldap/libraries/libldap/ldap.conf,v 1.4.8.6 2000/09/05 17:54:38 kurt Exp $
#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

#BASE    dc=example, dc=com
#URI    ldap://ldap.example.com ldap://ldap-master.example.com:666

#SIZELIMIT    12
#TIMELIMIT    15
#DEREF        never
HOST 127.0.0.1
BASE dc=grennan,dc=com

2.4 START THE SERVER
The name of the ldap deamon is slapd. If you are using a ldap package that came with your distro, you should have a startup script in /etc/rc.d/init.d (RedHat), that you can use to start LDAP. If not, you can start it with:

service ldap start

3.0 LDAP Migration tools

PADL Software Ltd. has a collection of tools, written in Perl, that you can use to convert configuration files to the LDIF format. If you are planning to use your LDAP server to authenticate users you want these tools.

RedHat includes these tools with RedHat 9.0. These tools are located in /usr/share/openldap/migration. If you don't find them in your distribution you can download these tools from:

    http://www.padl.com/OSS/MigrationTools.html

Install is simple.

untar zxf  MigrationTools.tgz
cd MigrationTools-44

You then must edit migrate_common.ph and change the following site-specific variables to reflect your installation:

# Default DNS domain
$DEFAULT_MAIL_DOMAIN = "grennan.com";

# Default base 
$DEFAULT_BASE = "dc=grennan,dc=com

4.0 Create a data file (YourOrg.ldif) 
Now we need to add the base entries into the LDAP.  Here is an example of a new base org. units you may need and a user new user.  The file we will create in out example is grennan.com.ldif.

dn: dc=grennan,dc=com
objectclass: top
objectclass: organization
o: grennan
description: Top level LDAP for Grennan.com
dn: ou=Group,dc=grennan,dc=com
ou: Group
objectClass: top
objectClass: organizationalUnit

dn: ou=People,dc=grennan,dc=com
ou: People
objectClass: top
objectClass: organizationalUnit

dn: ou=Services,dc=grennan,dc=com
ou: Services
objectClass: top
objectClass: organizationalUnit

/usr/share/openldap/migration/migrate_base.pl > base.ldif

If your orginization has more levels your suffix may contain more levels at the root. Maybe you need some thing like doc.gnu.grennan.com. However, migrate_base.pl starts its first entry two levels deep (grennan.com). When you try to ldapadd this file, it gives an error ("ldap_add: No such object") because grennan.com does not yet exist.

You can fix this by simply removed the first two entries of the output (grennan.com and gnu.grennan.com), which makes the first entry the same as my root (doc.gnu.grennan.com). You can then successfully run the ldapadd command as you described.

4.1 Importing the first records
Now we need to import the ldif file we just created. If your ldap server is not running, start it.  Then run this command to import your ldif file. Here is an example.

ldapadd -a -W -x -D "cn=Manager,dc=grennan,dc=com" -f base.ldif

If everything goes well you will simply get back a command prompt.

4.2 Dumping the all the LDAP data
To test the server we can list the entire contents. The program to do this is ldapsearch.  We pass it our base orginazation and something to search for. Every LDAP record has an object class assocated with it so we can ask for all object classes to get all records.

ldapsearch -x -b 'dc=grennan,dc=com' 'objectclass=*'

5.0 Using the Server

5.1 Create a test record
Create a file name newrec.ldif and create the needed fields.

# Garrett Barnett, < style="font-weight: bold;">grennan, com
dn: uid=gman,ou=People,dc=grennan,dc=com
cn: Garrett Barnett
sn: Barnett
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
userPassword: {crypt}$!Z0ksiAKjsKLAsjuwyuAK!jksX
uid: gman
uidNumber: 501
gidNumber: 501
loginShell: /bin/bash
homeDirectory: /home/gman
shadowLastChange: 10877
shadowMin: 0
shadowMax: 999999
shadowInactive: -1
shadowWarning: 7
shadowFlag: 0
shadowExpire: -1

5.2 Add the record to your LDAP
To add a record to the ldap database we use the command ldapadd.

ldapadd -W -x -D "cn=Manager,dc=grennan,dc=com" -W -f newrec.ldif

ldapsearch -x -b 'cn=Garrett Barnett,dc=grennan,dc=com'

Put some text here about how to modify a record

5.5 Delete the test record
Now you have a record you need to delete. This command should do the trick.

ldapdelete -W -x -D 'cn=Manager,dc=grennan,dc=com''cn=Garrett Barnett,dc=grennan,dc=com'

6.0 Securing your LDAP
First, if you havn't added an encrypted password to the /etc/openldap/slapd.conf file yet, do it now.

6.1 Migrating /etc/passwd and /etc/group

These tools are very simple to use. After you have installed them

/usr/share/openldap/migration/migrate_passwd.pl /etc/passwd > passwd.ldif

ldapadd -W -x -D "cn=Manager,dc=grennan,dc=com" -f passwd.ldif

/usr/share/openldap/migration/migrate_group.pl /etc/group > group.ldif

ldapadd -W -x -D "cn=Manager,dc=grennan,dc=com" -f group.ldif

7.0 Graphical tools

There are lots of GUI tools you can use. Kldap (http://www.mountpoint.ch/oliver/kldap/), KDirAdm (http://www.carillonis.com/kdiradm/), Directory Administrator (http://diradmin.open-it.org/index.php) and GQ (http://biot.com/gq/) are all good tools.  But the best tools is:

LDAP Browser/Editor: This tools is fantastic.  Browser/Editor  provides  a  user-friendly Windows Explorer-like interface to LDAP directories with tightly integrated browsing  and  editing capabilities. It is entirely written in Java with the help of the JFC (SwingSet) and JNDI class libraries. It connects to LDAP v2 and v3 servers.

You will LDAP Browser/Editor requires Java version 1.2.2 or greater.

    http://www-unix.mcs.anl.gov/~gawor/ldap

After you have unpacked the archive, you need to either edit the lbe.sh file to set $JAVA_HOME=/path, or you need to set JAVA_HOME as an shell inverment veriable.  Then you can run ./lbe.sh to start the Browser/Editor.

7.0 Implementing LDAP

Roel van Meer has a great HOWTO on LDAP implementations.  It covers all the common uses.In this section I will cover only the simplist.

7.1 Linux user authinication

User authentication is the most common use for an LDAP server.  RedHat 7.0 or later provides a very usefull command named authconfig and authconfig-gtk (a GUI version) to connect to a LDAP server. Simply run the command and mark the box labelled 'Use LDAP'.  Then enter the IP address of your LDAP server along with the Base DN.

To test this, create a user in your LDAP directory that is not in your /etc/passwd file.  Then check the account by fingering the user.  For example, if you add the test record for section 3.1 you should be able to essue the command:

finger gman

and get back a response.

8.0 Windows user authinication
Sorry, at this time you can not get a user, logging into a windows server, to authinicate with a LDAP server.  Microsoft has a server call "Active Directory" which can talk LDAP.  However it is not very robust for anything but a NT/2000 system. It is good for use in a windows domain but not for an enterprise.  It is good enuff to authinicate Linux users however.  Maybe in the next release of this document I will write this up.

3.5 Listing what you want

As of Netscape Communicator 4.5 you can use your broswer to communicate with an LDAP server. The syntax is:
ldap[s]://<hostname<:port>/<base_dn>?<attributes>?<scope>?<Filter>

• [s] represends a secure (ssl) connection 
• <Hostname> is the name (Or IP address) of the LDAP server you wish to connect to.
• <Port> is the port number the server is running on. The default port number is 389 for non secure servers and 636 for secure servers.
• <base_dn> is the distinguished name (DN) of the entry in the directory. This DN indentifies the entry that is to be the starting point of the search. If this is enmpty (ldap://<hostname>/) the search will start at the root of the tree. This will return to you some valuble information including the namingcontexts and the subschemasubentry.
• If you then use the nameingcontexts and the base_dn (ldap://<hostname>/<nameingcontexts>) you should be able to see the access control structure (aci). by using the subschemasubentry as the base_dn you can see the complete schema.
  
• <attributes> is a list of the "fields" you need returned. if no attributes are entered every field will be returned. For example ldap://<hostname>/<nameingcontexts>?cn,mail?sub? will return the name and email address of every record.
• <scope> controls the level of the search. It can have one of three key workds. (base, one, and sub) base retrieves information only about the DN <base_dn> specified in the URL.one retrieves information about entries one level delow the DN given in the URL. The base entry is not included in this scope.
  sub retrieves entries at all levels below the DN given in the URL. The base entry is included in the scope.
  
• <filter> filters the entries within the scope to records with matching attributes. 

• space %20
• < %3c
• > %3e
• " %22
• # %23
• % %25
• { %7b
• } %7d
• | %7c
• \ %5c
• ^ %5e
• ~ %7e
• [ %5b
• ] %5d
• ' %60

Wild cards and logical operators can be used to better filter the records.
Operators are:

• Equality = 
• Substring =<string>*<string>
• Greater than or equal >=
• Less then or equal <=
• Presence =*
• Approximate ~=

Boolean Operators are:

• AND (&(filer)(filter))
• OR (|(filter)(filter))
• NOT (!(filter)(filter))

3.6 EXAMPLES of USING LDAP: URLs
Here are a few examples.  For this example we will use a fictisus server at ldap.qrz.net. Our Orginazation will be "grennan.com,c=US".
 

ldap://ldap.qrz.net/o=grennan.com,c=US??sub?
This will return severs every record in the database.
 

ldap://ldap.qrz.net/o=grennan.com,c=US?cn,mail?sub?
This will return only the objects (persons) name and email address for every person in the database.
 

ldap://ldap.qrz.net/o=grennan.com,c=US??sub?(cn=Mark%20Grennan)
Will return only Mark Grennan's records. ;-)

ldap://ldap.qrz.net/o=grennan.com,c=US??sub?(cn=Mark*)
Will give you veryone who's name starts with Mark.

ldap://ldap.qrz.net/o=grennan.com,c=US??sub?(&(cn=Mark*)(sn=G*))
Will give you veryone who's name starts with Mark and their surname starts with G.
 

ldap://ldap.qrz.net/o=grennan.com,c=US??sub?(&(cn=Mark*)(!(sn=G*)))
This will give you every record with a common name that starts with Mark but does NOT have a sur-name that starts with G
 

4. Directory Schemas
Entries in the directory are made up of a collection of attributes and their associated values. Attributes may have one or multiple values. In order to identify a particular value in an entry, the attribute type name is specified along with the value, as in "cn=John Doe". This is referred to as an attribute:value pair.

Every entry contains an objectClass attribute that identifies what type of information the entry contains. In fact, the object class dictates which other attributes may be present in an entry. The directory schema defines the valid attribute types and object classes that may appear in the directory. Attribute type definitions define the maximum length and syntax of its values. Object class definitions specify which attributes MUST be present in an object of that class, as well as attributes that may be present. The standard schema definitions included with this product are listed at the end of this guide.

The schema files are installed in the /etc directory as:
 

/etc/slapd.oc.conf
/etc/slapd.oc.system
/etc/slapd.at.conf
/etc.slapd.at.system

To customize the schema, based on the type of data you wish to store in your directory, you may edit the slapd.oc.conf and slapd.at.conf files to add object class or attribute type definitions. The existing schema definitions in these two files may be modified prior to loading data into the directory. When data has been loaded into the directory, no modifications to these definitions are allowed, however, additions can still be made.
The server must be recycled before any changes to the schema take affect.

Be sure to update any replica's slapd.* files, and recycle their servers before adding data. If you don't, replication will fail. Altering the standard schema definition is not advisable since it may reduce the portability or interoperability of client applications.

slapd file format

Any line that begins with a '#" is ignored. Blank lines are also ignored.
A line that beigns with a space or a tab is considered a continuation of theprevious line. A line that begins with "include" is processed as an include line. An include line has the syntax:

include <filename>

When an include line is encountered, text from the given <filename> is logically inserted in the location of the include line. An included file may include more files. For example:

include /etc/slapd.at.Megacorp

Attribute Type Definitions

Valid attribute types are defined in the slapd configuration files. As installed, all attribute definitions appear in the slapd.at.conf and slapd.at.system files found in /etc. Definitions of attributes in the slapd.at.conf file may be modified prior to loading data into the directory. Additional definitions may be added at any time. Definitions may be added directly into slapd.at.conf, or may be contained in another file and included into slapd.at.conf.

Following is the syntax for attribute type definitions:

attribute <name> [<altname>...] <syntax> <columnname> <maxlength> <accessclass>

<name> is the name of the attribute. This is the name that is returned with the results of searches.

<altname> is an optional alternative name for the attribute that may be used interchangeably with <name> to specify the attribute in client requests. More than one <altname> can be specified.

<syntax> governs the content of and matching operations against the value of the attribute. It must be one of:
 

cis | caseignorestring

case ignore string, contains ascii printable characters, which are monocased prior to any comparisons during matching operations.

ces | caseexactstring

case exact string, contains ascii printable characters, which are compared "as is" during matching operations.

bin | binary

binary, contains any vinary values. This syntax is used for JPEG photo images, audio clips, X.509 certificates, and so on.

dn

distinguished name, values of these attributes should be distinguished names identifying other directory entries. The case of characters is ignored during comparisons.

tel | telephone

telephonenumber, values are identical to caseignorestring values except during matching operations, '-' and ' ' (space) characters are ignored. Note that parenthesis are not ignored, however.

<columnname> is a name of no more than 17 characters in length used as the name of the column in the db2 database table that holds the attribute's value.

<maxlength> is the maximum length (in bytes) that a value of the attribute may have. Attributes that might be commonly used in search filters should have <maxlength> set to 250 or less, to facilitate indexing of the values. The maximum possible values of all non-binary attributes is 32700. A binary attribute must be up to 200MB.

<accessclass> identifies the access class that the attribute belongs to. It must be one of the following; normal, sensitive, or critical. The accessclass sets the default access class for attributes created for this attribute type.

The slapd.at.conf file contains a standard set of LDAP attribute type definitions, which includes samples of all variations of this syntax.
 

4.1 Object Class Definitions

The slapd configuration files also define the object classess that are used in the directory. A standard set of LDAP object class definitions are located in the slapd.oc.conf and slapd.oc.system files. As with attribute definitions, the object class definitions in slapd.oc.conf may be modified prior to adding data to the directory. New object class definitions may be added at any time. These definitions may be added directly to the slapd.oc.conf file, or contained in a separate file, included from the existing configurations files as described above.

Following is the syntax for object class definitions:

objectclass <name> requires <attrlist> [allows <attrlist>]

where

<name> is the name of the object class.

<attrlist> is a comma-separated list of attribute names. Attribute names listed in the requires clause, must be present with any entry of this object class. An entry specifying this object class name that does not contain all of the required attributes, may not be added to the directory. An entry of this class may contain any attributes named in the allowed clause. Entries which specify this object class, but contain attributes other than those named as required or allowed may not be added to the directory. Every objectclass requires the objectClass attribute.

See the contents of the slapd.oc.conf file for examples of object class definitions.
 

5. TROUBLE SHOOTING

Are my instructions not clear.  If you find your self reading this part please send me email and tell me what your problem was/is.