[Freeipa-devel] per-group password policy proposal

[Rob Crittenden]

Simo Sorce wrote:
> 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.

If you say so :-)

I don't think this will have any impact on my design, it is just a way 
to point to discrete policies.

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

Yeah, I guess cn=etc would make sense.

> 
>> 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 use memberOf in the user entry to determine which CoS definition to 
use so it will be the DN of the group.

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

Yeah, I've been pondering the same thing, sort of a policy tool so an 
admin can see what policy would be applied for any given user (and truly 
trivial in 389 because we just query the pwdpolicysubentry attribute and 
display the contents of that entry).

> 
>> 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" ?

I guess we could apply the default policy to the ipausers group since 
all users are a member of that. We'd give it a 0 cosPriority so it would 
be the lowest.

I was planning on just having the plugin fall back to use the root 
policy so that if the attribute wasn't there then it would just fall thru.


> 
>> So am I on the right track here?
> 
> I like it.
> 
> Simo.
> 

whew.

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/20090611/2a250615/attachment.bin>