My setup is rather basic. ldaps://ldap.ipodion.at is master/sync provider. "consumer" is slave/consumer. Everything seems to be working fine, all attributes are replicated with the notable exception of the userPassword attribute. ldapsearch on the consumer shows the missing attributes, so it can't be a permissions problem:
consumer # ldapsearch -x -LL -D "cn=admin,dc=ipodion,dc=at" -W -H ldaps://ldap.ipodion.at -b "dc=int,dc=ipodion,dc=at" "(objectClass=person)" uidNumber userpassword Enter LDAP Password: version: 1
dn: cn=NextFreeUnixId,dc=int,dc=ipodion,dc=at uidNumber: 10007
dn: uid=tkircht,ou=people,dc=int,dc=ipodion,dc=at uidNumber: 500 userPassword:: e1NNRDV9dXZ1UkxMY1VDaThMSktablRSazJWMElCU2l
dn: uid=Administrator,ou=People,dc=int,dc=ipodion,dc=at uidNumber: 0 userPassword:: e1NNRDV9c2swZEtCMzUyb2JQTkRucTcxcDczc0VScXpB [...]
I added the acl for uidNumber just to make sure I didn't mistype any credential information, but the uidNumber attribute is replicated the user Password isn't.. I cannot find anything on this in the archives or the documentation - what am I doing wrong here?!
Any help would be appreciated
thanks, Thomas
Config files:
--------------------------------------------------------- provider: --------------------------------------------------------- ldap:~# grep -v '^#' /etc/ldap/slapd.conf | grep -v '^$' allow bind_v2 include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/samba.schema include /etc/ldap/schema/extension.schema schemacheck on pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args TLSCertificateFile /etc/ssl/certs/ldap.ipodion.cert.pem TLSCertificateKeyFile /etc/ssl/private/ldap.ipodion.key.pem TLSCACertificateFile /usr/share/ca-certificates/cacert.org/root.crt loglevel -1 modulepath /usr/lib/ldap moduleload back_bdb moduleload back_meta moduleload syncprov backend bdb database bdb suffix "dc=ipodion,dc=at" directory "/var/lib/ldap" overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 index objectClass eq index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub lastmod on rootdn "cn=admin,dc=ipodion,dc=at" rootpw <secret> access to attrs=userPassword by dn="cn=admin,dc=ipodion,dc=at" write by anonymous auth by self write by * none access to attrs=uidNumber by dn="cn=admin,dc=ipodion,dc=at" write by anonymous auth by self write by * none access to dn.subtree="ou=addressbook,dc=ipodion,dc=at" by self write by dn="cn=admin,ou=addressbook,dc=ipodion,dc=at" write by * read access to dn.base="" by * read access to * by dn="cn=admin,dc=ipodion,dc=at" write by * read
--------------------------------------------------------- consumer: --------------------------------------------------------- consumer:~# grep -v '^#' /etc/ldap/slapd.conf | grep -v '^$' allow bind_v2 include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/samba.schema schemacheck on pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args TLSCACertificateFile /etc/ssl/CA/cacert.pem loglevel 256 modulepath /usr/lib/ldap moduleload back_bdb backend bdb database bdb suffix "dc=int,dc=ipodion,dc=at" directory "/var/lib/ldap" index objectClass eq index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub lastmod on rootdn "cn=admin,dc=int,dc=ipodion,dc=at" rootpw {SSHA}<secret2> syncrepl rid=667 provider=ldaps://ldap.ipodion.at type=refreshOnly interval=01:00:00:00 searchbase="dc=int,dc=ipodion,dc=at" scope=sub schemachecking=on bindmethod=simple binddn="cn=admin,dc=ipodion,dc=at" credentials=<secret> access to attrs=userPassword by dn="cn=admin,dc=int,dc=ipodion,dc=at" write by anonymous auth by self write by * none access to dn.base="" by * read access to * by dn="cn=admin,dc=int,dc=ipodion,dc=at" write by * read
--On Tuesday, January 01, 2008 7:16 PM +0100 Thomas Kirchtag tkircht@ipodion.at wrote:
syncrepl rid=667 provider=ldaps://ldap.ipodion.at type=refreshOnly interval=01:00:00:00 searchbase="dc=int,dc=ipodion,dc=at" scope=sub schemachecking=on bindmethod=simple binddn="cn=admin,dc=ipodion,dc=at" credentials=<secret> access to attrs=userPassword by dn="cn=admin,dc=int,dc=ipodion,dc=at" write by anonymous auth by self write by * none
Seems clear to me. It can't write it. Note that the identity that can write is:
by dn="cn=admin,dc=int,dc=ipodion,dc=at" write
but syncrepl is acting as:
binddn="cn=admin,dc=ipodion,dc=at"
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Tuesday, January 01, 2008 7:16 PM +0100 Thomas Kirchtag tkircht@ipodion.at wrote:
syncrepl rid=667 provider=ldaps://ldap.ipodion.at type=refreshOnly interval=01:00:00:00 searchbase="dc=int,dc=ipodion,dc=at" scope=sub schemachecking=on bindmethod=simple binddn="cn=admin,dc=ipodion,dc=at" credentials=<secret> access to attrs=userPassword by dn="cn=admin,dc=int,dc=ipodion,dc=at" write by anonymous auth by self write by * none
Seems clear to me. It can't write it. Note that the identity that can write is:
by dn="cn=admin,dc=int,dc=ipodion,dc=at" write
but syncrepl is acting as:
binddn="cn=admin,dc=ipodion,dc=at"
According to the configuration files posted, the user "cn=admin,dc=ipodion,dc=at" is used as binddn by the consumer, but it is the rootdn on the producer, so it can read all values (the real, harmless error is that there's no point in authorizing access for the rootdn: it has unlimited access privileges). Local writes by syncrepl are performed with the local rootdn's identity, so there's no point in authorizing them either.
Right now, I don't seem to be able to find a reason for the incomplete replication. I note that no software version was mentioned, so unless the latest is used, there might be already resolved issues. After checking with the configuration files you provided, I note that OpenLDAP 2.3.40 correctly replicates userPassword as well as all other attrs.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
I am using OpenLDAP 2.3.25 (most current in Debian stable). I tried to follow Quanahs suggestion and added
access to * by dn="cn=admin,dc=int,dc=ipodion,dc=at" write by * read
on the consumer side, but it didn't change anything. I delete /var/lib/ldap/* and startet slapd but still: consumer /etc/ldap# slapcat | grep userPass consumer /etc/ldap#
I'd hate to leave the commodity of package management by installing the openLDAP tar-ball but if no other solution is available I will have to...
Thanks for your help so far!
Thomas
Pierangelo Masarati schrieb:
Quanah Gibson-Mount wrote:
--On Tuesday, January 01, 2008 7:16 PM +0100 Thomas Kirchtag tkircht@ipodion.at wrote:
syncrepl rid=667 provider=ldaps://ldap.ipodion.at type=refreshOnly interval=01:00:00:00 searchbase="dc=int,dc=ipodion,dc=at" scope=sub schemachecking=on bindmethod=simple binddn="cn=admin,dc=ipodion,dc=at" credentials=<secret> access to attrs=userPassword by dn="cn=admin,dc=int,dc=ipodion,dc=at" write by anonymous auth by self write by * none
Seems clear to me. It can't write it. Note that the identity that can write is:
by dn="cn=admin,dc=int,dc=ipodion,dc=at" write
but syncrepl is acting as:
binddn="cn=admin,dc=ipodion,dc=at"
According to the configuration files posted, the user "cn=admin,dc=ipodion,dc=at" is used as binddn by the consumer, but it is the rootdn on the producer, so it can read all values (the real, harmless error is that there's no point in authorizing access for the rootdn: it has unlimited access privileges). Local writes by syncrepl are performed with the local rootdn's identity, so there's no point in authorizing them either.
Right now, I don't seem to be able to find a reason for the incomplete replication. I note that no software version was mentioned, so unless the latest is used, there might be already resolved issues. After checking with the configuration files you provided, I note that OpenLDAP 2.3.40 correctly replicates userPassword as well as all other attrs.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it
Thomas Kirchtag wrote:
I am using OpenLDAP 2.3.25 (most current in Debian stable). I tried to follow Quanahs suggestion and added
access to * by dn="cn=admin,dc=int,dc=ipodion,dc=at" write by * read
on the consumer side, but it didn't change anything. I delete /var/lib/ldap/* and startet slapd but still: consumer /etc/ldap# slapcat | grep userPass consumer /etc/ldap#
I'd hate to leave the commodity of package management by installing the openLDAP tar-ball but if no other solution is available I will have to...
I insist: there should be no bug, but only a complete refresh (e.g., create a new consumer from scratch) should reveal it. If, for example, you had an ACL issue at the time replication occurred, and later on you fixed it, it will never re-sync unless forced.
An upgrade would definitely be quite beneficial, anyway, given the long list of fixed issues between 2.3.25 and 2.3.40.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
I know, I am not completely there yet, but I found a current OpenSuSE running openldap 2.3.37 and the same thing ocurred - it synced (into a previously empty /var/lib/ldap) and everything was there except for userPassword... are you sure this is not a configuration issue? I still suspect I got something badly mixed up there.. I just cannot figure out wht it is... I am grabbing a 2.3.40 tar-ball now and see what happens...
thanks
Thomas
Pierangelo Masarati wrote:
Thomas Kirchtag wrote:
I am using OpenLDAP 2.3.25 (most current in Debian stable). I tried to follow Quanahs suggestion and added
access to * by dn="cn=admin,dc=int,dc=ipodion,dc=at" write by * read
on the consumer side, but it didn't change anything. I delete /var/lib/ldap/* and startet slapd but still: consumer /etc/ldap# slapcat | grep userPass consumer /etc/ldap#
I'd hate to leave the commodity of package management by installing the openLDAP tar-ball but if no other solution is available I will have to...
I insist: there should be no bug, but only a complete refresh (e.g., create a new consumer from scratch) should reveal it. If, for example, you had an ACL issue at the time replication occurred, and later on you fixed it, it will never re-sync unless forced.
An upgrade would definitely be quite beneficial, anyway, given the long list of fixed issues between 2.3.25 and 2.3.40.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it
--On January 2, 2008 2:22:20 PM +0100 Pierangelo Masarati ando@sys-net.it wrote:
According to the configuration files posted, the user "cn=admin,dc=ipodion,dc=at" is used as binddn by the consumer, but it is the rootdn on the producer, so it can read all values (the real, harmless error is that there's no point in authorizing access for the rootdn: it has unlimited access privileges). Local writes by syncrepl are performed with the local rootdn's identity, so there's no point in authorizing them either.
Hm, I thought at least at one point in time, syncrepl used the identity it bound as to make the updates in the local DB, but I guess not. Maybe that was just a holdover in my ACL files from when I used slurpd.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On January 2, 2008 2:22:20 PM +0100 Pierangelo Masarati ando@sys-net.it wrote:
According to the configuration files posted, the user "cn=admin,dc=ipodion,dc=at" is used as binddn by the consumer, but it is the rootdn on the producer, so it can read all values (the real, harmless error is that there's no point in authorizing access for the rootdn: it has unlimited access privileges). Local writes by syncrepl are performed with the local rootdn's identity, so there's no point in authorizing them either.
Hm, I thought at least at one point in time, syncrepl used the identity it bound as to make the updates in the local DB, but I guess not. Maybe that was just a holdover in my ACL files from when I used slurpd.
I recall something similar: at some point, syncrepl switched to using the consumer database's rootdn. However, the only mention of something related to syncrepl and rootdn I could find in CHANGES was in 2.3.25, so it should already be in the version in use. What I believe is most likely is that at some point replication was initiated with an identity that couldn't read userPassword; eventually the ACL about userPassword was broadened, but the database was not re-sync'ed. In any case, the configuration files posted in the original message worked with 2.3.40.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
openldap-technical@openldap.org
-
Pierangelo Masarati -
Quanah Gibson-Mount -
Thomas Kirchtag -
Thomas Kirchtag