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
