[Freeipa-devel] per-group password policy proposal

[Rob Crittenden]

Simo Sorce wrote:
> On Wed, 2009-06-17 at 10:15 -0400, Rob Crittenden wrote:
>> 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.
>> Ok, I've been reading some code and it looks relatively straightforward, 
>> but I do have a couple of questions.
>>
>> What enforces an expired password? I assume the KDC currently does this 
>> enforcement. Do we want 389 doing this instead, using 
>> passwordExpirationTime? There are some special cases in the current code 
>> so I'm not sure if that still would apply.
> 
> We should still store expiration times also in the attributes the KDC
> knows about, or we need to patch the ldap driver to look at the DS
> policy attributes.

I think we should keep it since this is sort of an IPA-only requirement. 
I guess I need to keep krbLastPwdChange as well then.

>> If we switch to the 389 password policy we may inherit certain 
>> capabilities and not necessarily in a good way. Password retry counts, 
>> for example, will be enforced by the server itself.
> 
> Not sure how that would work, the KDC doesn't tell DS anything about
> retries. Or am I missing something/misunderstanding here ?

People can still authenticate with simple auth. By using the DS password 
policy we could enable features like limiting the number of password 
retries. Note that we don't have to expose it though.

In fact, this is probably a good thing. For example, when you add a new 
user their password starts out expired but they can still bind with LDAP 
single auth.

My fear is that we'd be doing policy in 2 places and we'd need to be 
sure to keep several attributes in sync.

There may be competing options as well. For example, DS has 
passwordMustChange which if set to on requires the user to change their 
password on first login or if DM has reset it. We do something similar 
already.

>> I'm mostly concerned about where we will store the policies vs where the 
>> server will look for them. It could be that this sort of thing doesn't 
>> get applied evenly because we may end up storing it differently. I still 
>> have a lot of code to read.
> 
> Keep the questions coming, we need to make sure we don't forget any
> feature while transitioning :-)

After reading some more it looks as if policy is pulled from the 
pwdpolicysubentry value so even if we use groups instead of storing it a 
sub entry we should be ok.

> 
>>> It will require some work in the password plugin but nothing mind
>>> blowing.
>> Depends on your perspective I suppose :-)
> 
> I guess so :-)
> 
> Simo.
> 

cheers

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/20090617/12d4865d/attachment.bin>