Hi,
I want to have some kind of dn-based association between two custom entries (e.g. account<--dn-->device). Therefore I use a combination of the memberOf- and refint overlay (configuration inspired by test057).
I use a custom schema: An auxiliary objectClass called "association". It has only one may-attribute called "associate". The custom 'memberOf'-Attribute is called "associationOf", which is a may-attribute of the objectClass "myAccount" (derived from account):
OpenLDAP Version: git OPENLDAP_REL_ENG_2_4
#example.com.schema # attributeType ( 1.3.6.1.4.1.9999999.10.1.1 NAME 'associate' DESC 'an associate' SUP distinguishedName )
attributeType ( 1.3.6.1.4.1.9999999.10.1.2 NAME 'associateOf' DESC 'associate of' SUP distinguishedName )
objectClass ( 1.3.6.1.4.1.9999999.10.2.1 NAME 'association' DESC 'association' SUP top AUXILIARY MAY ( associate ) )
objectClass ( 1.3.6.1.4.1.9999999.10.2.2 NAME 'myAccount' DESC 'my account' SUP account STRUCTURAL MAY ( associateOf ) )
#slapd.conf # include /opt/slapd_example.com/etc/openldap/schema/core.schema include /opt/slapd_example.com/etc/openldap/schema/cosine.schema include /opt/slapd_example.com/etc/openldap/schema/ppolicy.schema include /opt/slapd_example.com/etc/example.com.schema
pidfile /opt/slapd_example.com/var/run/slapd.pid argsfile /opt/slapd_example.com/var/run/slapd.args
loglevel none password-hash {CLEARTEXT} attributeOptions lang-
access to dn.base="" by * read access to dn.base="cn=Subschema" by * read
database config rootdn "cn=admin,dc=example,dc=com"
database mdb suffix "dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" rootpw "admin" directory /opt/slapd_example.com/var/openldap-data index objectClass,cn,ou,o,dc eq
add_content_acl on
overlay memberof memberof-group-oc association memberof-member-ad associate memberof-memberof-ad associateOf memberof-dangling ignore memberof-refint FALSE memberof-dn olcOverlay={1}memberof,olcDatabase={2}mdb,cn=config
overlay refint refint_attributes associate associateOf refint_nothing olcOverlay={0}refint,olcDatabase={2}mdb,cn=config refint_modifiersname olcOverlay={0}refint,olcDatabase={2}mdb,cn=config
#After starting the server, first I add a custom account: # cat << EOF | ldapmodify -x -H "ldap://localhost:2389/" -D "cn=admin,dc=example,dc=com" -w admin dn: uid=myAccount,dc=example,dc=com changetype: add objectClass: top objectClass: myAccount uid: myAccount
EOF
#Then I add a naked device: # cat << EOF | ldapmodify -x -H "ldap://localhost:2389/" -D "cn=admin,dc=example,dc=com" -w admin dn: cn=device,dc=example,dc=com changetype: add objectClass: top objectClass: device cn: device
EOF
Now I try to associate them using a single modify operation (adding the aux-objectClass association and the associate attribute). This approach fails, that means: The operation passes without error, but the account's associationOf attribute isn't added.
#This modify operation seems to be ignored by memberOf-overlay: # cat << EOF | ldapmodify -x -H "ldap://localhost:2389/" -D "cn=admin,dc=example,dc=com" -w admin dn: cn=device,dc=example,dc=com changetype: modify add: objectClass objectClass: association - add: associate associate: uid=myAccount,dc=example,dc=com -
EOF
#slapd-log (loglevel -1), see attached all-inclusive-modify.log
#Checking the results: # ldapsearch -x -H "ldap://localhost:2389/" -D "cn=admin,dc=example,dc=com" -w admin -b "dc=example,dc=com" -s one '(objectClass=*)'
# extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope oneLevel # filter: (objectClass=*) # requesting: ALL #
# device, example.com dn: cn=device,dc=example,dc=com objectClass: top objectClass: device objectClass: association cn: device associate: uid=myAccount,dc=example,dc=com
# myAccount, example.com dn: uid=myAccount,dc=example,dc=com objectClass: top objectClass: myAccount uid: myAccount
# search result search: 2 result: 0 Success
# numResponses: 3 # numEntries: 2
The second approach (resetting the device and myAccount entry and split the above modify operation into two operations works fine. Details see here:
#Splitting the previous modify operation into two works fine: # cat << EOF | ldapmodify -x -H "ldap://localhost:2389/" -D "cn=admin,dc=example,dc=com" -w admin dn: cn=device,dc=example,dc=com changetype: modify add: objectClass objectClass: association
EOF
cat << EOF | ldapmodify -x -H "ldap://localhost:2389/" -D "cn=admin,dc=example,dc=com" -w admin dn: cn=device,dc=example,dc=com changetype: modify add: associate associate: uid=myAccount,dc=example,dc=com
EOF
#slapd-log (loglevel -1), see attached split-modify.log
#Checking the results: # ldapsearch -x -H "ldap://localhost:2389/" -D "cn=admin,dc=example,dc=com" -w admin -b "dc=example,dc=com" -s one '(objectClass=*)'
# extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope oneLevel # filter: (objectClass=*) # requesting: ALL #
# device, example.com dn: cn=device,dc=example,dc=com objectClass: top objectClass: device objectClass: association cn: device associate: uid=myAccount,dc=example,dc=com
# myAccount, example.com dn: uid=myAccount,dc=example,dc=com objectClass: top objectClass: myAccount uid: myAccount associateOf: cn=device,dc=example,dc=com
# search result search: 2 result: 0 Success
# numResponses: 3 # numEntries: 2
Long story, short question: Is this the intended behaviour? If not is it caused by a misconfiguration or a bug?
Thank you very much for your help!
Best regards Dora