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_at_moeller.plus.com>:
> 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_at_gmail.com> wrote in message
> news:AANLkTimUyH9MSqcTe5sHmMOQdJpvdYhfqPOtf+Ajto9U_at_mail.gmail.com...
> 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_at_treenet.co.nz>:
>>
>> 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
>>
>
>
>
Received on Thu Dec 09 2010 - 21:36:22 MST
This archive was generated by hypermail 2.2.0 : Sat Dec 11 2010 - 12:00:02 MST