(Don't you just _love_ it when someone finally notices that the queue
for info-afs has a bunch of messages in it?)
>On Friday, April 14, 2000, 9:44 PM -0400 Ken Hornstein
Ouch! A one month delay! Why hasn't this been fixed already?!?!?!?!
>> - Find the person who decided to use the Kerberos protocol in the Windows
>> client instead of RX and slap them silly (okay, there MAY have been
>> a reason, but certainly RX has been ported to Windows, so that couldn't
>> be the issue!). This won't solve your problem, but you'll feel better.
>
>Actually, it is my impression that other than the cache manager service
>itself, no part of AFS for WinNT actually used Rx at the time the port was
>done. Remember that this started out as a hack to prove it could be done,
>and only became a product after it was clear there was some interest. The
>real answer here is that it should be rewritten.
I seem to recall that the WinNT client included something that talks to the
ptserver (for group membership management), which would also require
client-side RX.
>> - Get Transarc to release an AFS with Kerberos 5 support! I had heard
>> rumors this project has died/stalled; anyone got any more information?
>
>I'm afraid that is probably the case. Ben Cox was working on this last
>year before he left Transarc. I heard assurances that the work would
>continue, but I have seen nothing since then to indicate that it has.
I'm afraid I have the same feeling.
>In any event, I'm not sure how Krb5 support will help in this case. As you
>know, Win2K uses the Kerberos protocol, but doesn't export a krb5 API to
>applications, or AFAIK provide them with any way to read the credentials
>cache. So, Krb5 support in Win2K doesn't make it any easier than before to
>port Kerberos-aware applications to Windows.
I wasn't thinking about the Win2K Kerberos support; one of the "promises"
made for the Kerberos 5 support was to support configurations where you
weren't running a Transarc KDC. I was assuming that those sorts of
configurations would likely have a KDC that wasn't running on your
database servers, and you could configure it to work out of the box.
(One thing that's worth mentioning is that Microsoft supports the kpasswd
password changing protocol that _requires_ native use of krb5, so there
obviously _must_ be some way at getting at the raw V5 tickets; it's
probably just not documented).
--Ken
