[Freeipa-devel] per-group password policy proposal

[Simo Sorce]

On Thu, 2009-06-11 at 09:13 -0400, Rob Crittenden wrote:
> Stephen Gallagher wrote:
> > On 06/11/2009 03:36 AM, Sergei V. Kovylov wrote:
> >> Hello guys.
> >> I hope it's OK for devel if I share my point of view for this question.
> > 
> > Sergei, thank you very much for your input. We always welcome additional
> > points of view.
> > 
> >> I think that Dmitri is right. It's usual situation, when user may
> >> exists in several groups and decision of which group's policy must be
> >> applied is hard to define (it must be on end-user side not on
> >> developers one).
> > 
> > I'm not sure I necessarily agree with this. On a previous project I
> > worked on, we implemented group-based password policy as the merge of
> > the most-restrictive requirements of all of the groups the user was a
> > member of.
> > 
> > In other words, if user U is in groups A and B, with the following policies:
> > 
> > Group A:
> > Length: 6 or more characters, maximum 32
> > Complexity: Must contain one number, one capital letter and one
> > lower-case letter
> > 
> > Group B:
> > Length: Between 8 and 40 characters
> > Complexity: Must contain one number and one special character
> > 
> > The merge of these two groups for User A would be:
> > Length: Between 8 and 32 characters
> > Complexity: Must contain one number, one special character, one capital
> > letter and one lower-case letter
> > 
> > 
> > The problem with this approach is that it's possible to add someone to a
> > set of groups that have incompatible settings. For example, if you have
> > a maximum password of 8 characters and you require 3 numbers, 3
> > lower-case and 3 upper-case characters, then there is no way to satisfy
> > the condition. I think we solved this in that previous project by making
> > the maximum password length unnecessarily large and assuming that the
> > customer wouldn't be foolish enough to set that many rules.
> > 
> > <snip>
> 
> We don't have a mechanism to do this sort of password policy merge and 
> we couldn't do it with CoS at all (it returns only the "winner"). Not 
> that we have to do it with CoS :-)
> 
> What would trip us up in this case are min and max life for the same 
> reasons you point out for length.

I think CoS with CoS priority is the most understandable one.

It's unlikely a company will have badly mixed policies, usually you have
a weak and a strong policy applied to different and very separate groups
of people. In some company you may have different levels of security
required, but it is very unlikely you have policies of the same
"strength" that employs different constraints, and it is also unlikely
that the same person is in 2 different groups for pw policy purposes.

In my experience security policies are classified by strength, so using
a Cos Priority seem to be easy both to understand and to apply to real
cases.

So I'd go with Cos and Cos priority.
If some admins feels that cos priority is not appropriate it will be
easy to create pw-policy specific non-posix groups and apply them to
non-overlapping set of users.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York