Jeffrey Altman wrote:
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.
Well, it may have been, prior to this people where still using klog or the equivelent in the Windows client, or maybe not using the windows client at all. Yet on unix systems they where using whatever was provided locally that may have done mapping.
So when they installed OPenAFS and KFW they expected it would work.
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.
Since not many people have unix at home with AFS, (accept maybe the AFS admins) the firewall issues may not have shown up.
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.
Any maybe this is the missing piece, that some sites need special tools and the users did not realize it. We where distributing gssklog for windows for a while to our users.
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.
In some cases the Krb4 realm was supported by a kaserver in the cell, and not a KRB5 KDC in the realm by the same name. We still have a few users using the klog.
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.
But will it work with none Kerberos authentication without a lot of extra work or overhead? See my note to Jeff on this.
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.
I agree.
(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.
Not for a long time. It does now. I think I added it when KFW and OpenAFS where trying to use the krb524. At our site the mapping was not needed as it was 1-to-1 anyway for our main realm. We only have a hand full of users in the other realm, and they are not windows users.
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.
Well you now have the windows version of aklog in the OpenAFS source, how about a unix vrsion?
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.
I agree. But what is the way to do this. for those sites that need it?
The aklog is calling the PTS uisng pr_SNameToId() to see if the name will map. This might be a place to check if the token actually needs to be mapped as well.
Jeffrey Altman
--
Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
