[Freeipa-devel] per-group password policy proposal

[Dmitri Pal]

Simo Sorce wrote:
> 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.
>
>   
Sorry Simo I disagree. I think it is too complex, hard to mange and not 
deterministic enough.
Add to it that it can have problems with access control. In bulk update 
proposal you have to explicitly update user records to apply the policies.
So admin has to have the rights to do so. He will be able to only modify 
policies for the users that he can access.
With Rob's proposal one can mess with the group nesting and not realize 
that he weakened the policies for the highly sensitive accounts.
I think we can add this kind of functionality later on top of the direct 
updates if the users complain.
I doubt they will. Keep in mind that the PRD item was written having 
bulk update in mind.

-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/