[Freeipa-devel] per-group password policy proposal

Rob Crittenden rcritten at redhat.com
Wed Jun 10 21:38:37 UTC 2009


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20090610/59280d00/attachment.bin>


More information about the Freeipa-devel mailing list