Re: password policy: multiple subentries, multiple password attributes, ....

On Mon, 2010-07-05 at 14:43 -0700, Kurt Zeilenga wrote:
> The spec specifically allows for an user entry to be controlled by
> multiple policies (each for a different password attribute) but then
> defines pwdPolicySubentry to be single-valued.
> 
> It seems to me that the text as a whole doesn't really well consider
> the implications of multiple applicable password policies.
> 
> In our current implementation, we do implement 5.3.1, and mandate that
> only a single password policy be applicable to a given user.
> 
> We currently looking at userPassword v. authPassword implications with
> regard to auto-migration, as we're now supporting the latter for SCRAM
> authentication.  I think we'll assume that if both are present in an
> entry, they represent the same same user password.   We'll like need
> to support both RFC 2307 hashing and in conjunction with SCRAM
> authPassword hashing so that users can use either TLS
> +SimpleBind(WithPassword) or SCRAM.
> 
> I don't see the value of having two disjoint password policies, one
> for each attribute.   What I believe our customers will demand is an
> unified password policy covering both of these attributes.  (I can see
> a possible desire to support a disjoint password policy covering
> passwords for directory application specific passwords, such as when
> one has a different directory password from say an email password
> stored in the directory.  However, our customers which have different
> passwords for different directory applications tend to rely on
> multiple entries per user, one per directory application (with
> service-level authorization restrictions), not multiple passwords
> attributes in a single entry.)

Ack, having multiple password policies apply for different attributes
looks simply as an admin nightmare. Password policies tend to be few and
well defined as they are considered critical for the security of the
password. That means that usually it is quite easy to correctly define
all policies for all attributes for a specific subset of users.
Defining them as an intersection of multiple policies seem like a
feature I wouldn't want if I were an administrator. Looks powerful on
paper but also potentially complicated and complex is usually an enemy
of secure.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <[email protected]>
Principal Software Engineer at Red Hat, Inc. <[email protected]>