Wow, this week has been a productive one for finding new and interesting blog topics, mostly based on things that broke!
As much as I rely on Apple hardware and software for my work and personal life, that doesn’t mean I’m ready to give them a free pass on issues like cost (note to self: update the laptop price comparison with the latest models) or capability. I’ve mentioned before how much I dislike Apple’s sloppy approach to system administration on OS X Server. The logging is poor, with log entries scattered all over the place; the documentation is hit-or-miss (both in terms of coverage and quality), and there can be a wide range of behavior between different tools– some give you lots of detail (or at least more verbose messages on demand), while others don’t.
Our primary OS X server is bound to our Active Directory domain, and the services on it are “kerberized” so that users can use their AD accounts, via Kerberos, to ssh into the machine, log in to the wiki, and so on. After a bit of initial flailing around, this has worked steadily for a year or so.
We have recently been working to set up single sign-on (SSO) for Subversion on Mac OS X. This has proved challenging for lots of reasons that are too tedious to go into here (and speaking of tedious: please don’t bother telling me we should be using Git instead, kthxbai). As part of that process, someone accidentally deleted the machine account that the OS X server had been using and replaced it with a user account, with the same name, for use with a manually-kerberized service.
In the Windows world, deleting a computer’s account causes all sorts of fairly immediate breakage. To OS X’s credit, it didn’t seem to be bothered that the computer account was gone.. I mean, it didn’t log any errors or anything, so it must have been happy, right? (That’s sarcasm, in case you were wondering.) The server kept right on working, except that the previously-kerberized services would no longer accept AD credentials.
The fix for this seemed straightforward: first, remove the OS X server from the domain, then add it back. This would re-establish its machine account. That step went swimmingly, although we first had to rename the user account that was created for SSO.
The only problem was that after doing this, single sign-on still didn’t work.
It turns out that when you remove an OS X server from AD, the services are essentially un-kerberized. This seems like it would be easy to fix with the “Kerberize” button in Server Manager... except that it’s apparently broken, or something, given that no combination of inputs would be accepted. So, my next attempt was to use sso_util from the command line, which also didn’t work; I got a nondescript message telling me that there was a communications error, and that was it.
The correct answer, at least on Snow Leopard: use dsconfigad -enablesso. You can be excused for not knowing that, because if you go to Apple’s own documentation, it says to run a command called “disconfigad,” whatever the hell that is. Once I ran that command, Kerberos logons for the wiki, ssh, and console logon immediately started working, yay. Now with any luck I won’t have to fool with this stupid server for another year or so.
Paul's Down-Home Page 