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