[Freeipa-devel] Implement audit_as kdb layer function

[Simo Sorce]

On Tue, 2012-02-14 at 14:31 -0500, Rob Crittenden wrote:
> Simo Sorce wrote:
> > 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).
> 
> Opened ticket https://fedorahosted.org/freeipa/ticket/2393 for lockout.
> 
> >
> > 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.
> 
> That sounds reasonable to me, I think you should match the current 
> behavior of the KDC whatever it may be.
> 
> I wasn't able to test the lockout changes of this but the code looks ok, 
> so ACK given the new ticket(s). You'll need a slight rebase against ipa-2-2.

Pushed to master and ipa-2-2

Simo.

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