On Tue, 13 Dec 2016 12:29:57 +0200
Alexander Bokovoy <abokovoy@xxxxxxxxxx> wrote:
> On ti, 13 joulu 2016, Daniel P. Berrange wrote:
> >On Tue, Dec 13, 2016 at 12:19:45PM +0200, Alexander Bokovoy wrote:
> >> On ti, 13 joulu 2016, Alexander Bokovoy wrote:
> >> > On ti, 13 joulu 2016, Vít Ondruch wrote:
> >> > >
> >> > >
> >> > > Dne 12.12.2016 v 16:02 Stephen Gallagher napsal(a):
> >> > > > On 12/12/2016 04:53 AM, Vít Ondruch wrote:
> >> > > > > So several questions:
> >> > > > >
> >> > > > > 1) When I have 2 domains I login to with kerberos, how to
> >> > > > > really make it work. I don't want to kswitch all the time.
> >> > > > > I am using Kerberos to authenticate my email client, so I
> >> > > > > want to keep it working all the time.
> >> > > > >
> >> > > > There are patches still coming that will switch the fedora
> >> > > > packaging tools to use GSSAPI rather than Kerberos directly,
> >> > > > which will handle auto-selecting the right TGT. I'm not sure
> >> > > > what the status is on this, but Patrick Uiterwijk (CCed) was
> >> > > > looking into it.
> >> > >
> >> > > I am probably missing something, but if I am not mistaken, the
> >> > > primary ticket depends on order of my kinit calls and I am
> >> > > using several apps which needs kerberos authentication, so I
> >> > > can hardly see how fedora packaging tools changes can solve
> >> > > the major issue, i.e. if I do kinit
> >> > > vondruch@xxxxxxxxxxxxxxxxx, this ticket becomes the primary ...
> >> > The story is always more complex than it seems.
> >> >
> >> > There is Kerberos protocol. There is also GSSAPI interface that
> >> > allows to wrap Kerberos use under a more general security
> >> > exchange means. While Kerberos tools can deal with multiple
> >> > credential caches in the collection only by addressing the
> >> > currently selected credentials cache, GSSAPI-aware applications
> >> > enjoy ability to chose which credentials cache from the
> >> > collection to use based on the realm of the target service.
> >> >
> >> > Koji with a patch to use python-gssapi will have ability to
> >> > choose the credentials cache automatically based on the realm of
> >> > the target service, regardless of what credentials cache is
> >> > active right now in the collection. The version in Fedora right
> >> > now (1.11.0-1.fc25) is not yet built with the patch to use
> >> > python-gssapi.
> >> A small correction: koji 1.11.0-1.fc25 does use
> >> python-requests-kerberos which uses python-kerberos which is using
> >> GSSAPI C library. I verified that koji in Fedora 25 does work with
> >> credentials cache collections and properly chooses the credentials
> >> cache which is not the one currently active.
> >>
> >> However, default Fedora 25 configuration[1] does not set the
> >> default ccache name to a collection, only FreeIPA client installer
> >> does this.
> >>
> >> As result, if you have no
> >>
> >> [libdefaults]
> >> default_ccache_name = KEYRING:persistent:%{uid}
> >>
> >> in your krb5.conf, you are using the defaults compiled into libkrb5
> >> which is 'FILE:/tmp/krb5cc_%{uid}'. The latter is not a credentials
> >> cache _collection_ and cannot store multiple credentials from
> >> multiple realms.
> >>
> >> So, if you'd change default_ccache_name to a KEYRING:..-based
> >> version and re-logon, you'll be able to maintain multiple
> >> credentials caches at the same time.
> >>
> >> [1]
> >> http://pkgs.fedoraproject.org/cgit/rpms/krb5.git/tree/krb5.conf?h=f25
> >
> >Actually that's not quite right - if you look at krb5.spec you'll
> >see it then munges that krb5.conf to add
> >
> > default_ccache_name = KEYRING:persistent:%{uid}
> >
> >so all F25 installs should get that by default - all of my fresh
> >installs do.
> Mea culpa. Thanks for the correction. So, for fresh F25 installs this
> should be working fine -- at least with koji.
does anybody know if the krb5-auth-dialog tool [1] works with the
credentials cache?
Dan
[1] https://honk.sigxcpu.org/piki/projects/krb5-auth-dialog/
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
