Checking the transited list of a kerberos ticket in a transitive cross-realm trust situation...
Stefan Metzmacher <[email protected]> Fri, 18 Aug 2017 14:35:51 +0200
| Newsgroups | gmane.comp.encryption.kerberos.devel,gmane.comp.encryption.kerberos.heimdal.general,gmane.ietf.kitten,gmane.network.samba.internals |
|---|---|
| Message-ID | <[email protected]> |
Hi, I'm currently researching on how I can implement S4U2Self in Samba's winbindd in order to get the PAC with the full Windows authorization token in a reliable way for any user within an active directory forest as well across transitive forest trusts. The only thing that should be required is a service (computer) account in the primary domain/realm. But in practice I'm facing several problems: Heimdal (at least the copy of ~ 1.5 within Samba) doesn't support S4U2Self for cross-realm trusts. MIT (tested with 1.14.3) supports S4U2Self for cross-realm trusts, which are in simple hierarchy. Otherwise it complains and returns KRB5KRB_AP_ERR_ILL_CR_TKT. That can be fixed if I add the correct magic to the [capaths] section of krb5.conf. The problem happens when you have 2 tree root domains within an active directory forest together with a forest trust. In my case I have a forest called W4EDOM-L4.BASE with a single domain and a forest called BLA.BASE with a 2nd domain BLA2.BASE. So trust path between W4EDOM-L4.BASE and BLA2.BASE goes via BLA.BASE. In an active directory environment domain members just delegate authentication to the domain controllers, so they trust their DCs to do the correct things, e.g. applying SID-Filtering for the PAC within the tickets. So the service can just verify the PAC was correctly signed by a KDC of it's own realm and everything else shouldn't matter, it doesn't have to know about the full trust topology! While thinking about this I can't see any value in checking the transited list of the ticket. As that list is always under the control of the KDC that issued the ticket. And the service trusts it's own KDC anyway, as well as any KDC in the trust chain trusts the next hop. The only reason for this list might be debugging. The thing is that KDC's should apply some policies of which client realms can come over which direct trust. As KDC's have some knowledge about the trust topology. This is basically what the SID-Filtering in active directory is for, it prevents DCs from other domains/realms to impersonate principals of the local realm. Is there any reason to keep the krb5_check_transited() (in Heimdal) and krb5_check_transited_list() (in MIT) is their current form? If a KDC checks something it should be checking the PA-TGS-REQ, and verify the client realm is allowed to transit via the realm of the (cross-realm) tgt. But checking the transited field of the ticket seems pointless to me. If there's however a good reason to keep the checks for non active directory realms, I'd propose to add something like gss_set_cred_option(GSS_KRB5_CRED_NO_TRANSIT_CHECK_X) to Heimdal and MIT in order to allow applications to avoid the pointless checks. Comments on this would be highly appreciated! If you're not so familiar with active directory domains, please have a look at: https://www.samba.org/~metze/presentations/2017/SambaXP/StefanMetzmacher_sambaxp2017_windows_authentication-rev1-handout.pdf Thanks! metze _______________________________________________ krbdev mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/krbdev
signature.asc
(application/pgp-signature, 836 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJZlt8sAAoJEA219WEoab1WukIQAKuXHZipLlGFqVjCPm3Cuoge GNpTwms574qsjSLKFL25R6tLK7vCu1KYuwFmzCbL3Wc3e7/O3QG2u9SHU8XEfHWp bn7xg9Y5PX8iDhNUPtaIe6Ciw9fe51iL2aBHiIRyCw8LLi7FXmarGkowACL0qDGY GQkzu9j4XhBOGEqGvyQpPjBh19M/egEY+Nt+BNFOeBJX9KQTHJPNMORUtxF4HGMB s/dJCnRm/t6g5k6dg4dfqmBALganQbTCpWOsLACLZ8pYZ17C4yw/uweH+bhfT+gI HG6qga0ygmI9KoTQb7hbiKKANixJZ3IP+yhQDKF0r8EbUwPeqL/gOpLV6qCsQbJt rnqMb6YvDl0OKTalb7VyRVdyVyaz8czOcSemjY2OwVLC+K9pbFklNDiNujmYR1bh dcqpmAYNxF+BDzZqAxvQKLwsKLxqk42S+NTpIuun2hWnkattRoSy1t8H1FWwrFHq 9yytWUZgMdvsmor3YKy/tvJiBvnExi7Dm3OvYnAqh2H2jATsOIaxj32UuWb9drSM WoZcYG2ruyhe8KPSIo759jNsD3F6CP+u8OSv5d6NIgG8W9KiZ4AW7tFjBJ1r1MMz qlbD/dHMrrxvuG2Ndk3PWzN/y6LJ0tetKffQGTM7wJ6mjS5GIpWx1xmR6x2HpRIo LRv5jgZC34DpwuJKEpF6 =dYvT -----END PGP SIGNATURE-----