[Freeipa-devel] per-group password policy proposal

[Dmitri Pal]

Simo Sorce wrote:
> On Thu, 2009-06-11 at 17:34 -0400, Dmitri Pal wrote:
>   
>> Sorry Simo I disagree. I think it is too complex, hard to mange and
>> not deterministic enough.
>>     
>
> Can you explain where you see a problem, it seem pretty simple to me.
>   
I see a problem in determining what policy was used when something 
happened in the past.
Also the CoS is a complex notion and would be hard for admins to 
understand how to manage.
What is simple to you does not mean simple  for others. And you even 
acknowledged the complexity yourself.

>   
>> 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.
>>     
>
> You need to be able to be able to write to groups to change users
> memberships, so I don't see where there is an access control problem.
>   
You might have a right to create and nest groups and you will mess your 
environment by not understanding the impact.
With update case you can only ever affect users that you can access and 
you can't do the operation inadvertently.
You have to actually go and apply the policy. With groups approach you 
can create a new nesting and not realize that it affected password 
policies in the way you did not expected or wanted.
Finally to check what policy is active for the user you just quesry the 
user and see that if he has policy attributes this is the policy that 
applies, if he does not than the default one is used.
Very simple, logical and easy to work with.


>   
>> 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.
>>     
>
> I think that password policies should be managed primarily through
> groups that are used only to convey password policies. These groups
> should be manageable only by admins that have enough privileges to
> change password policies. I don't see an access control problem here.
>   
I agree with the statement. But difference is that the groups will be 
used to define the set of users to which the policies should apply.

>   
>> With Rob's proposal one can mess with the group nesting and not
>> realize that he weakened the policies for the highly sensitive
>> accounts.
>>     
>
> You can't weaken policies, because weaker policies have a lower Cos
> Priority, so they will never "win" when multiple policies are available
> for the same user. Always the highest (== most restrictive wins).
>
>   
Poor auditor...


>> I think we can add this kind of functionality later on top of the
>> direct updates if the users complain.
>>     
>
> Direct updates are cumbersome prone to fail and cause a lot of
> unnecessary traffic (therefore also slow). I really don't see any
> advantage.
>   
If it is done the plugin it is not remote.
It is not a frequent operation so performance issues are not that important.
It is a major security thing - it does not happen every day.
It should not be dynamic as you propose and the price is even better to 
discourage admin to flip-flop and take this seriously.
If the update failed the CLI or UI should just report it back letting 
admin to take a corrective action.


>   
>> I doubt they will. Keep in mind that the PRD item was written having 
>> bulk update in mind.
>>     
>
> Yes, but I see no risk here.
> If you mess up managing groups or determining password policies or their
> priorities you can also mess up bulk updates.
>   
I suggest we ask the freeipa-users about these two alternatives and see 
what the community will say.
May be I am wrong but I have seen problems with the flexible group 
approach in the past so I do not like it.



> Simo.
>
>   


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


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