# $OpenLDAP$
-# Copyright 1999-2000, The OpenLDAP Foundation, All Rights Reserved.
+# Copyright 1999-2006 The OpenLDAP Foundation, All Rights Reserved.
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.
H1: Schema Specification
-This chapter describes how to extend the user schema used by {{slapd}}(8).
+This chapter describes how to extend the user schema used by
+{{slapd}}(8). The chapter assumes the reader is familar with the
+{{TERM:LDAP}}/{{TERM:X.500}} information model.
+
The first section, {{SECT:Distributed Schema Files}} details optional
schema definitions provided in the distribution and where to obtain
other definitions.
H3: Object Identifiers
-Each schema element is identified by a globally unique
-{{TERM[expand]OID}} (OID). OIDs are also used to identify
-other objects.
-They are commonly found in protocols described by {{TERM:ASN.1}}. In
+Each schema element is identified by a globally unique {{TERM[expand]OID}}
+(OID). OIDs are also used to identify other objects. They are
+commonly found in protocols described by {{TERM:ASN.1}}. In
particular, they are heavily used by the {{TERM[expand]SNMP}} (SNMP).
-As OIDs are hierarchical, your organization
-can obtain one OID and branch it as needed. For example,
-if your organization were assigned OID {{EX:1.1}}, you could branch
-the tree as follows:
+As OIDs are hierarchical, your organization can obtain one OID and
+branch it as needed. For example, if your organization were assigned
+OID {{EX:1.1}}, you could branch the tree as follows:
!block table; colaligns="LR"; coltags="EX,N"; align=Center; \
title="Table 8.2: Example OID hierarchy"
including identifying LDAP schema elements.
Alternatively, OID name space may be available from a national
-authority (e.g., ANSI, BSI).
-
-For private experiments, OIDs under {{EX:1.1}} may be used. The
-OID {{EX:1.1}} arc is regarded as dead name space.
+authority (e.g., {{ORG:ANSI}}, {{ORG:BSI}}).
H3: Name Prefix
> EQUALITY caseIgnoreMatch
> SUBSTR caseIgnoreSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
-> attributeType ( 2.5.4.3 NAME ( 'cn' $ 'commonName' )
+> attributeType ( 2.5.4.3 NAME ( 'cn' 'commonName' )
> DESC 'common name(s) assciated with the object'
> SUP name )
title="Table 8.3: Commonly Used Syntaxes"
Name OID Description
boolean 1.3.6.1.4.1.1466.115.121.1.7 boolean value
-distinguishedName 1.3.6.1.4.1.1466.115.121.1.12 DN
-directoryString 1.3.6.1.4.1.1466.115.121.1.15 UTF-8 string
-IA5String 1.3.6.1.4.1.1466.115.121.1.26 ASCII string
-Integer 1.3.6.1.4.1.1466.115.121.1.27 integer
-Name and Optional UID 1.3.6.1.4.1.1466.115.121.1.34 DN plus UID
-Numeric String 1.3.6.1.4.1.1466.115.121.1.36 numeric string
+directoryString 1.3.6.1.4.1.1466.115.121.1.15 Unicode (UTF-8) string
+distinguishedName 1.3.6.1.4.1.1466.115.121.1.12 LDAP DN
+integer 1.3.6.1.4.1.1466.115.121.1.27 integer
+numericString 1.3.6.1.4.1.1466.115.121.1.36 numeric string
OID 1.3.6.1.4.1.1466.115.121.1.38 object identifier
-Octet String 1.3.6.1.4.1.1466.115.121.1.40 arbitary octets
-Printable String 1.3.6.1.4.1.1466.115.121.1.44 printable string
+octetString 1.3.6.1.4.1.1466.115.121.1.40 arbitary octets
!endblock
>
!block table; align=Center; coltags="EX,N"; \
title="Table 8.4: Commonly Used Matching Rules"
-Name Type Description
-booleanMatch equality boolean
-octetStringMatch equality octet string
-objectIdentiferMatch equality OID
-distinguishedNameMatch equality DN
-uniqueMemberMatch equality Name with optional UID
-numericStringMatch equality numerical
-numericStringOrderingMatch ordering numerical
-numericStringSubstringsMatch substrings numerical
-caseIgnoreMatch equality case insensitive, space insensitive
-caseIgnoreOrderingMatch ordering case insensitive, space insensitive
-caseIgnoreSubstringsMatch substrings case insensitive, space insensitive
-caseExactMatch equality case sensitive, space insensitive
-caseExactOrderingMatch ordering case sensitive, space insensitive
-caseExactSubstringsMatch substrings case sensitive, space insensitive
-caseIgnoreIA5Match equality case insensitive, space insensitive
-caseIgnoreIA5OrderingMatch ordering case insensitive, space insensitive
-caseIgnoreIA5SubstringsMatch substrings case insensitive, space insensitive
-caseExactIA5Match equality case sensitive, space insensitive
-caseExactIA5OrderingMatch ordering case sensitive, space insensitive
-caseExactIA5SubstringsMatch substrings case sensitive, space insensitive
+Name Type Description
+booleanMatch equality boolean
+caseIgnoreMatch equality case insensitive, space insensitive
+caseIgnoreOrderingMatch ordering case insensitive, space insensitive
+caseIgnoreSubstringsMatch substrings case insensitive, space insensitive
+caseExactMatch equality case sensitive, space insensitive
+caseExactOrderingMatch ordering case sensitive, space insensitive
+caseExactSubstringsMatch substrings case sensitive, space insensitive
+distinguishedNameMatch equality distinguished name
+integerMatch equality integer
+integerOrderingMatch ordering integer
+numericStringMatch equality numerical
+numericStringOrderingMatch ordering numerical
+numericStringSubstringsMatch substrings numerical
+octetStringMatch equality octet string
+octetStringOrderingStringMatch ordering octet string
+octetStringSubstringsStringMatch ordering octet string
+objectIdentiferMatch equality object identifier
!endblock
The second attribute, {{EX:cn}}, is a subtype of {{EX:name}} hence
{{slapd}}(8).
LDAPv3 servers publish schema elements in special {{subschema}}
-entries (or subentries). {{slapd}}(8) publishes a single subschema
-entry normally named {{EX:cn=Subschema}}. In a server which
-supports a single subschema subentry, the DN of the subschema
-subenty can usually be found by examining the value of the
-{{EX:subschemaSubentry}} attribute type in the {{root DSE}}.
-Other servers may publish multiple subschema entries. These
-can be located by examining the {{EX:subschemaSubentry}} attribute
-contained in the entry at the root of each administrative context.
+entries (or subentries). While {{slapd}}(8) publishes a single
+subschema subentry normally named {{EX:cn=Subschema}}, this behavior
+cannot be expected from other servers. The subschema subentry
+controlling a particular entry can be obtained by examining the
+{{EX:subschemaSubentry}} attribute contained in the entry at the
+root of each administrative context. For example,
+
+> ldapsearch -LLL -x -b "dc=example,dc=com" -s base "(objectclass=*)" subschemaSubentry
To obtain the schema from a subschema subentry, you can use
ldapsearch(1) as follows (replace the search base as needed):
> ldapsearch -LLL -x -b "cn=Subschema" -s base "(objectclass=subschema)" attributeTypes objectClasses
+where "cn=Subschema" is the value of subschemaSubentry returned in
+the prior search.
+
This will return {{TERM:LDIF}} output containing many type/value
pairs. The following is an abbreviated example:
> dn: cn=Subschema
+> objectClasses: ( 1.1.2.2.2 NAME 'myPerson' DESC 'my person' SUP inet
+> OrgPerson MUST ( myUniqueName $ givenName ) MAY myPhoto )
> attributeTypes: ( 1.1.2.1.1 NAME 'myUniqueName' DESC 'unique name wi
> th my organization' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubst
> ringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
> attributeTypes: ( 1.1.2.1.2 NAME 'myPhoto' DESC 'a photo (applicatio
> n defined format)' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
-> objectClasses: ( 1.1.2.2.2 NAME 'myPerson' DESC 'my person' SUP inet
-> OrgPerson MUST ( myUniqueName $ givenName ) MAY myPhoto )
Capture the output of the search in a file and then edit the file:
+ to contain only desired type/value pairs
^ join LDIF continuation lines
^ replace attribute type with directive name
-(e.g. {{EX:s/attributeTypes:/attributeType/}} and
-{{EX:s/objectClasses:/objectClass/}}).
+(e.g. {{EX:s/attributeTypes:/attributeType /}} and
+{{EX:s/objectClasses:/objectClass /}}).
+^ reorder lines so each element is defined before first use
^ continue long directives over multiple lines
For the three type/value pairs in our example, the edit should
> MUST ( myUniqueName $ givenName )
> MAY myPhoto )
-Save in an appropriately named file (e.g. {{F:my.schema}}).
+Save in an appropriately named file (e.g. {{F:local.schema}}).
You may now include this file in your {{slapd.conf}}(5) file.
!endif
H3: OID Macros
To ease the management and use of OIDs, {{slapd}}(8) supports
-{{Object Identifier}} macros. The {{EX:objectIdentifier}} is used
-to equate a macro (name) with a OID. The OID may possibly be derived
-from a previously defined OID macro. The {{slapd.conf}}(5) syntax
-is:
+{{Object Identifier}} macros. The {{EX:objectIdentifier}} directive
+is used to equate a macro (name) with a OID. The OID may possibly
+be derived from a previously defined OID macro. The {{slapd.conf}}(5)
+syntax is:
E: objectIdentifier <name> { <oid> | <name>[:<suffix>] }
projects / openldap / blobdiff