Appendix B. Schema Appendix

Schema Formats

The schema can be defined in several different formats, which can be confusing unless you know to expect slightly different formats. Different vendors use different formats. The LDAP RFCs generally use the BNF format, but vendors are not required to use this format in their documentation or implementation. The ASN.1 format is also used throughout the LDAP standard, and it is generally the choice of vendors. Vendors that developed from the first LDAP implementation at the University of Michigan use the slapd.conf format.

The schema must be defined in a predetermined format

Each format has the syntax for an object class and attribute presented, followed by examples of each. Chapter 1 includes an example of the person object class definition in the ASN.1 format. To quickly illustrate the basic differences between formats, let's look at the same person definition and at the definition for the cn attribute. For your convenience, I've included the ASN.1 person definition again.

ASN.1 Object Class Syntax

Brackets indicate optional parameters, CAPS indicate required elements, lowercase indicates supplied variables. These notes are different from those for the slapd format!

objectclassname OBJECT-CLASS ::= {
    SUBCLASS OF { superclass }
    [KIND objectclasskind]
    [MUST CONTAIN { attribute1 | attribute2 ...}]
    [MAY CONTAIN { attribute3 | attribute4 ...}]
    ID oid}

Example

person OBJECT-CLASS ::= {
    SUBCLASS OF { top }
    KIND abstract
    MUST CONTAIN { sn, | cn}
    MAY CONTAIN { userPassword | telephoneNumber |
        seeAlso | description }
    ID 2.5.6.6}

ASN.1 Attribute Syntax

attributename ATTRIBUTE ::= {
[SUBTYPE OF supertype]
[WITH SYNTAX syntaxname {syntaxbounds}]
[EQUALITY MATCHING RULE equalmatchingrulename]
[ORDERING MATCHING RULE ordermatchingrulename]
[SUBSTRINGS MATCHING RULE submatchingrulename]
[SINGLEVALUED]
ID oid}

Example

commonName ATTRIBUTE ::= {
SUBTYPE OF name
WITH SYNTAX DirectoryString {ub-common-name}
ID id-at-commonName }

BNF Object Class Syntax

Brackets indicate optional elements, CAPS indicate required elements, lowercase indicates supplied variables. These notes are different from those for the slapd format!

(oid NAME 'objectclassname' SUP superclass 
objectclasskind MUST (attribute1 $ attribute2) MAY
(attribute3 $ attribute4) )

Example

( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn 
$ cn ) MAY ( userPassword $ telephoneNumber $
seeAlso $ description ) )

BNF Attribute Syntax

(oid NAME 'attributename' [DESC 'description'] 
[OBSOLETE] [SUP supertype] [EQUALITY
equalmatchingrulename] [ORDERING
ordermatchingrulename] [SUBSTR submatchingrulename]
SYNTAX syntaxname {syntaxbounds} [SINGLE-VALUE]
[NO-USER-MODIFICATION] [USAGE attributeusage] )

Example

( 2.5.4.3 NAME 'cn' SUP name )

Slapd.conf Object Class Syntax

Brackets indicate optional parameters, CAPS indicate supplied variables, lowercase indicates required elements.

objectclass OBJECTCLASSNAME 
[oid OID]
[superior SUPERIORCLASS]
[requires LISTOFATTRIBS]
[allows LISTOFATTRIBS]

Example

objectclass person 
oid 2.5.6.6
superior top
requires
    sn
    cn
allows
    userPassword
telephoneNumber
seeAlso
description

Slapd.conf Attribute Syntax

attribute ATTRIBUTENAME [ALIAS] [OID] SYNTAX 
[ATTRIBUTEOPTIONS]

ATTRIBUTEOPTIONS allows the nondefault values of “operational” or “single” to be specified. These show that the attribute is operational, not generally returned to clients, and single valued. I believe you can also define attribute options, such as language code support, here.

Example

attribute cn commonName 2.5.4.3 cis

Even with the simple examples I have chosen, there is more going on here than I can cover briefly. Some of the differences can be explained by lack of support for schema functionality like subtyping. Some of the differences result from definitions working together with other definitions like syntax and matching rule definitions, and some of the formats link the definitions in different places.

The formats are summarized here; you can find full details online

Knowing the formal syntax of these formats is worthwhile only if you want to extend the schema of a directory or understand the relationship between existing schema elements. The syntax of the formats can be complex; so if you aren't interested in modifying the schema, the knowledge isn't useful. You can find good resources for all the formats and common schema elements online. These resources explain the basics of the syntax, so you can decipher schema definitions for yourself. For the URLs of these online resources, see Appendix G. The BNF format is what is used by the LDAP standards documents to describe the recommended schema definitions, but any of the formats can be used. The LDAP standard does not require that the BNF format be used by an implementation.

Common Syntaxes

Table B-1 lists common syntaxes that are used in other schema definitions. These syntaxes will be of interest to you if you modify the schema of your directory or need to understand what values are allowed in specific attribute types.

Table B-1. Common schema syntaxes

Name

OID

Description

Binary

1.3.6.1.4.1.1466.115.121.1.5

0 or 1

Bit String

1.3.6.1.4.1.1466.115.121.1.6

Strings of binary

Boolean

1.3.6.1.4.1.1466.115.121.1.7

TRUE or FALSE

Certificate

1.3.6.1.4.1.14666.115.121.1.8

Binary encoding of X.509 certificate

Certificate Pair

1.3.6.1.4.1.14666.115.121.1.10

Sequence of two certificates

Country String

1.3.6.1.4.1.1466.115.121.1.11

Two-character code as defined in ISO 3166

DirectoryString

1.3.6.1.4.1.1466.115.121.1.15

UTF-8–based text string

DistinguishedName

1.3.6.1.4.1.1466.115.121.1.12

DN string

DIT Content Rule Description

1.3.6.1.4.1.1466.115.121.1.16

Used to define content rules for an object class

Facsimile Telephone Number

1.3.6.1.4.1.1466.115.121.1.22

Telephone number with fax parameters included

Fax

1.3.6.1.4.1.1466.115.121.1.23

Fax images in octet string syntax; oddly, octet string syntax isn't noted in the RFC

Generalized Time

1.3.6.1.4.1.1466.115.121.1.24

Time with time zone specified

IA5 String

1.3.6.1.4.1.1466.115.121.1.26

International Alphabet 5 String; contains ASCII and some nonprintable escape characters

INTEGER

1.3.6.1.4.1.1466.115.121.1.27

An integer

JPEG

1.3.6.1.4.1.1466.115.121.1.28

JPEG images encoded in JFIF

Matching Rule Description

1.3.6.1.4.1.1466.115.121.1.30

Used to define matching rules

Matching Rule Use Description

1.3.6.1.4.1.1466.115.121.1.31

Used to define matching rule use definitions

MHS OR Address

1.3.6.1.4.1.1466.115.121.1.33

 

Name AND Optional UID

1.3.6.1.4.1.1466.115.121.1.34

A DN string with optional UID string

Name Form Description

1.3.6.1.4.1.1466.115.121.1.35

Used to define the name form of an object class, in other words, specify an RDN

Numeric String

1.3.6.1.4.1.1466.115.121.1.36

A string of numbers

Object Class Description

1.3.6.1.4.1.1466.115.121.1.37

Used to define an object class

OID

1.3.6.1.4.1.1466.115.121.1.38

An OID string

Other Mailbox

1.3.6.1.4.1.1466.115.121.1.39

String used to denote mail system and mailbox location

PostalAddress

1.3.6.1.4.1.1466.115.121.1.41

Sequence of directory strings denoting a postal address

Presentation Address

1.3.6.1.4.1.1466.115.121.1.43

 

PrintableString

1.3.6.1.4.1.1466.115.121.1.44

Text string with a restricted set of printable characters

Telephone Number

1.3.6.1.4.1.1466.115.121.1.50

Telephone number string in international phone format

UTC Time

1.3.6.1.4.1.1466.115.121.1.53

Printable string with time

LDAP Syntax Description

1.3.6.1.4.1.1466.115.121.1.54

Used to define a syntax

DIT Structure Rule Description

1.3.6.1.4.1.1466.115.121.1.17

Used to define a structural rule for an object class

OctetString

1.3.6.1.4.1.1466.115.121.1.40

Binary data in BER form

In several cases, the RFC 2252 authors deviated from established types and redefined the existing types for no clear reason. Some of the preexisting definitions are listed in Table B-2, because some LDAP vendors may choose to use the definitions with a differing OID.

Common Matching Rules

Tables B-3 through B-6 list common matching rules that are used in LDAP schema definitions. These rules will be of interest to you if you modify the schema of your directory or need to understand how values are compared in specific attribute types. All the common matching rules noted in RFC 2252 are included, as well as a few critical ones not noted in the RFC. The rules are listed in four separate tables by the type of matching rule: equality, ordering, substring, or subschema.

Table B-2. Common syntaxes with OIDs that deviate from original

Name

OID

PrintableString

2.1.0.1.1

Boolean

2.5.5.8

PostalAddress

2.5.4.16

Table B-3. Equality matching rules

ASN.1 Matching Rule

OID

OID of Syntax

Description

objectIdentifierMatch

2.5.13.0

1.3.6.1.4.1.1466.115.121.1.38

Used to match OIDs and other numeric identifiers

distinguishedMatch also known as distinguishedName Match

2.5.13.1

1.3.6.1.4.1.1466.115.121.1.12

Follows the rules for DNs, with each RDN checked

caseIgnoreMatch

2.5.13.2

1.3.6.1.4.1.1466.115.121.1.15

Case ignored, and spaces ignored if at beginning or end, or used in repetition

numericStringMatch

2.5.13.8

1.3.6.1.4.1.1466.115.121.1.36

Matches numeric strings and ignores spaces

caseIgnoreListMatch

2.5.13.11

1.3.6.1.4.1.1466.115.121.1.41

Uses caseIgnoreMatch to compare lists of DirectoryStrings

integerMatch

2.5.13.14

1.3.6.1.4.1.1466.115.121.1.27

Matches values as integers

bitStringMatch

2.5.13.16

1.3.6.1.4.1.1466.115.121.1.6

Compares bit strings to ensure that bits match

telephoneNumberMatch

2.5.13.20

1.3.6.1.4.1.1466.115.121.1.50

Case ignored, and all spaces and hyphens are ignored

presentationAddress Match

2.5.13.22

1.3.6.1.4.1.1466.115.121.1.43

Compares PresentationAddress strings

uniqueMemberMatch

2.5.13.23

1.3.6.1.4.1.1466.115.121.1.34

Uses distinguishedMatch rule to compare DN strings, and uses bitStringMatch to compare uid RDNs

protocolInformation Match

2.5.13.24

1.3.6.1.4.1.1466.115.121.1.42

Uses octetStringMatch rule to compare ProtocolInformation strings

generalizedTimeMatch

2.5.13.27

1.3.6.1.4.1.1466.115.121.1.24

Matches strings of GeneralizedTime. Unspecified minutes or seconds are assumed to be zero

caseExactIA5Match

1.3.6.1.4.1.1466.109.114.1

1.3.6.1.4.1.1466.115.121.1.26

Matches an IA5 string, case does count

caseIgnoreIA5Match

1.3.6.1.4.1.1466.109.114.2

1.3.6.1.4.1.1466.115.121.1.26

Matches an IA5 string, case is ignored

caseExactMatch

2.5.13.5

1.3.6.1.4.1.1466.115.121.1.15

Matches strings; case is significant, but spaces are ignored if at beginning or end, or used in repetition

booleanMatch

2.5.13.13

1.3.6.1.4.1.1466.115.121.1.7

Matches a boolean

octetStringMatch

2.5.13.17

1.3.6.1.4.1.1466.115.121.1.40

Matches a sequence of octet strings

Table B-4. Ordering matching rules

ASN.1 Matching Rule

OID

OID of Syntax

Description

generalizedTimeOrdering Match

2.5.13.28

1.3.6.1.4.1.1466.115.121.1.24

Orders strings of GeneralizedTime

caseIgnoreOrderingMatch

2.5.13.3

1.3.6.1.4.1.1466.115.121.1.15

Orders strings while ignoring case

Table B-5. Substring matching rules

ASN.1 Matching Rule

OID

OID of Syntax

Description

caseIgnoreSubstringsMatch

2.5.13.4

1.3.6.1.4.1.1466.115.121.1.58

Matches a string with a wildcard in any position, while ignoring case

telephoneNumberSubstrings Match

2.5.13.21

1.3.6.1.4.1.1466.115.121.1.58

Matches a PrintableString with a wildcard in any position; case does count, but spaces and hyphens are ignored

numericStringSubstrings Match

2.5.13.10

1.3.6.1.4.1.1466.115.121.1.58

Matches a NumericString with a wildcard in any position, spaces are ignored

Table B-6. Subschema matching rules

ASN.1 Matching Rule

OID

OID of Syntax

Description

IntegerFirstComponentMatch

2.5.13.29

1.3.6.1.4.1.1466.115.121.1.27

Matches the first integer in a sequence of integers

objectIdentifierFirstComponentMatch

2.5.13.30

1.3.6.1.4.1.1466.115.121.1.38

Matches the first OID component in an OID sequence

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.22.77.117