Andreas Hasenack wrote:
(pam_ldap-18[0-2], openldap-2.3.21)
While testing pam_ldap's ppolicy support I came accross this scenario.
The uid=fulano user has pwdReset set to TRUE, and my policy mandates
that he then changes the password.
These are the logs of what is happening (grepped for just conn=58 which
is where the error happened):
May 2 10:11:09 cs4 slapd[2588]: conn=58 fd=34 ACCEPT from IP=10.0.2.200:4078
(IP=0.0.0.0:389)
May 2 10:11:09 cs4 slapd[2588]: conn=58 op=0 BIND dn="" method=128
May 2 10:11:09 cs4 slapd[2588]: conn=58 op=0 RESULT tag=97 err=0 text=
May 2 10:11:09 cs4 slapd[2588]: conn=58 op=1 SRCH base="dc=example,dc=com"
scope=2 deref=0 filter="(uid=fulano)"
May 2 10:11:09 cs4 slapd[2588]: conn=58 op=1 SEARCH RESULT tag=101 err=0
nentries=1 text=
May 2 10:11:09 cs4 slapd[2588]: conn=58 op=2 BIND
dn="uid=fulano,ou=People,dc=example,dc=com" method=128
May 2 10:11:09 cs4 slapd[2588]: conn=58 op=2 BIND
dn="uid=fulano,ou=People,dc=example,dc=com" mech=SIMPLE ssf=0
May 2 10:11:09 cs4 slapd[2588]: conn=58 op=2 RESULT tag=97 err=0 text=
May 2 10:11:09 cs4 slapd[2588]: conn=58 op=3 BIND anonymous mech=implicit ssf=0
May 2 10:11:09 cs4 slapd[2588]: conn=58 op=3 BIND dn="" method=128
May 2 10:11:09 cs4 slapd[2588]: conn=58 op=3 RESULT tag=97 err=0 text=
May 2 10:11:09 cs4 slapd[2588]: conn=58 op=4 BIND dn="" method=128
May 2 10:11:09 cs4 slapd[2588]: conn=58 op=4 RESULT tag=97 err=0 text=
May 2 10:11:09 cs4 slapd[2588]: conn=58 op=5 SRCH base="dc=example,dc=com"
scope=2 deref=0 filter="(uid=fulano)"
May 2 10:11:09 cs4 slapd[2588]: conn=58 op=5 SEARCH RESULT tag=101 err=50
nentries=0 text=Operations are restricted to bind/unbind/abandon/StartTLS/modify
password
May 2 10:11:11 cs4 slapd[2588]: conn=58 fd=34 closed (connection lost)
There are several bind operations in this one connection. What I find
weird is that the last BIND operation before the error is anonymous: why
did the following search operation error then?
The ppolicy overlay will only detect Bind operations for user DNs that
reside in the backend upon which it's configured. Anonymous binds are
only processed by the frontend, so the ppolicy overlay doesn't know
anything about them. Since it doesn't know that a subsequent Bind has
succeeded, it doesn't reset its restrict flag.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
