[Freeipa-devel] Implement audit_as kdb layer function

[Simo Sorce]

On Tue, 2012-02-14 at 10:22 -0500, Rob Crittenden wrote:
> Simo Sorce wrote:
> > Without this function the audit counters (krbLastFailedAuth,
> > krbLastSuccessfulAuth, krbLoginFailedCount) are not updated causing a
> > regression.
> >
> > This function updates the counters unconditionally upon
> > successful/failed authentication (only if pre-auth is used which is the
> > default in FreeIPA).
> >
> > A side effect of how this is implemented is that no other attributes are
> > updated when this happens so that replication is not kicked (because we
> > filter audit counters from replication to avoid replication storms), in
> > 2.1.x updating these counters also ended up updating krbExtraData and
> > that caused replication to kick in.
> >
> > Simo.
> 
> This still isn't working quite right.

Can you tell me how did you test ?

> The user lockout is not working. The failed counter plateaus at the 
> lockout value (in my case 6). Any failures beyond 6 do not increment the 
> counter, I'm assuming there is some other interaction going on.
> 
> It does set the dates properly.

The audit functions do not lock the user, so please open a separate bug
for that. I need to investigate where it is done in the kdc's default
database code to see if it is yet another function that has been
delegated to the driver.

The reason it does not go beyond 6 is probably that max_fail is set to
5 ? Can you confirm ? If that's the case stopping at 6 is correct
according to my reading of the equivalent code in MIT's own database
(perhaps I should stop at 5 even, we can debate that).

Tangential to that I think we may have a bug in the ldap bind preop
plugin.
I think we reset failures if someone successfully binds, the problem is
that those are cleared even for GSSAPI binds, and that is wrong I think.
Because it means that if a suer has a valid ticket for LDAP and keeps
querying it, we keep resetting the counter but no real authentication
has been performed. An attcker could wait such an event to sneak in up
to max_fail -1 auth attemepts and then wai tfor a user bind to clear the
flag. I think the reset should happen only on password based logins, and
defer to the KDC to clear the auth count if the user makes an actual
successful AS request.
If you agree I will open a ticket on that.

Simo.

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