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

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Ido Shlomo
I am trying to upgrade our system's kerberos encryption from RC4 to AES256.
I've set up a Microsoft Windows Domain user with AES256 encryption support.
I'm creating a keytab for kinit using ktutil on Linux:

ADD_ENTRY="addent -password -p $DOMAIN_LOCAL_USER@$DOMAIN_UPCASE -k 2
-e AES256-CTS-HMAC-SHA1-96\n$DOMAIN_LOCAL_PASS\n"
echo -e "$ADD_BASE_ENTRY\n$ADD_ENTRY\nwkt user.keytab\nquit\n" | ktutil

kinit works well with that keytab.

However, when I'm creating an SPN for this user using ktutil on Linux

ADD_BASE_ENTRY="addent -password -p
MSSQLSvc/$SHORT_HOSTNAME.$DOMAIN_LOWCASE@$DOMAIN_UPCASE -k 2 -e
RC4-HMAC\n$DOMAIN_PASSWORD\n"
echo -e "rkt spns.keytab\n$ADD_BASE_ENTRY\n$ADD_ENTRY\nwkt
spns.keytab\nquit\n" | ktutil > /dev/null 2>&1

then I'm unable to accept incoming connections using krb 1.15.2:

GSS-API major_status:000d0000, minor_status:000186a6
GetGSSError(): GSS Error ERR_MAX: Unspecified GSS failure.  Minor code
may provide more information
GetGSSError(): GSS Error ERR_MIN: Request ticket server
MSSQLSvc/greensqlcent21.kerberosdc.msft:[hidden email] kvno 2
enctype aes256-cts found in keytab but cannot decrypt ticket

This has worked well when I was using RC4_HMAC for everything.

*Some background:*

My application mimics an MSSQL server. I'm running as a User (not as the
computer) and I have set this user to login with AES256. Initially, I have
kept the SPNs in the incoming keytab file with RC4_HMAC (this used to work
when the domain user was also authenticating using RC4_HMAC), but I got an
error that the gssapi accept function is looking for an AES256 entry in the
SPN keytab file. So I changed the SPN keytab file to also use AES256 and
got the above error.

Tested with both Windows 2k8 and 2k12 as Domain Controllers. Both fail.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Simo Sorce-3
On Tue, 2017-10-31 at 10:55 +0300, Ido Shlomo wrote:

> I am trying to upgrade our system's kerberos encryption from RC4 to AES256.
> I've set up a Microsoft Windows Domain user with AES256 encryption support.
> I'm creating a keytab for kinit using ktutil on Linux:
>
> ADD_ENTRY="addent -password -p $DOMAIN_LOCAL_USER@$DOMAIN_UPCASE -k 2
> -e AES256-CTS-HMAC-SHA1-96\n$DOMAIN_LOCAL_PASS\n"
> echo -e "$ADD_BASE_ENTRY\n$ADD_ENTRY\nwkt user.keytab\nquit\n" | ktutil
>
> kinit works well with that keytab.
>
> However, when I'm creating an SPN for this user using ktutil on Linux
>
> ADD_BASE_ENTRY="addent -password -p
> MSSQLSvc/$SHORT_HOSTNAME.$DOMAIN_LOWCASE@$DOMAIN_UPCASE -k 2 -e
> RC4-HMAC\n$DOMAIN_PASSWORD\n"
> echo -e "rkt spns.keytab\n$ADD_BASE_ENTRY\n$ADD_ENTRY\nwkt
> spns.keytab\nquit\n" | ktutil > /dev/null 2>&1
>
> then I'm unable to accept incoming connections using krb 1.15.2:
>
> GSS-API major_status:000d0000, minor_status:000186a6
> GetGSSError(): GSS Error ERR_MAX: Unspecified GSS failure.  Minor code
> may provide more information
> GetGSSError(): GSS Error ERR_MIN: Request ticket server
> > MSSQLSvc/greensqlcent21.kerberosdc.msft:[hidden email] kvno 2
> enctype aes256-cts found in keytab but cannot decrypt ticket
>
> This has worked well when I was using RC4_HMAC for everything.
>
> *Some background:*
>
> My application mimics an MSSQL server. I'm running as a User (not as the
> computer) and I have set this user to login with AES256. Initially, I have
> kept the SPNs in the incoming keytab file with RC4_HMAC (this used to work
> when the domain user was also authenticating using RC4_HMAC), but I got an
> error that the gssapi accept function is looking for an AES256 entry in the
> SPN keytab file. So I changed the SPN keytab file to also use AES256 and
> got the above error.
>
> Tested with both Windows 2k8 and 2k12 as Domain Controllers. Both fail.

One of the differences with AES is that those keys are generated using
a SALT, unlike RC4_HMAC. So if the salt is not properly computed your
key will not match.
IIRC for SPNs in AD the Salt is always the computer name (as stored in
the SamAccountName attribute), while in most krb implementation the
SALT is the principal name, this may be why your key generation doesn't
work.

You should probably fetch the keytab directly for AD instead of trying
to generate your own via a password. You can use use tools like mskutil
or similar.

HTH,
Simo.

--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Ido Shlomo
Since this is an automated task, I cannot generate anything outside the
machine.
Is it possible to specify the salt using ktutil?

On Oct 31, 2017 16:20, "Simo Sorce" <[hidden email]> wrote:

> On Tue, 2017-10-31 at 10:55 +0300, Ido Shlomo wrote:
> > I am trying to upgrade our system's kerberos encryption from RC4 to
> AES256.
> > I've set up a Microsoft Windows Domain user with AES256 encryption
> support.
> > I'm creating a keytab for kinit using ktutil on Linux:
> >
> > ADD_ENTRY="addent -password -p $DOMAIN_LOCAL_USER@$DOMAIN_UPCASE -k 2
> > -e AES256-CTS-HMAC-SHA1-96\n$DOMAIN_LOCAL_PASS\n"
> > echo -e "$ADD_BASE_ENTRY\n$ADD_ENTRY\nwkt user.keytab\nquit\n" | ktutil
> >
> > kinit works well with that keytab.
> >
> > However, when I'm creating an SPN for this user using ktutil on Linux
> >
> > ADD_BASE_ENTRY="addent -password -p
> > MSSQLSvc/$SHORT_HOSTNAME.$DOMAIN_LOWCASE@$DOMAIN_UPCASE -k 2 -e
> > RC4-HMAC\n$DOMAIN_PASSWORD\n"
> > echo -e "rkt spns.keytab\n$ADD_BASE_ENTRY\n$ADD_ENTRY\nwkt
> > spns.keytab\nquit\n" | ktutil > /dev/null 2>&1
> >
> > then I'm unable to accept incoming connections using krb 1.15.2:
> >
> > GSS-API major_status:000d0000, minor_status:000186a6
> > GetGSSError(): GSS Error ERR_MAX: Unspecified GSS failure.  Minor code
> > may provide more information
> > GetGSSError(): GSS Error ERR_MIN: Request ticket server
> > > MSSQLSvc/greensqlcent21.kerberosdc.msft:[hidden email] kvno 2
> > enctype aes256-cts found in keytab but cannot decrypt ticket
> >
> > This has worked well when I was using RC4_HMAC for everything.
> >
> > *Some background:*
> >
> > My application mimics an MSSQL server. I'm running as a User (not as the
> > computer) and I have set this user to login with AES256. Initially, I
> have
> > kept the SPNs in the incoming keytab file with RC4_HMAC (this used to
> work
> > when the domain user was also authenticating using RC4_HMAC), but I got
> an
> > error that the gssapi accept function is looking for an AES256 entry in
> the
> > SPN keytab file. So I changed the SPN keytab file to also use AES256 and
> > got the above error.
> >
> > Tested with both Windows 2k8 and 2k12 as Domain Controllers. Both fail.
>
> One of the differences with AES is that those keys are generated using
> a SALT, unlike RC4_HMAC. So if the salt is not properly computed your
> key will not match.
> IIRC for SPNs in AD the Salt is always the computer name (as stored in
> the SamAccountName attribute), while in most krb implementation the
> SALT is the principal name, this may be why your key generation doesn't
> work.
>
> You should probably fetch the keytab directly for AD instead of trying
> to generate your own via a password. You can use use tools like mskutil
> or similar.
>
> HTH,
> Simo.
>
> --
> Simo Sorce
> Sr. Principal Software Engineer
> Red Hat, Inc
>
>
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Isaac Boukris
On Tue, Oct 31, 2017 at 4:44 PM, Ido Shlomo <[hidden email]> wrote:
> Since this is an automated task, I cannot generate anything outside the
> machine.
> Is it possible to specify the salt using ktutil?

You can try an AS request where the KDC tells the salt, like:
# KRB5_TRACE=/dev/tty kinit principal

btw, for user-account in AD the salt is the UPN attribute of the user.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Isaac Boukris
On Tue, Oct 31, 2017 at 5:47 PM, Isaac Boukris <[hidden email]> wrote:
> On Tue, Oct 31, 2017 at 4:44 PM, Ido Shlomo <[hidden email]> wrote:
>> Since this is an automated task, I cannot generate anything outside the
>> machine.
>> Is it possible to specify the salt using ktutil?
>
> You can try an AS request where the KDC tells the salt, like:
> # KRB5_TRACE=/dev/tty kinit principal
>
> btw, for user-account in AD the salt is the UPN attribute of the user.


Sorry, I misread the question, thought you were asking how to find the
actual salt.
I am not familiar with such option in ktutil, though according to the
source code the recent version of it does provide this option
(alternatively, you can use the same code that ktutil uses and specify
the salt).

Regards.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Andreas Schneider
In reply to this post by Simo Sorce-3
On Tuesday, 31 October 2017 15:20:18 CET Simo Sorce wrote:

> On Tue, 2017-10-31 at 10:55 +0300, Ido Shlomo wrote:
> > I am trying to upgrade our system's kerberos encryption from RC4 to
> > AES256.
> > I've set up a Microsoft Windows Domain user with AES256 encryption
> > support.
> > I'm creating a keytab for kinit using ktutil on Linux:
> >
> > ADD_ENTRY="addent -password -p $DOMAIN_LOCAL_USER@$DOMAIN_UPCASE -k 2
> > -e AES256-CTS-HMAC-SHA1-96\n$DOMAIN_LOCAL_PASS\n"
> > echo -e "$ADD_BASE_ENTRY\n$ADD_ENTRY\nwkt user.keytab\nquit\n" | ktutil
> >
> > kinit works well with that keytab.
> >
> > However, when I'm creating an SPN for this user using ktutil on Linux
> >
> > ADD_BASE_ENTRY="addent -password -p
> > MSSQLSvc/$SHORT_HOSTNAME.$DOMAIN_LOWCASE@$DOMAIN_UPCASE -k 2 -e
> > RC4-HMAC\n$DOMAIN_PASSWORD\n"
> > echo -e "rkt spns.keytab\n$ADD_BASE_ENTRY\n$ADD_ENTRY\nwkt
> > spns.keytab\nquit\n" | ktutil > /dev/null 2>&1
> >
> > then I'm unable to accept incoming connections using krb 1.15.2:
> >
> > GSS-API major_status:000d0000, minor_status:000186a6
> > GetGSSError(): GSS Error ERR_MAX: Unspecified GSS failure.  Minor code
> > may provide more information
> > GetGSSError(): GSS Error ERR_MIN: Request ticket server
> >
> > > MSSQLSvc/greensqlcent21.kerberosdc.msft:[hidden email] kvno 2
> >
> > enctype aes256-cts found in keytab but cannot decrypt ticket
> >
> > This has worked well when I was using RC4_HMAC for everything.
> >
> > *Some background:*
> >
> > My application mimics an MSSQL server. I'm running as a User (not as the
> > computer) and I have set this user to login with AES256. Initially, I have
> > kept the SPNs in the incoming keytab file with RC4_HMAC (this used to work
> > when the domain user was also authenticating using RC4_HMAC), but I got an
> > error that the gssapi accept function is looking for an AES256 entry in
> > the
> > SPN keytab file. So I changed the SPN keytab file to also use AES256 and
> > got the above error.
> >
> > Tested with both Windows 2k8 and 2k12 as Domain Controllers. Both fail.
>
> One of the differences with AES is that those keys are generated using
> a SALT, unlike RC4_HMAC. So if the salt is not properly computed your
> key will not match.
> IIRC for SPNs in AD the Salt is always the computer name (as stored in
> the SamAccountName attribute), while in most krb implementation the
> SALT is the principal name, this may be why your key generation doesn't
> work.

There are different salt principals depending on the type, the most commond
are:

host/[hidden email]
[hidden email]
[hidden email]                                                                                                                                        

However you need to convert the salt principal to a salt data blob which is
passed to krb5_c_string_to_key(). Those need to be in the following form:

EXAMPLE.COMhost/somehost.example.com                                                                                                                              
EXAMPLE.COMSomeAccount                                                                                                                                            
EXAMPLE.COMSomePrincipal


        Andreas
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Ido Shlomo
In reply to this post by Isaac Boukris
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:[hidden email]). The problem occurs when an
incoming connection gives me a token that I cannot accept. The error is
that I cannot decrypt it.

On Oct 31, 2017 17:47, "Isaac Boukris" <[hidden email]> wrote:

On Tue, Oct 31, 2017 at 4:44 PM, Ido Shlomo <[hidden email]> wrote:
> Since this is an automated task, I cannot generate anything outside the
> machine.
> Is it possible to specify the salt using ktutil?

You can try an AS request where the KDC tells the salt, like:
# KRB5_TRACE=/dev/tty kinit principal

btw, for user-account in AD the salt is the UPN attribute of the user.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Ido Shlomo
In reply to this post by Andreas Schneider
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:[hidden email]). The problem occurs when an
incoming connection gives me a token that I cannot accept. The error is
that I cannot decrypt it.

On Nov 9, 2017 16:47, "Andreas Schneider" <[hidden email]> wrote:

> On Tuesday, 31 October 2017 15:20:18 CET Simo Sorce wrote:
> > On Tue, 2017-10-31 at 10:55 +0300, Ido Shlomo wrote:
> > > I am trying to upgrade our system's kerberos encryption from RC4 to
> > > AES256.
> > > I've set up a Microsoft Windows Domain user with AES256 encryption
> > > support.
> > > I'm creating a keytab for kinit using ktutil on Linux:
> > >
> > > ADD_ENTRY="addent -password -p $DOMAIN_LOCAL_USER@$DOMAIN_UPCASE -k 2
> > > -e AES256-CTS-HMAC-SHA1-96\n$DOMAIN_LOCAL_PASS\n"
> > > echo -e "$ADD_BASE_ENTRY\n$ADD_ENTRY\nwkt user.keytab\nquit\n" |
> ktutil
> > >
> > > kinit works well with that keytab.
> > >
> > > However, when I'm creating an SPN for this user using ktutil on Linux
> > >
> > > ADD_BASE_ENTRY="addent -password -p
> > > MSSQLSvc/$SHORT_HOSTNAME.$DOMAIN_LOWCASE@$DOMAIN_UPCASE -k 2 -e
> > > RC4-HMAC\n$DOMAIN_PASSWORD\n"
> > > echo -e "rkt spns.keytab\n$ADD_BASE_ENTRY\n$ADD_ENTRY\nwkt
> > > spns.keytab\nquit\n" | ktutil > /dev/null 2>&1
> > >
> > > then I'm unable to accept incoming connections using krb 1.15.2:
> > >
> > > GSS-API major_status:000d0000, minor_status:000186a6
> > > GetGSSError(): GSS Error ERR_MAX: Unspecified GSS failure.  Minor code
> > > may provide more information
> > > GetGSSError(): GSS Error ERR_MIN: Request ticket server
> > >
> > > > MSSQLSvc/greensqlcent21.kerberosdc.msft:[hidden email] kvno 2
> > >
> > > enctype aes256-cts found in keytab but cannot decrypt ticket
> > >
> > > This has worked well when I was using RC4_HMAC for everything.
> > >
> > > *Some background:*
> > >
> > > My application mimics an MSSQL server. I'm running as a User (not as
> the
> > > computer) and I have set this user to login with AES256. Initially, I
> have
> > > kept the SPNs in the incoming keytab file with RC4_HMAC (this used to
> work
> > > when the domain user was also authenticating using RC4_HMAC), but I
> got an
> > > error that the gssapi accept function is looking for an AES256 entry in
> > > the
> > > SPN keytab file. So I changed the SPN keytab file to also use AES256
> and
> > > got the above error.
> > >
> > > Tested with both Windows 2k8 and 2k12 as Domain Controllers. Both fail.
> >
> > One of the differences with AES is that those keys are generated using
> > a SALT, unlike RC4_HMAC. So if the salt is not properly computed your
> > key will not match.
> > IIRC for SPNs in AD the Salt is always the computer name (as stored in
> > the SamAccountName attribute), while in most krb implementation the
> > SALT is the principal name, this may be why your key generation doesn't
> > work.
>
> There are different salt principals depending on the type, the most commond
> are:
>
> host/[hidden email]
> [hidden email]
> [hidden email]
>
> However you need to convert the salt principal to a salt data blob which is
> passed to krb5_c_string_to_key(). Those need to be in the following form:
>
> EXAMPLE.COMhost/somehost.example.com
> EXAMPLE.COMSomeAccount
> EXAMPLE.COMSomePrincipal
>
>
>         Andreas
>
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Isaac Boukris
In reply to this post by Ido Shlomo
On Thu, Nov 9, 2017 at 5:00 PM, Ido Shlomo <[hidden email]> 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:[hidden email]). 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.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Ido Shlomo
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" <[hidden email]> wrote:

>
>
> On Thu, Nov 9, 2017 at 5:00 PM, Ido Shlomo <[hidden email]> 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:[hidden email]). 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.
>
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Simo Sorce-3
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" <[hidden email]> wrote:
>
> >
> >
> > On Thu, Nov 9, 2017 at 5:00 PM, Ido Shlomo <[hidden email]>
> > 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:[hidden email]). 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Shawn Emery
On Thu, Nov 9, 2017 at 4:46 PM, Simo Sorce <[hidden email]> 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" <[hidden email]> wrote:
> >
> > >
> > >
> > > On Thu, Nov 9, 2017 at 5:00 PM, Ido Shlomo <[hidden email]>
> > > 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:[hidden email]). 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             [hidden email]
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Ido Shlomo
In reply to this post by Simo Sorce-3
Thank you. I understand the options, but I am not familiar with tools that
may do that automatically. (currently this entire process is automated
using shell scripts).

On Nov 10, 2017 01:47, "Simo Sorce" <[hidden email]> 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.
>
> 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" <[hidden email]> wrote:
> >
> > >
> > >
> > > On Thu, Nov 9, 2017 at 5:00 PM, Ido Shlomo <[hidden email]>
> > > 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:[hidden email]). 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Isaac Boukris
On Fri, Nov 10, 2017 at 7:08 AM, Ido Shlomo <[hidden email]> wrote:
> Thank you. I understand the options, but I am not familiar with tools that
> may do that automatically. (currently this entire process is automated using
> shell scripts).

If you know the salt and it is different than what ktutil uses, then
you may be able to build the ktutil from git master which let's you
specify the salt.
For troubleshooting, i'd still suggest to try kinit and see what salt
the actually is, like:
KRB5_TRACE=/dev/stdout kinit principal |grep salt

HTH
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Andreas Schneider
In reply to this post by Ido Shlomo
On Thursday, 9 November 2017 16:00:37 CET Ido Shlomo 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:[hidden email]). The problem occurs when an
> incoming connection gives me a token that I cannot accept. The error is
> that I cannot decrypt it.

Looking at the keysalt list of kdc.conf it looks like MIT Kerberos doesn't
support the salts used by Microsoft. You would need to extend it so you can
do:

kadmin -e aes256-cts:msft,aes128-cts:msft to generate correct keys


        Andreas

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Simo Sorce-3
In reply to this post by Ido Shlomo
You may want to look into a utility called mskutil.

HTH,
Simo.

On Fri, 2017-11-10 at 08:08 +0300, Ido Shlomo wrote:

> Thank you. I understand the options, but I am not familiar with tools
> that
> may do that automatically. (currently this entire process is
> automated
> using shell scripts).
>
> On Nov 10, 2017 01:47, "Simo Sorce" <[hidden email]> 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.
> >
> > 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" <[hidden email]> wrote:
> > >
> > > >
> > > >
> > > > On Thu, Nov 9, 2017 at 5:00 PM, Ido Shlomo <[hidden email]>
> > > > 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:[hidden email]). 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
> >
> >

--
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Idan Freiberg
On MS Active Directory Domain Controllers there’s a tool called ktpass.exe
It will generate the correct key tabs for you.

בתאריך יום ו׳, 10 בנוב׳ 2017 ב-12:57 מאת Simo Sorce <[hidden email]>:

> You may want to look into a utility called mskutil.
>
> HTH,
> Simo.
>
> On Fri, 2017-11-10 at 08:08 +0300, Ido Shlomo wrote:
> > Thank you. I understand the options, but I am not familiar with tools
> > that
> > may do that automatically. (currently this entire process is
> > automated
> > using shell scripts).
> >
> > On Nov 10, 2017 01:47, "Simo Sorce" <[hidden email]> 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.
> > >
> > > 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" <[hidden email]> wrote:
> > > >
> > > > >
> > > > >
> > > > > On Thu, Nov 9, 2017 at 5:00 PM, Ido Shlomo <[hidden email]>
> > > > > 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:[hidden email]). 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
> > >
> > >
>
> --
> Simo Sorce
> Sr. Principal Software Engineer
> Red Hat, Inc
>
> _______________________________________________
> krbdev mailing list             [hidden email]
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
--
Idan Freiberg

PGP FP: 8108 7EC9 806E 4980 75F2  72B3 8AD3 2D04 337B 1F18
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

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

Ido Shlomo
The problem is that our product needs to generate SPNs on-the-fly, and it
runs on Linux.


On Nov 10, 2017 17:46, "Idan Freiberg" <[hidden email]> wrote:

> On MS Active Directory Domain Controllers there’s a tool called ktpass.exe
> It will generate the correct key tabs for you.
>
> בתאריך יום ו׳, 10 בנוב׳ 2017 ב-12:57 מאת Simo Sorce <[hidden email]>:
>
>> You may want to look into a utility called mskutil.
>>
>> HTH,
>> Simo.
>>
>> On Fri, 2017-11-10 at 08:08 +0300, Ido Shlomo wrote:
>> > Thank you. I understand the options, but I am not familiar with tools
>> > that
>> > may do that automatically. (currently this entire process is
>> > automated
>> > using shell scripts).
>> >
>> > On Nov 10, 2017 01:47, "Simo Sorce" <[hidden email]> 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.
>> > >
>> > > 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" <[hidden email]> wrote:
>> > > >
>> > > > >
>> > > > >
>> > > > > On Thu, Nov 9, 2017 at 5:00 PM, Ido Shlomo <[hidden email]>
>> > > > > 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:[hidden email]). 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
>> > >
>> > >
>>
>> --
>> Simo Sorce
>> Sr. Principal Software Engineer
>> Red Hat, Inc
>>
>> _______________________________________________
>> krbdev mailing list             [hidden email]
>> https://mailman.mit.edu/mailman/listinfo/krbdev
>>
> --
> Idan Freiberg
>
> PGP FP: 8108 7EC9 806E 4980 75F2  72B3 8AD3 2D04 337B 1F18
>
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev