[Freeipa-devel] per-group password policy proposal

[Rob Crittenden]

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.

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

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/20090612/e8d90892/attachment.bin>