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....@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: sel...@windows.example.com Cache version: 0 Server: krbtgt/windows.example....@windows.example.com Client: sel...@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....@windows.example.com Client: sel...@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....@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....@windows.example.com Principal: krbtgt/linux.example....@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/ad...@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: sel...@test.example.com Valid starting Expires Service principal 10/13/2015 15:00:48 10/14/2015 15:00:11 krbtgt/test.example....@test.example.com [selble@testhost ~]$ logout Connection to testhost closed. [selble@NW-8504LM ~]$ klist Credentials cache: API:8ADBA988-D160-4A3B-B0A9-35B56C29FFBD Principal: sel...@test.example.com Issued Expires Principal Oct 13 15:00:12 2015 Oct 14 15:00:11 2015 krbtgt/test.example....@test.example.com Oct 13 15:00:48 2015 Oct 14 15:00:11 2015 krbtgt/linux.example....@test.example.com Oct 13 15:00:48 2015 Oct 14 15:00:11 2015 host/testhost.prod.example....@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}, sel...@test.example.com for host/testhost.prod.example....@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