Re: [SQU] NDS Autentication

----- Original Message -----
From: "John Lauro" <jlauro@umich.edu>
To: <squid-users@ircache.net>
Sent: Sunday, October 29, 2000 1:40 AM
Subject: 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....)

So what happens on Citrix servers/Terminal servers? Novell has supported
those in it's client software for years.

>
> 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

How does BM identify a downstream proxy then? Or again TS/Citrix servers?

> 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...

Pity that they don't use standards based authentication: Digest
authentication is reasonably secure and doesn't involve man-in-the-middle
attacks against the outside web to perform authentication :=] Seriously
though that seems a fairly dodgy way of identifying your users.
If Novell didn't want to use Digest Authentication they could always write a
.dll for an NDS over http authentication mechanism and put it to the IETF as
an extension to rfc 2617 (Authentication types for http/1.1)

>
> 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.

Single sign on requires all the applications to be used to be able to access
the user credentials and offer them to servers *that identify themselves as
belonging to the same organisation*. AFAIK only NTLM is supported by
microsoft for that purpose. The use of SSH or kerberos in the unix world
provides a very similar feel. Possibly Kerberos will be supported by IE now
it';s part of Win2k.

Rob

>
> > 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
>
>

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