[OpenAFS] Cross-Realm AFS Service Principal Confusion

[Marcus Watts]

Christopher Heller <Christopher.Heller@sas.com> writes:
> Date:    Sun, 25 Oct 2009 23:26:20 EDT
> To:      "openafs-info@openafs.org" <openafs-info@openafs.org>
> From:    Christopher Heller <Christopher.Heller@sas.com>
> Subject: [OpenAFS] Cross-Realm AFS Service Principal Confusion
> 
> SSBqdXN0IGhhZCB0byByZS1ib290IG15IGVudGlyZSBuZXR3b3JrIChidWlsZGluZyB0cmFuc2Zv
> cm1lciB1cGdyYWRlKSwgYW5kIG5vdyB0aGF0IEkgYW0gYmFjayBvbmxpbmUgSSBoYXZlIGxvc3Qg
> ...
> translated reads:
> I just had to re-boot my entire network (building transformer upgrade), and now that I am back online I have lost the ability to authenticate with the cell. In my network I have a realm A.COM which houses user principals, and a realm B.COM which houses other principal types including afs/b.com@B.COM which is the service principal for the b.com realm. Additionally the user principals in the A.COM realm are the same as the PTS user names in the b.com cell, and the /etc/openafs/server/krb.conf file has a first line which reads 'B.COM A.COM'.
> 
> Here is a transcript of a cell login attempt (first I ran unlog && kdestroy):
> 
> > kinit heller@A.COM
> > klist
> Ticket cache: FILE:/tmp/...
> Default principal: heller@A.COM
> 
> Valid starting   Expires   Service Principal
> ...              ...       krbtgt/A.COM@A.COM
> 
> Kerberos 4 ticket cache: /tmp/...
> klist: You have no tickets cached
> 
> > aklog -d
> Authenticating to cell b.com (afsdb-1.b.com).
> Trying to authenticate to user's realm A.COM.
> Getting tickets: afs/b.com@A.COM.
> Using Kerberos V5 ticket natively
> About to resolve name heller to id in cell b.com.
> Id 20003
> Set username to AFS ID 20003
> Setting tokens. AFS ID 20003 / @ A.COM
> 
> > klist
> Ticket cache: FILE:/tmp/...
> Default principal: heller@A.COM
> 
> Valid starting   Expires   Service Principal
> ...              ...       krbtgt/A.COM@A.COM
> ...              ...       krbtgt/B.COM@A.COM
> ...              ...       afs/b.com@A.COM
> ...              ...       afs/b.com@B.COM
> 
> Kerberos 4 ticket cache: /tmp/...
> klist: You have no tickets cached
> 
> 
> What appears to be happening is I'm getting the afs/b.com@A.COM token installed and that is not the principal being used in the KeyFile on the afs BOS servers. The bigger trouble is the afs/b.com@A.COM principal doesn't actually seem to exist (doing a kinit afs/b.com@A.COM confirms this), so I'm not even sure why that is showing up! 
> 
> Hopefully my scenario isn't so convoluted that it is impossible to follow, does anyone have an idea as to what might be have gone wrong?
> 
> --
> _/_/_/_/ Chris Heller                                     Network Systems |
> _/_/_/   Teragram, A Division of SAS        e-mail: <heller@teragram.com> |
> _/_/_/   10 Fawcett St. 2nd Flr.             web: http://www.teragram.com |
> _/_/     Cambridge, Ma 02138 voice: 617.576.6800 x237 ~ fax: 617.576.7227 v
> 
> :

"kinit afs/b.com@A.COM" will attempt to authenticate *AS* your service principal.
This probably doesn't prove anything useful.  It's quite possible your
service principal is set so that it can't authenticate, in which case
the error code might well make it seem it doesn't exist.

The three things that might be most useful are:

//1 what does kadmin "getprinc afs/b.com@A.COM" say?
	If you have more than one kdc, does "kadmin.local" agree on all hosts?
//2 what does "kvno afs/b.com@A.COM" say? (you'll need a valid tgt first).
/3/ kvno's from "bos listkeys localhost -localauth" or "asetkey list".
	(but of course, don't tell us your checksum or key bytes.)

Other useful data would be the contents of krb5.conf, and any relevant dns
info (especially if you use that to supplement what's in krb5.conf),

The information on krb5.conf + dns will determine how the cell name
b.com and host afsdb-1.b.com is mapped to the kerberos realm & server.
If you think that you should not be getting afs/b.com@A.COM, then
this is the thing to look for.  If you intend to use afs/b.com@A.COM
then you probably don't need to look at this, and can proceed
to looking at kvno's and keys.  If you didn't intend to use this,
look at how you use '[domain_realm]' to map afsdb-1.b.com , or
perhaps also [capaths] if you intended to use cross-realm authentication.

The AFS keyfile does not have service principals, only keys and key versions.
If you're authenticating from multiple realms, either you set things up so
that you used the same key in each realm, or more likely you've arranged to
use a different kvno in each realm.  Regardless, the output from "kvno" will
tell you what kvno that realm's kdc thinks you should have.  The output
from "bos listkeys" or "asetkey list" will tell you want kvnos AFS will
understand (check all hosts to be sure they're the same.)  Ideally, you
would also compare the keys in AFS and in the kdb, but that's harder.

One final item of interest is the contents of the afs server side krb.conf
(probably /usr/afs/etc/krb.conf or /etc/openafs/server/krb.conf).
The afs servers use this to indicate which realms are local.
You should probably have both A.COM and B.COM on the first line.

				-Marcus Watts