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 _______________________________________________ Freeipa-devel mailing list Freeipafirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/freeipa-devel