diff options
Diffstat (limited to 'doc/guide/admin/schema.sdf')
| -rw-r--r-- | doc/guide/admin/schema.sdf | 491 |
1 files changed, 491 insertions, 0 deletions
diff --git a/doc/guide/admin/schema.sdf b/doc/guide/admin/schema.sdf new file mode 100644 index 0000000..dfb6700 --- /dev/null +++ b/doc/guide/admin/schema.sdf @@ -0,0 +1,491 @@ +# $OpenLDAP$ +# Copyright 1999-2018 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). The chapter assumes the reader is familiar 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. +The second section, {{SECT:Extending Schema}}, details how to define +new schema items. +!if 0 +The third section, {{SECT:Transferring Schema}} details how you can +export schema definitions from an LDAPv3 server and transform it +to {{slapd.conf}}(5) format. +!endif + +This chapter does not discuss how to extend system schema used by +{{slapd}}(8) as this requires source code modification. System +schema includes all operational attribute types or any object class +which allows or requires an operational attribute (directly or +indirectly). + + +H2: Distributed Schema Files + +OpenLDAP Software is distributed with a set of schema specifications for +your use. Each set is defined in a file suitable for inclusion +(using the {{EX:include}} directive) in your {{slapd.conf}}(5) +file. These schema files are normally installed in the +{{F:/usr/local/etc/openldap/schema}} directory. + +!block table; colaligns="LR"; coltags="F,N"; align=Center; \ + title="Table 8.1: Provided Schema Specifications" +File Description +core.schema OpenLDAP {{core}} (required) +cosine.schema Cosine and Internet X.500 (useful) +inetorgperson.schema InetOrgPerson (useful) +misc.schema Assorted (experimental) +nis.schema Network Information Services (FYI) +openldap.schema OpenLDAP Project (experimental) +!endblock + +To use any of these schema files, you only need to include the +desired file in the global definitions portion of your +{{slapd.conf}}(5) file. For example: + +> # include schema +> include /usr/local/etc/openldap/schema/core.schema +> include /usr/local/etc/openldap/schema/cosine.schema +> include /usr/local/etc/openldap/schema/inetorgperson.schema + +Additional files may be available. Please consult the OpenLDAP +{{TERM:FAQ}} ({{URL:http://www.openldap.org/faq/}}). + +Note: You should not modify any of the schema items defined +in provided files. + + +H2: Extending Schema + +Schema used by {{slapd}}(8) may be extended to support additional +syntaxes, matching rules, attribute types, and object classes. This +chapter details how to add user application attribute types and +object classes using the syntaxes and matching rules already supported +by slapd. slapd can also be extended to support additional syntaxes, +matching rules and system schema, but this requires some programming +and hence is not discussed here. + +There are five steps to defining new schema: +^ obtain Object Identifier ++ choose a name prefix ++ create local schema file ++ define custom attribute types (if necessary) ++ define custom object classes + + +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 +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: + +!block table; colaligns="LR"; coltags="EX,N"; align=Center; \ + title="Table 8.2: Example OID hierarchy" +OID Assignment +1.1 Organization's OID +1.1.1 SNMP Elements +1.1.2 LDAP Elements +1.1.2.1 AttributeTypes +1.1.2.1.1 x-my-Attribute +1.1.2.2 ObjectClasses +1.1.2.2.1 x-my-ObjectClass +!endblock + +You are, of course, free to design a hierarchy suitable to your +organizational needs under your organization's OID. No matter what hierarchy you choose, you should maintain a registry of assignments you make. This can be a simple flat file or something more sophisticated such as the {{OpenLDAP OID Registry}} ({{URL:http://www.openldap.org/faq/index.cgi?file=197}}). + +For more information about Object Identifiers (and a listing service) +see {{URL:http://www.alvestrand.no/objectid/}}. + +.{{Under no circumstances should you hijack OID namespace!}} + +To obtain a registered OID at {{no cost}}, apply for a OID +under the {{ORG[expand]IANA}} (ORG:IANA) maintained {{Private Enterprise}} arc. +Any private enterprise (organization) may request a {{TERM[expand]PEN}} (PEN) to be assigned under this arc. Just fill out the IANA form at {{URL: http://pen.iana.org/pen/PenApplication.page}} and your official PEN will be sent to you usually within a few days. Your base OID will be something like {{EX:1.3.6.1.4.1.X}} where {{EX:X}} is an integer. + +Note: PENs obtained using this form may be used for any purpose +including identifying LDAP schema elements. + +Alternatively, OID name space may be available from a national +authority (e.g., {{ORG:ANSI}}, {{ORG:BSI}}). + + +H3: Naming Elements + +In addition to assigning a unique object identifier to each schema +element, you should provide at least one textual name for each +element. Names should be registered with the {{ORG:IANA}} or +prefixed with "x-" to place in the "private use" name space. + +The name should be both descriptive and not likely to clash with +names of other schema elements. In particular, any name you choose +should not clash with present or future Standard Track names (this +is assured if you registered names or use names beginning with "x-"). + +It is noted that you can obtain your own registered name +prefix so as to avoid having to register your names individually. +See {{REF:RFC4520}} for details. + +In the examples below, we have used a short prefix '{{EX:x-my-}}'. +Such a short prefix would only be suitable for a very large, global +organization. In general, we recommend something like '{{EX:x-de-Firm-}}' +(German company) or '{{EX:x-com-Example}}' (elements associated with +organization associated with {{EX:example.com}}). + + +H3: Local schema file + +The {{EX:objectclass}} and {{EX:attributeTypes}} configuration file +directives can be used to define schema rules on entries in the +directory. It is customary to create a file to contain definitions +of your custom schema items. We recommend you create a file +{{F:local.schema}} in {{F:/usr/local/etc/openldap/schema/local.schema}} +and then include this file in your {{slapd.conf}}(5) file immediately +after other schema {{EX:include}} directives. + +> # include schema +> include /usr/local/etc/openldap/schema/core.schema +> include /usr/local/etc/openldap/schema/cosine.schema +> include /usr/local/etc/openldap/schema/inetorgperson.schema +> # include local schema +> include /usr/local/etc/openldap/schema/local.schema + + +H3: Attribute Type Specification + +The {{attributetype}} directive is used to define a new attribute +type. The directive uses the same Attribute Type Description +(as defined in {{REF:RFC4512}}) used by the attributeTypes +attribute found in the subschema subentry, e.g.: + +E: attributetype <{{REF:RFC4512}} Attribute Type Description> + +where Attribute Type Description is defined by the following +{{TERM:ABNF}}: + +> 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 +> [ "USAGE" whsp AttributeUsage ]; default userApplications +> whsp ")" +> +> AttributeUsage = +> "userApplications" / +> "directoryOperation" / +> "distributedOperation" / ; DSA-shared +> "dSAOperation" ; DSA-specific, value depends on server +> + +where whsp is a space ('{{EX: }}'), numericoid is a globally unique +OID in dotted-decimal form (e.g. {{EX:1.1.0}}), qdescrs is one or +more names, woid is either the name or OID optionally followed +by a length specifier (e.g {{EX:{10}}}). + +For example, the attribute types {{EX:name}} and {{EX:cn}} are defined +in {{F:core.schema}} as: + +> attributeType ( 2.5.4.41 NAME 'name' +> DESC 'name(s) associated with the object' +> 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' ) +> DESC 'common name(s) associated with the object' +> SUP name ) + +Notice that each defines the attribute's OID, provides a short name, +and a brief description. Each name is an alias for the OID. +{{slapd}}(8) returns the first listed name when returning results. + +The first attribute, {{EX:name}}, holds values of {{EX:directoryString}} +({{TERM:UTF-8}} encoded Unicode) syntax. The syntax is +specified by OID (1.3.6.1.4.1.1466.115.121.1.15 identifies the +directoryString syntax). A length recommendation of 32768 is +specified. Servers should support values of this length, but may +support longer values. The field does NOT specify a size constraint, +so is ignored on servers (such as slapd) which don't impose such +size limits. In addition, the equality and substring matching uses +case ignore rules. Below are tables listing commonly used syntax +and matching rules ({{slapd}}(8) supports these and many more). + +!block table; align=Center; coltags="EX,EX,N"; \ + title="Table 8.3: Commonly Used Syntaxes" +Name OID Description +boolean 1.3.6.1.4.1.1466.115.121.1.7 boolean value +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 {{TERM: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 +octetString 1.3.6.1.4.1.1466.115.121.1.40 arbitrary octets +!endblock + +> + +!block table; align=Center; coltags="EX,N"; \ + title="Table 8.4: Commonly Used Matching Rules" +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 +octetStringOrderingMatch ordering octet string +octetStringSubstringsMatch ordering octet string +objectIdentiferMatch equality object identifier +!endblock + +The second attribute, {{EX:cn}}, is a subtype of {{EX:name}} hence +it inherits the syntax, matching rules, and usage of {{EX:name}}. +{{EX:commonName}} is an alternative name. + +Neither attribute is restricted to a single value. Both are meant +for usage by user applications. Neither is obsolete nor collective. + +The following subsections provide a couple of examples. + + +H4: x-my-UniqueName + +Many organizations maintain a single unique name for each user. +Though one could use {{EX:displayName}} ({{REF:RFC2798}}), this +attribute is really meant to be controlled by the user, not the +organization. We could just copy the definition of {{EX:displayName}} +from {{F:inetorgperson.schema}} and replace the OID, name, and +description, e.g: + +> attributetype ( 1.1.2.1.1 NAME 'x-my-UniqueName' +> DESC 'unique name with my organization' +> EQUALITY caseIgnoreMatch +> SUBSTR caseIgnoreSubstringsMatch +> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 +> SINGLE-VALUE ) + +However, if we want this name to be used in {{EX:name}} assertions, +e.g. {{EX:(name=*Jane*)}}, the attribute could alternatively be +defined as a subtype of {{EX:name}}, e.g.: + +> attributetype ( 1.1.2.1.1 NAME 'x-my-UniqueName' +> DESC 'unique name with my organization' +> SUP name ) + + +H4: x-my-Photo + +Many organizations maintain a photo of each each user. A +{{EX:x-my-Photo}} attribute type could be defined to hold a photo. +Of course, one could use just use {{EX:jpegPhoto}} ({{REF:RFC2798}}) +(or a subtype) to hold the photo. However, you can only do +this if the photo is in {{JPEG File Interchange Format}}. +Alternatively, an attribute type which uses the {{Octet String}} +syntax can be defined, e.g.: + +> attributetype ( 1.1.2.1.2 NAME 'x-my-Photo' +> DESC 'a photo (application defined format)' +> SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 +> SINGLE-VALUE ) + +In this case, the syntax doesn't specify the format of the photo. +It's assumed (maybe incorrectly) that all applications accessing +this attribute agree on the handling of values. + +If you wanted to support multiple photo formats, you could define +a separate attribute type for each format, prefix the photo +with some typing information, or describe the value using +{{TERM:ASN.1}} and use the {{EX:;binary}} transfer option. + +Another alternative is for the attribute to hold a {{TERM:URI}} +pointing to the photo. You can model such an attribute after +{{EX:labeledURI}} ({{REF:RFC2079}}) or simply create a subtype, +e.g.: + +> attributetype ( 1.1.2.1.3 NAME 'x-my-PhotoURI' +> DESC 'URI and optional label referring to a photo' +> SUP labeledURI ) + + +H3: Object Class Specification + +The {{objectclasses}} directive is used to define a new object +class. The directive uses the same Object Class Description +(as defined in {{REF:RFC4512}}) used by the objectClasses +attribute found in the subschema subentry, e.g.: + +E: objectclass <{{REF:RFC4512}} Object Class Description> + +where Object Class Description is defined by the following +{{TERM:ABNF}}: + +> 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 ")" + +where whsp is a space ('{{EX: }}'), numericoid is a globally unique +OID in dotted-decimal form (e.g. {{EX:1.1.0}}), qdescrs is one or more +names, and oids is one or more names and/or OIDs. + + +H4: x-my-PhotoObject + +To define an {{auxiliary}} object class which allows +x-my-Photo to be added to any existing entry. + +> objectclass ( 1.1.2.2.1 NAME 'x-my-PhotoObject' +> DESC 'mixin x-my-Photo' +> AUXILIARY +> MAY x-my-Photo ) + + +H4: x-my-Person + +If your organization would like have a private {{structural}} +object class to instantiate users, you can subclass one of +the existing person classes, such as {{EX:inetOrgPerson}} +({{REF:RFC2798}}), and add any additional attributes which +you desire. + +> objectclass ( 1.1.2.2.2 NAME 'x-my-Person' +> DESC 'my person' +> SUP inetOrgPerson +> MUST ( x-my-UniqueName $ givenName ) +> MAY x-my-Photo ) + +The object class inherits the required/allowed attribute +types of {{EX:inetOrgPerson}} but requires {{EX:x-my-UniqueName}} +and {{EX:givenName}} and allows {{EX:x-my-Photo}}. + +!if 0 +H2: Transferring Schema + +Since the {{slapd.conf}}(5) schema directives use {{REF:RFC4512}} +format values, you can extract schema elements published by any +{{TERM:LDAPv3}} server and easily construct directives for use with +{{slapd}}(8). + +LDAPv3 servers publish schema elements in special {{subschema}} +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 'x-my-Person' DESC 'my person' SUP inet +> OrgPerson MUST ( x-my-UniqueName $ givenName ) MAY x-my-Photo ) +> attributeTypes: ( 1.1.2.1.1 NAME 'x-my-UniqueName' DESC 'unique name wi +> th my organization' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstrin +> gsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) +> attributeTypes: ( 1.1.2.1.2 NAME 'x-my-Photo' DESC 'a photo (applicatio +> n defined format)' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 + +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 /}}). +^ 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 +result in a file with contains of: + +> attributetype ( 1.1.2.1.1 NAME 'x-my-UniqueName' +> DESC 'unique name with my organization' +> EQUALITY caseIgnoreMatch +> SUBSTR caseIgnoreSubstringsMatch +> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 +> SINGLE-VALUE ) +> attributeType ( 1.1.2.1.2 NAME 'x-my-Photo' +> DESC 'a photo (application defined format)' +> SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 +> objectClass ( 1.1.2.2.2 NAME 'x-my-Person' +> DESC 'my person' +> SUP inetOrgPerson +> MUST ( x-my-UniqueName $ givenName ) +> MAY x-my-Photo ) + +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}} 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>] } + +The following demonstrates definition of a set of OID macros +and their use in defining schema elements: + +> objectIdentifier myOID 1.1 +> objectIdentifier mySNMP myOID:1 +> objectIdentifier myLDAP myOID:2 +> objectIdentifier myAttributeType myLDAP:1 +> objectIdentifier myObjectClass myLDAP:2 +> attributetype ( myAttributeType:3 NAME 'x-my-PhotoURI' +> DESC 'URI and optional label referring to a photo' +> SUP labeledURI ) +> objectclass ( myObjectClass:1 NAME 'x-my-PhotoObject' +> DESC 'mixin x-my-Photo' +> AUXILIARY +> MAY x-my-Photo ) + |