[OpenAFS-devel] Anyone supporting multiple realms in a "all realms are equal" type of setup?

[Douglas E. Engert]

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/cell@realm and
the client can not determine if this needs be run by krb524d.

(BTW our ak5log and krb524d mods used afsx/cell@realm to map to
afs/cell@cell, The DCE server never had a principal for
afs/cell@realm The DCE AFS/DFS translator reserver the afs/cell@realm
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/cell@realm ticket, but expected afs/cell@realm 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  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444