[Freeipa-devel] per-group password policy proposal

[Simo Sorce]

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.

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

-- 
Simo Sorce * Red Hat, Inc * New York