Incompatibility between krb's AES256-CTS-HMAC-SHA1-96 and Microsoft Windows Domain

Simo Sorce simo at
Thu Nov 9 18:46:59 EST 2017

the problem is that you do not get the key out of AD but you use
kerberos utils to generate it. As mentioned before when you do that the
"wrong" salt is used, so your keys cannot work.

It works for "users" because it just so happen that both the AD KDC and
your utilities use the same logic to derive keys for UPNs. But AD uses
a different logic for SPNs.

You need to either modify your utilities to deal with the salt
"properly" according to how the KDC generates hashes from a password,
or you need to use utilities that let the KDC generate the keys and
give you back a keytab,
That's it, there is no other way around.


On Thu, 2017-11-09 at 23:03 +0300, Ido Shlomo wrote:
> No. I am registering an SPN for a single account.
> The operation has 2 phases:
> Add an entry to the local keytab using ktuil.
> Add an entry to the User object in the Active Directory using
> openldap.
> On Nov 9, 2017 20:10, "Isaac Boukris" <iboukris at> wrote:
> > 
> > 
> > On Thu, Nov 9, 2017 at 5:00 PM, Ido Shlomo <shloim at>
> > wrote:
> > > The thing is that kinit works well for the user (not computer)
> > > The problem is that I register an SPN on the DC for that user
> > > (again, not
> > > computer) using ldap, and then I resgister the same SPN
> > > (MSSQL/ at DOMAIN.COM). The problem occurs
> > > when an
> > > incoming connection gives me a token that I cannot accept. The
> > > error is
> > 
> > that
> > > I cannot decrypt it.
> > 
> > Wait, are you registering the same SPN twice to two different
> > accounts?
> > You aren't supposed to do that I think, as the KDC might encrypt
> > the
> > ticket with the key of the other principal.
> > 

Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc

More information about the krbdev mailing list