Michael Ströder wrote:
HI!
I've declared an attribute type like this with LDAP syntax OID:
( 1.3.6.1.4.1.5427.1.389.100.4.18 NAME 'aeApplicableSOC' DESC 'AE-DIR: structural object classes for which policy is applicable' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 X-ORIGIN 'AE-DIR' )
Which is pretty similar to this:
( 2.5.4.0 NAME 'objectClass' DESC 'RFC4512: object classes of the entity' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
Now I wonder why I can't use the object class NAMEs instead of the OIDs as attribute or assertion values, e.g. why I can't find the entries with filter (aeApplicableSOC=aeUser).
This reminds me a bit of the similar OID vs. NAME issue with 'pwdAttribute' in 'pwdPolicy' entries.
It's the exact same issue. The objectIdentifierMatch function only works with numeric OIDs. The ppolicy overlay inserts its own matching function to make the name work.
Eventual I'd like to have a constraint like this:
# check whether appropriate password policy is assigned constraint_attribute structuralObjectClass,pwdPolicySubentry set "this/structuralObjectClass & this/pwdPolicySubentry/aeApplicableSOC"
Not possible without custom code.
Ciao, Michael.
Howard Chu wrote:
Michael Ströder wrote:
Eventual I'd like to have a constraint like this:
# check whether appropriate password policy is assigned constraint_attribute structuralObjectClass,pwdPolicySubentry set "this/structuralObjectClass & this/pwdPolicySubentry/aeApplicableSOC"
Not possible without custom code.
Hmm, are this/structuralObjectClass and this/pwdPolicySubentry generally unusable in set-constraints?
Or does it not work because of the different matching rules?
I'm asking because this constraint is not applied at all (with aeApplicableSOC declared as IA5 String, lines wrapped in the e-mail):
constraint_attribute pwdPolicySubentry set "this/pwdPolicySubentry & ([ldap:///{{ aedir_suffix }}?entryDN?sub? (&(objectClass=aePolicy)(aeStatus=0)(aeApplicableSOC=] + this/structuralObjectClass + [))]/entryDN)"
Ciao, Michael.
openldap-technical@openldap.org