原文链接

OpenLDAP under olc(On-line configuration) (cn=config) either as part of the standard installation or they can be added using this procedure or by the include statement in the slapd.conf configuration file).

commonName (cn)

surname(姓)

  • An attribute definition includes its type (or SYNTAX), for example, a string or number, and how it behaves in certain conditions, for instance, whether comparison operations are case-sensitive or case-insensitive using what are called matchingRules (more on this later, much later).
  • entries must contain one, and only one, STRUCTURAL objectClass. A STRUCTURAL objectClass may have a SUPerior (may be part of a hierarchy) which is also STRUCTURAL and thus the hierarchy may be viewed as a single STRUCTURAL objectClass
  • entries may contain any number of AUXILIARY objectClasses.
  • Each objectclass supported by an LDAP server forms part of a collection called objectclasses which can be discovered via the subschema.

ldap entry structure

The formal objectclass definition is defined in RFC 2252 section 4.4 and looks like this:

ObjectClassDescription = "(" whsp
 numericoid whsp      ; ObjectClass identifier
 [ "NAME" qdescrs ]
 [ "DESC" qdstring ]
 [ "OBSOLETE" whsp ]
 [ "SUP" oids ]       ; Superior ObjectClasses
 [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
                      ; default structural
 [ "MUST" oids ]      ; AttributeTypes
 [ "MAY" oids ]       ; AttributeTypes
  whsp ")"

Ooof! whsp means a space character, and when they say it should be there, believe them. Rather than try and explain all these paramaters individually, lets start with some examples.

The following is a simple standard objectclass definition for country taken from the core.schema supplied with OpenLDAP distributions.

objectclass ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL
  DESC '2 character iso 3611 assigned country code'
  MUST c
  MAY ( searchGuide $ description ) )

The globally unique part is defined by 2.5.6.2 which is called an OID (ObjectIdentifier).

Obtaining an enterprise OID, formally a Private Enterprise Number (PEN), that allows you to define your own attributes and objectclasses is a trivial and zero cost process via IANA. It is a VERY BAD THING™ to re-use existing OIDs.

MUST c MUST indicates that the attributes in the following list are mandatory. In this case the attribute c (c or countryName) has to be present or an objectClass instance will not be created (it will fail with a nasty error message) and if this is a STRUCTURAL objectClass an entry will not be created (it will fail with an even nastier error message). Single values are written as shown, multiple attributes are enclosed in parentheses and separated with a $ (dollar sign), such as ( attr1 $ attr2 $ attrn). If there are no mandatory (MUST) attributes this section is not present.

MAY ( searchGuide $ description ) MAY indicates that the attributes in the following list are optional and do not need to be present in order to create an instance of the objectClass. Multiple values are written as shown, whereas single attributes do not need the parentheses (see MUST attributes above for singleton syntax). If there are no optional (MAY) attributes this section is not present.

  • Each objectclass supported by an LDAP server forms part of a collection called objectclasses which can be discovered via the subschema.
  • An attribute supported by an LDAP server forms part of a collection called attributetypes which can be interrogated via the subschema.

    AttributeTypeDescription = “(“ whsp

    numericoid whsp     ; AttributeType identifier
    

    [ “NAME” qdescrs ] ; name used in AttributeType
    [ “DESC” qdstring ] ; description
    [ “OBSOLETE” whsp ]
    [ “SUP” woid ] ; derived from this other

    ; AttributeType
    

    [ “EQUALITY” woid ; Matching Rule name
    [ “ORDERING” woid ; Matching Rule name
    [ “SUBSTR” woid ] ; Matching Rule name
    [ “SYNTAX” whsp noidlen whsp ] ; Syntax OID
    [ “SINGLE-VALUE” whsp ] ; default multi-valued
    [ “COLLECTIVE” whsp ] ; default not collective
    [ “NO-USER-MODIFICATION” whsp ]; default user modifiable
    [ X-ORDERED whsp type ] ; non-standard - default not X-ORDERED
    [ “USAGE” whsp AttributeUsage ]; default userApplications
    whsp “)”

whsp means a space character and must be present.

attributetype ( 2.5.4.3 NAME ( 'cn' 'commonName' ) SUP name )

attributetype ( 2.5.4.41 NAME 'name'
  EQUALITY caseIgnoreMatch
  SUBSTR caseIgnoreSubstringsMatch
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} is an OID which defines the data type and what rules (data validation) are applied to the data. The full list is in RFC 2252 section 4.3.2. In this case the OID defines it to be a Directory String type which is defined in RFC 2252 section 6.10 to be in the UTF-8 form of the ISO 10646 character set. The value {32768} indicates the maximum length of the string and is optional. (More info on LDAP Data Types.)

Additional Definition Elements:

These notes can be mercifully skipped for most readers and are provided only for those working in the bowels of OpenLDAP or who are trying to figure out what those {} mean when working with OpenLDAP’s on-line configuration(OLC cn=config) system.

  • ‘X-ORDERED type’ is a non-standard element (currently, and incompletely, defined only by draft-chu-ldap-xordered-00) and is used extensively in OpenLDAP’s OLC (cn=config) feature. The use of this element in an attribute definition enables the use of ordered sets.
  • type may be either ‘VALUES’ or ‘SIBLINGS’.
  • ‘VALUES’ is used only with MULTI-VALUE attributes and indicates that each attribute will have an order element of the form {x} prepended to its value (and which then becomes part of its value) and where x is a numeric value starting from 0. This allows multi-valued attributes to be addressed explicity (for modify or delete operations) and for new attributes to be inserted in order where it is important, for example, when using ACLs/ACPs in the olcAccess attribute.
  • ‘SIBLINGS’ may only be used in SINGLE-VALUE attributes. Where an attribute with this value is present in an entry it indicates that its immediate child entries (one level only) must have an ordered value {x} in their DN. The ordered value prefix may be added explicitly when the child entry is added or if not present it will be allocated a sequentially ordered number value prefix starting from 0 when the child entry is added.

OpenLDAP built-in matchingRules

ldapsearch -H ldap://ldap.example.com -x -s base -b "cn=subschema"
  "(objectclass=*)" matchingrules
# matchingrules may be changed to 
# attributetypes objectclasses etc., etc.

The selected indexes (indices) have optimized certain forms of access. You can still search using an attribute that is not indexed - it will just take longer.

# ACL1
access to attrs=userpassword
       by self       write
       by anonymous  auth
       by group.exact="cn=itpeople,ou=groups,dc=example,dc=com"
                     write
       by *          none
# ACL2
access to attrs=carlicense,homepostaladdress,homephone
       by self       write
       by group.exact="cn=hrpeople,ou=groups,dc=example,dc=com"
                     write
       by *          none
# ACL3
access to *
       by self       write
       by group.exact="cn=hrpeople,ou=groups,dc=example,dc=com"
                     write
       by users      read
       by *          none

# Indices to maintain for this directory
# required if searches will use 
# unique id so equality match only
index    uid    eq
# allows general searching on commonname, givenname and email
index    cn,gn,mail eq,sub
# allows multiple variants on surname searching
index sn eq,sub
# sub above includes subintial,subany,subfinal
# optimise department searches
index ou eq
# if searches will include objectClass uncomment following
# index objectClass eq
# shows use of default index parameter
index default eq,sub
# indices missing - uses default eq,sub
index telephonenumber



# ACL Notes
# The following additional notes apply for 2.4:
# 1. attrs is now used instead of attr (to reduce warning messages)
# 2. Removed the ,expand modifier with all regex expressions since
#    2.4 rejected some (but not all) ACL's which contained this modifier
# 3. 2.4 checking is much more rigorous and rejected ACL 8 since it contained
#    attributes to be added later
# 4. If exact or base contains a regular expression substitution then
#    the expand keyword must be used
# ACL1
access to attrs=userpassword
  by self       write
  by anonymous  auth
  by group.exact="cn=itpeople,ou=groups,dc=example,dc=com" write
  by *          none

# ACL2
# allow read of addressbook by owner and itpeople; no-one else see it
access to dn.regex="^ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$"
    attrs=entry
  by dn.exact,expand="cn=$1,ou=people,dc=example,dc=com" read
  by group.exact="cn=itpeople,ou=groups,dc=example,dc=com" write
  by users none

# ACL3
# allows itgroup to create addressbook but not see entries
access to dn.regex="cn=[^,]+,ou=people,dc=example,dc=com$"
   attrs=children
  by group.exact="cn=itpeople,ou=groups,dc=example,dc=com" write
  by users none break

# ACL4
# allows creation of entries in own addressbook; no-one else can
# access it, needs write access to the ENTRY attribute (ACL5 or ACL6A)
# and the entries CHILDREN (ACL4)
access to dn.regex="ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$"
   attrs=children
  by dn.exact,expand="cn=$1,ou=people,dc=example,dc=com" write
  by users none

# ACL5 - only required prior to 2.2
# allow creation of entries in own addressbook; no-one else can 
# access it, needs write access to the ENTRY attribute (ACL5 or ACL6A)
# and the entries CHILDREN (ACL4)
#access to dn.regex="ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$"
#   attrs=entry
#  by dn.exact,expand="cn=$1,ou=people,dc=example,dc=com" write
#  by users none

# ACL6 - only required prior to 2.2
# allow creation of entries in own addressbook; no-one else can 
# access it
#access to dn.regex="ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$"
#   filter=(objectclass=inetorgperson)
#  by dn.exact,expand="cn=$1,ou=people,dc=example,dc=com" write
#  by users none

# ACL6A - 2.2+ replace both ACL5 and ACL6 with this ACL
access to dn.regex="ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$"
   attrs=entry,@inetorgperson
  by dn.exact,expand="cn=$1,ou=people,dc=example,dc=com" write
  by users none

# ACL7
# allows sales to create entries in customers
# authenticated user can only read
access to dn.one="ou=customers,dc=example,dc=com"
   attrs=children
  by group.exact="cn=salespeople,ou=groups,dc=example,dc=com" write
  by users read

# ACL8
access to attrs=carlicense,homepostaladdress,homephone
  by self       write
  by group.exact="cn=hrpeople,ou=groups,dc=example,dc=com" write
  by *          none

# ACL8A - control access to equipment
access to dn.one="ou=equipment,dc=example,dc=com"
  by group.exact="cn=itpeople,ou=groups,dc=example,dc=com" write
  by users      read
    by *          none
# ACL9
access to *
  by self       write
  by group.exact="cn=hrpeople,ou=groups,dc=example,dc=com" write
  by users      read
  by *          none
# root or superuser
rootdn "cn=jimbob, dc=example, dc=com"
rootpw dirtysecret
# The database directory MUST exist prior to running slapd AND 
# change path as ncessary
directory    /var/db/openldap/example-com

# Indices to maintain for this directory
# unique id so equality match only
index    uid    eq
# allows general searching on commonname, givenname and email
index    cn,gn,mail eq,sub
# allows multiple variants on surname searching
index sn eq,sub
# sub above includes subintial,subany,subfinal
# optimise department searches
index ou eq
# if searches will include objectClass uncomment following
# index objectClass eq
# shows use of default index parameter
index default eq,sub
# indices missing - uses default eq,sub
index telephonenumber

LDAP: Data Types

OPenLDAP Single Sign ON

OpenLDAP Configuration

  • global attributes (or global slapd.conf Directives) apply to the LDAP server they typically include environmental parameters, such as the location of files. In OLC they are defined using the olcGlobal objectClass in the cn=config entry.
  • Attributes/Directives form a strict hierarchy: global can be overridden by backend or database directives, backend can be overridden by database directives. If a attribute/directive is specified in a global section and is not overridden its scope (influence) is all the lower sections (backend and database).

    Global Section Directives (OLC (cn=config) and slapd.conf)

LDAP LDIF and DSML

LDAP URL

Configuring Dynamic Groups

LDAP Security TLS

文章目录
  1. 1. Additional Definition Elements:
  2. 2. OpenLDAP built-in matchingRules
  3. 3. OpenLDAP Configuration
  4. 4. LDAP LDIF and DSML
  5. 5. LDAP URL