AFP login via Kerberos from 10.5 clients to 10.4 server broken

Question

I don't know if this is connected to the problem laid out by William W. Higgins in [Open Directory or LDAP Problem with 10.5 Client and 10.4 Server|http://discussions.apple.com/thread.jspa?threadID=2163645&tstart=0]. The symptoms are... somewhat different, so I'll start a new thread.
We've got a small office with a bunch of 10.5.8 clients, a couple of 10.6 clients, one lone Windows 2000 client, and a number of remote users. I've had my OS X Server 10.4.11 machine (a PowerMac G5 single 1.8GHz, fwiw) working happily as an OD Master for the past few weeks. It's mostly a file server and a back DNS server for our public web site—we have web service turned on, but it's mostly to allow remote users to download files (or upload via WebDAV). The server has a secondary NIC that's hooked up to the cable modem in the DMZ. Everything else is behind the modem's NAT.
We've had some things show up on the logs that are making us want to tighten security, both in the LAN and over the internet. We've gone to HTTPS for the web server and are using TLS/SSL for the PureFTPd server. We closed the SMB ports on the external firewall—something we should have done years ago, probably.
I wanted to switch the AFP service over to Kerberos authentication only. However, when I make that change in Admin Server>AFP>Settings>Access, none of the clients can log on; they get an error reading:
+*Connection Failed*+
+There was an error connecting to the server. Check the server name or IP address and try again.+
+If you are unable to resolve the problem, contact your network administrator.+
Then, after you click on OK, you get the following:
+Sorry, the operation could not be completed because an unknown error occurred.+
+(Error code -5002)+
That code seems to indicate a Kerberos problem.
And when I try to log on as a network user from one of the clients, I get this message:
*+You are unable to log in to the user account "user" at this time+*
+Logging in failed because an error occurred.+
Gee, that's helpful!
Server Admin shows OD and Kerberos as up and running. The Password Service log has the following entry:
+Jan 21 2010 09:18:21 AUTH2: {0x4b4df87638fa1ec80000003400000034, bound-client-machine$} CRAM-MD5 authentication succeeded.+
So the log-on didn't go through Kerberos, for some reason, though it's been working fine that way for weeks.
I tried using +sso_util configure -r KERBEROS.REALM -a diradmin afp+ to make sure that single sign-on was running for AFP. No change.
I can use +dscl -u username -p localhost read /LDAPv3/Users/username+ and read the information on the user's home directory.
I can use /System/Library/CoreServices/Kerberos (or Ticket Agent) to request and receive a ticket. (Side note: does Kerberos really not allow login by secondary short names??? That's a pain! If I add principals for the secondary short names, will it authenticate correctly to the proper account???)
FTP is working. Web authentication is working. If I turn Kerberos authentication off for AFP, everything else seems to return to normal... but then the passwords are passed as cleartext, which isn't acceptable.
So... Is this a bug? Is this a conflict with PureFTPd? Am I doing something wrong?
Message was edited by: David Kudler

Answer 1

Post-reboot:
Well, the good news is that the kdc now shows up in the kadmin log as starting up:
Jan 26 11:43:02 localhost kadmind[98](info): Seeding random number generator
Jan 26 11:43:03 localhost kadmind[98](info): No dictionary file specified, continuing without one.
Jan 26 11:43:04 localhost kadmind[98](info): starting
The lack of dictionary file I believe is a minor error, right?
The bad news is that a) clients are no longer able to receive tickets (+*Kerberos Error* Configuration does not specify default realm+) and b) clients can't log on at all—not even via the Finder>Go>Connect to Server... command. Not even when you use the static IP address of the server rather than the DNS name.
DNS still seems to be working. I can get reverse lookup:
*cerberus:~ root#* dig -x 10.1.10.2
; << DiG 9.3.6-APPLE-P2 << -x 10.1.10.2
;; global options: printcmd
;; Got answer:
;; -HEADER<<- opcode: QUERY, status: NOERROR, id: 45389
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 2
;; QUESTION SECTION:
;2.10.1.10.in-addr.arpa. IN PTR
;; ANSWER SECTION:
2.10.1.10.in-addr.arpa. 3600 IN PTR cerberus.limbo.jcf.org.
;; AUTHORITY SECTION:
10.1.10.in-addr.arpa. 3600 IN NS ns1.jcf.org.
10.1.10.in-addr.arpa. 3600 IN NS cerberus.limbo.jcf.org.
10.1.10.in-addr.arpa. 3600 IN NS 10.1.10.1.
;; ADDITIONAL SECTION:
ns1.jcf.org. 86400 IN A 207.58.140.213
cerberus.limbo.jcf.org. 3600 IN A 10.1.10.2
;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jan 26 11:50:51 2010
;; MSG SIZE rcvd: 163</div>
*cerberus:~ root#* dig cerberus.hades.jcf.org
; <<>> DiG 9.3.6-APPLE-P2 <<>> cerberus.hades.jcf.org
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36453
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;cerberus.hades.jcf.org. IN A
;; ANSWER SECTION:
cerberus.hades.jcf.org. 86400 IN A 10.0.1.2
;; AUTHORITY SECTION:
hades.jcf.org. 86400 IN NS cerberus.hades.jcf.org.
hades.jcf.org. 86400 IN NS 10.1.10.1.
;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jan 26 11:51:46 2010
;; MSG SIZE rcvd: 93
</div>
*cerberus:~ root#* changeip -checkhostname
Primary address = 10.1.10.2
Current HostName = cerberus.limbo.jcf.org
DNS HostName = cerberus.limbo.jcf.org
The names match. There is nothing to change.
(The DNS also checks out from the clients.)
But.... fubar.
When I run +kadmin.local listprincs+, it lists all of the users and computers I've added—plus a couple that I don't recognize but that seem to be the products of bound computers (the names are along these lines, rather than the actual computer names for the clients: +LKDC:SHA1.59B886209B027XXXXXXXXXXXXXXXXXXXXXXXXXXX$@CERBERUS.LIMBO.JCF.ORG+). But when I run +kadmin.local list_policies *+, it just pops down to the next prompt. There don't seem to be any policies defined. That can't be right, can it????
Further weirdness: I tried rebinding the client that I'm working from (an iMac running 10.6.2), also using the IP address. It goes through the binding process, but no dice—when I try to run System/Library/CoreServices/Kerberos.app, I still can't get a ticket. And the weird bit is, there doesn't seem to be a /Library/Preferences/edu.mit.Kerberos plist file on the client. Well, no wonder the client's Kerberos app can't authenticate the realm—there's no local file in which the data is stored!
I should note that when I rebooted this morning, I first booted to the backup drive and ran Disk Utility; I repaired permissions—more than once—and repaired the disk directory as well. Perhaps I have confused the **** out of it. Though how the permissions got fouled in the first place is beyond me.
I have other things to do (as it says in my profile, I'm the local IT guy by default)—though everyone where I work needs this problem solved.
At this point my options seem to be:
1.) Back up, demote, promote and reload the OD server.
2) Reinstall from scratch.
If anyone has any suggestions in the next hour or so, I'd love to hear them!
Message was edited by: David Kudler