Re: [SQU] NDS Autentication

Robert Collins wrote:

> Is this using basic, Digest or NTLM authentication for the browser? I didn't
> think IE (or netscape for that matter) would present credentials to a proxy
> other than NTLM without prompting the user.
>
> The back-end system (LDAP/NDS/htpasswd etc) is largely irrelevant for
> "seamless" logins - what matters is the front end presented to the
> application.
>
> I would be very interested to know what http headers Bordermanager returns
> to IE with the 407 (Proxy authentication required) prompt when the user
> starts up IE. That would pretty much tell you what is going on.

BorderManager doesn't use HTTP for the authentication process when talking to
windows machine. You have to run a special program on the workstation. From
my understanding (which might be off somewhat, but should be close....)

The way single sign on works with BorderManger:
assuming access rules require authentication, and it isn't authenticated yet...

   then BM box sends a request to the client workstation.
   the workstation must be running a special clntrst (client trust) program.
(which is why it only works transparently on windows machines)
   the clntrst program logs into the BM box via NDS using the single-sign on
Novell had for years for their 4.x and above servers.
   the clntrst program then replies with the connection information to the
BM box where it can be verified they are logged in.
   If the user logs out of the work station, it also logs them out of the
proxy, and so web access is cut off unless they are relogged in and clntrust
will work...

If clntrst doesn't work (not logged in or timeout), the user is redirected to a
https: server running on the BM box. You can then log in via a login form.
The login form then redirects you back to the original web site you attempted
to goto assuming you log in. In this case BM simply tracks by IP, and after a
certain amount of web idle time it will make the person log back in again.
 The latest versions will optionally use session based cookies instead of
tracking by IP so that people behind a network address translator don't share
the same credentials. Then with tripple redirects (pretending to be the
destination site on one), it can track the session by cookies and when you
switch sites transparently issue a new cookie. That is good in that if you are
idle longer then the timeout, you only have to log in once, and of course the
NAT issue. Hoewver, that does not work with secure https sites for obvious
reasons...

On the minus side.... There was a posting to BUGTRAQ that the BM -> client was
weak... Essentially you could run a simple UDP forwarder on a Unix box,
redirect it to a windows box, and you would get the credentials of that windows
box from the Unix box for purposes of browsing the web... Essential goes
BM->Unix->workstation and then workstation logs in securely and replies
back->Unix->BM, and BM says ok you have rights. That was a while ago, so it
might be fixed with the latest service packs.

> Rob
>
> ----- Original Message -----
> From: "John Lauro" <jlauro@umich.edu>
> To: <squid-users@ircache.net>
> Sent: Saturday, October 28, 2000 11:30 PM
> Subject: Re: [SQU] NDS Autentication
>
> > Henrik Nordstrom wrote:
> >
> > > Fabricio Lima wrote:
> > >
> > > > Can I do the same with squid? (sure, using remote autentication!)
> > > > But how? Which is the name of the "module" that makes a communication
> > > > between squid and NDS ???
> > >
> > > I think you can use the ldap_auth module for authenticating against NDS
> > > if exported using the LDAP service.
> >
> > Correct me if I am wrong, but as I understand LDAP but haven't actually
> > tried it.... That might work, but from what I understand LDAP wouldn't be
> > transparent and would be "SAME" login, and not "SINGLE" login. The user
> > would have to login into squid, instead of it authenticating transparently
> > in the background on first connect.
> >
> > With Bordermanager, you login once into the network. (Well, for Windows
> > machines.... Mac and Unix are closer to what I assume LDAP would be, and
> > require a login via the browser....)

--
To unsubscribe, see http://www.squid-cache.org/mailing-lists.html