Policy Core Lightweight Directory Access Protocol (LDAP) Schema
updated by
- rfc-4104 — Policy Core Extension Lightweight Directory Access Protocol Schema (PCELS)
Extracted elements (30)
DIT structure rules and content rules were deliberately excluded from the PCLS, even though they add useful schema constraints, because X.500 requires a structural class with no superior structure rule to be a subschema administrative point (undesirable for policy), most LDAP servers do not support inheritance of these rules, and augmentation is required when auxiliary classes are subclassed.
DN references are included for rule-specific conditions even though a DIT subtree search below the rule would find them, because relying solely on subtree search risks missing conditions that belong there or finding ones inadvertently placed or not yet removed — though this comes at the cost of thwarting access control inheritance and referential integrity.
For each of pcimGroup and pcimRule, three classes are defined (abstract superclass, auxiliary subclass, structural subclass) rather than a single class. This provides maximum flexibility: auxiliary attachment allows co-location of policy data with other entries, while structural instances allow standalone policy entries.
LDAP aliases were removed from the schema in this version because the IETF has not produced a specification for how aliases are represented in the directory or how server implementations should process them, making their use unreliable across implementations.
The PCIM class PolicyTimePeriodCondition would normally map to pcimTimePeriodConditionAuxClass, but this name exceeds the maximum length supported by some directories; it was therefore abbreviated to pcimTPCAuxClass.
The pcimKeywords attribute supports a special value 'POLICY' as a fallback tagging mechanism for directory implementations that do not support auxiliary class matching in the objectClass attribute, ensuring PDPs can still locate all policy-relevant entries.
Current LDAP servers vary considerably in their support for DIT content rules, DIT structure rules, and name forms, and most do not support inheritance of structure and content rules; the PCLS therefore omits these constructs as normative elements to avoid interoperability barriers.
LDAP class names in the PCLS begin with a lowercase character (e.g., pcimPolicy) rather than uppercase as in the information model, because X.500 does not allow class names to begin with an uppercase character, even though LDAP itself is case-insensitive.
Some LDAP directory implementations do not support matching of auxiliary classes in the objectClass attribute; in those environments, entries relevant to policy should be tagged by inserting the special keyword 'POLICY' into the pcimKeywords multi-valued attribute rather than relying on objectClass filtering.
A PDP MUST be able to use a less efficient means of retrieval if pcimSubtreesPtrAuxClass optimization is not available to it; SHOULD understand the class, be capable of retrieving subtree entries, and doing so recursively.
A policy rule SHALL NOT have either its conditions or its actions attached both to itself and to other entries simultaneously, with one exception: a policy rule may reference validity periods via pcimRuleValidityPeriodList while having other conditions attached to itself.
All subclasses of pcimConditionAuxClass and pcimActionAuxClass MUST also be auxiliary classes, in order to preserve the ability to represent rule-specific or reusable conditions/actions and simple policy rules.
If any attribute constraint is violated (e.g., invalid enumeration value, negative integer where non-negative required), the policy rule SHOULD be treated as being disabled and its execution SHOULD be stopped.
If the value of the pcimRoles attribute does not conform to the format '<RoleName>[&&<RoleName>]*' with role names in alphabetical UCS-2 collating order, the attribute is malformed and the policy rule SHOULD be treated as disabled.
Implementations that use an LDAP directory as their policy repository and want to implement policy information according to RFC 3060 SHALL use the LDAP schema defined in this document, or a schema that subclasses from the schema defined in this document.
It is recommended that two or more naming attributes SHOULD NOT be used together to form a multi-part RDN, since support for multi-part RDNs is limited among existing directory implementations.
Since any of the three naming attributes (class-specific name, cn, orderedCimKeys) MAY be used for naming an instance of a PCLS class, implementations MUST be able to accommodate instances named in any of these ways.
The pcimRulePriority value of 0 SHOULD be treated as 'don't care'; a negative value SHOULD be treated as an error and administrators SHOULD treat the rule as disabled.
pcimConditionAuxClass (OID 1.3.6.1.1.6.1.11) is an auxiliary class rooted at 'top' that introduces the semantics of being a policy condition. Subclasses of this class represent actual conditions and are attached to pcimRuleConditionAssociation (rule-specific) or pcimPolicyInstance (reusable).
pcimPolicy is the abstract base class for all LDAP classes representing policy-related instances. It provides MAY attributes cn, dlmCaption, dlmDescription, orderedCimKeys, and pcimKeywords (a multi-valued keyword set for directory client filtering). OID: 1.3.6.1.1.6.1.1.
pcimRuleActionAssociation (OID 1.3.6.1.1.6.1.10) is a structural class held under pcimRule via DIT containment. It MUST carry pcimActionOrder (unsigned integer; 0 = order irrelevant; negative is an error disabling the rule) and MAY carry pcimActionName and pcimActionDN (DN to reusable action).
pcimRuleConditionAssociation (OID 1.3.6.1.1.6.1.8) is a structural class held under pcimRule via DIT containment. It MUST carry pcimConditionGroupNumber (non-negative integer identifying DNF/CNF group) and pcimConditionNegated (Boolean), and MAY carry pcimConditionName and pcimConditionDN (DN to reusable condition).
pcimRuleValidityAssociation (OID 1.3.6.1.1.6.1.9) is a structural class that binds scheduled activation/deactivation times to a policy rule, either via an attached pcimTPCAuxClass or via the DN attribute pcimTimePeriodConditionDN referencing a reusable time period condition.
pcimSubtreesPtrAuxClass is an LDAP-only auxiliary class carrying a multi-valued DN attribute that points to subtrees containing policy-related objects. A PDP is configured with an initial DN, retrieves this class, then issues subtree searches against each referenced anchor — enabling retrieval of all relevant policy entries in as few as three LDAP operations.
pcimTPCAuxClass (OID 1.3.6.1.1.6.1.12) is an auxiliary subclass of pcimConditionAuxClass providing time-based activation scheduling. Its MAY attributes include pcimTPCTime, pcimTPCMonthOfYearMask, pcimTPCDayOfMonthMask, pcimTPCDayOfWeekMask, pcimTPCTimeOfDayMask, and pcimTPCLocalOrUtcTime.
The three policy group classes — abstract pcimGroup (OID 1.3.6.1.1.6.1.2), auxiliary pcimGroupAuxClass (1.3.6.1.1.6.1.3), and structural pcimGroupInstance (1.3.6.1.1.6.1.4) — collectively map the PCIM PolicyGroup class, providing maximum DIT design flexibility. The single attribute pcimGroupName is a user-friendly, optionally naming string.
The three policy rule classes — abstract pcimRule (OID 1.3.6.1.1.6.1.5), auxiliary pcimRuleAuxClass (1.3.6.1.1.6.1.6), and structural pcimRuleInstance (1.3.6.1.1.6.1.7) — map PCIM's PolicyRule. pcimRule defines 11 MAY attributes covering name, enabled state, condition/action/validity DN lists, usage, priority, mandatory flag, sequenced-action ordering, and role-combinations.
Section 8 registers a set of LDAP object identifiers (OIDs) under the arc 1.3.6.1.1.6 for the 23 PCLS classes and their attributes, and registers corresponding OID descriptors (short names like 'pcimPolicy', 'pcimRule', etc.) in the IANA LDAP Descriptor registry.
Reusable conditions and actions stored under pcimRepository instances require access control expressions that are independent of any specific policy rule, creating a broader attack surface than rule-specific conditions whose permissions naturally mirror those of their parent rule.
The PCLS stores policy rules that control access to and management of network resources; unauthorized modification of policy entries could allow an attacker to grant excessive privileges, deny service, or otherwise subvert network administration. Implementations MUST apply appropriate LDAP access controls to all pcimPolicy subtree entries.