Hi folks,
we are experiencing an issue where we don't know this is a bug or missing
feature in MIT Kerberos. I tend to a bug.
We have a headless service which relies on a client keytab to perform some
HTTP calls from within a C application with libcurl. Once in a while these
calls fail due to: "K
On 08/17/2016 08:51 AM, Osipov, Michael wrote:
> The keytab contains three keys for one principal: RC4, AES128, AES256.
> Our home realm is backed up by 80 to 100 KDCs of various Windows Server
> versions, not all support AES. KDC lookups rely on DNS only and we do
> not intend to hardcode them in
Michael,
This does not fix your issue, its more for clarification of discussion.
The "domain functional level" should be dictating the behavior of the
aggregate AD environment. You can control the preference for encryption
type in the krb5.conf's [libdefaults] enctype
settings (default_tgs_enctyp
If it is Active Directory that you are talking about here, I would be focusing
on upgrading the DCs that are still running unsupported operating systems.
There are no currently supported versions of Windows that cannot support AES128
and AES256.
You could turn off the AES enctypes in all DCs us
