[19680] in Kerberos_V5_Development
Re: Incompatibility between krb's AES256-CTS-HMAC-SHA1-96 and
daemon@ATHENA.MIT.EDU (Shawn Emery)
Thu Nov 9 19:41:13 2017
MIME-Version: 1.0
In-Reply-To: <1510271219.7682.232.camel@redhat.com>
From: Shawn Emery <shawn.emery@gmail.com>
Date: Thu, 9 Nov 2017 17:40:51 -0700
Message-ID: <CAChzXmaShMU+5wrgveB3vkwfXX=cwz-=TtRs1W+o=_V=yOu09g@mail.gmail.com>
To: Simo Sorce <simo@redhat.com>
Cc: MIT Kerberos Dev List <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Thu, Nov 9, 2017 at 4:46 PM, Simo Sorce <simo@redhat.com> wrote:
> 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.
Note that the salts for AD are derived from the UPN attribute:
host/<lower case node name up to 15 characters>.<domain name>@<realm name>
not the individual SPNs, as would be the case for non-AD environments.
Shawn.
--
> 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@gmail.com> wrote:
> >
> > >
> > >
> > > On Thu, Nov 9, 2017 at 5:00 PM, Ido Shlomo <shloim@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@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
>
> _______________________________________________
> krbdev mailing list krbdev@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
