Cesar Garcia wrote:
[this is largely a kerberos question, but I am cross posting in case anyone on the openafs mailing list may have had a similar experience]We are having two problems with larger krb5 afs/service tickets. Specifically when krb5_creds.ticket.length exceeds order of about 350 bytes we run into these two problems (the length tolerence differs slightly between the two issues): 1 - we are still running openafs 1.2.13 fileservers which don't seem to like the larger tickets, they treat requests as if the request came from: #define ANONYMOUSID 32766 so in effect, the tokens are useless
Correct. You must use OpenAFS 1.4 servers in order to support tickets larger than 344 bytes. (Actually 1.3.65 or above.) Here is the diff. It can be applied to 1.2 servers provided you can recompile. http://www.openafs.org/cgi-bin/cvsweb.cgi/openafs/src/rxkad/rxkad.p.h.diff?r1=1.10&r2=1.8
2 - on machines running older versions of the openafs client, ktc_SetToken fails as follows: nptest05:/u/cesarg$ aklog aklog: unable to obtain tokens for cell b.ny.ms.com (status: 11862789). nptest05:/u/cesarg# translate_et 11862789 11862789 (ktc).5 = AFS kernel pioctl doesn't exist
Similar problem. The pioctl buffer isn't large enough to hold the input. Rebuilding is required if you want to support the larger ticket sizes.
Upgrading openafs servers is well under way, but realistically another 6 months before completion. Upgrading openafs clients is unfortunately much more difficult for us to do - largely due to [let's call it] political factors, that upgrade schedule is much much longer. We see these problems on client machines that have many (>7 or 8) interfaces, as the TGTs we obtain are addressful - removing IP addresses (e.g., kinit -A) works, but unfortunately is not a short term option for us as this causes problems for legacy/interal apps built with *very* old krb5 libs - and unfortunately my team doesn't own those apps. As a workaround, we attempted to obtain afs service tickets via krb5_get_cred_via_tkt(), specifying an empty set of addresses (arg 4), but this doesn't seem to have any impact on the length of the resulting afs service ticket (cred.ticket.length).
The address list comes from the TGT.
In fact if we request 0, 50, or 100 IPs via arg 4, it still doesn't seem to influence the length of the afs service ticket. The afs ticket length seems to be tied to the length of the tgt in all cases.
Exactly.
Is this expected? I've yet to go deep enough into the relevent tgs req code to understand why this happens.
Yes.
Is there something else we could do that will result in smaller tickets. I realize our real problem is political, a short term answer for us unfortunately cannot require that we strip IPs from our TGTs, or require openafs client and server upgrades - these contraints are horrible - believe me, none of us are happy about it ... not looking for sympathy :-) Are there any additional details we can provide that would help. I suppose it is possible our code/workaround is simply coded incorrectly. I'd be willing to send out code if someone thinks that is the case. Any help in understanding this is greatly appreciated.
Hacking the KDC to strip addresses for the AFS service principal or using the krb524d (Kerberos v4 tickets will only support a single address and will always be small enough.) Jeffrey Altman Secure Endpoints Inc.
smime.p7s
Description: S/MIME Cryptographic Signature
