Is your feature request related to a problem? Please describe.
The lack of this feature is not currently impeding any project of mine, but I see this as being potentially favorable to those directory service engineers with backgrounds in cyber security.
Describe the solution you'd like
Control over the naming of entries should be possible by way of name forms and DIT structure rules.
Name forms and DIT structure rules are defined within RFC 4512 (to a small degree) and ITU-T Rec. X.501. For the sake of completeness, I'm going to assume the reader is unfamiliar with these most excellent concepts.
Name forms are globally-scoped and registered schema definitions which express two important components for evaluation during the LDAP Add or ModifyDN of an entry.
The STRUCTURAL object class (clause "OC")
The required and optional attribute OID(s) (clauses "MUST" and "MAY")
These clauses are used to declare what attributes are required (and optionally permitted) for use in the naming of the RDN held by an entry bearing the specified STRUCTURAL object class.
For example, consider the following name form per RFC 2273:
( 1.3.6.1.1.2.1
NAME 'domainNameForm'
OC domain
MUST dc )
This name form states that entries which bear the domainSTRUCTURAL object class MUST utilize the dc attribute type for the attribute type of the RDN.
However, name forms are totally inert by themselves, and do not serve any function unless actively referenced by a DIT structure rule.
A DIT structure rule is a non-registered schema definition with a scope limited to the administrative area of the DIT in question. Its purpose is to reference a name form and enforce it where LDAP Add or ModifyDN operations are concerned.
For example, to draw from the above name form example, the following DIT structure rule could be set to begin enforcing the naming strategy:
( 0
NAME 'domainStructureRule'
FORM domainNameForm )
DIT structure rules also allow subordination as is observed with object classes via the SUP clause. For example, given the following name form and DIT structure rule, we can associate the naming policy desired for entries below the domain entry:
( 1.3.6.1.4.1.56521.999
NAME 'ouNameForm'
OC organizationalUnit
MUST ou )
( 1
NAME 'ouStructureRule'
FORM ouNameForm
SUP ( 0 1 ) )
Here, we've chosen the common ou naming strategy for entries subordinate to the domain entry. This is achieved by referencing the structure rule integer identifier "0" as the superior structure rule. Also, by adding "1" as a superior structure rule (itself), we can allow multiple levels of OUs, e.g.: "ou=Consultants,ou=Accounts,dc=example,dc=com", through recursion.
Attempts to violate an established policy in an administrative area governed in this manner shall return a naming violation, or result code "64".
DIT structure rules and name forms shall have no impact upon entries already present, only those indicated via LDAP Add and ModifyDN.
Entries currently under governance of a DIT structure rule shall bear the governingStructureRule operational attribute, thereby indicating what structure rule it honors.
As you can see, DIT structure rules and name forms are extremely powerful naming governance features. They also have the virtue of being more favorable to cyber security professionals, as their management does NOT involve the modification of acis (a practice that is generally discouraged where DIT structure rules and name forms are supported).
Describe alternatives you've considered
As mentioned earlier, use of acis to effect this kind of behavior is generally discouraged. This introduces comparatively high levels of risk. Management of these naming policies within the schema would be far more preferable, and has few to no security implications.
Additional context
I've made a few contributions to the OpenDJ project in the form of documentation. DIT structure rules and name forms were not covered in their documentation, thus I added a new section recently. Feel free to read it if you'd like to learn more these concepts.
Considerations should be made for offline LDIF loads in addition to online LDAP Add or ModifyDN operations. For example, should DIT structure rules and name forms be implemented within a DIT long after that DIT was created, offline load "issues" could arise if the DIT structure rules being used to not reflect the data being loaded. This may be mitigated with an override flag, or perhaps ignored altogether during offline loads. I think that is a more appropriate question for the devs to answer someday.
In closing, while C++ is not my language of choice, I am willing and able to serve in an advisory/SME capacity for this issue, as I have a great deal of experience with this subject matter. I can assist with standards compliance and test cases at the very least.
JesseCoretta
commented
3 weeks ago
Is your feature request related to a problem? Please describe.
The lack of this feature is not currently impeding any project of mine, but I see this as being potentially favorable to those directory service engineers with backgrounds in cyber security.
Describe the solution you'd like
Control over the naming of entries should be possible by way of name forms and DIT structure rules.
Name forms and DIT structure rules are defined within RFC 4512 (to a small degree) and ITU-T Rec. X.501. For the sake of completeness, I'm going to assume the reader is unfamiliar with these most excellent concepts.
Name forms are globally-scoped and registered schema definitions which express two important components for evaluation during the LDAP Add or ModifyDN of an entry.
STRUCTURALobject class (clause "OC")These clauses are used to declare what attributes are required (and optionally permitted) for use in the naming of the RDN held by an entry bearing the specified
STRUCTURALobject class.For example, consider the following name form per RFC 2273:
This name form states that entries which bear the
domainSTRUCTURALobject class MUST utilize thedcattribute type for the attribute type of the RDN.However, name forms are totally inert by themselves, and do not serve any function unless actively referenced by a DIT structure rule.
A DIT structure rule is a non-registered schema definition with a scope limited to the administrative area of the DIT in question. Its purpose is to reference a name form and enforce it where LDAP Add or ModifyDN operations are concerned.
For example, to draw from the above name form example, the following DIT structure rule could be set to begin enforcing the naming strategy:
DIT structure rules also allow subordination as is observed with object classes via the
SUPclause. For example, given the following name form and DIT structure rule, we can associate the naming policy desired for entries below thedomainentry:Here, we've chosen the common
ounaming strategy for entries subordinate to thedomainentry. This is achieved by referencing the structure rule integer identifier "0" as the superior structure rule. Also, by adding "1" as a superior structure rule (itself), we can allow multiple levels of OUs, e.g.: "ou=Consultants,ou=Accounts,dc=example,dc=com", through recursion.Attempts to violate an established policy in an administrative area governed in this manner shall return a naming violation, or result code "64".
Subentries should NOT be governed by name forms and DIT structure rules in the conventional sense. See my Subentry Name Form I-D and ITU-T Rec. X.501 clause 14.2.
DIT structure rules and name forms shall have no impact upon entries already present, only those indicated via LDAP Add and ModifyDN.
Entries currently under governance of a DIT structure rule shall bear the
governingStructureRuleoperational attribute, thereby indicating what structure rule it honors.As you can see, DIT structure rules and name forms are extremely powerful naming governance features. They also have the virtue of being more favorable to cyber security professionals, as their management does NOT involve the modification of
acis (a practice that is generally discouraged where DIT structure rules and name forms are supported).Describe alternatives you've considered
As mentioned earlier, use of
acis to effect this kind of behavior is generally discouraged. This introduces comparatively high levels of risk. Management of these naming policies within the schema would be far more preferable, and has few to no security implications.Additional context
I've made a few contributions to the OpenDJ project in the form of documentation. DIT structure rules and name forms were not covered in their documentation, thus I added a new section recently. Feel free to read it if you'd like to learn more these concepts.
Considerations should be made for offline LDIF loads in addition to online LDAP Add or ModifyDN operations. For example, should DIT structure rules and name forms be implemented within a DIT long after that DIT was created, offline load "issues" could arise if the DIT structure rules being used to not reflect the data being loaded. This may be mitigated with an override flag, or perhaps ignored altogether during offline loads. I think that is a more appropriate question for the devs to answer someday.
In closing, while C++ is not my language of choice, I am willing and able to serve in an advisory/SME capacity for this issue, as I have a great deal of experience with this subject matter. I can assist with standards compliance and test cases at the very least.
Thank you,
Jesse Coretta