On fre, 2008-10-31 at 13:55 -0500, Richard wrote:
> * What specific piece of the puzzle on the client side is it about the
> NTLM or kerberos authentication methods that allow the authentication
> traffic secure by sending only the credential hashes?
The client talks to the microsoft SSP libraries and subsystem when
requested to provide authentication by a trusted proxy.
> (Am I correct in
> understanding that it is the ntlm_auth program that speaks to the NTLM
> client and negotiates for the credential hashes to be exchanged?)
No and yes, that's the server side that Squid uses for speaking to the
domain controllers to verify the provided credentials. The first thing
this does is to send a challenge which is relayed by Squid to the
client.
> * When squid is configured to use *digest* authentication, I understand
> that the traffic between the squid server and the LDAP server is
> encrypted. Is the traffic between the browser and the squid server
> also encrypted when using Digest? If so, how is it the client browser
> know to encrypt/hash the communications for the return trip to the server?
Digest authentication is a hashed authentication scheme, exchanging
one-time hashes instead of passwords on the wire. The acutal password is
only known by the client, the server only knows how to verify that the
exchanged one-time hash corresponds to the password and current session.
> **Short of loading a program on a client machine, are there any
> proxy servers out there that can prompt for credentials while keeping
> secure the communication between the workstation and the proxy server?
Using digest authentication will do this.
> ** What is it that has to happen to ensure that the authentication
> traffic from any browser to any proxy server is encrypted?
Neigher NTLM, kerberos or Digest is encrypted. But in all thre the
exchanged "password" is a one-time cryptographic hash of the password
and various session dependent details.
Modern windows versions provide single-sign-on for all three, but also
support prompting for credentials if the proxy isn't trusted or (Digest
ony) the realm is not the AD domain.
> * Considering the fact that I'm trying to use digest_ldap_auth against
> an MS LDAP/AD 2003 server that should be storing several precomputed
> digest hash versions of H(username:realm:password)
You can't use this helper to access the standard Active Directory
password details, but you can store an additional suitable DIgest hash
in another attribute and tell the helper to use this.
Or you can use a separade Digest password file on the proxy, and only
verify group memberships etc in the AD.
> A) Is it even possible to use digest_ldap_auth to do digest authenticate
> against an Active Directory 2003's LDAP database server?
Yes, but not to the system password. At least not without writing and AD
extension.
> B) What would be a working example command line of a successful
> digest_ldap_auth test against an AD 2003 server? (In my attempts, I have
> been unable to identify the proper digest hash containing LDAP (-A)
> attribute to use in a lookup. I *THINK* this is because MS AD2003
> expects the digest hash request to come via a SASL mechanism...which
> begs the question...is there a SASL mechanism that works with
> squid+AD2003?)
The Microsoft AD Digest implementation expects to be fully responsible
for the Digest implementation itself from what I understand, but not
sure. One way to find out is to read the Microsoft protocol
documentation which is provided on request. I don't have access to these
documents.
Regards
Henrik
This archive was generated by hypermail 2.2.0 : Sun Nov 02 2008 - 12:00:00 MST