credentials_krb5: use gss_acquire_cred for client-side GSSAPI use case

Alexander Bokovoy ab at samba.org
Fri Mar 3 12:23:14 UTC 2017


On pe, 03 maalis 2017, Stefan Metzmacher wrote:
> Hi Alexander,
> 
> >>>>> Attached patch is needed for upcoming FreeIPA 4.5 release to allow use
> >>>>> of Samba Python bindings in a privile separation mode provided by
> >>>>> GSS-proxy (https://pagure.io/gssproxy). FreeIPA bug is here:
> >>>>> https://pagure.io/freeipa/issue/6671, Samba bug is
> >>>>> https://bugzilla.samba.org/show_bug.cgi?id=12611
> >>>>>
> >>>>> Please see more details in the commit message.
> >>>>
> >>>> Please have a look at
> >>>> https://bugzilla.samba.org/show_bug.cgi?id=12480
> >>>> for the reasons why we can't use gss_acquire_cred().
> >>> Sorry Metze, but you are wrong in this particular case.
> >>>
> >>> We are using gss_acquire_cred() in a lot of other places -- source3 code
> >>> uses GENSEC GSE module on server side through auth_generic_prepare()
> >>> which priorities GENSEC GSE. 
> >>
> >> No we only use gss_acquire_cred() as a fallback in gse_init_server()
> >> when gss_krb5_import_cred() has a bug importing a keytab.
> >>
> >> Are you looking at an older relase? that doesn't have the #12480
> >> patches?
> > No, there is also gss_acquire_cred() in master for source3/libads/sasl.c
> > but that is only used if gss_krb5_import_cred() is not defined.
> 
> We always have gss_krb5_import_cred() as we rely on MIT 1.9,
> please review the attached patch to remove the #ifdef.
RB+ by me. Thanks.
 
> > For 4.5 I'd need to make sure #12480 is patched too.
> 
> It's in 4.5.4 and 4.4.10.
Ok, something I missed here but it is not important right now.

> 
> >>> However, cli_credentials_get_client_gss_creds() is only called in two
> >>> places:
> >>>
> >>> - gensec_gssapi_client_creds() in source4/auth/gensec/gensec_gssapi.c
> >>>   where it is called with default credentials cache. This is client side
> >>>   use of GENSEC with GSSAPI and never is called inside winbindd where it
> >>>   could stumble on MEMORY: ccaches.
> >>
> >> Will operate on cli_credentials_get_client_gss_creds() in almost all cases
> >> where we use kerberos, e.g. when the user didn't 'kinit' before
> >> and passed a password.
> > Nope. It only is used when GENSEC GSSAPI is used. We have separate
> > GENSEC Kerberos module that is using other codepaths and provides
> > support for the same OIDs. Both don't work with gssproxy due to this
> > bug.
> 
> gensec_gssapi.c is the module we're using for kerberos authentication!
> gensec_krb5.c is only for simulating the 3.6 code and for the kpassword
> sign/seal logic.
> 
> So gensec_gssapi.c is the one that's used with MEMORY ccaches all the time,
> for command line credentials and for special smbtorture tests.
> 
> Note that we only use the default ccache if no -U is provided to the
> command line tools. In all other cases (I always use -U and never a
> separate kinit) we use MEMORY ccaches.
Ok, I see where the problem comes from -- I'm using Python bindings here
and not command line. I do not specify explicit user name there through
creds interface because I do have default ccache set up for me by the
environment and I don't want to use anything else. This is a valid case
as forcing to use the default ccache again through creds API is not
reasonable. I mean, yes, you can do that, but this is ugly.

> >> See my other mail for the solution we can aim for.
> > I did reply to it already. We have two places where we want to use
> > non-default ccache:
> > 
> > source3/libads/sasl.c:  maj = gss_krb5_import_cred(&min, kccache, NULL, NULL, cred);
> > 
> > source3/librpc/crypto/gse.c:    gss_maj = gss_krb5_import_cred(&gss_min,
> > source3/librpc/crypto/gse.c-                                   gse_ctx->ccache,
> > 
> > 
> > Other four are using default ccache.
> 
> We almost never want to use the default cache!
We do and we do use it in FreeIPA use case for last three years without
any issues.
 
> > Changing to gss_acquire_cred_from()
> > would mean we have to obtain default ccache name first and supply it as
> > part of a cred store spec. I have code for that, but I was under
> > impression you didn't like using gss_acquire_cred_from() at all.
> 
> No, I didn't like gss_acquire_cred()!
Ah.

> 
> gss_acquire_cred_from() is fine, I just used gss_krb5_import_cred()
> for now as up to now they provided the same functionality but portable
> to all supported kerberos libraries.
> 
> Now that you showed a valid requirement to use gss_acquire_cred_from(),
> we should do that via a wrapper.
> 
> > If you are OK for gss_acquire_cred_from(), I'll do a wrapper.
> 
> I am:-) Thanks!
Ok.

-- 
/ Alexander Bokovoy



More information about the samba-technical mailing list