Re: [SQU] Disable authentication Realm, No Authprompts with MS-Proxy Explorer , : Now where is the NTLM module?

On Mon, 16 Oct 2000, Robert Collins wrote:

> Hi Michael,
> Before we get onto some instructions, the ntlm code is *not a module*.
I knew that from the first mails I read about, I admit my original
mail could be misinterpreted in a way that I didn't though.

> If you have any trouble please just hop back onto the list.
You'll regret that you said that... ;-) Well, actually I'd have asked the
list even if you didn't ask me to do it.

Ok, first there are a few simple problems I encountered. They are not very
serious and to be expected from an ALPHA or BETA version, but I still list
them here as I don't know if you are aware of them and as I think you are
interested in usage reports of your software. Please don't misunderstand
this as complaining or whining:

a) Some readme describing the NTLM process in general
b) squid.conf should (shortly) list the arguments of the nltm_auth
   helper. Or at least the helper prog should give a usage message with
   no or unparsable arguments. The info in the source alone is too much
   hidden.
c) default squid.conf uses authenticate_program rather than
   authenticate_program_ntlm for the ntlm helper. I'm also
   under the impression that a keyword proxy_auth_ntlm is accepted
   in acl commands but has no function, btw.
d) It should be made more clear if the DC argument to nltm_auth must be
   the netbios name or might be an ip address or other name. Similarly
   it should be made more clear if user names in proxy_auth acl's must
   be <domain>\<user> or not. It seems that the default domain for ntlm
   config option has no effect THERE.

And now to a real bug and then my problem:

e) It seems I need to specify the DC by netbios name and ensure it can be
   translated to ip address with the normal resolver. If the name cannot
   be resolved, ntlm_auth gives no error and does not abort. Instead it
   connects to a bogus ip address. Unfortunately it is not a real bogus
   address, but the ip of the name server. In my case this was really
   bad because it is almost the address of the PDC and it is also an NT
   system so I got odd SMB errors because the name server really wondered
   why I ask it for a connection to the PDC and I had a hard time finding
   that out by system call traces and stuff.

   Although I should have pinned it down to the broken source line, I had
   no time for that. Sorry, So I can only guess about the reason: Probably
   return value of gethostbyname is not checked and the ip from a static
   buffer which was used to connect to the nameserver to query the name is
   used.

   Anyway, you can work around it by using the right configuration.
   BTW, I don't know if the name of the proxy needs to registered as a
   domain member in the PDC, we did this in the process, if it is really
   needed it should be documented.

f) This is now a real problem for me: It seems that I can have only
   one proxy_auth acl active at own time. What do I mean by that, well if
   I have:

   http_access allow proxy_auth XXX
   http_access allow !CONNECT proxy_auth REQUIRED

   it's ok if I'm user XXX (second proxy_auth not reached) but otherwise
   it does not work at all. Instead the second ntlm_auth run notes on
   stderr:

   "Weird, disconnected" (or connection lost or something, sorry don't
   know the exact wording right now, at least it clearly states the tcp
   connection to the PDC was disconnected). Well it doesn't mention the
   PDC in the message, but the message comes from the SMB lib so I think
   this is waht it refers to. It then returns ERR domain controller error.

   If I configure only 1 ntlm helper process, I don't get a disconnect
   msg. Instead, I get a warning in squids error log I should configure
   more helpers and I get a TCP_DENY error in the access.log and the
   browser does not complain about authentication but gives a can't
   connect to proxy error.

   This really looks to me as if BOTH proxy_auth acls are evaluated at the
   same time and this fails. I cannot tell you if the PDC disconnects
   because it wants to deal with one request at a time only or if
   the ntlm module (ok ok.. squid's ntlm implemention) can't deal with
   more than one active proxy_auth which results in proxy_auth getting odd
   credentials which then cause the PDC to just disconnect.

   As a consequence I cannot tell you if ntlm-auth should just retry on
   a disconnect or if the error is in squid itself.

   I should mention that the same access config worked with v2.3 and
   smb_auth and the same PDC.

   I also had the strange feeling that (in acl definitions):

   specifying proxy_auth with non-existing users or users w/o <domain>\
   prefix can cause PDC disconnects.
   specifying proxy_auth "filename"
   does not work, seems sometimes as if \ is not read right from a file
   however you specify it. Seems having symbolic links involved does also
   hinder proxy_auth "filename", although I have all that well working
   for dst "filename".
   I could not clearly reproduce all these proxy_auth "filename" things,
   it is late (too late) at night and I might be wrong here.

   It seems that with extremely careful acls I can get together what
   I want (something like:)

   http_access allow CONNECT proxy_auth "httpsusers"
   http_access deny CONNECT
   http_access allow !CONNECT proxy_auth REQUIRED

   but I had some special rules in mind which I cannot add with a single
   proxy_auth checked for each connection. I'm unsure here, because I'm
   quite cross-legged already, so I dunno if my basics REALLY work and if
   its really impossible to get the acls do all I want with a single
   proxy_auth checked.

Now, case f) is the only one currently open to me, so I'm most interested
in that one, that is what's on with those multiple ntlm proxy_auths
active.

Any answer or patch or workaround is appreciated. If you need more
details, exact error logs, exact system call traces, ask me. I can also
try some things.

I should maybe mention this is on linux 2.2.16 with gcc 2.95.2 (yes, I
know, only one I have), but I doubt this is related to the problem.

Please advise, thx,
Michael.

--
Michael Weller: eowmob@exp-math.uni-essen.de, eowmob@ms.exp-math.uni-essen.de,
or even mat42b@spi.power.uni-essen.de. If you encounter an eowmob account on
any machine in the net, it's very likely it's me.
--
To unsubscribe, see http://www.squid-cache.org/mailing-lists.html