[This is preliminary documentation and subject to change.]
Attributes are defined by Attribute-Schema objects. Like all other directory service (DS) objects, each Attribute-Schema object has attributes that define it. If this seems confusing, that's because it is. If you haven't done so, now would be a good time to look at the Directory Service Terminology section.
An entry in the attribute table has the following attribute-value pairs (with one exception) that describe the Attribute.
Common-Name | Every object in the DS has a naming attribute from which its Relative Distinguished Name (RDN) is formed. The Naming Attribute for Attribute-Schema objects is Common-Name. The value assigned to Common-Name is the value that the Attribute-Schema will have as its Relative Distinguished Name, in this case "Access Permissions". |
Admin-Display-Name | The Common-Name of a given object might not be descriptive enough for use in administration tools. Admin-Display-Name is available for tools to use as a display name for an attribute when the naming attribute is not appropriate. |
Admin-Description | Can hold additional descriptive text for use by an administrative application. Generally this attribute is identical in value to the Admin-Display-Name. |
Object-Class | Every object in the DS is an instance of a known Object Class. Attribute definitions are all of Object Class Attribute-Schema. |
Attribute-ID | An OID uniquely identifying this attribute. OIDs are discussed in the DS Terminology section. |
OM-Syntax | Syntax of this attribute as defined by the XAPIA XOM (X/Open Object Model) specification. This model provides a relatively fine-grained definition of syntax. For example, there are distinct OM-Syntaxes to distinguish among several types of printable strings, based on the supported character set, whether case is significant, etc. XOM provides a further refinement in OM-Syntax - "Object". "Object" syntax uses a third attribute, OM-Object-Class (an OID), to uniquely identify the type of object referred to. |
Attribute-Syntax | Syntax of this attribute. Attribute-Syntax may be further refined by OM-Syntax. In practice, the Attribute-Syntaxes used in the NTDS each map onto a unique OM-Syntax, so further clarification is not needed. Attribute-Syntaxes that identify attributes with a complex structure have an OM-Syntax of 127, indicating an "object", and an OM-Object-Identifier that identifies the object in question. |
OM-Object-Class | If the OM-Syntax of the attribute is 127, indicating an "object" syntax, the OM-Object-Class is an OID identifying the "object" syntax in question. |
LDAP-Display-Name | The name of this attribute as known to the LDAP agent for the NTDS. This is the name LDAP clients must use to read or write this attribute. Note that Active Directory clients access the NTDS using LDAP, so these names are the names to use with Active Directory when reading and writing attributes via the Active Directory Get and Put methods. |
Single- or Multi-Valued | The Exception. Stored in the DS as Single-Valued=TRUE or FALSE, the Schema Browser reports this as "single-valued." or "multi-valued" rather than as an attribute-value pair. Attributes in the NTDS may be single-valued or multi-valued. A multi-valued attribute can contain multiple values, all of uniform syntax. |
System-Only | System-only properties can only be changed by the Directory System Agent (DSA). System-only properties are those that Windows NT and the NTDS depend on for normal operations. For example, Attribute-ID and Governs-ID OIDs in the schema are system-only properties. |
Schema-ID-GUID | A Globally Unique Identifier (GUID) that uniquely identifies all classes and attributes in the schema. Unlike OIDs, which are issued by a central authority, GUIDs are generated by a special algorithm. GUIDs are fixed length and can be dealt with more efficiently than OIDs. The NTDS uses OIDs for interoperability with external clients and GUIDs internally for efficiency. |
Comment | A brief explanation of what the attribute is used for. This is not stored in the schema, it is stored in the schema source and included in the documentation. |