On Mon, 2015-07-06 at 11:46 +0200, Sumit Bose wrote: > On Fri, Jul 03, 2015 at 05:01:13PM -0400, Simo Sorce wrote: > > On Fri, 2015-07-03 at 21:34 +0200, Sumit Bose wrote: > > > On Fri, Jul 03, 2015 at 02:12:34PM -0400, Simo Sorce wrote: > > > > On Fri, 2015-07-03 at 11:59 +0200, Jakub Hrozek wrote: > > > > > On Fri, Jul 03, 2015 at 11:54:46AM +0200, Jakub Hrozek wrote: > > > > > > Hi, > > > > > > > > > > > > the attached patches fix https://fedorahosted.org/sssd/ticket/2701 > > > > > > > > > > > > The first patch just adds a common function instead of copying the > > > > > > same > > > > > > pattern again to the new test. > > > > > > > > > > > > The second adds a new request krb5_auth_queue_send() that wraps > > > > > > krb5_auth_send() and also uses the Kerberos authentication queue. I > > > > > > hope > > > > > > the unit tests cover a lot of use-cases, if not, please suggest > > > > > > more! > > > > > > > > > > > > btw I was thinking that the chaining might not always be necessary > > > > > > if > > > > > > the ccache is of type MEMORY and I hope that the serializaton > > > > > > wouldn't > > > > > > be perceived as performance regression for users. Shall we say that > > > > > > Pavel's cached auth patches are a more systematic solution that > > > > > > doesn't > > > > > > rely on properties of the ccache type in that case? > > > > > > > > > > I'm sorry, but CI fails on Debian because of wrong linking with > > > > > libraries. I'm already testing a fix. Review of the rest is > > > > > appreciated > > > > > :-) > > > > > > > > If we are serializing all authentications then a busy server would be > > > > swamped. I do not see a per-user/per-cache queue so I would tentatively > > > > NACK the approach sorry. > > > > > > The current cache queue is per user, see add_to_wait_queue() for > > > details. > > > > I actually did look to check that and failed, I blame the late hour :-) > > > > Per-user is fine by me, though I would seriously consider de-duplication > > while we are here. > > I think this might be a useful feature, although I think it should not > be on by default. We have discussed this already a bit 5 years ago > together with the initial implementation of the auth queues in the krb5 > responder. Here are some links for reference: > > https://fedorahosted.org/sssd/ticket/533 > https://lists.fedorahosted.org/pipermail/sssd-devel/2010-October/004821.html > https://lists.fedorahosted.org/pipermail/sssd-devel/2010-December/005307.html > > But I think this feature would need some more discussion. E.g. where > should it be implemented, in the PAM responder on in the auth backends?
auth backend, the pam responder may not have enough context to properly decide. > How does is related to the cached authentication feature? It doesn't relate in any way IMO. > How should failed authentication be handled, de-dup as well or send them to > the > backend to allow the server to update the failed logon counter properly? The backend de-dups them and you won't know if an authentication is successful or failed until the answer comes back, so de-duping has already happened. > Shall de-duplication be done by user or by user and by service? This is a good question, I think it makes sense to have it per-user, however you must always check that everything is the same, user, password, any other option. Reading #533 I think the original concern about counting failures is a little bit misguided. The reason why we have unsuccessful counts is to avoid password guessing where an attacker tries a different password at every attempt. It is not a measure to somehow punish the user for sending the wrong password. So if an "attacker" where to send 100 auth requests all with the same password it makes no sense to lock up the user account, they SHOULD, ideally, count as a single failure. And actually de-duplication may end up saving a user with scripts. Think of a situation where the user has a script that makes 10 actions that require authentication when he inputs his password. If he enters the wrong password he may lock himself out for X time with just one attempt. With de-dup instead if chewed only one attempt and he can try again (assuming all auths happen at the same time). > Given that I would recommend to commit the patches in the current state > and add a RFE ticket to discussion de-duplication for one of the next > releases. Sure, we can open a separate ticket. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ sssd-devel mailing list [email protected] https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
