Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA12007; Fri, 15 Dec 95 09:43:35 EST Received: by MIT.EDU id AB09428; Fri, 15 Dec 95 09:33:55 EST Date: Fri, 15 Dec 95 09:33:55 EST From: MAILER-DAEMON@MIT.EDU (Mail Delivery Subsystem) Subject: Returned mail: Cannot send message for 3 days Message-Id: <9512151433.AB09428@MIT.EDU> To: To: proven@PO7.LOCAL To: tytso@PO9.LOCAL To: basch@lehman.com To: jis@E40-PO.LOCAL To: tlyu@PO9.LOCAL ----- Transcript of session follows ----- 451 zucco@gardenia.saclay.cea.fr... Cannot send message for 3 days zucco@gardenia.saclay.cea.fr... Cannot send message for 3 days ----- Unsent message follows ----- Received: from achilles.ctd.anl.gov by MIT.EDU with SMTP id AA21358; Tue, 12 Dec 95 09:10:28 EST Received: from pembroke.ctd.anl.gov (pembroke.ctd.anl.gov [146.137.64.73]) by achilles.ctd.anl.gov (8.6.11/8.6.11) with ESMTP id IAA21060; Tue, 12 Dec 1995 08:10:30 -0600 Received: (b17783@localhost) by pembroke.ctd.anl.gov (8.6.11/8.6.11) id IAA15674; Tue, 12 Dec 1995 08:10:29 -0600 Date: Tue, 12 Dec 1995 08:10:29 -0600 Message-Id: <199512121410.IAA15674@pembroke.ctd.anl.gov> From: Doug Engert To: Gary Gaskell Cc: kerberos@MIT.EDU, David Conran , Jason Andrade , Andrew Sammut Subject: Using krb in a multiple realm environment In-Reply-To: References: <199507191236.HAA13196@achilles.ctd.anl.gov> 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