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:***@KERBEROSDC.MSFT 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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Simo Sorce]

Post by 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.
-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
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
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
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.

[Ido Shlomo]

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

Post by Ido Shlomo

Post by Ido Shlomo
I am trying to upgrade our system's kerberos encryption from RC4 to

AES256.

Post by Ido Shlomo
I've set up a Microsoft Windows Domain user with AES256 encryption

support.

Post by Ido Shlomo
-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
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
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
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

Post by Ido Shlomo
kept the SPNs in the incoming keytab file with RC4_HMAC (this used to

work

Post by Ido Shlomo
when the domain user was also authenticating using RC4_HMAC), but I got

an

Post by Ido Shlomo
error that the gssapi accept function is looking for an AES256 entry in

the

Post by Ido Shlomo
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Isaac Boukris]

Post by Ido Shlomo
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Isaac Boukris]

Post by Isaac Boukris

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

# 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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Ido Shlomo]

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:***@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.

Post by Ido Shlomo
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Isaac Boukris]

Post by Ido Shlomo
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
incoming connection gives me a token that I cannot accept. The error is

that

Post by Ido Shlomo
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[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.

Post by Isaac Boukris

Post by Ido Shlomo
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
incoming connection gives me a token that I cannot accept. The error is

that

Post by Ido Shlomo
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[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.

Post by Ido Shlomo
No. I am registering an SPN for a single account.
Add an entry to the local keytab using ktuil.
Add an entry to the User object in the Active Directory using
openldap.

Post by Isaac Boukris

Post by Ido Shlomo
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
incoming connection gives me a token that I cannot accept. The error is

that

Post by Ido Shlomo
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.

[Shawn Emery]

Post by 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.

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

Post by Simo Sorce

Post by Ido Shlomo
No. I am registering an SPN for a single account.
Add an entry to the local keytab using ktuil.
Add an entry to the User object in the Active Directory using openldap.

Post by Isaac Boukris

Post by Ido Shlomo
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
incoming connection gives me a token that I cannot accept. The error is

that

Post by Ido Shlomo
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
_______________________________________________
https://mailman.mit.edu/mailman/listinfo/krbdev

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Ido Shlomo]

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).

Post by 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.

Post by Ido Shlomo
No. I am registering an SPN for a single account.
Add an entry to the local keytab using ktuil.
Add an entry to the User object in the Active Directory using openldap.

Post by Isaac Boukris

Post by Ido Shlomo
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
incoming connection gives me a token that I cannot accept. The error is

that

Post by Ido Shlomo
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Isaac Boukris]

Post by Ido Shlomo
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Simo Sorce]

You may want to look into a utility called mskutil.

HTH,
Simo.

Post by Ido Shlomo
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).

Post by 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.

Post by Ido Shlomo
No. I am registering an SPN for a single account.
Add an entry to the local keytab using ktuil.
Add an entry to the User object in the Active Directory using openldap.

Post by Isaac Boukris

Post by Ido Shlomo
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
occurs
when an
incoming connection gives me a token that I cannot accept.
The
error is

that

Post by Ido Shlomo
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

[Idan Freiberg]

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

Post by Simo Sorce
You may want to look into a utility called mskutil.
HTH,
Simo.

Post by Ido Shlomo
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).

Post by 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.

Post by Ido Shlomo
No. I am registering an SPN for a single account.
Add an entry to the local keytab using ktuil.
Add an entry to the User object in the Active Directory using openldap.

Post by Isaac Boukris

Post by Ido Shlomo
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
occurs
when an
incoming connection gives me a token that I cannot accept.
The
error is

that

Post by Ido Shlomo
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
_______________________________________________
https://mailman.mit.edu/mailman/listinfo/krbdev

[Ido Shlomo]

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

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

Post by Simo Sorce
You may want to look into a utility called mskutil.
HTH,
Simo.

Post by Ido Shlomo
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).

Post by 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.

Post by Ido Shlomo
No. I am registering an SPN for a single account.
Add an entry to the local keytab using ktuil.
Add an entry to the User object in the Active Directory using openldap.

Post by Isaac Boukris

Post by Ido Shlomo
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
occurs
when an
incoming connection gives me a token that I cannot accept.
The
error is

that

Post by Ido Shlomo
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
_______________________________________________
https://mailman.mit.edu/mailman/listinfo/krbdev

--
Idan Freiberg
PGP FP: 8108 7EC9 806E 4980 75F2 72B3 8AD3 2D04 337B 1F18

_______________________________________________
krbdev mailing list ***@mit.edu
htt

[Andreas Schneider]

Post by Simo Sorce

Post by 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.
-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
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
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
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/***@EXAMPLE.COM
***@EXAMPLE.COM
***@EXAMPLE.COM

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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Ido Shlomo]

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:***@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.

Post by Ido Shlomo

Post by Simo Sorce

Post by 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.
-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

Post by Simo Sorce

Post by Ido Shlomo
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
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
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
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

Post by Simo Sorce

Post by Ido Shlomo
computer) and I have set this user to login with AES256. Initially, I

have

Post by Simo Sorce

Post by Ido Shlomo
kept the SPNs in the incoming keytab file with RC4_HMAC (this used to

work

Post by Simo Sorce

Post by Ido Shlomo
when the domain user was also authenticating using RC4_HMAC), but I

got an

Post by Simo Sorce

Post by Ido Shlomo
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

Post by Simo Sorce

Post by Ido Shlomo
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
However you need to convert the salt principal to a salt data blob which is
EXAMPLE.COMhost/somehost.example.com
EXAMPLE.COMSomeAccount
EXAMPLE.COMSomePrincipal
Andreas

_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Andreas Schneider]

Post by Ido Shlomo
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
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev