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