NTLM authentication : some questions

Henrik,
    Chemolli and I are likely to do some hacking on the NTLM code based on
the two emails floating around before. Before we do that I have a couple of
questions about the notes on sourceforge.

* Is Andy Doran still around/active - I'm happy to work with him on this, or
is it currently unmaintained?
* With regards to your proposed auth_class directive, I suspect your
architecture would fall over with systems such as Metaframe. I think that
the structure discussed should allow the same flexability, particularly if
we were to look at allowing more than one instance of a given auth_type
helper program - as long as we put a sanity check in the acl parsing code to
prevent collisions, the same functionality should just drop right out.
* Has anyone got/seen/able to _easily_ get, what a NTLM browser passes as
X-Proxy-Auth on subsequent connections? This is related to the two DENIED
messages.
* How does this sound as a fairly safe way to avoid logging the two DENIED
messages on every connection:

    For the first request, log the DENIED. Present all applicable auth
types. If _any_ auth type requires handshaking, set a AUTH_IN_PROGRESS FLAG.
    on the next part of the handshake, if AUTH_IN_PROGESS is set, AND the
browser returned a matching handshaking auth-type, AND the auth code returns
AUTH_IN_PROGRESS again DO NOT log anything. Otherwise log a DENIED and reset
any AUTH_IN_PROGRESS flag. (next request will start with a clean slate).
    and so on for n AUTH_IN_PROGRESS steps, where n is the longest handshake
we know of.
    When the auth_code returns a valid username log the request and if
possible keep as a state item whatever we expect to see from that same
authenticated client again on their next new tcp connection.
    If we see such a token, it's the same user, log and process the request
as normal. (ie still check that that user is allowed, but don't start a new
handshake process).

That means that a hacked client will be logged if they violate the
handshaking auth protocol, and non handshaking requests will be logged as
they are now. Buffer overruns? we don't have those (grin).

Any comments anyone?

Also we looking to extend the auth helper's responses and expected inputs to
allow handshaking or non-handshaking as appropriate for each auth type. At
the same time we will add multiple-auth-helpers so that
kerberos/digest/basic/ntlm code does not have to be rolled into one. Is
anyone working on that sort of thing at the moment or is it a clean slate?

Critical to good performance on this will be the ability to write the
request to the authenticator, and read the response as a call-back, pausing
the acl check - does anyone predict problems with this? I think the
redirector does something similar doesn't it?

And finally to anyone who has looked at the changed request flow in the NLTM
branch vs the head request flow - does anyone have any
preference/input/comments/suggestions? I suspect that the approach we've got
may fit better with the existing flow.....

Note: for the moment I'm ignoring NLTM WWW authentication thru the proxy.
That should not affect the Authentication code.

Rob
Received on Tue Jul 18 2000 - 05:39:16 MDT