Douglas E. Engert wrote:
But I think part of this is not the user's problem but KfW/OpenAFS's problem. The assumption appears to be "mappings? we do't need no stinking mappings" so bypass krb524 because all it was doing was converting a k5 ticket to a token. That is a good goal but I think you jumped ahead.
Some history here. krb524 was only supported in KFW 2.6 through 2.6.2(?). It was only supported in OpenAFS in 1.3.60 through 1.3.64. The implementations used krb524 to obtain a Kerberos 4 TGT from a Kerberos 5 TGT and then use Kerberos 4 to obtain an afs service ticket. The time period of this support was approximately six months. I removed this support because it was causing more headaches then it was worth.
We discovered that krb524 could not be used without resulting in large numbers of complaints to help desks from home users when krb524d could not be reached. Sometimes it could not be reached because the Kerberos realm does not support it. Other times it could not be reached because several of the large ISPs blocked port 4444/udp due to a worm that attacked Windows systems.
As soon as it became clear that Kerberos 5 tickets could be used directly by all current versions of OpenAFS servers and that all OpenAFS servers had to be upgraded to at least that version due to fatal bugs I implemented support for Kerberos 5 tickets as tokens in OpenAFS and KFW. If Kerberos 5 tickets could not be used, then users should either not install KFW or should disable the use of KFW. Organizations would need to provide their own tools for obtaining afs tokens.
Previous to the brief attempt to support krb524, OpenAFS and KFW only supported the use of Kerberos 4 service tickets which were obtained by directly obtaining a Kerberos 4 TGT from the password. There was no mapping being done by krb524d for afs whenever an afs service ticket was obtained using Kerberos 4 instead of Kerberos 5.
Many sites may not have planed ahead to have a K5 realm match the AFS cell, with a one-to-one user mapping. Some may have only use the kaserver and now have AD and had no coordination of userids across both, now that they need to use both together and need some mappings.
I agree. Most sites do not plan ahead and did not think through the
potential consequences of their actions. All they did was follow the
directions that were recommended in the afs-krb5 migration kit. Since the afs krb.conf file was not mentioned in that document, krb524d based mapping was implemented instead when the realm and cell names failed to match.
jhutz's proposal solves this problem in a general way.
As you pointed out it is complicated by the fact that the same principal name of afs/cell is used with and without the mapping. And by the fact that the client can not determine if no mapping is needed, since the KDC can issue a ticket for afs/[EMAIL PROTECTED] and the client can not determine if this needs be run by krb524d.
Since the same principal name is used for Kerberos 4 to afs as for Kerberos 5 to afs, I believe it is the need to perform a mapping which is what needs to be detected.
(BTW our ak5log and krb524d mods used afsx/[EMAIL PROTECTED] to map to afs/[EMAIL PROTECTED], The DCE server never had a principal for afs/[EMAIL PROTECTED] The DCE AFS/DFS translator reserver the afs/[EMAIL PROTECTED] for itself with DFS.)
But did you offer afs/[EMAIL PROTECTED] as well? If so, you have defeated the purpose.
Maybe what should have happened was that the AFS servers should have been modified to use a different name for direct access, like afsk5/[EMAIL PROTECTED] ticket, but expected afs/[EMAIL PROTECTED] to be mapped by krb524d. Then the client could try for one or the other and know what to do.
maybe but since krb524d was never shipped as part of OpenAFS or Transarc AFS I don't think that it should be considered a standard feature of AFS. It is also true that all implementations of krb524d do not perform this mapping. So it is not possible to even say that if krb524d is available it should be used.
The problem is not the use of krb524d to convert a Kerberos ticket from Kerberos 5 to Kerberos 4. It is the hacks that were added to transform the principal name which is causing the problem. As such it is this special mapping that must be detected not the potential to use krb524d.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
