[Freeipa-devel] per-group password policy proposal

[Dmitri Pal]

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/