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

[Douglas E. Engert]

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/cell@realm 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/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.)
> 
> 
> But did you offer afs/cell@realm 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/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.
> 
> 
> 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  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444