[Freeipa-devel] per-group password policy proposal

[Simo Sorce]

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.

The only parts that enforce password policy in freeipa re really
kadmin.local and our password plugin. Initially we decide to go for the
MIT schema because we were unsure about letting kadmin run (it would
obey only the MIT krb schema). 
But since we decided not to allow kadmin, and since kadmin.local is used
only to manage keytabs in the bootstrap process and in emergency cases,
I think we can easily drop that schema and fully embrace the DS one.

It will require some work in the password plugin but nothing mind
blowing.

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

No kidding :-)

> First, we set up a place to hold the policies:
> 
> dn: cn=nsPwPolicyContainer,$SUFFIX
> objectClass: top
> objectClass: nsContainer
> cn: nsPwPolicyContainer

I would put this under cn=etc or cn=accounts probably.

> 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

As said above we can easily use the native DS policies which are richer.

One question though, wht the name of the policy includes the whole group
DN ? Is that what links the policy to the group ?
Or is this just some CoS convention?
Can that be changed and simplified ?
Maybe reference the group nsUniqueId instead ?

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

No, we should just use cos priority, it's perfectly understandable.
Also I guess an admin can query a user to see what applies to him like
the password plugin would right ?

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

I guess we can define a global group that embodies the default policy ?
"DefaultPwPolicyGroup" ?

> So am I on the right track here?

I like it.

Simo.

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