Hello I installed a new openldap replica (openldap-servers-2.4.23-20.el6.i686) , with a partial replication enabled by restricting certain branches/attributes to the binddn account that replicate from the master. However, on some operation (modify userPassword for example) the modification fails:
Mar 22 17:51:20 ldapz2 slapd[24456]: No structuralObjectClass for entry (uid=bde,ou=People,dc=int-evry,dc=fr) Mar 22 17:51:20 ldapz2 slapd[24456]: entry failed schema check: no structuralObjectClass operational attribute Mar 22 17:51:20 ldapz2 slapd[24456]: null_callback : error code 0x50 Mar 22 17:51:20 ldapz2 slapd[24456]: syncrepl_entry: rid=001 be_modify failed (80) Mar 22 17:51:20 ldapz2 slapd[24456]: do_syncrepl: rid=001 rc 80 retrying (9 retries left)
what's wrong ? could it be related to the fact that the binddn account cannot read all attributes from the master ? I did checked that he can read userpassword attribute though . is there an ACL to be set to hte replica binddn account to allow him to read operational attributes ?
thanks for your help.
Mar 22 17:51:20 ldapz2 slapd[24456]: entry failed schema check: no structuralObjectClass operational attribute
could it be related to the fact that the binddn account cannot read all attributes from the master ?
sounds like the replication user is not allowed to read the structuralObjectClass attribute of the object that's userPassword gets modified.
on the provider try: ldapsearch -D cn=replicationuser,[...] -w replicationuser-password -b [...]dc=domain,dc=com cn=user-with-changed-password +
by appending the + symbol you request all structural attributes. if structuralObjectClass is not returned try adapting your acls.
bests, Marvin
Le 22/03/2012 21:24, Marvin Mundry a écrit :
Mar 22 17:51:20 ldapz2 slapd[24456]: entry failed schema check: no structuralObjectClass operational attribute could it be related to the fact that the binddn account cannot read all attributes from the master ?
sounds like the replication user is not allowed to read the structuralObjectClass attribute of the object that's userPassword gets modified.
on the provider try: ldapsearch -D cn=replicationuser,[...] -w replicationuser-password -b [...]dc=domain,dc=com cn=user-with-changed-password +
by appending the + symbol you request all structural attributes. if structuralObjectClass is not returned try adapting your acls.
bests, Marvin
OK, I tried to search for operational attribute with the replica binddn from the replica to the master:
ldapsearch -x uid=test -H ldap://master.it-sudparis.eu -D cn=replic,ou=System,dc=int-evry,dc=fr -W userpassword cn + result is # test, People, int-evry.fr dn: uid=test,ou=People,dc=int-evry,dc=fr createTimestamp: 20080910055004Z cn: Jehan TEST userPassword:: XXXXXXXXXXXXXXXXXXXXXXRcTZYS0ZULi5OXXXXXXXXXXXX modifyTimestamp: 20120322172339Z
so I did get some operational attributes, but apparently not all ! what kind of ACL do I need to set to allow all operational attributes to that binddn ?
Thanks.
Le 23/03/2012 12:01, jehan procaccia a écrit :
Le 22/03/2012 21:24, Marvin Mundry a écrit :
Mar 22 17:51:20 ldapz2 slapd[24456]: entry failed schema check: no structuralObjectClass operational attribute could it be related to the fact that the binddn account cannot read all attributes from the master ?
sounds like the replication user is not allowed to read the structuralObjectClass attribute of the object that's userPassword gets modified.
on the provider try: ldapsearch -D cn=replicationuser,[...] -w replicationuser-password -b [...]dc=domain,dc=com cn=user-with-changed-password +
by appending the + symbol you request all structural attributes. if structuralObjectClass is not returned try adapting your acls.
bests, Marvin
OK, I tried to search for operational attribute with the replica binddn from the replica to the master:
ldapsearch -x uid=test -H ldap://master.it-sudparis.eu -D cn=replic,ou=System,dc=int-evry,dc=fr -W userpassword cn + result is # test, People, int-evry.fr dn: uid=test,ou=People,dc=int-evry,dc=fr createTimestamp: 20080910055004Z cn: Jehan TEST userPassword:: XXXXXXXXXXXXXXXXXXXXXXRcTZYS0ZULi5OXXXXXXXXXXXX modifyTimestamp: 20120322172339Z
so I did get some operational attributes, but apparently not all ! what kind of ACL do I need to set to allow all operational attributes to that binddn ?
Thanks.
I finaly come to a solution of enumarating all the operational attributes to be read by the binddn of the replic user: access to attrs=modifyTimestamp,createTimestamp,structuralObjectClass,creatorsName,entryCSN,modifiersName,subschemaSubentry,hasSubordinates by self write by dn="cn=admin,dc=int-evry,dc=fr" write by dn="cn=replic,ou=System,dc=int-evry,dc=fr" read
but i'am not sure it's the best way to do it !?
moreover, I had an acl rule below that one that allowed read to only modifyTimestamp attribute:
access to dn.subtree="ou=Group,ou=System,dc=int-evry,dc=fr" attrs=cn,sn,modifyTimestamp by dn="cn=admin,dc=int-evry,dc=fr" write by dn="cn=replic,ou=System,dc=int-evry,dc=fr" read
I wonder what happen then for ou=Group,ou=System,dc=int-evry,dc=fr sub-objects will they inherit 1st rules allowing read on all operational attributes, or will it have acces only to modifyTimestamp !?
openldap-technical@openldap.org
-
jehan procaccia -
Jehan PROCACCIA
-
Marvin Mundry