[Freeipa-devel] per-group password policy proposal

[Rob Crittenden]

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.

rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20090611/026bc63b/attachment.bin>