Re: squid3 PRE1 ?

From: Robert Collins <robertc@dont-contact.us>
Date: 23 Apr 2003 20:48:04 +1000

On Wed, 2003-04-23 at 18:44, michele.de-martin@electrolux.it wrote:
> Here is what I've done (and I would like to be included in squid
> distribution, if it is ok for you).
>
> 1. A perl script that can do basic authentication against multiple not
> trusted domain. It uses "rpcclient" command from samba to authenticate user
> credential aginst PDCs.
> The users credentials passed by squid are in the form "DOMAIN\USER
> password" and so it's easy to authenticate against the right PDC.

Sure, and thats fine for inclusion in squid in the helpers/basic_auth/
subtree.

> 2. A perl script that can check if a given user belongs to a given NT group
> on a given PDC. It uses "rpcclient" command from samba.
> The user passed by squid is in the form "DOMAIN\USER" and again it's easy
> to select the right PDC.
>
> 3. A C program (ugly modified from "helpers/SMB/ntlm_auth.c") that do all
> the YR->TT->KK->AF job. It relies on first NEGOTIATE packet sent with "YR"
> to select the right domain/PDC.

Well, that won't work. You'll get mysterious authentication failures and
popups, without serious changes to squid.

> The "kit" is now in a production enviroment but I went into that strange
> behaviour of random pop-windows asking for username/password (see
> squid-users for details).

Yah, this is a result of your NTLM multi domain approach.

> On the right domain selection.
> In my knowledge, a user can login a NT workstation/server only if his
> domain is the same as the workstation one, or there is a trust relationship
> between them.

Yes.

> Given this situation, using the workstation domain to select
> the PDC to authenticate against or using the user domain is quite the same.

Nope.

> I think this is how the NT workstation works to authenticate a user from a
> trusted domain (I am not sure about this).

It's not. I am sure.

> This is also how original NTLM squid authenticator works, I think.

No, it's not.

> Anyway, if my assumptions are wrong, it is worth to introduce multi domain
> authentication with the limitation that it works only if "user domain"
> == "workstation domain". We can warn about it in documentation/README etc.

For the NTLM code, no, it's not worth introducing the wrong thing. I'm
happy to provide feedback on your ideas to help you get it doing the
right thing. But your current approach *will* fail. Always.

To get the basic multi-domain authenticator into squid, simply patch
configure.in to include it in the list of basic helpers, and add your
code to a directory in helpers/basic_auth, with a Makefile.am. Then send
in a patch that includes the changes to configure.in, and the new
directory.

For the NTLM multi-domain hack, you need to address the following key
before it's worth considering:

* Squid internally only has one challenge per helper available. You need
to alter this to be one challenge per domain per helper, and logic to
send the correct challenge to the client, where currently squid sends
some the challenge of the chosen helper.

Without that, squid will *consistently* cause pop-ups to appear on
workstations, because the challenge is not one issued by the domain the
auth request was sent to.

What NT workstations do is issue a challenge locally, and then use an
RPC call over the secure channel to their login server to have the
triple (user domain, issued challenge, recieved response) checked. ONLY
trusted workstations can issue this RPC call. Now, the winbind helper
uses the winbindd challenge to perform this same RPC call. IF, and only
IF, you have a helper that can do the same - issue a challenge, and then
choose the DC to verify it after-the-fact - then multi-domain
authentication will work reliably.

Now, the way that this hypothetical helper would work, is by having
secure channels to all the DC's needed (which is what being a domain
member gives you within a domain, and domain trusts gives you cross
domains).

So, the long term solution IMO is to hack up winbindd to allow
membership in multiple domains, without trust relationships between
them. If that is done,. squid doesn't need to change at all, and this
will be the most reliable solution.

Rob

-- 
GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.

Received on Wed Apr 23 2003 - 04:48:57 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:19:42 MST