[Freeipa-devel] per-group password policy proposal

[Dmitri Pal]

Simo Sorce wrote:
> On Fri, 2009-06-12 at 11:44 -0400, Rob Crittenden wrote:
>   
>> Dmitri Pal wrote:
>>     
>>> Simo,
>>>
>>> We have some disagreements and some agreements.
>>> The fundamental disagreement is about doing it dynamically by CoS or 
>>> putting the policy right into the user entry.
>>> I think we will have troubles with CoS with auditing down the road.
>>> I assume that all the changes are tracked in the audit logs and it would 
>>> be much easier to correlate the change of the policy directly on the 
>>> user entry than indirectly by changing group membership.
>>>       
>> I want to state again that we have no audit logs on the attribute level. 
>> We will know that someone has touched a record but not necessarily what 
>> was done to it. Here I'm changing the user's last name:
>>
>> [12/Jun/2009:11:23:38 -0400] conn=258 op=2 BIND dn="" method=sasl 
>> version=3 mech=GSSAPI
>> [12/Jun/2009:11:23:38 -0400] conn=258 op=2 RESULT err=0 tag=97 
>> nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=example,dc=com"
>> <snip a bunch of searches while we find the user to be modified>
>> [12/Jun/2009:11:24:54 -0400] conn=258 op=11 MOD 
>> dn="uid=tuser1,cn=users,cn=accounts,dc=example,dc=com"
>> [12/Jun/2009:11:24:54 -0400] conn=258 op=11 RESULT err=0 tag=103 
>> nentries=0 etime=0
>> [12/Jun/2009:11:24:54 -0400] conn=258 op=12 SRCH 
>> base="uid=tuser1,cn=users,cn=accounts,dc=example,dc=com" scope=0 
>> filter="(objectClass=*)" attrs=ALL
>> [12/Jun/2009:11:24:54 -0400] conn=258 op=12 RESULT err=0 tag=101 
>> nentries=1 etime=0
>>
>> All we have is a MOD operation.
>>
>> A password change is similarly opaque:
>> [12/Jun/2009:11:35:00 -0400] conn=258 op=15 EXT 
>> oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_extop"
>> [12/Jun/2009:11:35:00 -0400] conn=258 op=15 RESULT err=0 tag=120 
>> nentries=0 etime=0
>>
>>     
>>> I think this is very important for compliance (PCI, SOX etc) to be able 
>>> to correlate the change in the policy to specific security event.
>>>       
>> Ok then a lot more logging will need to be added to DS.
>>     
>
> As I proposed in my mail, we should probably have the password plugin
> perform this logging at password change time, that should solve all
> issues and will be agnostic to the method used to provide the policy.
>
>   
It should probably be done by the audit plugin that will integrate DS 
with the Audit system.
Remember we talked about something like this.
But it is down the road.
For now I think that recording the policy information in the log by 
password plugin will make sense.
This rises a different  question which grants a separate thread.
So I agree with CoS approach now.

>>> The "update" scheme makes the forensic analysis much easier. This is the 
>>> main argument.
>>>
>>> But if others do not see it as important I am not going to argue any more.
>>>
>>>       
>> It isn't a matter of importance, I just think we can obtain the same 
>> results using CoS with a lot less work.
>>     
>
> I concur, and a lot less error prone.
>
> Simo.
>
>   


-- 
Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/