Re: ntlm authentication concurrency

From: Henrik Nordström <henrik_at_henriknordstrom.net>
Date: Thu, 15 Dec 2011 01:18:58 +0100

ons 2011-12-14 klockan 13:46 +1300 skrev Amos Jeffries:

> The reason why it is not supported is that NTLM (and Negotiate to a
> lesser degree) protocol is stateful and spreads pieces of the
> challenge/token-exchange/credentials-response over several HTTP
> requests. To handle this each helper has a 1:1:1 relationship pinning an
> active client and a winbind connection state together through the helper
> state data.

Well, the reason why concurrency wasn't added to the ntlm scheme is that
at the time when concurrency was added to the helper protocols both the
ntlm scheme and stateful helpers interface in general was in such shape
that concurrency could not easily be added there.

Both have been cleaned up considerably since then, and adding
concurrency support to stateful helpers should be a lot easier now.

A related note here is that the helper protocol for NTLM, Negotiate and
Kerberos is almost identical. In fact the three schemes in Squid is
actually the same code with a search/replace of the identifiers and a
minor change in one of the helper commands. So if support for
concurrency is added to one then the exact same change can be applied to
them all.

> From the beginning of the auth handshake through to its
> completion. This stateful relationship effectively "locks" the helper to
> 1 concurrency channel.

No. But it locks that channel until the handshake is completed.

> The other helpers can support a form of fake-concurrency by buffering
> the input requests and processing them in sequence very fast. To Squid
> this is essentially the same as real concurrency, just slower. But for
> NTLM processing two token-exchanges in a row is not an option, will
> corrupt the credentials validation.

Well, the helper naturally needs to explicitly support this mode and
keeping appropriate internal state per channel.

> It is theoretically possible to write an NTLM helper which accepts
> concurrency tags and maintains a bunch of separate states internally
> linking the channel-ID to a particular winbind connection.

And such helper already exists for ntlm and negotiate.

The Samba 4 windbind ntlm_auth helper supports concurrency
(multiplexing). It's still limited to one winbind query at a time for
the login verification, but may process any number of challenges in
parallell.

Not sure how much it's been tested, if at all. Apparently not mentioned
in the man page even but the mode is activated by the --multiplex
command line option.

Regards
Henrik
Received on Thu Dec 15 2011 - 00:19:10 MST

This archive was generated by hypermail 2.2.0 : Thu Dec 15 2011 - 12:00:07 MST