Viewing Software Enhancements/7089
Full headers

Major security issue: yes  no

Notes:

Notification:

Date: Tue, 15 Nov 2011 11:23:13 +0000
From: noel@debian.org
To: openldap-its@OpenLDAP.org
Subject: ppolicy adds PWDFAILURETIME to organizationalUnit

Full_Name: Noel K.the
Version: 2.4.25
OS: Debian GNU/Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (80.187.103.39)


Hello,

using the ppolicy overlay with no special options:

slapd.conf
...
overlay ppolicy
ppolicy_default "cn=ppolicy,dc=domain,dc=lan"
ppolicy_use_lockout
...

cn=ppolicy,dc=domain,dc=lan
objectClass: top
objectClass: device
objectClass: pwdPolicy
objectClass: pwdPolicyChecker
cn: ppolicy
pwdMaxAge: 2592000
pwdExpireWarning: 3600
pwdMaxFailure: 5
pwdLockout: TRUE
pwdMustChange: TRUE
pwdMinLength: 6
pwdSafeModify: FALSE
pwdAttribute: userPassword


I'm scanning the LDAP data for PWDFAILURETIME attributes from time to time and
found the following ou with this attribute (slapcat output):

dn: ou=test,dc=domain,dc=lan
objectClass: organizationalUnit
ou: test
structuralObjectClass: organizationalUnit
entryUUID: ad5a6bc6-8a9c-1030-810d-db1b7d10e7b5
creatorsName: cn=admin,dc=domain,dc=lan
createTimestamp: 20111014104028Z
PWDFAILURETIME: 20111115101034Z
PWDFAILURETIME: 20111115101036Z
PWDFAILURETIME: 20111115101039Z
PWDFAILURETIME: 20111115111624Z
PWDFAILURETIME: 20111115111629Z
PWDACCOUNTLOCKEDTIME: 20111115111629Z
entryCSN: 20111115111629.327963Z#000000#000#000000
modifiersName: cn=admin,dc=domain,dc=lan
modifyTimestamp: 20111115111629Z

The PWDFAILURETIME on an organizationalUnit were created by:
$ ldapsearch -x -W -D ou=test,dc=domain,dc=lan
Enter LDAP Password: 
ldap_bind: Invalid credentials (49)

IMHO it is a bug that the ppolicy adds the PWDFAILURETIME attribute to DN's
which don't have a userPassword attribute and cannot get one.

Do you aggree?

Thanks for your answer.

Regards

  Noel K.the

Followup 1

Date: Tue, 15 Nov 2011 12:40:08 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
To: noel@debian.org
CC: openldap-its@openldap.org
Subject: Re: (ITS#7089) ppolicy adds PWDFAILURETIME to organizationalUnit

noel@debian.org wrote:
> IMHO it is a bug that the ppolicy adds the PWDFAILURETIME attribute to DN's
> which don't have a userPassword attribute and cannot get one.

Hmm, this is somewhat debatable. I'm not sure. But I also don't see any harm
in the current behaviour. It's surely the client configuration which needs to
be fixed.

Ciao, Michael.

Followup 2

Subject: Re: (ITS#7089) ppolicy adds PWDFAILURETIME to organizationalUnit
From: =?ISO-8859-1?Q?No=EBl_K=F6the?= <noel@debian.org>
To: michael@stroeder.com
Cc: openldap-its@openldap.org
Date: Mon, 21 Nov 2011 10:08:37 +0100

--=-OBICNroNT6O1Nc+JWJc8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Michael,

>noel debian.org wrote:
>> IMHO it is a bug that the ppolicy adds the PWDFAILURETIME attribute to
D=
N's
>> which don't have a userPassword attribute and cannot get one.

> Hmm, this is somewhat debatable. I'm not sure. But I also don't see any h=
arm
> in the current behaviour. It's surely the client configuration which need=
s to

:(

> be fixed.

In my case the behaviour is pollution my data with unneeded and unwanted
data in ous which I want to prevent. I don't have control over the
clients so sadly I cannot fix the source of the problem (the requests).
The PWDFAILURETIME (and PWDACCOUNTLOCKEDTIME) is only useful when there
is a userPassword: attribute ( when using pwdAttribute: userPassword).
Is there any chance that the behaviour is accepted as a problem?

--=20
No=C3=ABl K=C3=B6the <noel debian.org>
Debian GNU/Linux, www.debian.org

--=-OBICNroNT6O1Nc+JWJc8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEABECAAYFAk7KFRUACgkQ9/DnDzB9Vu2a8QCfdLgeqXZE6hgK5wy2Tk+bZCAZ
vMYAnA9UHtRGoukZcJ/KtvxHDZECFP6d
=91QP
-----END PGP SIGNATURE-----

--=-OBICNroNT6O1Nc+JWJc8--

Followup 3

Date: Mon, 21 Nov 2011 16:02:56 +0100
From: =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= <michael@stroeder.com>
To: =?UTF-8?B?Tm/Dq2wgS8O2dGhl?= <noel@debian.org>
CC: openldap-its@openldap.org
Subject: Re: (ITS#7089) ppolicy adds PWDFAILURETIME to organizationalUnit

No..l K..the wrote:
>> noel debian.org wrote:
>>> IMHO it is a bug that the ppolicy adds the PWDFAILURETIME attribute
>>> to DN's which don't have a userPassword attribute and cannot get
>>> one.
> 
>> Hmm, this is somewhat debatable. I'm not sure. But I also don't see any
>> harm in the current behaviour. It's surely the client configuration
>> which needs to
> 
> :(
> 
>> be fixed.
> 
> In my case the behaviour is pollution my data with unneeded and unwanted 
> data in ous which I want to prevent. I don't have control over the 
> clients so sadly I cannot fix the source of the problem (the requests). 
> The PWDFAILURETIME (and PWDACCOUNTLOCKEDTIME) is only useful when there 
> is a userPassword: attribute ( when using pwdAttribute: userPassword). Is
> there any chance that the behaviour is accepted as a problem?

Maybe you got me wrong: I don't have a really strong opinion on that (nor am
I the one who decides on this).

The question is: What should the pwdFailureTime exactly mean?

I understand what's your personal opinion on that and I somewhat support it.
But there might be corner-cases where the current behaviour makes sense.

Ciao, Michael.

Followup 4

From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
Date: Wed, 23 Nov 2011 19:01:20 +0100
To: noel@debian.org
Cc: openldap-its@openldap.org
Subject: Re: (ITS#7089) ppolicy adds PWDFAILURETIME to organizationalUnit

draft-behera-ldap-password-policy:

- Says this should be supported via attribute SubtreeSpecification
  in the pwdPolicy subentry.

  I think OpenLDAP does not support this attribute, it accepts it but
  does not do anything.

- Leaves room to make the requested behavior configurable in cn=config,
  or for that matter make it the default:

  The draft mostly says ppolicy applies to "user entries".  Browsing
  it quicly, I don't see it define what that means, nor consider the
  existence of non-user entries.  A config attribute could define that.

I don't know if anyone will bother to implement this (patches welcome)
but I don't see a formal problem with whether it could/should be done.

-- 
Hallvard