> Fortunately the "kaserver" performs most of the "MIT kerberos server"
> functions correctly, so a single kerberos server can be used for both Andrew
> filesystem, and MIT principal and instance, authentication. It may be that
> the "uss" program is flawed in its' ability to handle "principle and
> instance pair". We like many sites roll our own account maintance
> applications using the basic AFS and/or MIT Kerberos utilities or library
> functions so never had cause to gripe about it. Transarc has done a pretty
> good job of fixing a number of kerberos interoperability problems.
There are actually two cases where bugs have not been fixed that are
particularly annoying, since I'm relatively certain I submitted patches for
both.
Both are in the Kerberos udp interface. One is simply to actually add an error
code and really return KDC_TIME_ERR (or whatever it is) when the reason
authentication failed is a time problem, instead of just KDC_GEN_ERR.
The other is more complex. As a result of a fix submitted a long time ago by
Richard Basch when he was still with MIT (I think) cross-realm authentication -
when using the udp interface instead of rx - won't work.
The details:
It used to be that when any key with krbtgt as its "aname" was created, a magic
internal flag was set in the kaserver, KAF_SPECIAL (IIRC). This caused the key
to be always kept in the kaserver's cache of keys, but also when its key was
changed the kvno was forced to be monatomically increasing, regardless of a
kvno switch being specified in the admin command to change it. (And I think it
had a third effect, but I don't recall what if any, and it's not relevant to
this either. Maybe it was "old versions kept forever")
Richard submitted a fix which caused the function which adjudged if a new key
was "Special" to no longer decide crossrealm TGTs were special, only the local
realm TGT. This meant crossrealm TGTs could have arbitrary kvnos set. Except
there was this one problem. *Only* crossrealm TGTs which pre-exist this case
would be KAF_SPECIAL and therefore cached by the kaserver. But when a request
came in on the UDP interface for a crossrealm TGT which was created after this
fix and therefore not special the first piece of code it hit tried to get the
kvno of the TGT for the realm in which a ticket was being requested. And it
lost, because it was neither in the cache, nor was a ubik transaction opened
yet, and the comment just above the lookup kvno even says something like "we
should really do this after getting a transaction".
The fix is actually simple. The init transaction call moves above the kvno
lookup from several lines further down in the code, and all of the "goto fail"s
between where it gets moved to and where it was moved from become "goto abort"
since you of course need to clean up your transaction if you fail!
We (CMU Computing Services) have been using this code for several years. It's
not an issue to us, only when we try to exchange keys with a site which runs
Transarc binaries and isn't willing to shut down all of their kaservers to run
a magic "bless this key" database modifier.
-D
