mån 2006-04-10 klockan 15:59 +0200 skrev Paolo Biancolli: > You mentioned I need at least the -A option to the line in squid.conf. Yes. It's required as without it the helper has no means of knowing how to retrieve the users password (as plain-text or digest H(A1) hash) from the directory server. > The ldap database I am authenticating against is a MS 2003 active > directory. Do I specify the password attribute which contains the > users password (unicodePwd attribute in active directory) i.e. Have you verified that this attribute does contain the plain text password? Last word I have heard regarding this attribute is that a) Storage of "reversibly encrypted" passwords must be enabled in the directory server for plain-text passwords to be at all stored by MS-AD. <url: b) The attributes storing password information isn't published via LDAP by MS AD, only internal RPC calls. It's only available via LDAP as a write-only attributes for setting the password.. c) It's content is encrypted. d) unicodePwd contains the NT# of the password, not the actual password. As such it's only useful for Microsoft NTLM and related authentication schemes, not for Digest authentication. <url:http://msdn.microsoft.com/library/en-us/adschema/adschema/a_unicodepwd.asp> Only 'a' and 'd' is verified from Microsoft documentation, but I am pretty sure about 'b' and 'c' as well. What can be said for sure is that you can't use this attribute in combination with the -e flag to digest_pw_auth. The -e flag expects the password attribute to contain the exact hashed form I quoted earlier, nothing else. To use the -e flag you need to extend MS AD to store a Digest password hash on the form quoted earlier in addition to the NT & LM hashes it normally stores. Windows2003 supports hashing of passwords in a way which looks like it could be made useable by Squid, but it is at this stage unclear how to make use of this information. This is provided by Microsoft as part of the "Advanced Digest" support for IIS 6.0 and later.. If this information can be accessed via LDAP then extending digest_ldap_auth to support this isn't hard. If your directory service can somehow be convinced into exposing the plain-text password of the user (which I doubt) and you think this is a good path then Squid digest_ldap_auth can make use of that information by not specifying the -e option, and somewhat securely so via TLS (-Z flag). But be warned that anyone who gain access to the credentials used by digest_ldap_auth can easily get hold of all users plain-text password from the directory in such setups.. Regards Henrik
Attachment:
signature.asc
Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signerad meddelandedel
