[6351] in Kerberos
Using krb in a multiple realm environment
daemon@ATHENA.MIT.EDU (Doug Engert)
Tue Dec 12 09:36:30 1995
Date: Tue, 12 Dec 1995 08:10:29 -0600
From: Doug Engert <DEEngert@anl.gov>
To: Gary Gaskell <gaskell@dstc.edu.au>
Cc: kerberos@MIT.EDU, David Conran <conran@dstc.edu.au>,
Jason Andrade <jason@dstc.edu.au>,
Andrew Sammut <sammut@dstc.qut.edu.au>
In-Reply-To: <Pine.OSF.3.91.951212114748.741N-100000@typhoon.dstc.qut.edu.au>
Gary Gaskell writes:
>
> Hi Doug,
>
> I thought you might be the best person to respond to this question.
>
> The situation here is that six universities are involved in the DSTC.
> Currently our admins use kerberised rlogin to login securely to the
> various universities to perform admin tasks. We have elected to do this
> via two different kerberos realms.
>
> The usability question is:
>
> The default is that only one TGT exists in the user's cache at once. Now
> say that I am doing work locally (at realm = DSTC.QUT.EDU.AU) and what to
> concurrently do work at another university (At realm = DSTC.EDU.AU), when
> I kinit to the other realm, it wipes out the TGT to the current realm.
> Isn't that inconvenient?
Yes and no. Unlike AFS were you can have tokens for two cells at the
same time, Kerberos allows you to be authenticated as one principal at
a time. You could look at this as a feature. It is designed to work
in a single sign-on environment, where you as a user have only one
identity, which is good world wide. Once you authenticate, you use
this authentication everywhere. But today you have two choices here:
o Use cross realm authentication. This will give you true single
sign-on. If your two Kerberos realms can
share a cross realm key, a user can get a ticket for a server in the
other realm. The user then adds a .k5login file to his home
directory which lists which foreign users are allowed to use this
account. (I am assuming you are using Kerberos 5. Kerberos 4 has
some cross cell capabilities as well which I have not tried.)
o Kerberos 5 allow you to set the environment variable KRB5CCNAME to
point to the cache. (KRB5CCNAME=FILE:/tmp/krb5cc_p19411) You could
then setup a script to switch back and forth.
>
> Would it be silly to hack the code to allow more than one TGT? Anyone
> else hassled by this?
>
I would not recommend this. I know you are very active with DCE, and
since the Kerberos 5 and DCE can share the same ticket cache, to some
extent, if you change this for Kerberos it won't work with DCE.
As you may already know, we are working on DCE and Kerberos
interoperability, We now have four DCE test cells operating at four
different national labs, and we can use the Kerberos 5 clients,
rlogin/rlogind, telnet/telnetd and a simple ftp/ftpd between them
using cross realm/cell authentication.
Let me know if this helps.
Douglas E. Engert
Systems Programming
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(708) 252-5444
Internet: DEEngert@anl.gov
