[Freeipa-devel] per-group password policy proposal

[Simo Sorce]

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.

> 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.

> 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.

> 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).

> 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.

> 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.

Simo.

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