Re: krb524d, aklog and AFS tokens
So I may have fixed it, at least partially. The AFS token discard error
number, 19270408, when translated with 'translate_et 19270408' gives
"ticket contained unknown key version number". Which after some more
digging gives the following paragraph from the krb524/README file once
indicates that my Transarc AFS servers don't understand the encrypted
tickets:
Configuring krb524d AFS Conversion
==
The krb524d looks in the appdefaults section of krb5.conf for an
application called afs_krb5 to determine whether afs principals
support encrypted ticket parts as tokens. The following configuration
fragment says that afs/[EMAIL PROTECTED] supports the new
token format but [EMAIL PROTECTED] and
afs/[EMAIL PROTECTED] do not. Note that the default is to
assume afs servers support the new format.
[appdefaults]
afs_krb5 = {
ATHENA.MIT.EDU = {
# This stanza describes principals in the
#ATHENA.MIT.EDU realm
afs = false
afs/athena.mit.edu = false
afs/sipb.mit.edu = true
}
}
After adding the appdefaults section to my krb5.conf file and restarting
the krb5kdc and krb524d services, I am now successfully using aklog. On
the windows client it looks like WAKE is able to obtain valid AFS tokens
using the krb tgt (I'm at home trying to do this via XP's remote desktop so
it's a little painful).
So yeah, steps forward, but ... This seems to only work on systems for
which there exists a host/FQDN principal in the krb5 database. So this
isn't going to work for systems on a DSL connection or systems under DHCP
with varying hostnames. (Testing now gives me an error of "Incorrect net
address".)
So my question to the group, and sorry if this should go to an afs list
instead of the krb list - what do people use for AFS access for remote/home
users once they've migrated their afs to krb5?
--Matthew
--On Wednesday, March 05, 2003 11:06 PM -0500 Matthew Mauzy
<[EMAIL PROTECTED]> wrote:
Key version numbers match (unless I'm not looking at the correct info).
How do I check the enc types?
--Matthew
% bos listkeys db0
key 0 has cksum ...
key 1 has cksum ...
key 2 has cksum ...
Keys last changed on Mon Mar 3 17:34:49 2003.
kadmin: getprinc afs
Principal: [EMAIL PROTECTED]
...
Last password change: Mon Mar 03 17:32:38 EST 2003
...
Number of keys: 1
Key: vno 2, DES cbc mode with CRC-32, no salt
Attributes:
--On Thursday, March 06, 2003 12:30 PM +1300 Nathan Ward
<[EMAIL PROTECTED]> wrote:
Check your key version numbers, and your enc types. I had this problem
several times and it was a combination of these 2 problems that caused
it.
Nathan Ward
Matthew Mauzy wrote:
I found the following post by Cesar Garcia posted in Feb 2002. I'm
running into a similar problem and wonder if anyone has solved it.
I just migrated my AFS cell with afs-krb5 Migration Kit v1.3 to use
krb5 v1.2.7. I'm running fakeka and krb524d on the KDC and
ka-forwarder on the AFS DB servers and am able to use klog and
authenticate to the new krb5 database. The problem is that aklog
isn't working correctly. When I kinit (successfully) and then run
aklog I get what appears to be a valid AFS token:
[EMAIL PROTECTED] ~ 8: tokens
Tokens held by the Cache Manager:
User's (AFS ID 9458) tokens for [EMAIL PROTECTED] [Expires Mar 6 03:52]
--End of list--
but any thing that requires permissions, like 'touch temp', fails with
the following error in the messages file:
kernel: afs: Tokens for user AFS id x for cell amath.unc.edu are
discarded (rxkad error=19270408)
I'm fairly certain that the fakeka/ka-forwarder combo are working
properly as klog still works fine. It's just tokens that are created
with aklog that fail.
Since the windows AFS clients don't use the ka services, none of my
windows clients are able to login to the AFS cell. I'm trying to use
WAKE, (from Rose-Hulman http://www.rose-hulman.edu/TSC/software/wake/
) to get around the Windows AFS/krb5 issues, but all the problems keep
coming back to what seems to be a krb524 problem.
--Matthew
__
Matthew W. Mauzy
Systems Administrator
Applied Math @ UNC-CH
email : [EMAIL PROTECTED] pager : [EMAIL PROTECTED]
(W) 919.962.9819 www.amath.unc.edu/~mauzy/ (P) 919.347.0390
__
Kerberos mailing list [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: krb524d, aklog and AFS tokens
Key version numbers match (unless I'm not looking at the correct info). How do I check the enc types? --Matthew % bos listkeys db0 key 0 has cksum ... key 1 has cksum ... key 2 has cksum ... Keys last changed on Mon Mar 3 17:34:49 2003. kadmin: getprinc afs Principal: [EMAIL PROTECTED] ... Last password change: Mon Mar 03 17:32:38 EST 2003 ... Number of keys: 1 Key: vno 2, DES cbc mode with CRC-32, no salt Attributes: --On Thursday, March 06, 2003 12:30 PM +1300 Nathan Ward <[EMAIL PROTECTED]> wrote: Check your key version numbers, and your enc types. I had this problem several times and it was a combination of these 2 problems that caused it. Nathan Ward Matthew Mauzy wrote: I found the following post by Cesar Garcia posted in Feb 2002. I'm running into a similar problem and wonder if anyone has solved it. I just migrated my AFS cell with afs-krb5 Migration Kit v1.3 to use krb5 v1.2.7. I'm running fakeka and krb524d on the KDC and ka-forwarder on the AFS DB servers and am able to use klog and authenticate to the new krb5 database. The problem is that aklog isn't working correctly. When I kinit (successfully) and then run aklog I get what appears to be a valid AFS token: [EMAIL PROTECTED] ~ 8: tokens Tokens held by the Cache Manager: User's (AFS ID 9458) tokens for [EMAIL PROTECTED] [Expires Mar 6 03:52] --End of list-- but any thing that requires permissions, like 'touch temp', fails with the following error in the messages file: kernel: afs: Tokens for user AFS id x for cell amath.unc.edu are discarded (rxkad error=19270408) I'm fairly certain that the fakeka/ka-forwarder combo are working properly as klog still works fine. It's just tokens that are created with aklog that fail. Since the windows AFS clients don't use the ka services, none of my windows clients are able to login to the AFS cell. I'm trying to use WAKE, (from Rose-Hulman http://www.rose-hulman.edu/TSC/software/wake/ ) to get around the Windows AFS/krb5 issues, but all the problems keep coming back to what seems to be a krb524 problem. --Matthew --- Forwarded Message --- OK. I may have figured the error. Although the the key version number for my afs principal is 1, the 1.2.2 krb524d (using -k) returns a V4 cred with a kvno of 0. I determined this on the client side, I'll have to walk through the server code to see why the cred is returned with a kvno of 0. "Cesar" == Cesar Garcia <[EMAIL PROTECTED]> writes: Cesar> This is not exactly a Kerberos specific issue, but perhaps Cesar> the folks on this mailing list might have some insight. Cesar> I decided for now to go with Ken's suggestion that I simply Cesar> remove the IP addresses from my V5 tickets, and do ticket Cesar> forwarding sans IP addresses. Cesar> It appears that the one dependency we have on IP addresses Cesar> is k524. Our client code is modern and works fine. It's an Cesar> old krb524d which we currently run on a CyberSafe KDC that Cesar> requires IP addresses in the requesting ticket. Cesar> So thanks to Doug Engert, we have a -k option that allows Cesar> one to run the MIT krb524d with a keytab, which handles Cesar> null IP addresses just fine - and I don't immediately, or Cesar> perhaps ever, have to solve the problem of writing the glue Cesar> to get it to work the CyberSafe KDB. Simply extracting all Cesar> the necessary keys to a keytab file suffices. Cesar> I then add the following keys to a keytab file: Cesar> 1 - krbtgt/[EMAIL PROTECTED] Cesar> 2 - [EMAIL PROTECTED] (*) Cesar> (*) An aside - this predates me, so I'm not sure what all Cesar> the reasons were) Since all of our AFS cells use the same Cesar> server principal, we don't have afs/[EMAIL PROTECTED] Cesar> for each of our cells, just one principal [EMAIL PROTECTED] Cesar> (one k5realm) for all cells. Not sure how/if this is Cesar> relevant, but it is different. Cesar> The basic algorithm for obtaining tokens for all cells follows: Cesar> 1 - using V5 TGS, obtain a ticket V5 ticket for [EMAIL PROTECTED] Cesar> (this ticket get's cached) Cesar> 2 - using k524 and V5 ticket for [EMAIL PROTECTED], obtain a V4 ticket Cesar> for [EMAIL PROTECTED] Cesar> 3 - foreach cell, invoke ktc_SetToken, passing in the V4 cred Cesar> obtained in step 2. Cesar> This code is implemented in a lib/app we call ak5log and works Cesar> with the cybersafe based krb524d, with either the cybersafe Cesar> based k524 client or the MIT based k524 client. Cesar> When we try to run either the cybersafe or MIT based client Cesar> against the MIT krb524d (using -k), the ak5log code completes, Cesar> but I get the following messages in syslog: Cesar> Cesar> Feb 12 21:05:09 imus afs: [ID 255639 kern.notice] afs: Tokens for user of AFS id 4843 for cell w.ny.ms.com are discarded (rxkad error=19270408) Cesar> Cesar> with a similar error going to my console. Cesar> krb524init itself seems to work fine against the same MIT Cesar> krb524d with the keytab. That is the I can V4 tgt and run Cesar> my v4 ap
Re: krb524d, aklog and AFS tokens
Understood, I've just been delaying for no good reason. I'll find time one of these weekends to submit various patches. Thanks. > "Sam" == Sam Hartman <[EMAIL PROTECTED]> writes: > "Cesar" == Cesar Garcia <[EMAIL PROTECTED]> writes: Cesar> I've been meaning to submit a patch for this to Cesar> [EMAIL PROTECTED]: *** krb524d.c Wed Mar 5 19:24:17 2003 Cesar> --- krb524d.c.new Wed Mar 5 19:33:44 2003 *** Sam> If you expect a patch like this to get reviewed and applied: Sam> 1) You do actually need to submit it to krb5-bugs Sam> 2) Describe what problem it exists Sam> 3) Describe why you see the problem and others might not. This is Sam>particularly important in this instance as krb524d is very clearly Sam>not broken for most users. Sam> --Sam Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: krb524d, aklog and AFS tokens
> "Cesar" == Cesar Garcia <[EMAIL PROTECTED]> writes: Cesar> I've been meaning to submit a patch for this to Cesar> [EMAIL PROTECTED]: *** krb524d.c Wed Mar 5 19:24:17 2003 Cesar> --- krb524d.c.new Wed Mar 5 19:33:44 2003 *** If you expect a patch like this to get reviewed and applied: 1) You do actually need to submit it to krb5-bugs 2) Describe what problem it exists 3) Describe why you see the problem and others might not. This is particularly important in this instance as krb524d is very clearly not broken for most users. --Sam Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: krb524d, aklog and AFS tokens
I've been meaning to submit a patch for this to [EMAIL PROTECTED]:
*** krb524d.c Wed Mar 5 19:24:17 2003
--- krb524d.c.new Wed Mar 5 19:33:44 2003
***
*** 410,418
--- 410,421
/* out of memory? */
ret = errno;
memset (key, 0, sizeof (*key));
+ krb5_kt_free_entry(context, &entry);
return ret;
}
+ if(kvnop)
+ *kvnop = entry.vno;
krb5_kt_free_entry(context, &entry);
return 0;
} else if (use_master) {
This patch in it's form was not compiled or tested, I just forged it
from actual working changes, but it looks correct. (it also includes a
one line fix for a memory leak).
> "Matthew" == Matthew Mauzy <[EMAIL PROTECTED]> writes:
Matthew> I found the following post by Cesar Garcia posted in Feb 2002. I'm running
Matthew> into a similar problem and wonder if anyone has solved it.
Matthew> I just migrated my AFS cell with afs-krb5 Migration Kit v1.3 to use krb5
Matthew> v1.2.7. I'm running fakeka and krb524d on the KDC and ka-forwarder on the
Matthew> AFS DB servers and am able to use klog and authenticate to the new krb5
Matthew> database. The problem is that aklog isn't working correctly. When I kinit
Matthew> (successfully) and then run aklog I get what appears to be a valid AFS
Matthew> token:
Matthew> [EMAIL PROTECTED] ~ 8: tokens
Matthew> Tokens held by the Cache Manager:
Matthew> User's (AFS ID 9458) tokens for [EMAIL PROTECTED] [Expires Mar 6 03:52]
Matthew>--End of list--
Matthew> but any thing that requires permissions, like 'touch temp', fails with the
Matthew> following error in the messages file:
Matthew> kernel: afs: Tokens for user AFS id x for cell amath.unc.edu are
Matthew> discarded (rxkad error=19270408)
Matthew> I'm fairly certain that the fakeka/ka-forwarder combo are working properly
Matthew> as klog still works fine. It's just tokens that are created with aklog
Matthew> that fail.
Matthew> Since the windows AFS clients don't use the ka services, none of my windows
Matthew> clients are able to login to the AFS cell. I'm trying to use WAKE, (from
Matthew> Rose-Hulman http://www.rose-hulman.edu/TSC/software/wake/ ) to get around
Matthew> the Windows AFS/krb5 issues, but all the problems keep coming back to what
Matthew> seems to be a krb524 problem.
Matthew> --Matthew
Matthew> --- Forwarded Message ---
Matthew> OK. I may have figured the error.
Matthew> Although the the key version number for my afs principal is 1,
Matthew> the 1.2.2 krb524d (using -k) returns a V4 cred with a kvno of 0.
Matthew> I determined this on the client side, I'll have to walk through the
Matthew> server code to see why the cred is returned with a kvno of 0.
> "Cesar" == Cesar Garcia <[EMAIL PROTECTED]> writes:
Cesar> This is not exactly a Kerberos specific issue, but perhaps
Cesar> the folks on this mailing list might have some insight.
Cesar> I decided for now to go with Ken's suggestion that I simply
Cesar> remove the IP addresses from my V5 tickets, and do ticket
Cesar> forwarding sans IP addresses.
Cesar> It appears that the one dependency we have on IP addresses
Cesar> is k524. Our client code is modern and works fine. It's an
Cesar> old krb524d which we currently run on a CyberSafe KDC that
Cesar> requires IP addresses in the requesting ticket.
Cesar> So thanks to Doug Engert, we have a -k option that allows
Cesar> one to run the MIT krb524d with a keytab, which handles
Cesar> null IP addresses just fine - and I don't immediately, or
Cesar> perhaps ever, have to solve the problem of writing the glue
Cesar> to get it to work the CyberSafe KDB. Simply extracting all
Cesar> the necessary keys to a keytab file suffices.
Cesar> I then add the following keys to a keytab file:
Cesar> 1 - krbtgt/[EMAIL PROTECTED]
Cesar> 2 - [EMAIL PROTECTED] (*)
Cesar> (*) An aside - this predates me, so I'm not sure what all
Cesar> the reasons were) Since all of our AFS cells use the same
Cesar> server principal, we don't have afs/[EMAIL PROTECTED]
Cesar> for each of our cells, just one principal [EMAIL PROTECTED]
Cesar> (one k5realm) for all cells. Not sure how/if this is
Cesar> relevant, but it is different.
Cesar> The basic algorithm for obtaining tokens for all cells follows:
Cesar> 1 - using V5 TGS, obtain a ticket V5 ticket for [EMAIL PROTECTED]
Cesar> (this ticket get's cached)
Cesar> 2 - using k524 and V5 ticket for [EMAIL PROTECTED], obtain a V4 ticket
Cesar> for [EMAIL PROTECTED]
Cesar> 3 - foreach cell, invoke ktc_SetToken, passing in the V4 cred
Cesar> obtained in step 2.
Cesar> This code is implemented in a lib/app we call ak5log and works
Cesar> with the cybersafe based krb524d, with either the cybersafe
Cesar> based k524 client or the MIT based k524 client.
Cesar> When we try to run either the cybersafe or MIT based client
Cesar> against the MIT krb524d (using -k), the ak5log code completes,
Cesar> bu
Re: krb524d, aklog and AFS tokens
Check your key version numbers, and your enc types. I had this problem several times and it was a combination of these 2 problems that caused it. Nathan Ward Matthew Mauzy wrote: I found the following post by Cesar Garcia posted in Feb 2002. I'm running into a similar problem and wonder if anyone has solved it. I just migrated my AFS cell with afs-krb5 Migration Kit v1.3 to use krb5 v1.2.7. I'm running fakeka and krb524d on the KDC and ka-forwarder on the AFS DB servers and am able to use klog and authenticate to the new krb5 database. The problem is that aklog isn't working correctly. When I kinit (successfully) and then run aklog I get what appears to be a valid AFS token: [EMAIL PROTECTED] ~ 8: tokens Tokens held by the Cache Manager: User's (AFS ID 9458) tokens for [EMAIL PROTECTED] [Expires Mar 6 03:52] --End of list-- but any thing that requires permissions, like 'touch temp', fails with the following error in the messages file: kernel: afs: Tokens for user AFS id x for cell amath.unc.edu are discarded (rxkad error=19270408) I'm fairly certain that the fakeka/ka-forwarder combo are working properly as klog still works fine. It's just tokens that are created with aklog that fail. Since the windows AFS clients don't use the ka services, none of my windows clients are able to login to the AFS cell. I'm trying to use WAKE, (from Rose-Hulman http://www.rose-hulman.edu/TSC/software/wake/ ) to get around the Windows AFS/krb5 issues, but all the problems keep coming back to what seems to be a krb524 problem. --Matthew --- Forwarded Message --- OK. I may have figured the error. Although the the key version number for my afs principal is 1, the 1.2.2 krb524d (using -k) returns a V4 cred with a kvno of 0. I determined this on the client side, I'll have to walk through the server code to see why the cred is returned with a kvno of 0. "Cesar" == Cesar Garcia <[EMAIL PROTECTED]> writes: Cesar> This is not exactly a Kerberos specific issue, but perhaps Cesar> the folks on this mailing list might have some insight. Cesar> I decided for now to go with Ken's suggestion that I simply Cesar> remove the IP addresses from my V5 tickets, and do ticket Cesar> forwarding sans IP addresses. Cesar> It appears that the one dependency we have on IP addresses Cesar> is k524. Our client code is modern and works fine. It's an Cesar> old krb524d which we currently run on a CyberSafe KDC that Cesar> requires IP addresses in the requesting ticket. Cesar> So thanks to Doug Engert, we have a -k option that allows Cesar> one to run the MIT krb524d with a keytab, which handles Cesar> null IP addresses just fine - and I don't immediately, or Cesar> perhaps ever, have to solve the problem of writing the glue Cesar> to get it to work the CyberSafe KDB. Simply extracting all Cesar> the necessary keys to a keytab file suffices. Cesar> I then add the following keys to a keytab file: Cesar> 1 - krbtgt/[EMAIL PROTECTED] Cesar> 2 - [EMAIL PROTECTED] (*) Cesar> (*) An aside - this predates me, so I'm not sure what all Cesar> the reasons were) Since all of our AFS cells use the same Cesar> server principal, we don't have afs/[EMAIL PROTECTED] Cesar> for each of our cells, just one principal [EMAIL PROTECTED] Cesar> (one k5realm) for all cells. Not sure how/if this is Cesar> relevant, but it is different. Cesar> The basic algorithm for obtaining tokens for all cells follows: Cesar> 1 - using V5 TGS, obtain a ticket V5 ticket for [EMAIL PROTECTED] Cesar> (this ticket get's cached) Cesar> 2 - using k524 and V5 ticket for [EMAIL PROTECTED], obtain a V4 ticket Cesar> for [EMAIL PROTECTED] Cesar> 3 - foreach cell, invoke ktc_SetToken, passing in the V4 cred Cesar> obtained in step 2. Cesar> This code is implemented in a lib/app we call ak5log and works Cesar> with the cybersafe based krb524d, with either the cybersafe Cesar> based k524 client or the MIT based k524 client. Cesar> When we try to run either the cybersafe or MIT based client Cesar> against the MIT krb524d (using -k), the ak5log code completes, Cesar> but I get the following messages in syslog: Cesar> Cesar> Feb 12 21:05:09 imus afs: [ID 255639 kern.notice] afs: Tokens for user of AFS id 4843 for cell w.ny.ms.com are discarded (rxkad error=19270408) Cesar> Cesar> with a similar error going to my console. Cesar> krb524init itself seems to work fine against the same MIT Cesar> krb524d with the keytab. That is the I can V4 tgt and run Cesar> my v4 apps with no problem. Cesar> The error apparently corresponds to "Unknown key". I've verified Cesar> the key and kvno for [EMAIL PROTECTED] that was extracted to the Cesar> keytab file, and it appears to be correct. I assume I would Cesar> have failed earlier had that not been the case. Cesar> When I list my tokens, the listing looks normal.t The Cesar> tokens themselves, however, are worthless. Cesar> We're running various versions of transarc afs (3.5, 3.6) Cesar> on our solaris machine
krb524d, aklog and AFS tokens
I found the following post by Cesar Garcia posted in Feb 2002. I'm running into a similar problem and wonder if anyone has solved it. I just migrated my AFS cell with afs-krb5 Migration Kit v1.3 to use krb5 v1.2.7. I'm running fakeka and krb524d on the KDC and ka-forwarder on the AFS DB servers and am able to use klog and authenticate to the new krb5 database. The problem is that aklog isn't working correctly. When I kinit (successfully) and then run aklog I get what appears to be a valid AFS token: [EMAIL PROTECTED] ~ 8: tokens Tokens held by the Cache Manager: User's (AFS ID 9458) tokens for [EMAIL PROTECTED] [Expires Mar 6 03:52] --End of list-- but any thing that requires permissions, like 'touch temp', fails with the following error in the messages file: kernel: afs: Tokens for user AFS id x for cell amath.unc.edu are discarded (rxkad error=19270408) I'm fairly certain that the fakeka/ka-forwarder combo are working properly as klog still works fine. It's just tokens that are created with aklog that fail. Since the windows AFS clients don't use the ka services, none of my windows clients are able to login to the AFS cell. I'm trying to use WAKE, (from Rose-Hulman http://www.rose-hulman.edu/TSC/software/wake/ ) to get around the Windows AFS/krb5 issues, but all the problems keep coming back to what seems to be a krb524 problem. --Matthew --- Forwarded Message --- OK. I may have figured the error. Although the the key version number for my afs principal is 1, the 1.2.2 krb524d (using -k) returns a V4 cred with a kvno of 0. I determined this on the client side, I'll have to walk through the server code to see why the cred is returned with a kvno of 0. "Cesar" == Cesar Garcia <[EMAIL PROTECTED]> writes: Cesar> This is not exactly a Kerberos specific issue, but perhaps Cesar> the folks on this mailing list might have some insight. Cesar> I decided for now to go with Ken's suggestion that I simply Cesar> remove the IP addresses from my V5 tickets, and do ticket Cesar> forwarding sans IP addresses. Cesar> It appears that the one dependency we have on IP addresses Cesar> is k524. Our client code is modern and works fine. It's an Cesar> old krb524d which we currently run on a CyberSafe KDC that Cesar> requires IP addresses in the requesting ticket. Cesar> So thanks to Doug Engert, we have a -k option that allows Cesar> one to run the MIT krb524d with a keytab, which handles Cesar> null IP addresses just fine - and I don't immediately, or Cesar> perhaps ever, have to solve the problem of writing the glue Cesar> to get it to work the CyberSafe KDB. Simply extracting all Cesar> the necessary keys to a keytab file suffices. Cesar> I then add the following keys to a keytab file: Cesar> 1 - krbtgt/[EMAIL PROTECTED] Cesar> 2 - [EMAIL PROTECTED] (*) Cesar> (*) An aside - this predates me, so I'm not sure what all Cesar> the reasons were) Since all of our AFS cells use the same Cesar> server principal, we don't have afs/[EMAIL PROTECTED] Cesar> for each of our cells, just one principal [EMAIL PROTECTED] Cesar> (one k5realm) for all cells. Not sure how/if this is Cesar> relevant, but it is different. Cesar> The basic algorithm for obtaining tokens for all cells follows: Cesar> 1 - using V5 TGS, obtain a ticket V5 ticket for [EMAIL PROTECTED] Cesar> (this ticket get's cached) Cesar> 2 - using k524 and V5 ticket for [EMAIL PROTECTED], obtain a V4 ticket Cesar> for [EMAIL PROTECTED] Cesar> 3 - foreach cell, invoke ktc_SetToken, passing in the V4 cred Cesar> obtained in step 2. Cesar> This code is implemented in a lib/app we call ak5log and works Cesar> with the cybersafe based krb524d, with either the cybersafe Cesar> based k524 client or the MIT based k524 client. Cesar> When we try to run either the cybersafe or MIT based client Cesar> against the MIT krb524d (using -k), the ak5log code completes, Cesar> but I get the following messages in syslog: Cesar> Cesar> Feb 12 21:05:09 imus afs: [ID 255639 kern.notice] afs: Tokens for user of AFS id 4843 for cell w.ny.ms.com are discarded (rxkad error=19270408) Cesar> Cesar> with a similar error going to my console. Cesar> krb524init itself seems to work fine against the same MIT Cesar> krb524d with the keytab. That is the I can V4 tgt and run Cesar> my v4 apps with no problem. Cesar> The error apparently corresponds to "Unknown key". I've verified Cesar> the key and kvno for [EMAIL PROTECTED] that was extracted to the Cesar> keytab file, and it appears to be correct. I assume I would Cesar> have failed earlier had that not been the case. Cesar> When I list my tokens, the listing looks normal.t The Cesar> tokens themselves, however, are worthless. Cesar> We're running various versions of transarc afs (3.5, 3.6) Cesar> on our solaris machines, openafs 1.2.2 on our linux boxes. Cesar> AFS servers are solaris. Cesar> Before I go digging into this problem some more, I was wondering Cesar> if anyone might have some insight on
