Full_Name: Christian Manal Version: 2.4.21 OS: SunOS 5.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:638:708:30dd:221:85ff:fe3f:1775) I have noticed a problem regarding ExOp PASSMOD and chaining in my OpenLDAP environment. Maybe some of the other overlays are doing their part in this as well. Password changes started behaving weird at some point: When a slave runs for a few days and some user tries to change his password, the change is done in the local database only (no chaining done or referral returned), resulting in an inconsistent database between the slave and all the other servers. That way logging in to services which connect to the LDAP servers in a round-robin fashion sometimes works with the "new" password and sometimes with the old one. After I restart the slapd on the slaves, everything works again for a few days, before it goes bad again. Every other write gets chained just fine when a slave is in this condition. It's only the PASSMOD operations that are stuck. I have one master and four slaves running on Solaris 10. One of them SPARC, the others x86. Software Versions are: OpenLDAP 2.4.21 BDB 4.8.26 Cyrus SASL 2.1.23 Heimdal Kerberos 1.3.3 All the configs and the sourcecode of my self-made pwdCheckModule for ppolicy can be found here: http://www.informatik.uni-bremen.de/~moenoel/ldap/ As pointed out by Pierangelo Masarati, this may be the same issue as reported here: <http://www.openldap.org/lists/openldap-technical/201003/msg00019.html> Regards, Christian Manal
> Every other write gets chained just fine when a slave is in this > condition. It's only the PASSMOD operations that are stuck. One quick question: can you tell the parameters of the offending PASSMOD operations? I mean: old/new password, password generated automatically or provided, operation performed for self or by a privileged identity, and so? Thanks, p.
Am 31.07.2010 04:46, schrieb masarati@aero.polimi.it: >> Every other write gets chained just fine when a slave is in this >> condition. It's only the PASSMOD operations that are stuck. > > One quick question: can you tell the parameters of the offending PASSMOD > operations? I mean: old/new password, password generated automatically or > provided, operation performed for self or by a privileged identity, and > so? > > Thanks, p. > > The PASSMODs are done by Linux 'passwd', using pam_ldap (mostly on Debian Lenny, if that matters). The new passwords are provided by the user and the operation is perfomed as "self". I don't know if pam_ldap provides the old password as a parameter to the PASSMOD operation. Binding is done with 'simple bind'. The whole SASL/Kerberos stuff is configured and working, but not yet deployed. I could add the client config (PAM, ldap.conf and so on) to the server related stuff in the linked directory, if you need it. Regards, Christian Manal
changed notes
cannot reproduce
moved from Incoming to Software Bugs
We were unable to reproduce this problem. If you can provide full configs that demonstrate the issue, feel free to reopen this bug.