The issue is the AFS cell name is not the same as the user's realm name. The K5 is using cross realm, where as in the past the krb524d could have covered this up.
This goes back to what is the difference between a realm and a cell. I would argue a cell is an authorization domain, a realm is authorization domain. AFS needs to be able to map a principal in a realm to an afs user in it cell. By default AFS is assuming the cell name matches the realm name, or if the realm-of-cell file (forgot the name) is set, then the cell is in that realm. It needs more flexibility to map foreign principals to local cell.
This is a practical issue, as newer realms are coming on line which don't match the older AFS cell names.
I disagree with the statement that a realm is an authorization domain.
A realm is an authentication domain. Kerberos authentication provides
an authenticated name and a trust path by which the name was authenticated. It does not provide any form of authorization UNLESS
the Kerberos ticket contains a PAC of ACLs.
In the traditional Kerberos model, the authenticated Kerberos principal name would be used in an authorization exchange by the service to determine what that principal is allowed to use. In the case of AFS the authorization database is PTS.
I believe it is very important that the authenticated name be preserved
for logging and because you never know when some admininstrator might
screw up and issue [EMAIL PROTECTED] to [EMAIL PROTECTED] to different
users when both the FOO.COM and BAR.COM realms are trusted by the foobar.com cell.
If there is a mapping to be applied it should be applied within the authorization database (ptserver) not in something that modifies authentication names.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
