Re: Checking the transited list of a kerberos ticket in a transitive cross-realm trust situation...

Moving this from [email protected] to [email protected],
sorry...

Am 18.08.2017 um 14:35 schrieb Stefan Metzmacher via samba-technical:
> 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
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJZlun/AAoJEA219WEoab1WVjEQAJckqMOIjULNVC8aj4V7Zxpo
0TXoSOvtC++n/dTRNJ3sUmn+qHOEVpvBCcjTslciC+5RKsdZNPk6pkvcOX6s2tmQ
tBjQ76O9SOZBJ3z0wjsqTIuBGx6Yg3+piUcNOaGqezRMd2wtjhrz1ziKxKcKgMZP
qfVVZiSOJKkN407hj1EWeyQ5aGyv9cmchpzY01hSiWdDn/o252PccLIfwbAWl0UI
TcfG+kzVSmIfz0qBR+5O11lBknXez7CDPEK+8IX411byIj32YVYOBOZhSKxESYUk
B8L31km4lPZfbwXTipxqA2ssLCGYIZgAGG8MGPrdprM70fXHuQTmL1nTu22FnzZu
bWwMl2Ooxb5EjLoL1OEkxov2T1Rc8dStLHqXXoVj2qHjj7hsic67wyd8rHF1o7WM
+v0nmBTaEVXfm0E1yYMEZRrDUXiXeP9VCE7u3RvhXUKGSy0Jl9wmwMZSCjsAgnfc
V6Uueah6a7q3UJWQL5/4zFI6zU6FZFgjIn0N6qmGRIJjroVET53ZQQ4wF0CirxeR
DYuFqczx9Lx1Q04G/6+pfRWAQAUL1AIAc2J7Vst0xQEYR7l9aofrNtTxA5CbihHi
gj2gEBB/8WYih1Iw61sXHQHw92iZIAzRS3hwIHXXuADLFEGxYZfqOzgtbsCJmYkO
q3LJXY7bpTErOblgjt2q
=/udw
-----END PGP SIGNATURE-----