Jeffrey Altman wrote:
I hate following up to my own post but I don't think I stated my objection clearly enough.
I will object to the implementation and deployment of any afs credential retrieval service which implements a username mapping that results in a situation in which the initial authentication name has a one to many authorization relationship dependent upon how the authentication name was presented to AFS.
The amount of my time that has been wasted working with end users who download KFW or OpenAFS for Windows, who report that OpenAFS does not work after they successfully obtain a token only to find out that the problem was caused because of some behind the scenes mapping used by their cell, is simply too high.
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.
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.
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.
(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.)
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.
Other than that the client needs some cell based information as to either to map or not.
Any mapping of a user name must be performed in such a way that when a user believes she has received a token using authentication name "foo" that there is one and only one by which an authorization decision will be made on that name.
We may have been lucky, as we have been using AFS and Kerberos for so long. We implemented a unique name facility based on the UMich concept years ago so if we combined realms or cells the users would match.
We looked at DFS too. We have never had a K5 KDC issue a K4 ticket directly as we used DCE for the KDCs for a while, and now AD. We always used krb524d. DCE is now gone. The AFS cell was there long before these and will most likely be there after they are gone!
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
