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
Attachment:
signature.asc
Description: This is a digitally signed message part
