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