Re: Cross Realm Trust with AD - PROCESS_TGS Error
Please disregard this. It was a password mismatch after all, in some way, shape, or form. The password used for the trust principal was a strong password with many special characters, and despite recreating the principal numerous times with the password checked and rechecked on each side, it didn't work. I strongly suspect that Windows wasn't taking it for some reason, as it was entered on the command line, and may well have had a character that Windows didn't like. I'm simply noting it here for posterity's sake. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Cross Realm Trust with AD - PROCESS_TGS Error
And one more potentially useful piece of information that may suggest the krbtgt/linux.example@windows.example.com principal doesn't exist: [selble@NW-8504LM ~]$ kinit krbtgt/linux.example@windows.example.com krbtgt/linux.example@windows.example.com's Password: kinit: krb5_get_init_creds: Client (krbtgt/linux.example@windows.example.com) unknown (I have limited visibility into the Windows side of things, so I just want to make sure that everything I have done is correct before trying to probe there) Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Constrained Delegation and PAC : Realm crossover
Hi, >> What I'm left wondering is, if the client's KDC knows what delegations >> are permitted, as is the case with FreeIPA, is it not simpler to pass on >> the additional tickets for smtp/ and imap/ in an AD structure in the >> webmail ticket? > > This is a potential optimization I have been thinking about before, but > requires clients that understand how to extract these tickets and put > them in their ccache. Perfectly doable though. I'm wondering about this for the design of TLS-KDH. I have a couple of flags in mind that request for ticket properties, and I'm wondering if S4U2Proxy should be added as a flag. S4U2Proxy is not an IETF standard, another is that it also lacks a number of quality signs -- such as exchangeable ciphers, portability and I have security concerns about concatenating strings without separator marks. So my tendency is not to specify such a flag (but leave it open for extensions by others) in TLS-KDH, but instead consider having a flag to request this ticket-carrying AD. That is a New Thing, but at least it is absolutely clear and downright simple. Especially if the AD contains the standardised KRB-CRED message; the MIT krb5 API has krb5_rd_cred() to easily decode that, and I assume Heimdal has something similar. Do tell me if I'm thinking silly thoughts :) >> I must still be missing why S4U2Proxy works the way it does. It may be >> that it was designed with more flexibility in mind though, that probably >> suits the mindset of its inventors. > > S4U2Proxy is built this way because in the Microsoft implementation it > is the receiving service that enforces access control. IIRC the KDC does > not, it just either always allow proxy for any target or for none. Yes, that also matches with what the S4U2Self approach does; it also grabs control based on things that scare me. I suppose the implicit assumption is that it functions within a realm, which makes it less usable for more general use when TLS-KDH gets to crossover to foreign realms. Thanks, -Rick Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Cross Realm Trust with AD - PROCESS_TGS Error
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,
for , 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
IssuedExpires 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
Re: Constrained Delegation and PAC : Realm crossover
On 20/10/15 05:03, Rick van Rein wrote: > Hi, > > >> There are 2 different approaches for Constrained Delegation, one where >> Access control is applied at the KDC level, and one that relies on the >> receiving service to apply access control. >> >> When using an MS-PAC you have an AD element that tells you whether the >> ticket is the result of delegations, or is a ticket that has been >> release directly to the owner of the TGT. >> >> So services can always check that. >> >> In FreeIPA however we added actual access control, so that service >> HTTP/webmail.example.com can be allowed to only ever get delegated >> tickets for imap/imap.example.net and nothing else. >> > That's what I was hoping to find, indeed. > >> It's up to the imap service admins and the EXAMPLE.NET KDC admins to >> decide what to use and what to enforce. >> > What I'm left wondering is, if the client's KDC knows what delegations > are permitted, as is the case with FreeIPA, is it not simpler to pass on > the additional tickets for smtp/ and imap/ in an AD structure in the > webmail ticket? This is a potential optimization I have been thinking about before, but requires clients that understand how to extract these tickets and put them in their ccache. Perfectly doable though. > This might even work recursively, that is if imap/ > needed further privileges to afs/ or so. I wouldn't want smtp/ to get > to that ticket but imap/ should. > > I must still be missing why S4U2Proxy works the way it does. It may be > that it was designed with more flexibility in mind though, that probably > suits the mindset of its inventors. S4U2Proxy is built this way because in the Microsoft implementation it is the receiving service that enforces access control. IIRC the KDC does not, it just either always allow proxy for any target or for none. >> (it seem you sent this to me privately, was that intentional ? If not >> feel free to forward my reply to the list on reply, if needed) >> > Not intended. I've resent my message, and am now forwarding your full > comments inline to the list. > > Thanks for your explanations, Simo! > > > > -Rick > > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > -- Simo Sorce * Red Hat, Inc * New York Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Constrained Delegation and PAC : Realm crossover
Hi, > There are 2 different approaches for Constrained Delegation, one where > Access control is applied at the KDC level, and one that relies on the > receiving service to apply access control. > > When using an MS-PAC you have an AD element that tells you whether the > ticket is the result of delegations, or is a ticket that has been > release directly to the owner of the TGT. > > So services can always check that. > > In FreeIPA however we added actual access control, so that service > HTTP/webmail.example.com can be allowed to only ever get delegated > tickets for imap/imap.example.net and nothing else. > That's what I was hoping to find, indeed. > It's up to the imap service admins and the EXAMPLE.NET KDC admins to > decide what to use and what to enforce. > What I'm left wondering is, if the client's KDC knows what delegations are permitted, as is the case with FreeIPA, is it not simpler to pass on the additional tickets for smtp/ and imap/ in an AD structure in the webmail ticket? This might even work recursively, that is if imap/ needed further privileges to afs/ or so. I wouldn't want smtp/ to get to that ticket but imap/ should. I must still be missing why S4U2Proxy works the way it does. It may be that it was designed with more flexibility in mind though, that probably suits the mindset of its inventors. > (it seem you sent this to me privately, was that intentional ? If not > feel free to forward my reply to the list on reply, if needed) > Not intended. I've resent my message, and am now forwarding your full comments inline to the list. Thanks for your explanations, Simo! -Rick Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Constrained Delegation and PAC : Realm crossover
Hi Simo, > I guess I need to ask you for a detailed example of a transaction to > understand what you are aiming to. Gladly, thanks :) An example of use I have in mind is a party owning a domain name, based on externally hosted components from online providers, all secured and linked together through Kerberos. The domain name may provide basic mechanisms such as web, IMAP and SMTP. The domain's KDC is either included in the domain package or taken in from an externally hosted service, or perhaps this is the one component hosted under own control (maybe using a dedicated Raspberry Pi distribution). To assert his online identity, the domain owner can take in externally hosted services like XMPP and SIP. And a Kerberos-protected WebMail may be taken in because of its user interface. This WebMail service is interesting, because it requires access to IMAP and SMTP. Since this WebMail is an external service, it should not be permitted more access than what it needs to function though. I am wondering if constrained delegation can help the domain's clients to safely use the external WebMail service, with constrained delegation to limit the access from WebMail to IMAP and SMTP and nothing more. Sorry if I'm not very good at reverse-engineering the security architecture from the MS-SFU, -KILE and -PAC documentation. I also didn't find a HOWTO-styled instruction for this facility with an open source Kerberos. Thanks! -Rick Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
