[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
forced password change + update: blocked by ppolicy
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?