Cross Realm Trust with AD - PROCESS_TGS Error

Tue Oct 20 11:40:58 EDT 2015

Hi,

I'm running into a situation where I have setup a one-way trust with a 
MIT Kerberos realm (LINUX.EXAMPLE.COM) trusting a AD realm 
(WINDOWS.EXAMPLE.COM).  The krbtgt/LINUX.EXAMPLE.COM at WINDOWS.EXAMPLE.COM 
principal exists in both realms, and I *believe* that the password for 
the principal is the same for both realms.  The reason I say that I 
believe this is true is because when I get a TGT for the 
WINDOWS.EXAMPLE.COM realm, and try to SSH to a box in the 
LINUX.EXAMPLE.COM realm (with GSSAPI authentication), it fails, but 
"klist -v" on the client looks like this:

[selble at NW-8504LM src]$ klist -v
Credentials cache: API:B69F0AA6-EAA8-4019-9D50-3617EF56E80C
         Principal: selble at WINDOWS.EXAMPLE.COM
     Cache version: 0

Server: krbtgt/WINDOWS.EXAMPLE.COM at WINDOWS.EXAMPLE.COM
Client: selble at WINDOWS.EXAMPLE.COM
Ticket etype: aes256-cts-hmac-sha1-96, kvno 3395
Ticket length: 1133
Auth time:  Oct 20 11:18:55 2015
End time:   Oct 20 21:18:55 2015
Renew till: Oct 27 11:18:55 2015
Ticket flags: pre-authent, initial, renewable, forwardable
Addresses: addressless

Server: krbtgt/LINUX.EXAMPLE.COM at WINDOWS.EXAMPLE.COM
Client: selble at WINDOWS.EXAMPLE.COM
Ticket etype: aes256-cts-hmac-sha1-96
Ticket length: 1108
Auth time:  Oct 20 11:18:55 2015
Start time: Oct 20 11:22:41 2015
End time:   Oct 20 21:18:55 2015
Ticket flags: ok-as-delegate, pre-authent, forwardable
Addresses: addressless

The GSSAPI authentication fails as so:

debug1:  Miscellaneous failure (see text)
Error from KDC: PROCESS_TGS

debug1:  An invalid name was supplied
unknown mech-code 0 for mech 1 2 752 43 14 2

debug1:  Miscellaneous failure (see text)
unknown mech-code 0 for mech 1 3 6 1 5 5 14

debug1:  Miscellaneous failure (see text)
unknown mech-code 2 for mech 1 3 6 1 4 1 311 2 2 10

debug1:  An unsupported mechanism was requested
unknown mech-code 0 for mech 1 3 5 1 5 2 7

debug1:  Miscellaneous failure (see text)
unknown mech-code 0 for mech 1 3 6 1 5 2 5

And the LINUX.EXAMPLE.COM KDC throws errors like this, which to me 
highly suggest a password mismatch for the 
krbtgt/LINUX.EXAMPLE.COM at WINDOWS.EXAMPLE.COM principal in each realm:

Oct 20 11:25:58 kdc.prod.example.com krb5kdc[1578](info): TGS_REQ (4 
etypes {18 17 16 23}) 192.168.100.100: PROCESS_TGS: authtime 0,  
<unknown client> for <unknown server>, Decrypt integrity check failed

The trust principal looks right to me (and the AD realm supports AES 
encryption for sure):

kadmin.local:  getprinc krbtgt/LINUX.EXAMPLE.COM at WINDOWS.EXAMPLE.COM
Principal: krbtgt/LINUX.EXAMPLE.COM at WINDOWS.EXAMPLE.COM
Expiration date: [never]
Last password change: Mon Oct 19 17:22:01 EDT 2015
Password expiration date: [none]
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Mon Oct 19 17:22:01 EDT 2015 
(root/admin at LINUX.EXAMPLE.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 6
Key: vno 1, aes256-cts-hmac-sha1-96, no salt
Key: vno 1, aes128-cts-hmac-sha1-96, no salt
Key: vno 1, des3-cbc-sha1, no salt
Key: vno 1, arcfour-hmac, no salt
Key: vno 1, des-hmac-sha1, no salt
Key: vno 1, des-cbc-md5, no salt
MKey: vno 1
Attributes:
Policy: [none]

I have a separate TEST.EXAMPLE.COM realm, and setting things up as I did 
for the WINDOWS.EXAMPLE.COM realm, I can get a TGT for the 
TEST.EXAMPLE.COM realm, and use it to authenticate to a 
LINUX.EXAMPLE.COM system:

[selble at NW-8504LM ~]$ ssh testhost
Last login: Tue Oct 13 14:57:00 2015 from 172.21.77.111
[selble at testhost ~]$ klist
Ticket cache: KEYRING:persistent:6850:krb_ccache_x2QBVOf
Default principal: selble at TEST.EXAMPLE.COM

Valid starting       Expires              Service principal
10/13/2015 15:00:48  10/14/2015 15:00:11  
krbtgt/TEST.EXAMPLE.COM at TEST.EXAMPLE.COM
[selble at testhost ~]$ logout

Connection to testhost closed.
[selble at NW-8504LM ~]$ klist
Credentials cache: API:8ADBA988-D160-4A3B-B0A9-35B56C29FFBD
         Principal: selble at TEST.EXAMPLE.COM

   Issued                Expires               Principal
Oct 13 15:00:12 2015  Oct 14 15:00:11 2015  
krbtgt/TEST.EXAMPLE.COM at TEST.EXAMPLE.COM
Oct 13 15:00:48 2015  Oct 14 15:00:11 2015  
krbtgt/LINUX.EXAMPLE.COM at TEST.EXAMPLE.COM
Oct 13 15:00:48 2015  Oct 14 15:00:11 2015  
host/testhost.prod.example.com at LINUX.EXAMPLE.COM

(my krb5.conf contains an mapping for the prod.example.com domain to the 
LINUX.EXAMPLE.COM realm, for what it's worth)

When doing this, I see happy messages like this on the LINUX.EXAMPLE.COM 
KDC:

Oct 19 16:59:20 kdc.prod.example.com krb5kdc[1578](info): TGS_REQ (4 
etypes {18 17 16 23}) 172.21.77.111: ISSUE: authtime 1445288271, etypes 
{rep=18 tkt=18 ses=18}, selble at TEST.EXAMPLE.COM for 
host/testhost.prod.example.com at LINUX.EXAMPLE.COM

So, before I pull out what little is left of my hair, and before I 
hassle the Windows side of the shop to see if the principal exists 
properly on their side, is there anything else this could be besides a 
password mismatch on the "trust principal" (for lack of a better term)?

Thoughts and suggestions are most welcome.

Thanks,

Sean