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
This archive was generated by hypermail pre-2.1.9 : Mon May 01 2006 - 12:00:02 MDT