cross realm trust

Matthew B. Brookover mbrookov at mines.edu
Wed Aug 8 10:14:42 EDT 2007


It was the entry in .k5login.  I had a typo in the realm name.
ARRGHGHGH!

Thank you Douglas.

Matt
  

On Wed, 2007-08-08 at 08:32 -0500, Douglas E. Engert wrote:

> All of this looks correct, but look at these two things:
> 
> the ~/.k5login file of the user on oneoften.mines.edu. If the user
> is in one realm, and the server in the other, you need either the
> ~/.k5login listing the users allowed to use this unix account.
> 
> What is the default_realm in the server's krb.conf?
> 
> You can also to some testing by starting a seperate sshd:
>   sshd -p 2222 -ddd   then on the client use
>   ssh -p 2222 -vvv oneoften.mines.edu
> 
> Matthew B. Brookover wrote:
> > I am trying to get two realms to trust each other.  Both realms are in
> > the Mines.EDU domain.  The first realm is production systems and is
> > named MINES.EDU, the second realm is for development systems and named
> > DEVMINES.EDU.  The documentation that I have read only discusses the
> > case where there is one Kerberos realm per domain.  In this case I have
> > two Kerberos realms in one domain.
> > 
> > The client (merlin.Mines.EDU) is in the MINES.EDU realm and the server
> > (oneoften.Mines.EDU) is in the DEVMINES.EDU realm.  Both of the Kerberos
> > KDCs are running Kerberos 1.6.1 with the recent patches.  I am using
> > OpenSSH for testing, any host in MINES.EDU can ssh to any other host in
> > MINES.EDU and login without a password, and any host in DEVMINES.EDU can
> > ssh to any other host in DEVMINES.EDU and login without a password using
> > Kerberos to authenticate.
> > 
> > After some digging through the documentation, I learned that the domain
> > realm section of the krb5.conf file could be used to map either a host
> > or a domain name to a realm name.  After some tinkering, my client
> > (merlin.Mines.EDU) has a domain realm like this:
> > 
> > [domain_realm]
> >  oneoften.mines.edu = DEVMINES.EDU
> >  oneoften.Mines.EDU = DEVMINES.EDU
> >  oneoften = DEVMINES.EDU
> >  mines.edu = MINES.EDU
> >  .mines.edu = MINES.EDU
> >  Mines.EDU = MINES.EDU
> >  .Mines.EDU = MINES.EDU
> > 
> > And my server (oneoften.Mines.EDU) has this:
> > 
> > [domain_realm]
> >  merlin.mines.edu = MINES.EDU
> >  merlin.Mines.EDU = MINES.EDU
> >  merlin = MINES.EDU
> >  .Mines.EDU = DEVMINES.EDU
> >  Mines.EDU = DEVMINES.EDU
> >  .mines.edu = DEVMINES.EDU
> >  mines.edu = DEVMINES.EDU
> > 
> > 
> > My capaths section on merlin and oneoften look like this:
> > 
> > [capaths]
> >  MINES.EDU = {
> >    DEVMINES.EDU = MINES.EDU
> >  }
> >  
> >  DEVMINES.EDU = {
> >    MINES.EDU = DEVMINES.EDU
> >  }
> > 
> > When I ssh from Merlin to oneoften, the KDC in MINES.EDU logs this:
> > 
> > Aug 07 16:13:31 immortal.Mines.EDU krb5kdc[2719](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 138.67.4.11: ISSUE: authtime 1186524790, etypes {rep=18 tkt=23 ses=18}, mbrookov at MINES.EDU for krbtgt/DEVMINES.EDU at MINES.EDU
> > Aug 07 16:13:31 immortal.Mines.EDU krb5kdc[2719](info): TGS_REQ (1 etypes {18}) 138.67.4.11: ISSUE: authtime 1186524790, etypes {rep=18 tkt=23 ses=18}, mbrookov at MINES.EDU for krbtgt/MINES.EDU at MINES.EDU
> > 
> > 
> > And the KDC for DEVMINES.EDU logs this:
> > 
> > Aug 07 16:13:31 sixoften.Mines.EDU krb5kdc[5385](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 138.67.4.11: ISSUE: authtime 1186524790, etypes {rep=18 tkt=23 ses=18}, mbrookov at MINES.EDU for host/oneoften.mines.edu at DEVMINES.EDU
> > 
> > 
> > It looks to me like that Merlin goes to the kdc, in the MINES.EDU realm,
> > gets the krbtgt/DEVMINES.EDU at MINES.EDU ticket, then goes to the KDC for
> > the DEVMINES.EDU realm and gets the ticket for
> > host/oneoften.mines.edu at DEVMINES.EDU.  
> > 
> > But, ssh still asks for a password.
> > 
> > 
> > [mbrookov at merlin ~]$ kdestroy ; kinit ; klist -f
> > Password for mbrookov at MINES.EDU: 
> > Ticket cache: FILE:/tmp/krb5cc_5467_V9EjEj
> > Default principal: mbrookov at MINES.EDU
> > 
> > Valid starting     Expires            Service principal
> > 08/07/07 16:13:10  08/08/07 07:13:10  krbtgt/MINES.EDU at MINES.EDU
> >         renew until 08/08/07 16:13:08, Flags: FRIA
> > 
> > 
> > Kerberos 4 ticket cache: /tmp/tkt5467
> > klist: You have no tickets cached
> > [mbrookov at merlin ~]$ ssh oneoften
> > mbrookov at oneoften's password: 
> > Permission denied, please try again.
> > mbrookov at oneoften's password: 
> > Permission denied, please try again.
> > mbrookov at oneoften's password: 
> > Received disconnect from 138.67.130.65: 2: Too many authentication failures for mbrookov
> > [mbrookov at merlin ~]$ klist -f
> > Ticket cache: FILE:/tmp/krb5cc_5467_V9EjEj
> > Default principal: mbrookov at MINES.EDU
> > 
> > Valid starting     Expires            Service principal
> > 08/07/07 16:13:10  08/08/07 07:13:10  krbtgt/MINES.EDU at MINES.EDU
> >         renew until 08/08/07 16:13:08, Flags: FRIA
> > 08/07/07 16:13:31  08/08/07 07:13:10  krbtgt/DEVMINES.EDU at MINES.EDU
> >         renew until 08/08/07 16:13:08, Flags: FRAT
> > 08/07/07 16:13:31  08/08/07 07:13:10  host/oneoften.mines.edu at DEVMINES.EDU
> >         renew until 08/08/07 16:13:08, Flags: FRAT
> > 
> > 
> > Kerberos 4 ticket cache: /tmp/tkt5467
> > klist: You have no tickets cached
> > [mbrookov at merlin ~]$ 
> > 
> > I have never set up a cross realm relationship between two realms, but
> > the logs and the tickets on the client look correct to me.
> > 
> > I have double checked the password for the krbtgt/DEVMINES.EDU at MINES.EDU
> > principals in both realms and am sure they match. Just in case I set up
> > the krbtgt/MINES.EDU at DEVMINES.EDU principals in both realms.  All 4
> > principals used to set up the cross realm trust have the same key
> > version number, passwords, etc.
> > 
> > The realms section of /etc/krb5.conf has both the MINES.EDU realm and
> > the DEVMINES.EDU realm.
> > 
> > Merlin is running Fedora 7 with all of the patches and Oneoften is
> > running Red Hat Enterprise Linux 4 update 5 with all of the patches.
> > 
> > I have ran out of straws to grasp at.  Does any body have any ideas?
> > 
> > thank you
> > 
> > Matt
> > mbrookov at mines.edu
> > 
> > ________________________________________________
> > Kerberos mailing list           Kerberos at mit.edu
> > https://mailman.mit.edu/mailman/listinfo/kerberos
> > 
> > 
> 



More information about the Kerberos mailing list