Attribute Types #
Attribute types define the set of attributes that may be used in the server and how operations involving that attribute should be conducted. Among other things, it combines an LDAPSyntaxes and set of matching rules with a unique OID and human-readable names.
The attribute type description format is described in RFC 4512, section 4.1.2. The definition is as follows:
AttributeTypeDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
[ SP "SUP" SP oid ] ; supertype
[ SP "EQUALITY" SP oid ] ; equality matching rule
[ SP "ORDERING" SP oid ] ; ordering matching rule
[ SP "SUBSTR" SP oid ] ; substrings matching rule
[ SP "SYNTAX" SP noidlen ] ; value syntax
[ SP "SINGLE-VALUE" ] ; single-value
[ SP "COLLECTIVE" ] ; collective
[ SP "NO-USER-MODIFICATION" ] ; not user modifiable
[ SP "USAGE" SP usage ] ; usage
extensions WSP RPAREN ; extensions
usage = "userApplications" / ; user
"directoryOperation" / ; directory operational
"distributedOperation" / ; DSA-shared operational
"dSAOperation" ; DSA-specific operational
Elements of AttributeTypes#
The
Object Identifier is a mandatory numeric
OID used to uniquely identify the attribute type in the server. Although the specification requires a numeric OID, some
LDAP Server Implementations also allow a non-numeric
OID for the purpose of convenience. In this case, the non-numeric OID is typically the same as the name of the attribute type followed by the string "-oid".
The
OPTIONAL Short Names (descriptors) is a set of human-readable name
Attribute-Names that may also be used to refer to the AttributeTypes.
An
OPTIONAL human-readable description. If there is a description, then it should be enclosed in single quotation marks.
An optional not active or
OBSOLETE flag that may be used to indicate whether the attribute type is active. If an attribute type is marked as "
OBSOLETE", then it means that it should not be referenced by any new elements created in the
DSA.
An optional reference to the
superior attribute type. If there is a superior type, then it may be referenced by either its
OID or any of its
human-readable names.
An optional equality matching rule definition. If a specific equality matching rule is provided, then it may be referenced by either its OID or any of its human-readable names. If no equality matching rule is given, then the attribute type will use the default equality matching rule for the associated attribute syntax. If the attribute syntax does not have a default equality matching rule, then equality matching operations will not be allowed for attributes of that type.
An optional ordering matching rule definition. If a specific ordering matching rule is provided, then it may be referenced by either its OID or any of its human-readable names. If no ordering matching rule is given, then the attribute type will use the default ordering matching rule for the associated attribute syntax. If the attribute syntax does not have a default ordering matching rule, then ordering matching operations will not be allowed for attributes of that type.
An optional substring matching rule definition. If a specific substring matching rule is provided, then it may be referenced by either its OID or any of its human-readable names. If no substring matching rule is given, then the attribute type will use the default substring matching rule for the associated attribute syntax. If the attribute syntax does not have a default substring matching rule, then substring matching operations will not be allowed for attributes of that type.
An optional attribute syntax for use with the attribute type. If it is provided, then it should be given as a numeric OID. The syntax identifier may also optionally contain an integer value enclosed in curly braces directly following the OID (without any spaces between the last digit of the OID and the opening curly brace), which may be used to suggest a minimum upper bound on the length of values for attributes of that type. OpenDS does not enforce any maximum length restrictions for attribute values, so if a length is given then it will be ignored.
An optional
SINGLE-VALUE flag, which indicates that attributes of that type will only be allowed to have a single value in any entry in which they appear. If this flag is not present in the attribute type description, then attributes of that type will be allowed to have multiple distinct values in the same entry.
An optional
COLLECTIVE Flag, which indicates that the attributes of that type are assigned their values by virtue in their membership in some collection. Collective attributes are described in
RFC 3671
(Collective Attributes in LDAP).
An optional
NO-USER-MODIFICATION Flag, which indicates that values of attributes of that type cannot be modified by external clients (i.e., the values may only be modified by internal processing within the server).
An optional
Attribute Usage Flags specification, which may indicate how the attribute type is to be used.
An optional set of
Extended Flags for the AttributeTypes.
- X-ORIGIN -- Provides information about where the attribute type is defined (e.g., whether it came from a particular RFC or Internet Draft, etc.
- X-SCHEMA-FILE -- Indicates which schema file contains the attribute type definition (this is generally used for internal purposes only and does not get exposed to clients).
- X-APPROX -- Indicates which approximate matching rule should be used for the attribute type. If this is specified, then its value should be the name or OID of a registered approximate matching rule.
A AttributeTypes Example#
For
example, the following is the attribute type description for the standard
uid attribute type:
( 0.9.2342.19200300.100.1.1 NAME 'uid' EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256}
X-ORIGIN 'RFC 1274' )
In this case, the OID is "0.9.2342.19200300.100.1.1". There is a single human-readable name of "uid". The caseIgnoreMatch rule should be used for equality matching, and the caseIgnoreSubstringsMatch rule should be used for substring matching. The attribute type uses the directory string syntax with a suggested minimum upper bound of 256 characters, and the attribute type definition was taken from RFC 1274. There is no description or superior type specified. The attribute type is not marked OBSOLETE, SINGLE-VALUE, COLLECTIVE, or NO-USER-MODIFICATION. There is no ordering matching rule specified, which means that the server will fall back on the default ordering rule used by the directory string syntax, and there is no X-APPROX extension to specify the approximate matching rule so the default approximate rule for the directory string syntax will be used there as well.
Attribute Type Inheritance #
As noted above, one attribute type can reference another as its superior class. This has two primary effects:
- The matching rule and attribute syntax specifications from the superior attribute type may be inherited by the subordinate type if it does not override the superior definition. For example, if the superior attribute type uses the "IA5 String" syntax, then the subordinate attribute type will also use the IA5 String syntax unless its definition overrides that by specifying an alternate syntax. According to the specification in RFC 4512
, section 2.5.1, an attribute type may have a different syntax than its superior type only if the syntax for the subordinate type is a refinement of (i.e., allows a subset of the values of) the syntax for the superior attribute type.
- The OID and/or any of the human-readable names associated with the superior attribute type may be used to collectively reference all of the subordinate types. For example, the name attribute type is referenced as the superior type for the cn, sn, c, l, st, o, ou, title, givenName, initials, generationQualifier, and dmdName attribute types. Therefore, a filter of "(name=test)" should match an entry if any attribute with one of those types has a value of "test".
It is not allowed for a subordinate attribute type to have a different usage than its superior type. That is, if the superior type is "userApplications", then the subordinate type must also be "userApplications". Similarly, if a superior type is declared COLLECTIVE then the subtype must also be COLLECTIVE, but if the superior type is not COLLECTIVE, then the subordinate type must also not be COLLECTIVE.
LDAPWiki try to implement AttributeTypes definitions using a consistent manner:
!! Attribute Definition
!! [LDAP] [Attribute] Definition
The [{$pagename}] [AttributeTypes] is defined as:
* [OID] of []
* [NAME|Attribute-Name]: [{$pagename}]
* [DESC]:
* [OBSOLETE flag] (only if present)
* [Supertype]:
** (only if present)
* [EQUALITY]: []
* [ORDERING]: []
* [SYNTAX]: []
* [SINGLE-VALUE] (only if present)
* [NO-USER-MODIFICATION] (only if present)
* [USAGE]: [UserApplications]
* [Extended Flags]:
** [X-ORIGIN]: []
* Used as [MUST] in:
**
* Used as [MAY] in:
**
For Microsoft Active Directory
!! [LDAP] [Microsoft Active Directory Attribute] Definition
The [{$pagename}] [AttributeTypes] is defined as:
* [CN|Cn]:
* [OID] of []
* [NAME|Attribute-Name]: [{$pagename}]
* [DESC]:
* [EQUALITY]: []
* [ORDERING]: []
* [SYNTAX]: []
* [LOWERBOUND]:
* [UPPERBOUND]:
* [OMSyntax]:
* [SchemaIDGUID]:
* [mapiID]:
* [SINGLE-VALUE] (only if present)
* [NO-USER-MODIFICATION] (only if present)
* [USAGE]: [UserApplications]
* [Extended Flags]:
** [X-ORIGIN]: []
* [X-SYSTEMFLAGS]
* [X-SCHEMAFLAGSEx]
* [X-SEARCH-FLAGS]
* Used as [MUST] in:
**
* Used as [MAY] in:
**
There might be more information for this subject on one of the following: