(ITS#5146) slapo-ppolicy

[tonni@hetnet.nl]

Full_Name: Tony Earnshaw
Version: 2.3.38
OS: Red Hat derived: Fedora FC6 and RHEL5
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (213.10.163.78)


I'm adopting ppolicy for the enterprise site I manage as far as OpenLDAP is
concerned. It's running on RHEL5, has a 2.3 provider and 3 delta-syncrepl
consumers. Main application software is Samba PDC (100+ Windows XP users), LTSP
(Linux Terminal Server Project) for around 80 terminals and email (smtp and
IMAP).

Up to now, after 4 years, the site's password policy has been to force all users
to accept new passwords that Admin generates for them with apg (good passwords).
Each uid and password is (thanks to OpenLDAP), valid for every service offered
by the site.

We are going to change our password policy to that of Semersheim and force users
to change their own policy at regular intervals, according to slapo-ppolicy. I'm
doing lab tests on my own Fedora FC6 machine prior to implementing. Everything
OpenLDAP supplies works, no complaint. Even Windows passwords get changed in
sync, if the correct interface (in our case pam) is chosen. That's not the
subject of this ITS.

My complaint is, that by changing our ACLs to allow users write access to
necessary attributes, ppolicy opens up a can of worms. Specifically, the
attribute userPassword is multi value. That is, given a suitable utility
(examples are phpldapadmin and gq), a user with write rights can enter multiple
passwords for his account. Each of these extra passwords *works* and the
superfluous passwords bypass ppolicy's pwdHistory, never get recorded, are
always valid. IOTW, a user who has many passwords can validate with any of them
and none but one is subject to ppolicy pwdHistory constraints.

I've temporarily solved this by patching servers/slapd/schema_prep.c such that
userPassword becomes SINGLE-VALUE. But this is obviously not the way to go. If
the rfcs decree that userPassword has to be multi-value, then it has to be
multi-value, however downright *STUPID* the rfc. Someone else has to change
that.

I'd like to see ppolicy refuse to accept a multi-value userPassword. "But that's
not part of Semersheim", you enjoinder. Well, eff Semersheim, that's a draft,
accepting multi-value userPassword is (somewhere) an rfc.