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

[Simo Sorce]

Ido,
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.

Simo.

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 gmail.com> wrote:
> 
> > 
> > 
> > On Thu, Nov 9, 2017 at 5:00 PM, Ido Shlomo <shloim at gmail.com>
> > 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/mymachine.domain.com:1433 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