Hi Tom,
AES is a stronger encryption than RC4, why it is selected first by clients
who support it (Windows 7,Vista, 2008, newer MIT/Heimdal versions on Unix).
XP/Windows 2003 clients will continue to use RC4 as AES is not supported in
XP/Windows 2003 .
Markus
"Tom Tux" <tomtux80@xxxxxxxxx> wrote in message
news:AANLkTinyJGcwbo_iTjqfaa2Kes6GQz0nyYqx=xZu5f3Q@xxxxxxxxxxxxxxxxx
Hi Markus
In the meantime, the klist -etk /etc/krb5.keytab have AES entries:
AES-128 CTS mode with 96-bit SHA-1 HMAC
AES-256 CTS mode with 96-bit SHA-1 HMAC
But they were made by the nightly "msktutil --auto-update" job (after
30 days were passed). And during this step, that
msDS-SupportedEncryption-Type-Attribut was also created on the
computer-object in the active-directory. That was also the reason, why
squid stopped authenticating the users, because the necessary lines
(aes) for w2k8 in the krb5.conf for w2k8, didn't exists yet.
During the first (initial) msktutil (which creates a computer-object
in the ad-domain), I didn't use the option "--enctypes 28", because on
this time, we just had w2k3-domain-controllers.
I don't exactly understand, why squid stops authenticating, when I
change the krb5.conf-file back to "default_tgs_enctypes = rc4-hmac
des-cbc-crc des-cbc-md5" (without aes). On my client, I see also
session-tickets for the http-service with only rc4-hmac (instead of
aes) and this works fine (when the krb5.conf is already configured
with aes).
Could it be, that msktutil realizes, that it has to authenticate to a
w2k8-dc and therefore add the msDS-SupportedEncryption-Type-attribut
to the computer-object and use the "aes"-algorithm as its preferred
one?
Is the aes stronger than the rc4-hmac and that could be the reason,
why I'm not able to talk to squid with "rc4-hmac"? So the stronger
wins?
Thanks in advance.
Tom
2010/12/9 Markus Moeller <huaraz@xxxxxxxxxxxxxxxx>:
Hi Tom,
What does klist -ekt squid.keytab show ? Does it have an entry for AES ?
Did you use --enctypes 28 with msktutil as described here
http://wiki.squid-cache.org/ConfigExamples/Authenticate/Kerberos#Create_keytab
?
Markus
"Tom Tux" <tomtux80@xxxxxxxxx> wrote in message
news:AANLkTimUyH9MSqcTe5sHmMOQdJpvdYhfqPOtf+Ajto9U@xxxxxxxxxxxxxxxxx
I recognized, that the values in the AD-computer-object (attribut
msDS-SupportedEncryption-Type) has to match the client-kerberos-ticket
(session-key) and the settings made in /etc/krb5.conf. On all three
parts, the aes-256....value must be set.
If not, there's not authentication possible.
Is it true, that always the strongest key (in this case probably aes-256)
wins?
Tom
2010/12/9 Amos Jeffries <squid3@xxxxxxxxxxxxx>:
On 09/12/10 19:43, Tom Tux wrote:
Hi
We moved our W2K3-Domaincontrollers to W2K8-DC's. The active-directory
operational mode is still 2003.
We're using kerberos-authentication against the active-directory.
Nightly runs the "msktutil --auto-update" on the squid-proxy. One day,
this updated the computer-account and added the new
msDS-SupportedEncryption-Type = 28.
On one morning, nobody could be authenticated against the
active-directory. On the cache.log, I saw the following error:
authenticateNegotiateHandleReply: Error validating user via Negotiate.
Error returned 'BH gss_accept_sec_context() failed: Unspecified GSS
failure. Minor code may provide more information. Encryption type not
permitted'
So, I added the "aes256-cts-hmac-sha1-96" encryption-type in the
/etc/krb5.conf-file. Now, everything is working fine. On the
computer-object in the active-directory, I see a value of 28 on the
attribut "msDS-SupportedEncryption Types" (updated through msktutil).
When I trace the kerberos-traffic between the proxy and the new
w2k8-domain-controller, I still see the old encryption-type "rc4-hmac"
is being used.
Why is there not the new encryption-type "aes" used? Why is still the
"old" one used? Before I updated the krb5.conf with the "aes"-part,
nobody was able to authenticate. And now, squid "talks" still with the
old one?
Squid uses whatever support is available in the libraries, which may be
version-specific from when it was built. It is likely that they and/or
squid
need to be upgraded to support that algorithm.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.9
Beta testers wanted for 3.2.0.3
