>Has anyone successfully used the Windows AFS client in an AFS cell with Ken
>Hornstein's NRL AFS-Kerberos5 migration kit (which allow you to run a
>normal Krb5 server, storing afs3, krb5, and krb4 keys)?
Why yes, we have .... but it required a packet sniffer to figure out
what was wrong.
>We've successfully
>used it with unix clients (using aklog to obtain AFS tokens from krb5
>tickets) and have preserved the ability for users from foreign cells to
>authenticate to our servers by running "fakeka", which decodes just enough
>of the RX packet to forward the authentication request to the krb5 server.
>So far so good... but the Windows AFS client has looked more attractive to
>us lately and we cannot get it to work with our modified setup...
Okay, here's the deep dark secret to the Windows AFS client: it does
not use the RX protocol for authentication! It sends a Kerberos 4
packet to the kaservers (which also happen to implement a V4 KDC
as well). It's not getting a response, so you get this error.
The two easy solutions are:
- Run KDCs on your database servers
- Add your KDCs to your CellServDB on the windows machines
I did the latter at first; worked fine (Once the "wrong" DB servers timed
out, everything was okay).
A little bit harder solution:
- Use the Windows aklog that comes with the migration kit (may not be
practical if you want single sign-on without some GINA rework, but
we use it here and it works fairly well).
Better solutions:
- 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.
- Get Transarc to release an AFS with Kerberos 5 support! I had heard
rumors this project has died/stalled; anyone got any more information?
--Ken
