Kerberos Ticket Renewal Problems

Paul: have you ruled out time sync issues? As you probably know, Kerberos breaks if machines are > about 5 mins out of sync.

What does running "klist" (in Terminal) on the Xserve tell you? Any differences in output between when the ticket is valid and when it's not?

MacBook Pro Mac OS X (10.4.8)

Hi Paul

I dont think this is a OSX Server issue as such. By default the Kerberos Policy in the Domain Controller Security Settings sets the user ticket lifetime to 10 hours. You can expand this to something more suitable.

Paul: I don't think you need to extend the time - as Antonio mentioned, the defualt ticket time is 10 hours, so my guess is that when the 10 hours is up, the OS X server tries to get a new ticket, but the clocks are out of sync by more than 5 minutes, and thus it fails.

Next time the ticket renewal breaks, run the klist command, and check the exaclt time of both system clocks, and let us know what you find. It's important to do this while the OS X server is unable to renew it's ticket.

MacBook Pro Mac OS X (10.4.8)

Hi Paul

Dave makes a good point and its worth trying. Correct me if I am wrong Paul, the AD Server uses itself as the Time Server. If you point it to an Internet based Time Server – in my experience – it tends to be more accurate and time sync issues tend to disappear. My colleague has done this on our AD Server and its relatively painless. Obviously you use the command line:

net time /setsntp:[desired time server dns name or public IP]

The configuration change is not effective immediately, you can manually stop and restart the w32time service:

net stop w32time
net start w32time

Inspect the Event log and w32time process will log the changes or report a failure.

As for internet time servers, strangely Microsoft’s tends to be unreliable. Apple’s is not too bad, MIT have their own of course.

time.euro.apple.com - 17.72.133.45 & 17.72.133.42
time.mit.edu - 18.7.21.144 (you may have to doublecheck this one)