[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ppolicy behaviour after several binds

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/