I need some help interpreting these logs. They are from pam_ldap-182 changing a password on an openldap-2.3.24 server with the password policy overlay:
slapd[11017]: conn=112 op=12 BIND dn="uid=john,ou=People,dc=example,dc=com" method=128 slapd[11017]: conn=112 op=12 BIND dn="uid=john,ou=People,dc=example,dc=com" mech=SIMPLE ssf=0 slapd[11017]: conn=112 op=12 RESULT tag=97 err=0 text= slapd[11017]: conn=112 op=13 PASSMOD uid="uid=john,ou=People,dc=example,dc=com" new slapd[11017]: conn=112 op=14 MOD dn="uid=john,ou=People,dc=example,dc=com" slapd[11017]: conn=112 op=14 MOD attr=shadowLastChange slapd[11017]: conn=112 op=14 RESULT tag=103 err=50 text=Operations are restricted to bind/unbind/abandon/StartTLS/modify password slapd[11017]: conn=111 fd=19 closed (connection lost) slapd[11017]: conn=112 op=13 RESULT oid= err=0 text= This "john" user has pwdReset: TRUE, and the policy mandates the password change. All lines have the same syslog timestamp. The events are: - password change via EXOP - update of the shadowLastChange attribute The problem is that the update of shadowLastChange was rejected, and it seems to me the reason is that the password change EXOP didn't complete yet, is that it? If yes, how is this possible considering that pam_ldap uses the ldap_extended_operation_s() for the EXOP and later on ldap_modify_s()? These are synchronous operations, right? So how come the second operation be initiated before the first one finished? I don't think pam_ldap is multi-threaded. Or is the reason for the failure something else?
