[Freeipa-devel] per-group password policy proposal

[Christoffer Strömblad]

Could it perhaps be an idea to do some sort of aggregate policy? Say
that there are a couple of groups, including subgroups and they all have
different password policies. Perhaps when a new group is added, modified
or deleted an "aggregate" password policy is created and stored in the
"top" branch (forgive me, I'm not that familiar with LDAP).

So the default will become some sort of common denominator using the
highest requirements to set the policy.

One group might have 30 day expiration and 7 min length. Another minimum
10 length and 60 day expiration.

The final "aggregate policy" would become:
Expiration: 30 days
Min length: 10.

My reasoning around this type of policy would be that a user, member of
several groups have more access rights and should hence be treated as
such. Hence a stronger password should be required from this particular
user.

Problems with aggregate policy
I guess however that maintaining such a thing would require that the
code would need to change each time a new attribute is added to the
password policy. Which might need to happen anyways.

It might be dumb, but I thought I'd share the idea nonetheless.

Regards,
Chris
On Wed, 2009-06-10 at 17:38 -0400, 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?
> 
> rob
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 489 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20090611/649cb3b6/attachment.sig>