[SSSD] [PATCH] Chain authentication requests in all Kerberos-based providers

Simo Sorce simo at redhat.com
Mon Jul 6 12:54:08 UTC 2015


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




More information about the sssd-devel mailing list