Lightweight Directory Access Protocol LDAP

1
Lightweight Directory Access ProtocolLDAP

• Useful site/reference books for LDAP
• http//www.openldap.org
• Understanding and Deploying LDAP Directory
  Services, Tim Howes
• LDAP System Administration, Gerald Carter
• LDAP is an open, vendor-independent network
  protocol for accessing directory services.
  "lightweight" protocol is efficient and easy to
  use.
• LDAP enables central management of users, groups,
  devices and data, helps reduce the number of
  distinct, application-specific directories,
  hence, eases the administration works.

2
LDAP

• LDAP defines a message protocol used by directory
  clients and directory servers. The LDAP protocol
  uses different messages. For example, a bind
  request may be sent from the client to the LDAP
  server at the beginning of a connection. A search
  request is used to search for entry/entries in
  the directory.
• LDAP defines a standard method for accessing and
  updating information in a directory.
• LDAP defines a communication protocol it defines
  the transport and format of messages used by a
  client to access data in a directory.
• LDAP does not define the directory service itself.

3
LDAP Standards

• LDAP and X.500
• X.500 is an overall model for directory service.
  The Directory Access Protocol (DAP) of X.500 is a
  "heavyweight" protocol that operates over a full
  OSI protocol stack and requires a significant
  amount of computing resources.
• LDAP was originally developed as a front end for
  accessing X.500 directory service. LDAP is a
  lightweight protocol that runs directly over
  TCP/IP (port 389) and efficiently provides most
  of the functionality of DAP for Internet access.
• LDAP standards RFC1777, 2251, 3377, 4510-4519,
  etc.
• LDAP V3 extended LDAP V2 in various areas such
  as
• Referrals and Continuations A server that does
  not store the requested data can refer the client
  to another server.
• Simple Authentication and Security Layer (SASL).
• Internationalization with Unicode.
• Schema directory, extended operations, controls,
  etc.

4
LDAP applications

• Enterprises with distributed computer systems can
  use online directories for fast searches,
  cost-effective management of users and security,
  and a central integration point for multiple
  applications and services.
• Email system may use LDAP to look up addresses.
  LDAP can be used as a central authentication
  server. LDAP is used by many commercial
  directory systems.
• LDAP is useful for storing information that would
  be read from many locations, but updated
  infrequently. Typical information include email
  addresses, phone numbers, staff/customer/student
  data, etc.

5
Directory Systems

• Directory systems such as Novell eDirectory,
  Microsoft Active Directory and OpenLDAP, help
  administrators to manage systems and network
  resources.
• A directory system is like a database but there
  are differences, for examples,
• Read-to-write ratio of directories are much
  higher.
• The scale of data distribution in directory
  systems are much higher.
• Data synchronization (between replicas) in
  directory systems may be less stringent.
• Types of directory systems NOS based (e.g.
  Windows AD), application specific (e.g. Lotus
  Notes), open standard (e.g. OpenLDAP), global
  directory (e.g. DNS), etc.

6
Directory for managing resources

• Directory lets organizations store information in
  a hierarchical, object-oriented fashion.
  Directory uses objects (entries) to represent
  network resources such as users, groups,
  machines, devices, and applications.
• Directory uses containers to represent
  organizations or collections of related objects.
  Directory manages the relationships among objects
  and containers to provide a single, centralized,
  comprehensive view.
• This makes resources easier to find, manage, and
  use in a highly distributed network.
• By grouping related users and network resources
  objects in containers, administrators can easily
  apply different settings (such as access
  permissions) to different groups.
• Directory also lets administrators delegate
  specific administrative privileges and tasks to
  individual users.

7
LDAP Four Models

• Four models for the use of directory services
• LDAP Information model defines the kind of data
  in the directory
• LDAP Naming model defines the organization and
  reference to the directory data
• LDAP Functional model defines the way to access
  and update the data
• LDAP Security model defines the way to protect
  data from unauthorized access

8
LDAP Information Model

• LDAP information model defines the types of data
  and basic units of information that can be stored
  in the directory.
• The basic unit of information is the entry, a
  collection of information (attributes) about an
  object. Often, information in an entry describes
  a real-world object such as people, departments,
  servers, printers, etc..
• A set of attributes is stored in an entry.
• Each attribute has a type and one or more values.
  
• The type describes the kind of information
  contained.
• The value contains the actual data.
• Each entry contains information describing what
  it is or, to which object class it belongs
  called objectClass.

9
Relationship between Entries and Attributes
10
Attributes

• Each directory entry contains a collection of
  attribute types and values. Attributes hold
  specific data element such as a name and a phone
  number.
• cn common name
• sn surname

11
LDAP Naming Model

• LDAP naming model defines how to organize and
  refer data, i.e. how to refer to any particular
  directory entry within the directory structure.
  The design of a naming model is important for
  unique and unambiguous reference to an entry.
• A naming model is also referred to as Namespace
  and Directory Information Tree (DIT).

dccsa-snm dccom
ouServers
ouPeople
cnSales web server
ouSales
cnJohn Chan
12
LDAP Naming Model

• LDAP naming model specifies that entries are
  arranged in an inverted tree structure. LDAP
  names are backward relative to file system names
  
• Every node (entry/object) in an LDAP directory
  contains data (attributes).
• Some nodes can "contain" other nodes.
  Organizational Unit (OU) is an example of objects
  that can "contain" other objects.

dccsa-snm dccom
ouSales
ouEngineering
cnJohn Chan
cnKen Wong
13
LDAP Naming Model DN and RDN

• LDAP directory namespace is hierarchical, it has
  the concept of fully-qualified names called
  Distinguished Names (DNs).
• Each entry has a unique DN, such as,
• cnJohn Chan, ouEngineering, dccsa-snm,
  dccom.
• The DN of an entry helps identify the location of
  the entry in the directory tree.
• In any entrys DN, the leftmost component is
  called the Relative Distinguished Name (RDN),
  e.g. cnJohn Chan
• RDN of an entry must be unique among all its
  siblings.
• Alias entry an entry pointing to another entry.

14
LDAP Functional Model

• The Functional model describes operations that
  can be performed.
• Three groups of operations are defined in the
  functional model
• Interrogation operations - searching the
  directory and retrieve of data
• Update operations - add, delete, rename and
  modify entries
• Authentication and control operations - identify
  clients, controls in a session.
• In addition to the above operations, version 3 of
  the LDAP protocol defines the way to add extended
  operation.

15
LDAP Functional Model

• Two interrogation operations search operation
  and compare operation.
• Search operation is for searching the directory
  for entries and retrieve individual directory
  entries.
• Compare operation clients submits a compare
  request with a DN, an attribute name, and a
  value. The server returns positive or negative
  (true or false boolean) answer.
• Authentication and control operations
• Bind - a client authenticates itself to the
  directory.
• Unbind - to terminate a connection and all
  operations.
• Abandon - client issue an abandon request, with a
  message ID, to indicate which operation
  previously requested is no longer needed.

16
LDAP Search Operation

• Used to search for entries and retrieve them
• An LDAP search may takes eight parameters
  including
• DN of base object for search
• search scope
• search filter
• list of attributes to return
• Other parameters alias, size, time, boolean

17
LDAP Search Operation Search Scope

• A Sub-tree search scope covers the entire subtree
  from the search base.
• A One-level search scope covers the immediate
  next level from the search base.
• A Base search scope covers the search base only.

18
LDAP Filters

• A standard method for selecting relevant entries
  in a LDAP search operation. Detailed
  specifications are given in RFC 2254, 2251.
• Each filter is enclosed in parentheses. To
  combine filters, use or .

present attr "" substring attr ""
initial any final initial value any ""
( value "") final value attr
AttributeDescription from Section 4.1.5 of
RFC2251 value AttributeValue from Section
4.1.6 of RFC 2251
filter "(" filtercomp ")" filtercomp and / or
/ not / item and "" filterlist or ""
filterlist not "!" filter filterlist 1
filter item simple / present / substring simple
attr filtertype value filtertype equal /
approx / greater / less equal "" approx
"" greater "gt" less "lt"
19
LDAP Filter - example

• Return all entries in the scope of the search
  with attribute cn having the value "Albert"
• (cn Albert)
• Return all entries in the scope of the search
  which do not have the attribute cn with the value
  "Albert"
• (!(cn Albert))
• Return all entries in the scope of the search
  which have the attribute matching a combination
  of multiple filters, for example,
• (( snChan)((cnAlbert)(cnJohn)))

20
LDAP Add and Delete Operations

• Creates a new entry with
• The DN of new entry, and
• A list of attributes and their values to put in
  the new entry
• Requirement
• parent of new entry exists
• no entry of same name exists in that parent
• new entry matches requirements of schemas
• access control allows operation
• Deletes an entry
• Takes DN of entry to delete
• Requirement
• entry exists
• entry has no child objects
• access control allows operation

21
LDAP Modify Operation

• Allows updating existing entry
• Can add, delete or replace attributes
• Can modify many attributes in one modify
  operation
• Requirement
• entry exists
• all attribute modifications must succeed
• resulting entry obeys schemas
• access control permits modification

22
LDAP Rename and Move Operations

• Rename an entry
• Parameters the DN and the new RDN of entry
• Requirement
• entry exists
• new name not already used by other entry
• access control allows operation
• Moving an entry to a new parent entry
• Parameters the DN of the entry, DN of the new
  parent entry
• Requirement
• the new parent entry exists
• no entry in the new parent has the same RDN
• access control allows operation

23
LDAP Bind Operation

• Authenticates client to the directory
• Three bind types
• Simple bind
• send DN and password in clear text to server
• Need to use TLS to encrypt communication in this
  case
• Simple Authentication and Security Layer (SASL)
  bind
• A standard protocol independent way of
  negotiating and performing authentication
• Anonymous bind
• No (empty) DN and password
• Client can bind, perform operations, bind again,
  and perform other operations

24
OpenLDAP utilities

• The utility ldapsearch is used to query a
  directory, for example,
• ldapsearch x h ldap.csa-snm.com b
  "dccsa-snm,dccom" "((ousales)(acTypestaff))"
• Common parameters/options for ldapsearch
• -x use simple authentication instead of SASL
• -h specify hostname of LDAP server
• -b specify the DN of the search base
• -s specify the search scope, options are base,
  one and sub
• -D specify a DN to bind with
• -w specify a password (use W for interactive
  prompt)
• Other utilities of OpenLDAP
• ldapmodify, ldapdelete, ldapadd, ldapmodrdn
  (rename RDN), ldapcompare, ldappasswd
• slapadd, slapcat, slapindex, slappasswd

25
LDAP Security Model

• LDAP security model protects the information in
  the directory from unauthorized access. With
  anonymous bind, the server does not know who the
  client is, hence, limited (or none) privileges
  will be provided.
• Apart from simple binding, LDAP also supports
  (LDAPv3) Secure Socket Layer SSL, Transport Layer
  Security TLS and Simple Authentication and
  Security Layer SASL.
• Similar to the use of HTTPS (Hypertext Transfer
  Protocol over SSL) for secure web access, LDAP
  over SSL (LDAPS) allows secure LDAP client access
  and client authentication (uses port 636).
• For secure directory data (queries/search and
  results) transmission between LDAP server and
  clients, LDAPv3 can use TLS encryption to prevent
  eavesdropping on the Internet.

26
Directory Security

• Securing an LDAP directory
• Authentication - checking the identification, two
  parties (user server) involved with a third
  party of mutual trust.
• Authorization assign access rights to someone,
  and requiring certain rights to access resources
  or perform actions on resources. Different
  levels of access (read, write, etc.) to different
  resources may be assigned to different users.
• Encryption transmitting or storing data
  securely so it is kept private.

27
Directory Schema

• A directory schema is a set of rules that
  determines what data can be stored in a
  directory. Schema determines the allowed object
  classes and attributes. LDAP schema formats
  ASN.1, U of Michigan, LDAPv3.
• A directory schema also determines how directory
  servers and clients should treat information
  during directory operations such as a search.
  Before a directory server stores a new or
  modified entry, it checks the entrys contents
  against the schema rules. Whenever directory
  clients or servers compare two attribute values,
  they consult the schema to determine what
  comparison algorithm to use.
• Schemas can be used to impose constraints on the
  size, range, and format of data values stored in
  the directory.
• There is only one namespace for attributes the
  definition of an attribute, such as cn, is the
  same for all Object Classes that support that
  attribute.

28
Directory Schema

• Sets of rules that describes what kind of data is
  stored.
• Determines rules that entries must follow.
• Reduces duplication of data
• Specifies details of object classes such as
  required attributes and allowed attributes.
• Specifies details of attributes such as how to
  compare, data type, range/size, etc.
• Schema consists of Attribute Types, Attribute
  Syntaxes and Object Classes.
• Example of schema core.schema of openLDAP

29
Object Classes

• Object classes are defined in LDAP Schema.
• Object classes are used to group related
  information. An object class models some
  real-world object such as a person, printer, or
  network device.
• An object class defines what attributes must, or
  may be present in an entry
• For example, an object class called person that
  hold information about peoples requires that a
  name be present in the entry, and allows a number
  of optional attributes to be included, such as
  age, sex, telephone, etc.

30
Object Classes

• An object class includes the following
  information
• A name that uniquely identifies the class, such
  as person
• An Object ID (OID) that also uniquely identifies
  the class
• A set of mandatory attribute types.
• A set of allowed attribute types, could be quite
  long.
• A kind (or type) structural, auxiliary or
  abstract.
• Multiple object classes
• An entry can be one type of structural object
  class and can also be several types of auxiliary
  object classes.
• An entry cannot be two different types of
  structural object classes (e.g. an entry cannot
  be a person as well as a device)

31
Kind/type of Object Class

• Structural object classes represent real-world
  objects. Most object classes are structural
  classes. Each entry should belong to exactly one
  structural object class. Classes of this type can
  be instantiated into objects. Example person
• Auxiliary object classes are used to add a set of
  attributes to an entry that already belongs to a
  structural class classes of this type provide
  attributes that extend a structural class.
  Classes of this type cannot be used on their own.
  Example dcObject
• Abstract object classes are used only for classes
  needed to support LDAPs basic information model.
  Classes of this type provide attributes that
  flow through the hierarchy, for example, the
  abstract object class top ensures that all
  classes derived from it contain the attribute
  objectClass. Abstract object classes cannot be
  instantiated into object.

32
Example of Object Class

• Here is the definition for the object class
  person
• objectclass ( 2.5.6.6 NAME 'person'
• SUP top STRUCTURAL
• MUST ( sn cn )
• MAY ( userPassword telephoneNumber
• seeAlso description ) )
• This says a person entry must contain
• a surname (sn) and
• common name (cn),
• and may contain a userPassword, a
  telephoneNumber, a description, and a reference
  to another LDAP entry.

33
Object Class inheritance

• Object class inheritance is also referred as
  subclassing. With subclassing, one object class
  can be derived from another, and inherits the
  characteristics.
• For example, the object class inetOrgPerson
  extends the object class organizationalPerson and
  includes additional attribute types.
• Therefore, inetOrgPerson entries must have all
  the "required" attributes defined in the object
  class organizationalPerson. Also, inetOrgPerson
  entries are allowed to include any of the
  "optional" attributes of the object class
  organizationalPerson.

34
Object Class Definitions for top and organization

• Objectclass top
• (2.5.6.0
• Name top
• ABSTRACT
• MUST (
• objectClass
• )
• )
• Objectclass organization
• (2.5.6.4
• NAME organization
• SUP top
• STRUCTURAL
• MUST (
• o
• MAY (
• userPassword
• searchGuide

• seeAlso
• businessCategory
• x121Address
• registeredAddress
• destinationIndicator
• preferredDeliveryMethod
• telexNumber
• teletexTerminalIdentifier
• telephoneNumber
• internationaliSDNNumber
• facsimileTelephoneNumber
• street
• postOfficeBox
• postalAddress
• physicalDeliveryOfficeName
• st
• l
• description
• )

35
Example Object Class Definitions (1)

• Object class top
• All object classes derived from the object class
  top
• Its purpose is to ensure every object contains
  the objectClass attribute
• It exists only to be subclassed i.e., ABSTRACT
• You will not find an entry for object class top
• Because every object class inherits from top,
  every object class must contain the attribute
  objectClass
• (2.5.6.0
• NAME top
• ABSTRACT
• MUST (
• objectClass
• )
• )

36
Example Object Class Definitions (2)

• Object class person
• Derived from top
• Besides the attribute objectClass inherited
  from top every person entry must have the
  attributes sn and cn
• The line with SUP top expresses that the
  object class top is its ancestor
• We can use the numeric OID here SUP 2.5.6.0
• (2.5.6.6
• NAME person
• SUP top
• STRUCTURAL
• MUST (
• sn cn
• )
• MAY (
• userPassword telephoneNumber seeAlso
  description
• )
• )

37
Example Object Class Definitions (3)

• Object class organizationalPerson
• Derived from person
• This object class has a number of attributes
  useful for implementing an employee object such
  as fax number, organizational unit and so on.
• It adds more optional attributes in addition to
  those provided by person.
• (2.5.6.7
• NAME 'organizationalPerson'
• SUP person
• STRUCTURAL
• MAY (
• title x121Address registeredAddress
  destination Indicator preferredDeliveryMet
  hod telexNumber teletexTerminal Identifier
  telephoneNumber internationaliSDNNumber
  facsimileTelephoneNumber street postOfficeBox
  postalCode postalAddress physicalDeliveryOff
  iceName ou st 1
• )
• )

38
Example Object Class Definitions (4)

• Object class inetOrgPerson
• This class was intended to accommodate
  information about a person in a typical
  Internet/Intranet environment
• (2.16.840.1.113730.3.2.2
• NAME ' inetOrgPerson '
• SUP organizationalPerson
• STRUCTURAL
• MAY (
• audio businessCategory carLicense
  departmentNumber displayName employeeNumber
  employeeType givenName homePhone
  homePostalAddress initials jpegPhoto
  labeledURI mail manager mobile o pager
  photo roomNumber secretary uid
  userCertificate x500uniqueIdentifier
  preferredLanguage userSMIMECertificate
  userPKCS12
• )
• )

39
LDAP Data Interchange Format (LDIF)

• LDIF is defined in RFC 2849
• LDIF is used to represent entries of an LDAP
  directory or a set of changes to an LDAP
  directory in a text-based file format.
• LDIF can be used for a variety of management
  functions, including backup, replication, bulk
  import/export or modification.
• For example, to add entries, you can first put
  all the details of the entries in a ldif file and
  then use the ldapadd command with the option f
  ltfilename of ldifgt

dn uidjohnc,ouPeople,dccsa-snm,dccom uid
johnc cn John Chan givenName John sn
Chan mail johnc_at_csa-snm.com objectClass
person description a staff dn
uidmayc,ouPeople,dccsa-snm,dccom
Example of LDIF
40
Example - Content of a directory exported to a
LDIF file

• dn oldap_abc.de
• objectclass top
• objectclass organization
• o ldap_abc.de
• l Munich
• dn ouIT, oldap_abc.de
• objectclass top
• objectclass organizationalUnit
• ou IT
• description Information Technologies
• dn ouHR, oldap_abc.de
• objectclass top
• objectclass organizationalUnit
• ou HR
• description Human Resources

• dn uidSParker, ouHR, oldap_abc.de
• objectclass top
• objectclass person
• objectclass organizationalPerson
• objectclass inetOrgPerson
• ou HR
• cn Sarah Parker
• sn Parker
• givenName Sarah
• uid SParker
• mail SarahParker_at_ldap_abc.de
• Mobile [phone]

41
Different Types of Objects

• We have three different types of objects
• The whole organization is identified by an o
• oldap_abc.de
• The individual departments, called
  organizationalUnit abbreviated with ou
• ouIT,oldap_abc.de
• ouHR,oldap_abc.de
• The entry for a single person, called
  inetOrgPerson is identified as follows
• uidSParker,ouHR,oldap_abc.de
• Each entry corresponds directly to an object in
  the real world, i.e, a person, a printer, a
  computer, an organization, etc.

42
LDAP URLs

• RFC 2255 defines the format of URL for LDAP
  system
• ldapurl ldap"//" hostport "/" dn "?"
  attributes "?" scope "?" filter "?"
  extensions
• port number defaults to 389 for LDAP and 636
  for LDAPS
• dn the distinguished name used as the base of
  the search
• scope either base, one or subtree
• attributes a comma-separated list of the
  attributes to return
• filter the search filter to apply
• Example querying an LDAP server on port 389 and
  doing a subtree search of the CSA-SNM for any
  entry with a surname of "Chan", retrieving all
  attributes
• ldap//csa-snm.com389/dccsa-snm,dccom??sub?(sn
  Chan)

43
Directory Structure

• Hierarchical structure
• A deeper (more layers) structure can easily
  delegate controls to local departments/units
• Searching can be more efficient
• Flat structure
• A simple and flat structure (with a few
  containers) needs fewer movements of objects
  between containers when there is change in the
  real-world organization of staff and equipment
  (e.g. reorganization, changing of departments)
• Other factors for design directory structure
• Replication
• Access Control
• Requirement of applications that use the directory

44
Directory Structure
45
LDAP Referrals

• LDAP referrals and search result continuation
  references are pieces of knowledge reference
  information sent from an LDAP server to an LDAP
  client indicating that other servers need to be
  contacted to fulfill the client's request.
• LDAP referrals When an LDAP client performs an
  LDAP add, modify, delete, modify DN, compare, or
  search operation with a base-level scope, and the
  server does not hold the target entry, the
  knowledge reference information is returned to
  the client in an LDAP referral.
• LDAP search result continuation references If
  the server was able to locate the entry referred
  to by the baseObject but was unable to search all
  the entries in the scope at and under the
  baseObject, the server may return one or more
  search result continuation references.
• The information in LDAP referrals and search
  result continuation references is in the format
  of an LDAP Uniform Resource Locator (URL).

46
LDAP Referral Chaining

• The information in LDAP referral or reference
• Host name of the server to contact
• Port number of the server
• The base DN or target DN this part is optional.
• Example ldap//serverB.csa-snm.com389/ousales
  ,dccsa-snm,dccom
• Another way to glue together directory partitions
  is with chaining. When this approach is used and
  if the server is unable to process the client's
  request completely because it does not hold all
  the required data, it (the server) contacts other
  servers on behalf of the client (forming a chain
  of connections between servers). After the other
  servers have completed the operations, the server
  that was contacted by the client returns the
  combined results to the client.

47
LDAP Replication

• In replication systems, a Master server sends
  updates to another server a Replica (or slave)
  server accepts those changes.
• Single-Master Replication system
• Only one server contains a writable copy of a
  given directory entry. Only the master server
  can perform write operations.
• All replicas contain read-only copies of the
  entry.
• Multi-Master Replication system
• More than one read/write copy of an entry is
  available. Client may submit update operation to
  any of the read/write replicas. The set of
  cooperating servers need to ensure that changes
  are propagated to all servers and that
  consistency is maintained.

48
Single-Master Replication

• Method I all modifications go to the master LDAP
  server
• Method II Referrals
• Client sends modification to replica
• Replica returns referral to master
• Client resubmits modification to master
• Master returns results to client
• Master updates replica with change
• Method III Chaining
• Client sends modification to replica
• Replica forwards request to master
• Master returns result to replica
• Replica forwards result to client
• Master updates replica

49
OpenLDAP Access Control

• OpenLDAP server Stand-alone LDAP daemon (slapd)
• At present, there is no standard LDAP access
  control model specified. Different vendors are
  using different approaches to implement access
  control. Some vendors place a separate Access
  Control List (ACL) on each directory entry
  (possibly with inherited settings from parent
  entries). With OpenLDAP, there is not a separate
  ACL for each entry. Instead, directives in the
  slapd configuration file form the basis for
  access control policy.
• All slapd runtime configuration is accomplished
  through the slapd.conf file. An important
  configuration in the slapd.conf file is about
  access control. Access to slapd entries and
  attributes is controlled by the access directives
  defined in the configuration file.
• Reference for slapd.conf - http//www.openldap.org

50
OpenLDAP Access Control

• ltaccess directivegt access to ltwhatgt
• by ltwhogt ltaccessgt ltcontrolgt
• ltwhatgt dn.ltbasic-stylegtltregexgt
  dn.ltscope-stylegtltDNgt
  filterltldapfiltergt attrsltattrlistgt
• ltwhogt anonymous users self
• dn.ltbasic-stylegtltregexgt
  dn.ltscope-stylegtltDNgt
• ltaccessgt selfltlevelgtltprivgt
• ltlevelgt none auth compare search read
  write
• ltscope-stylegt base one subtree children
• ltprivgt -wrscx0
• ltcontrolgt stop continue break

51
OpenLDAP Access Control

• The ltwhatgt part of an access specification
  determines the entries and attributes to which
  the access control applies.
• Examples of specifying ltwhatgt
• dn"cnJohn,oustaff,dccsa-snm,dccom"
• dn.base"oustaff,dccsa-snm,dccom"
• match the base entry only, i.e. oustaff
• dn.one"oustaff,dccsa-snm,dccom"
• match entries at the next level
• dn.subtree"oustaff,dccsa-snm,dccom"
• match entries of the subtree including the base
  entry
• dn.children"oustaff,dccsa-snm,dccom"
• match entries of the subtree excluding the base
  entry
• Attributes are selected by including a
  comma-separated list of attribute names in the
  ltwhatgt selector, for example,
• dn.subtree"oustaff,dccsa-snm,dccom" attrssn

52
OpenLDAP Access Control

• The ltwhogt part identifies the entity or entities
  being granted access. Entities can be specified
  by a number of ways
• the special "" identifier, matching any entry,
• the keyword "self" matching the entry protected
  by the access,
• Anonymous non-authenticated Users
  authenticated
• a regular expression matching an entry's
  distinguished name
• a regular expression matching the client's IP
  address or domain name
• The kind of ltaccessgt granted can be one of the
  following
• none auth compare search read write
• Each level implies all lower levels of access,
  e.g. granting the write access to an entry also
  grants read, search, compare, and auth access to
  that entry.

53
OpenLDAP Access Control