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.