[OpenAFS] Problems with discarded tickets rxkad
error=19270408(OpenAFS 1.2.8/Krb51.3.3/gssklog 0.10)
Douglas E. Engert
deengert@anl.gov
Mon, 14 Jun 2004 15:54:41 -0500
The symptoms could indicate that the clients are normally using one gssklogd,
but under some situations they are using a different one. It gets the list
of AFS DB servers, and starts to try each.
The different gssklogd is using a different version of the KeyFile, and
it is making up a token using a key found there, but this key is not in the other
KeyFiles on the other AFS servers.
The gssklogd looks for the highest kvno in the the KeyFile. The file has a
4 byte count of the number of entries, followed by the entries, which have a
4 byte kvno and 8 byte DES key. od -x KeyFile is handy. The file is always
100 bytes long.
The other thing to look for, when you see a bad token, is to look at the
Kerberos ticket cache with klist and see which gssklogd was being contacted.
It (or they) will have a gssklog/<host>@<realm> ticket. See if the same server
is always involved. You can then look at the syslog to see if gssklogd issued a token.
I assume you are running more then one gssklogd, at least two, but possibly one
on each of the AFS DB servers.
Another thing to try is try each server using
gssklog -server <host>
where <host> is the FQDN of the AFS DB with a gssklogd.
See if one fails but not the others.
Mark Dalton wrote:
> Thankyou for the note.
>
> This problem happens intermittently.. Like it will be fine for days of
> heavy use,
> then suddenly we start having tickets 'discarded' with the below
> messages. So it
> works most of the time. It happens at across different machines, and
> we see more
> errors on machines that are being used more heavily (more users), but
> when it happens
> it normally happens on multiple machines. And we have not been able to
> recreate
> this problem, it just happens to us.. (not at a specific time of day).
>
> Apparently the second cell is not even used, so we don't see any
> discarded tickets
> there.. No one is logged into that any more.
>
> The paths here are a bit different. But I have found the KeyFile's on
> the 5 servers
> involved. (One I am trying to get access to). gssklogd uses the same
> file.
>
> Douglas E. Engert wrote:
>
> >
> >Mark Dalton wrote:
> >
> >
> >
> >>We are using (OpenAFS 1.2.8/Krb5 1.3.3/gssklog 0.10), and we get a rash of
> >>discarded tickets from time to time. Below is all the relevant
> >>information I can think of..
> >>I did not setup the servers, I am just trying to resolve the problems of
> >>the tokens getting
> >>discarded.
> >>
> >>Any help or hints of where to look would be greatly appreciated. It
> >>bothered me there
> >>were two keys, but I am thinking those are for two different realms.
> >>
> >>We are loosing tickets on the 'cray.com' realm, from Linux clients
> >>(32bit and 64bit machines).
> >>
> >>Mark
> >>
> >>kernel: afs: Tokens for user of AFS id #### for cell XXX.com are
> >>discarded (rxkad error=19270408)
> >>
> >>
> >>
> >
> >translate_et 19270408 says:
> > 19270408 (rxk).8 = ticket contained unknown key version number
> >
> >Are all the /usr/afs/etc/KeyFile on the AFS servers in the cell
> >identical, and do they match the copy of the KeyFile used by the gssklogd?
> >
> >
> >
> Yes, I was able to check the main AFS server and 3 of the 4 slave
> servers. (I am
> trying to get access to the other). And I see tokens granted on all 4
> slave servers.
> And gssklogd uses the same KeyFile..
>
> >You say you have two cells. Do you see the message for only one cell,
> >or for both?
> >
> >
> >
> The one cell was just a small test cell, rarely used.
>
> >The KDC and gssklogd share a K5 key and kvno, by normal Kerberos
> >means using a keytab, and used by GSSAPI.
> >
> >The gssklogd creates a token and used the copy of the /usr/afs/etc/KeyFile to get
> >a key. This key and kvno must be in the /usr/afs/etc/KeyFile of the servers.
> >
> >The key and kvno in the AFS KeyFile are independent of the key and kvno in the KDC.
> >
> >
> >
> I am not sure how to check to see what is actually listed in these data
> files.
> Apparently we have cfengine running that updates the files hourly
> including the key file,
> but that also does not seem to coincide with the times the problems happen.
>
> It does work most of the time, but then we will have a day it fails..
> It will clear up on its own
> or if we restart the AFS server 'bos restart' then all is well again.
> Sometimes it is just a few
> peoples tokens discarded other times.
>
> Thanks!
>
> Mark
>
> >>The Kerberos server has:
> >>
> >>There are two cells:
> >> afs/cray.com
> >> afs/rs.cray.com
> >>
> >>kadmin.local: getprinc afs/cray.com
> >>Principal: afs/cray.com@CRAY.COM
> >>Expiration date: [never]
> >>Last password change: Thu Jun 03 21:16:48 CDT 2004
> >>Password expiration date: [none]
> >>Maximum ticket life: 0 days 10:00:00
> >>Maximum renewable life: 7 days 00:00:00
> >>Last modified: Thu Jun 03 21:16:48 CDT 2004 (####/####@CRAY.COM)
> >>Last successful authentication: [never]
> >>Last failed authentication: [never]
> >>Failed password attempts: 0
> >>Number of keys: 1
> >>Key: vno 1, DES cbc mode with CRC-32, no salt
> >>Attributes:
> >>Policy: [none]
> >>
> >>and
> >>kadmin.local: getprinc afs/rs.cray.com
> >>Principal: afs/rs.cray.com@CRAY.COM
> >>Expiration date: [never]
> >>Last password change: Thu May 20 00:13:51 CDT 2004
> >>Password expiration date: [none]
> >>Maximum ticket life: 0 days 10:00:00
> >>Maximum renewable life: 7 days 00:00:00
> >>Last modified: Thu May 20 00:13:51 CDT 2004 (####/####@CRAY.COM)
> >>Last successful authentication: [never]
> >>Last failed authentication: [never]
> >>Failed password attempts: 0
> >>Number of keys: 1
> >>Key: vno 3, DES cbc mode with CRC-32, no salt
> >>Attributes:
> >>Policy: [none]
> >>
> >>sunbeam.wc.cray.com% bos listkeys sunbeam
> >>key 3 has cksum ############ --- These have different checksums
> >>key 2 has cksum ############ --- These have different checksums
> >>Keys last changed on Thu Jun 10 03:06:05 2004.
> >>All done.
> >>
> >>kdc.conf has:
> >>[kdcdefaults]
> >> kdc_ports = ##,###
> >>
> >>[realms]
> >> CRAY.COM = {
> >> database_name = /var/krb5kdc/principal
> >> admin_keytab = /var/krb5kdc/kadm5.keytab
> >> acl_file = /var/krb5kdc/kadm5.acl
> >> key_stash_file = /var/krb5kdc/.k5.CRAY.COM
> >> kadmind_port = ###
> >> max_life = 10h 0m 0s
> >> max_renewable_life = 7d 0h 0m 0s
> >> master_key_type = des3-hmac-sha1
> >> supported_enctypes = des3-hmac-sha1:normal
> >>des-cbc-crc:normal des:nor
> >>mal des:v4 des:norealm des:onlyrealm des:afs3 des-cbc-crc:afs3
> >> }
> >>
> >>krb5.conf has:
> >>[libdefaults]
> >> default_realm = CRAY.COM
> >> default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc des-cbc-md5
> >> default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc des-cbc-md5
> >> krb4_config = /etc/krb.conf -- does not exist
> >> krb4_realms = /etc/krb.realms -- does not exist
> >> forwardable = true
> >>
> >>[realms]
> >> CRAY.COM = {
> >> kdc=mac1.cray.com
> >> kdc=mac2.cray.com
> >> kdc=mac3.cray.com
> >> kdc=mac4.cray.com
> >> admin_server=mac4.cray.com
> >> default_domain=CRAY.COM
> >> v4_instance_convert = {
> >> cray = cray.com
> >> }
> >> }
> >>[domain_realm]
> >> .cray.com = CRAY.COM
> >> cray.com = CRAY.COM
> >>[logging]
> >> kdc = SYSLOG:DEBUG:LOCAL3
> >> admin_server = SYSLOG:DEBUG:LOCAL3
> >> default = SYSLOG:DEBUG:LOCAL3
> >>
> >>[appdefaults]
> >> kinit = {
> >> renewable = true
> >> forwardable= true
> >> }
> >> rlogin = {
> >> forwardable= true
> >> }
> >> rsh = {
> >> forwardable= true
> >> }
> >> telnet = {
> >> autologin = true
> >> forwardable= true
> >> }
> >>
> >>_______________________________________________
> >>OpenAFS-info mailing list
> >>OpenAFS-info@openafs.org
> >>https://lists.openafs.org/mailman/listinfo/openafs-info
> >>
> >>
> >
> >--
> >
> > Douglas E. Engert <DEEngert@anl.gov>
> > Argonne National Laboratory
> > 9700 South Cass Avenue
> > Argonne, Illinois 60439
> > (630) 252-5444
> >
> >
> >
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
--
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444