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

From: Stefan Metzmacher <[email-masked]>
Date: Thu, 23 Jan 2020 12:25:50 +0100

Hi Nico,

it would be great if we could make some progress here...

Any hints how to avoid gss_set_cred_option() with a more modern
construct that would be acceptable for upstream MIT and Heimdal.

Thanks!
metze

Am 05.12.19 um 17:26 schrieb Stefan Metzmacher:
> Hi Nico,
> 
>> On Fri, Nov 22, 2019 at 11:24:44AM +0100, Stefan Metzmacher wrote:
>>>> Correspondingly and symmetrically, the right way to request some
>>>> behavior on the side where the credential is available, is to associate
>>>> that request with the desired_name for which the credential is acquired.
>>>
>>> So you mean we need to pass an explicit desired_name to
>>> gss_acquire_cred_from() and use gss_set_name_attribute() calls
>>> (for no_transit_check and iterate_acceptor_keytab) on that desired_name
>>> before?
>>
>> Oh, wait, right.  That's not going to work when you want a default
>> credential.
>>
>> Alright.  I've got a nasty cold and can't think straight, and deadlines
>> to meet to boot too.  I'll respond more thoughtfully some time next
>> week.
> 
> I hope you feel better again:-)
> 
> Looking at the gss_acquire_cred_from() prototype:
> 
>  GSSAPI_LIB_FUNCTION OM_uint32 GSSAPI_LIB_CALL
>  gss_acquire_cred_from(OM_uint32 *minor_status,
>                       gss_const_name_t desired_name,
>                       OM_uint32 time_req,
>                       const gss_OID_set desired_mechs,
>                       gss_cred_usage_t cred_usage,
>                       gss_const_key_value_set_t cred_store,
>                       gss_cred_id_t *output_cred_handle,
>                       gss_OID_set *actual_mechs,
>                       OM_uint32 *time_rec)
> 
> I thought that additional cred_store elements would also
> be a way to modify the resulting cred_handle.
> 
> On a similar matter I'll soon need a way to modify
> a GSS_C_INITIATE cred_handle that forces KRB5_GC_CACHED to
> be used, so that gss_init_sec_context() is garanteed to
> avoid any network usage.
> 
> Any hints would be much appreciated:-)
> 
> Thanks!
> metze
> 
> _______________________________________________
> krbdev mailing list             [email-masked]
> https://mailman.mit.edu/mailman/listinfo/krbdev
>

---

From: Greg Hudson <[email-masked]>
Date: Thu, 23 Jan 2020 11:15:32 -0500

> it would be great if we could make some progress here...

Does this need to be an application flag, or can it be in the krb5.conf
realm configuration?  Presumably people are currently working around
this by setting [capaths] on the server; a realm variable would simplify
this workaround by not requiring specific knowledge of the domain geometry.

I reviewed the thread, and it sounds like the current understanding is
that AD applies a transited check (of sorts) to cross-realm tickets, but
 doesn't say so by setting the transit-policy-checked flag in the
ticket.  From the upstream point of view the server's realm
configuration is in a better position to know that the realm is an AD
realm than the server application; perhaps that is not true from Samba's
point of view, but I thought I would check.

---

From: Stefan Metzmacher <[email-masked]>
Date: Fri, 24 Jan 2020 19:49:37 +0100

Hi Greg,

> ticket. 

Exactly.

> From the upstream point of view the server's realm

In Samba we know that we're joined to an AD domain
and then we want to force disabling the transited check
for gss_accept_sec_context().

For Samba as AD DC we want also want to disable this for
krb5_rd_req_decoded in the KDC too.

A krb5.conf option would also be good in order to support
non-samba services in AD-Domains. But the c library should also
support changing it at runtime.

metze