Hi Tom,
Looking at the source of msktutil 0.4 I see that it checks the AD
capability and creates keys for all supported encryption types, not only the
ones you had before in the keytab.
Regards
Markus
"Tom Tux" <tomtux80_at_gmail.com> wrote in message
news:AANLkTi=xEKDXyFwDycD_KAhH7B31=7oWuvExcidC6Eef_at_mail.gmail.com...
Hi Markus
Thanks for this hint. Is it true, that the msktutil checks, if a DC
could "speak" with AES and then update the
msDS-SupportedEncryption-Type-Attribut on the computer-object in the
active-directory? In my case, I had this behaviour. And I don't know
exactly, if it's msktutil's guilt.
Tom
2010/12/10 Markus Moeller <huaraz_at_moeller.plus.com>:
> 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_at_gmail.com> wrote in message
> news:AANLkTinyJGcwbo_iTjqfaa2Kes6GQz0nyYqx=xZu5f3Q_at_mail.gmail.com...
> 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 Tue Dec 14 2010 - 18:40:10 MST
This archive was generated by hypermail 2.2.0 : Wed Dec 15 2010 - 12:00:03 MST