10:43 a.m.
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.
1:24 p.m.
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
4:01 a.m.
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.
8:29 a.m.
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 !?
4093
days inactive
4097
days old
openldap-technical@openldap.org
3 comments
3 participants
participants (3)
-
jehan procaccia -
Jehan PROCACCIA
-
Marvin Mundry