Hello,
A couple of month back we discussed on samba mailing-list an issue in heimdal with S4U2Self when the user is not in the same domain as the impersonating service. The problem is that we cannot just start by sending S4U2Self request to local KDC in the service realm and hope to be referred. Instead we first need to obtain a TGT to TGS in that user's realm. Only then we can send S4U2Self request to a KDC in the user's realm and follow back referrals to our own realm. See MS-SFU sections [3.1.5.1.1.1] and [4.2] for details, as well as MIT implementation where it works ok. I would like to propose the attached patch which I have tested against windows lab env, both direct forest trust and transitive forest trust with two child domains thru parent (passes make-check). Example test: kgetcred --debug --out-cache=out --impersonate=[hidden email] -H HTTP/[hidden email] A couple of follow-ups items I am thinking on: - Try to see if it can be tested by heimdal. - Do we need to fix get_cred_kdc_capath() too or just fail it early (we currently issue a failed sfu request before falling back to referrals). - When the impersonated user is given as UPN (enterprise?) then according to MS-SFU [3.1.5.1.1.1] the first step is to locate user's realm (since the same UPN suffix can be used in different realms). This is done by sending AS request to the local KDC of the service with the UPN follow referrals till we get pre-auth required. This is implemented in MIT in s4u_identify_user() and I'm considering porting it. - The fix currently only works when the service name is given as SPN, that is a shared global namespace and can be referred by KDC in other realms. The way MIT work around this, is by converting the user principal to enterprise name (user@domain) which is a global namespace as well (convert_to_enterprise()). I wonder if it is worth porting since the caller could determine the situation and convert by himself. Thank you, Isaac B. |
Hi again,
On Sat, Jul 14, 2018 at 5:45 AM, Isaac Boukris <[hidden email]> wrote: > A couple of follow-ups items I am thinking on: > - Try to see if it can be tested by heimdal. > > - Do we need to fix get_cred_kdc_capath() too or just fail it early > (we currently issue a failed sfu request before falling back to > referrals). Now that I've looked into heimdal's impersonate tests, I realize the current KDC behavior is to issue a s4u2self ticket to any user from any realm, as long as the service ask it for it self, so it always succeeds (unless hdb plugin implements hdb_check_s4u2self() as in samba). In fact, even in its own domain the KDC doesn't perform any check to see if the user exist in db (unless it needs to add PAC), which doesn't sound very useful to me as it doesn't provide the service with much info. So I think it would be better to try get this tested within samba instead. As regarding get_cred_kdc_capath(), I think it cannot be fixed. IIUC it tries to get the referral-tgts explicitly by requesting them from the KDCs along the path (and without canonicalize flag). However, this doesn't seem to work for s4u2self, and if I ask tgt-referral with 'pa-for-user' I just get bad-match error (also I couldn't find any such flow in doc). Given the above, I'm in favor to fail get_cred_kdc_capath() if the service and impersonated user are from different realms and rely on referrals. This means the client will try to locate user's realm to request s4u2self ticket (and that realm has to exist). Thoughts? P.S. this is now PR #389 |
Free forum by Nabble | Edit this page |