[Freeipa-devel] per-group password policy proposal

[Sergei V. Kovylov]

Hello guys.
I hope it's OK for devel if I share my point of view for this question.
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). Moreover, password policy is just a top of iceberg,
because there are lots of aspects which freeipa may cover, for example
template for user creation (pre-defined home directories, access
policy etc.). In this case usage of DS roles and CoS may provide
flexible mechanism of manage. In part of password policy usage of
filtered roles will do the same as per-group policy but without fixing
them to special group and exclude some mechanism of group classes ( i
mean password policy group, some other option group). In such case
freeipa will provide policy mechanism which may be used not only for
group but for some sub-entry, for some attribute in user account etc.
With CoS we are able to define MAY or MUST one policy in nested group
be replaced by parent one or not.

Thanks.

2009/6/11 Dmitri Pal <dpal at redhat.com>:
> Rob Crittenden wrote:
>>
>> One feature we want to add to v2 is per-group password policy. The IPA
>> password policy is implemented completely separately from the DS password
>> policy (because it is the KDC that does the enforcement, AFAICT).
>>
>> Currently it finds the password policy by searching the base for
>> objectClass=krbPwdPolicy.
>>
>> What I propose is to leave that, it will become the "global" password
>> policy, and add an search before that to look for the pwdpolicysubentry
>> attribute in the user.
>>
>> This attribute is used for the DS password policy to tell it where in the
>> tree the password policy for this entry exists. I'm not quite sure I want to
>> re-use this attribute like this but it's a starting point anyway.
>>
>> The way I want to do per-group password policy is to create a Class of
>> Service for it.
>>
>> Tread carefully when reading this, it is known to cause serious headaches.
>>
>> First, we set up a place to hold the policies:
>>
>> dn: cn=nsPwPolicyContainer,$SUFFIX
>> objectClass: top
>> objectClass: nsContainer
>> cn: nsPwPolicyContainer
>>
>> And here is a sample policy:
>>
>> dn:
>> cn="cn=group1,cn=groups,cn=accounts,$SUFFIX",cn=nsPwPolicyContainer,$SUFFIX
>> objectClass: top
>> objectClass: nsContainer
>> objectClass: krbPwdPolicy
>> cn: cn=group1,cn=groups,cn=accounts,$SUFFIX
>> krbMinPwdLife: 3600
>> krbPwdMinDiffChars: 0
>> krbPwdMinLength: 8
>> krbPwdHistoryLength: 0
>> krbMaxPwdLife: 7776000
>>
>> We start with a classic CoS entry that utilizes the existing CoS template
>> infrastructure (for account locking):
>>
>> dn: cn=Password Policy,cn=accounts,$SUFFIX
>> description: Password Policy based on group membership
>> objectClass: top
>> objectClass: ldapsubentry
>> objectClass: cosSuperDefinition
>> objectClass: cosClassicDefinition
>> cosTemplateDn: cn=cosTemplates,cn=accounts,$SUFFIX
>> cosAttribute: pwdpolicysubentry operational
>> cosSpecifier: memberOf
>> cn: Password Policy
>>
>> To make a policy for a specific group we just need to add a template for
>> it. Here is what it would look like for group1:
>>
>> dn: cn="cn=group1,cn=groups,cn=accounts,$SUFFIX",
>> cn=cosTemplates,cn=accounts,$SUFFIX
>> objectClass: top
>> objectClass: cosTemplate
>> objectClass: extensibleobject
>> pwdpolicysubentry:
>> cn="cn=group1,cn=groups,cn=accounts,$SUFFIX",cn=nsPwPolicyContainer,$SUFFIX
>> cosPriority: 1
>>
>> So you add all this, and add a user to group1 and query for
>> pwdpolicysubentry you get
>> "cn=group1,cn=groups,cn=accounts,$SUFFIX",cn=nsPwPolicyContainer,$SUFFIX
>>
>> The ipa_pwd_extop plugin would search for this attribute and if it found
>> one, would pull the policy from the attribute value, otherwise it would fall
>> back to the global policy.
>>
>> Now we don't want to deal with overlapping policies but I'm not sure we
>> can do a whole lot about it, particularly when a group is made a member of
>> another group. It would be painful to recursively look at every single user
>> to see if they already have a policy.
>>
>> The best we can do, I think, is to check when a user is added to a group
>> whether they already have a policy and if so, quit.
>>
>> Or we can try to control which policy to use based on cosPriority. I'm not
>> sure how we would expose this to the user interface but I think that the
>> higher number winning is a pretty understandable concept. The problem would
>> be having a way to know what the current highest value is.
>>
>> I'm not entirely sure yet how this would be managed. I suspect we could
>> get away with a standard CRUD API to manage creating the policies and
>> associating them with a group. We'd just need some special way to specify
>> group or global.
>>
>> So am I on the right track here?
>
> I am not sure.
> I was envisioning it quite differently.
> The ambiguity in this case critical and might be not acceptable since it
> would be hard to determine which policy should be used in case user is a
> member of different groups.
> Management of priorities is also a pain and creates complex  UI and CLI.
> I was more thinking about having a specific policy per user. AFAIR the
> software can check the user related password policy attributes right now
> without any changes to the code. There attributes just not there. So we need
> to give admin the ability to set them. I was thinking that defining password
> policies is a bulk operation that updates specific users that belong to a
> group and creates the attributes in the user entries. If we do it this way
> we would be able to say:
>
> Password policy is XYZ.
> Apply this password policy to users in this group (including or not
> including sub groups) for those users that do not have the policy set or for
> all users in the given group.
> There might be other conditions for the query.
>
> In such case it is easy to control who gets the policy when the policy is
> defined and easy to determine what policy is active for the user (for audit
> purposes) since there is no ambiguity.
>
>
>>
>> rob
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Freeipa-devel mailing list
>> Freeipa-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>
>
> --
> Thank you,
> Dmitri Pal
>
> Engineering Manager IPA project,
> Red Hat Inc.
>
>
> -------------------------------
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel
>