[Freeipa-devel] Implement audit_as kdb layer function

[Rob Crittenden]

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.

rob