[37266] in Kerberos
Cross Realm Trust with AD - PROCESS_TGS Error
daemon@ATHENA.MIT.EDU (Sean Elble)
Tue Oct 20 11:41:15 2015
To: Kerberos@mit.edu
MIME-Version: 1.0
Date: Tue, 20 Oct 2015 11:40:58 -0400
From: Sean Elble <elbles@sessys.com>
Message-ID: <291f2a39d5ad0d1da5f04fc63c2430a4@mail.sessys.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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@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@NW-8504LM src]$ klist -v
Credentials cache: API:B69F0AA6-EAA8-4019-9D50-3617EF56E80C
Principal: selble@WINDOWS.EXAMPLE.COM
Cache version: 0
Server: krbtgt/WINDOWS.EXAMPLE.COM@WINDOWS.EXAMPLE.COM
Client: selble@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@WINDOWS.EXAMPLE.COM
Client: selble@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@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@WINDOWS.EXAMPLE.COM
Principal: krbtgt/LINUX.EXAMPLE.COM@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@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@NW-8504LM ~]$ ssh testhost
Last login: Tue Oct 13 14:57:00 2015 from 172.21.77.111
[selble@testhost ~]$ klist
Ticket cache: KEYRING:persistent:6850:krb_ccache_x2QBVOf
Default principal: selble@TEST.EXAMPLE.COM
Valid starting Expires Service principal
10/13/2015 15:00:48 10/14/2015 15:00:11
krbtgt/TEST.EXAMPLE.COM@TEST.EXAMPLE.COM
[selble@testhost ~]$ logout
Connection to testhost closed.
[selble@NW-8504LM ~]$ klist
Credentials cache: API:8ADBA988-D160-4A3B-B0A9-35B56C29FFBD
Principal: selble@TEST.EXAMPLE.COM
Issued Expires Principal
Oct 13 15:00:12 2015 Oct 14 15:00:11 2015
krbtgt/TEST.EXAMPLE.COM@TEST.EXAMPLE.COM
Oct 13 15:00:48 2015 Oct 14 15:00:11 2015
krbtgt/LINUX.EXAMPLE.COM@TEST.EXAMPLE.COM
Oct 13 15:00:48 2015 Oct 14 15:00:11 2015
host/testhost.prod.example.com@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@TEST.EXAMPLE.COM for
host/testhost.prod.example.com@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
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
