AFP doesn't play nice with Kerberos...

Question

I'd prefer any open ideas before blowing away the OD master and redoing all the accounts....
If I leave the AFP Authentication type to "Any", network accounts can login to any computer (and with network or portable home directories). If set to Kerbeors, we get the "User account is located on a AFP/SMB share...."
If logged in, when attempting to connect by AFP, the "Standard" authentication appears. At this point, if I set the AFP access type back to "Kerberos" (which prevents users from logging in), they will get a -35 error as stated before (one or more required items cannot be found...blah blah). Interestingly, if we use the standalone Kerberos app (System/Library/Core Services/Kerberos) to get a Kerberos TGT, we can then connect to AFP shares using Kerberos authentication. So, it seems as if Kerberos is having problems getting connections started.
So, for now, it seems as if I have to rely on AFP access via the non-kerberized ("Standard") method, which definitely reduces our security. But, at least people can login to network machines.
So, in the end, Kerberos doesn't really know what is going on...it seems like its pretty confused.
kdc.log
Jul 01 09:07:56 myserver.mydomain.com krb5kdc[268](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.10.147: UNKNOWN_SERVER: authtime 1151759266, [email protected] for krbtgt/[email protected], Server not found in Kerberos database
Jul 01 09:07:56 myserver.mydomain.com krb5kdc[268](info): TGS_REQ (7 etypes {18 17 16 23 1 3 2}) 192.168.10.147: UNKNOWN_SERVER: authtime 1151759266, [email protected] for krbtgt/[email protected], Server not found in Kerberos database
ldap log
Jul 1 09:06:04 myserver slapd[90]: <= bdbequalitycandidates: (apple-computers) index_param failed (18)\n
Jul 1 09:06:35 myserver slapd[90]: SASL [conn=137] Failure: no user in database\n
system.log
Jul 1 09:05:50 myserver servermgrd: AFPDefines Start AFP Server request\n
Jul 1 09:05:50 myserver configd[92]: executing /usr/sbin/AppleFileServer
Jul 1 09:07:40 myserver /usr/sbin/PasswordService: client response doesn't match what we generated<br>
Many different systems...   Mac OS X (10.4.7)  

Answer 1

Yes, you're on track with the quickest way to solve this problem: Recreate your Open Directory Master. However, you can save all of the data stored in the database, except for user passwords, if you use Workgroup Manager's File > Export command to save your users, groups, and computer lists. Even MCX records for same are preserved.
(Exporting from Workgroup Manager is not the same as doing a directory backup and restore via Server Admin. Doing a restore would likely not solve your problem.)
On to the specifics: I'm guessing that you created the Open Directory Master when your server was using Mac OS X Server 10.4.5 or earlier. Before version 10.4.6, Kerberization was a hit-and-miss procedure: sometimes it would work and sometimes it would not, even when the server's hostname was properly set and a DNS record existed for that name. The problem resides in a hostname resolution issue, but it's one that is most easily fixed by updating to Mac OS X Server 10.4.6 or 10.4.7 and recreating your Open Directory Master. In Mac OS X Server 10.4.6, Apple introduced a better way for the server's hostname to be set.
In versions 10.4 through 10.4.5, you'd have to make the following changes before promoting your server to Open Directory Master: edit /etc/hostconfig and change HOSTNAME=-AUTOMATIC- to the server's host name, ensure that the server had a valid DNS record for its hostname (via the server's DNS service or existing DNS service), and run the hostname (or equivalent) command to ensure that the hostname was really set. All of this was required to circumvent a system that Apple had put into place but that wasn't effectively working. With the HOSTNAME=-AUTOMATIC- entry in /etc/hostconfig, the server was supposed to set its hostname choosing the first of these that was true: doing a DHCP client ID search, doing a reverse DNS search from the primary Ethernet interface's IPv4 address, setting the hostname to the Bonjour name, then setting it to "localhost." Unfortunately, what always happened, unless the initial boot returned a different result, was the Bonjour name was returned as the hostname. (Some Apple literature calls the Bonjour name, which is a mDNS name, the "local hostname.") Thus, running hostname would always return the Bonjour name, which prevented Kerberos from starting, as Kerberos needs a valid DNS name for the server's hostname.
Starting with Mac OS X Server 10.4.6, Apple introduced a better way to do a reverse DNS lookup and set the hostname automatically at startup time. Thus, for 10.4.6 and later, /etc/hostconfig needs to have HOSTNAME=-AUTOMATIC-, and you need to ensure that the server is providing DNS services or that your existing DNS services have an entry for the server already.
You may find this article helpful: http://docs.info.apple.com/article.html?artnum=302044
It offers an additional suggestion of adding an entry for the server to /etc/hosts, should some problem with DNS arise. It also uses scutil --set to set the hostname; this command performs the equivalent of using the hostname command as I've suggested. In my testing since 10.4.6, I have had to recreate some Open Directory databases in order to get Kerberos working (or working again); however, usually the hostname is set properly after a restart automatically.
Just for reference, the "Standard" authentication for AFP uses Diffie-Hellman Exchange (DHX), which is an encrypted password transport.
--Gerrit