Christopher Heller <[email protected]> writes: > Date: Sun, 25 Oct 2009 23:26:20 EDT > To: "[email protected]" <[email protected]> > From: Christopher Heller <[email protected]> > 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/[email protected] > 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 [email protected] > > klist > Ticket cache: FILE:/tmp/... > Default principal: [email protected] > > Valid starting Expires Service Principal > ... ... krbtgt/[email protected] > > 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/[email protected]. > 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: [email protected] > > Valid starting Expires Service Principal > ... ... krbtgt/[email protected] > ... ... krbtgt/[email protected] > ... ... afs/[email protected] > ... ... afs/[email protected] > > Kerberos 4 ticket cache: /tmp/... > klist: You have no tickets cached > > > What appears to be happening is I'm getting the afs/[email protected] token > installed and that is not the principal being used in the KeyFile on the afs > BOS servers. The bigger trouble is the afs/[email protected] principal doesn't > actually seem to exist (doing a kinit afs/[email protected] 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: <[email protected]> | > _/_/_/ 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/[email protected]" 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/[email protected]" say? If you have more than one kdc, does "kadmin.local" agree on all hosts? //2 what does "kvno afs/[email protected]" 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/[email protected], then this is the thing to look for. If you intend to use afs/[email protected] 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 _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
