13 Feb 2011

Open Directory Demotion: Just Don't

I've been having this problem recently where I try to use Workgroup Manager and I get authentication errors. It affects all computers bound to my open directory so its a server issue, except I can still get kerberos tickets and all other services function as expected. I can even work with Server Admin.

After a good googling I found this little gem. (among others)

The two pieces of advice I gleaned from the internet were:

  1. Fiddle around with the security options in the binding pane
  2. Demote and re-promote your open directory, effectively restoring to defaults
I have a problem with "solutions" that consist of tossing everything and starting again from system defaults. Yes it will probably work but I didn't make computer science my profession to take the easy route and go back to the defaults every time a niggling issue crops up. I couldn't administer the directory but at least the services were all up.

Anyway being a bit time poor this week I fiddled around with the binding options until I could log in again and left it.
This doesn't show the options that worked, but read on to find out why that probably doesn't matter anyway...
The only problem was that the authentication issue kept cropping up over the week and to top it off I was annoyed that suddenly the security options that I had been using for ages were apparently no longer usable.

Come the weekend and with non critical time to work on the server I set about trying to solve the problem once and for all. Out of frustration I decided to go with option 2 above. It would mean a lot of work but I was at the end of my tether. So I backed up the directory and demoted the server to a stand alone directory. The server was re-promoted to Open Directory Master and I tried to merge the backup back into the directory. 

It failed repeatedly. (You know how that feels)

The backup kept failing on merge so I decided to try importing and replacing the directory, in spite of the fact that this step would probably re-introduce the problem. When you import the directory, however, users that had admin rights have those rights stripped. I assume thats a security thing. I then had a directory with no admin user in it.

So another demotion and re-promotion was required, but this time I gave the diradmin user a different UID and a different short name. The idea is to have an admin user that won't clash with users that are in your directory backup. The hunch paid off and the directory merged this time and after restoring admin rights to my original diradmin user I was back where I started.

At this point reading the fine manual seemed like a good idea.

Page 87 talks about authenticated binding. While this is a nice idea it also causes a world of hurt when used with DHCP and...
Important: If you choose “Encrypt all packets (requires SSL or Kerberos)” and “Enable authenticated directory binding,”make sure your users are using one or the other for binding and not both.
I made the decision that authenticated binding wasn't needed on my network and then proceeded to turn on all the other security measures. Also from the manual:
Note: If you change the security policy for the LDAP directory of an Open Directory master, you must disconnect and reconnect (unbind and rebind) every computer connected (bound) to this LDAP directory
So then if you change these settings without rebinding your clients then you may end up with strange issues, perhaps issues such as authentication issues with workgroup manager (maybe). I imagine the authentication started to work when I changed the settings back to what they were originally when the directory was first set up and clients initially bound.

So with the lesson that the Snow Leopard Server manuals are actually pretty good learned and sane options chosen all thats left is to rebind all the clients(!)

6 Feb 2011

The different types of Open Directory users

So you have a snow leopard server and you have set up Open Directory and a reverse DNS entry for the server and you're other computers have joined the domain. Well done on getting that far. Now you want to decide how to set up your user account(s) so that it works the best for you. How do you configure them and what is fastest or most practical? This is a guide to help you figure out exactly how you want your Open Directory (OD) set up and then give you some tips for migration.

Local, Remote, or Mobile?
There are 3 main types of account you can have on OS X when attached to an Open Directory server (not including administrative and restricted user, a status which can apply to any of these 3 accounts). Each type of user has benefits and drawbacks.

A local account
is probably what you have now. Accounts created in the accounts pane on an OS X computer are local accounts and they can be administrative or restricted or managed by parental controls whether on the local computer or on a remote computer. You can run a local account in an OD setup no problems. If there is an account on the server with the same short name as on your local computer then Snow Leopard on your client machine is smart enough to be able to pick that up and ask if you want to set up the services that have been provided for you.

Pretty sweet. This type of user can also get kerberos tickets from the server, but you'll have to do it manually every login. Either with a kinit command in Terminal or by tricking iCal to store your Kerberos credentials in your Keychain. (it then automatically kinits for you). But that kinda defeats the point of "Single sign on" if you have to change the kerberos password in your keychain every time you have to change your actual password.

Another problem is that this user will not be affected by managed preferences set up with workgroup manager. I like using managed preferences to auto mount network shares and setting up some common settings for every computer I log in to, and even some for all users on the network. Look into managed preferences and you'll be considering the switch of account type to one of the others...

A remote account
is an account that lives entirely on the server. You add the account on the server and set a home directory for the account and then you can log in with the same user environment on all computers attached to your directory. Perfect if you have multiple computers and want to move, seamlessly, between them. You get your Kerberos ticket automatically at login so you are truly in a single sign on environment. You can also manage the preferences of the remote users so you can add stuff to the dock or auto mount shares from your server and loads of other cool things in Workgroup Manager. Great! 

The drawbacks can be quite large. As your home directory typically exists on the network the speed of your computer is limited by the speed of your network. AirPort users beware, you'll really want to be hooked up by ethernet for anything more than document editing, which I have done successfully over an AirPort connection. You can be sneaky and set up a remote account's home directory to point to /Users/ in Workgroup Manager. 
Look at that. A local directory for a remote account!? Whoda thunk it.

This then creates a home directory on each of the computers you log in to. You do lose that same environment on every computer you log into, but you get Single sign on and the speedup is great. The only other major issue is that you will still need to be able to access your server to log in. This isn't great for portable computers. And so enter the

Mobile Account!
These accounts are designed to be the "best of both worlds" between local and remote accounts. The remote account that you take with you. Configure an account (or computer) in workgroup manager to be able to set up a mobile account and you're away. Your computer makes a copy of the user information in your Open Directory and keeps it in sync whenever it can. You get a kerberos ticket automatically at login and you can log in from outside the reach of your directory server.

Your data is all stored on your local computer and you have the option to sync it back your network home directory. This can be a pain to set up and can add extra time to logins and logouts so it depends on how much you want to trade off the convenience of having all your data everywhere vs login and logout times. Mobile accounts also refresh their managed preferences whenever you log in within sight of your directory server.

For me, personally, I run a mobile account with home syncing off. I think its the perfect balance between the nice benefits of SSO and being part of a directory with the ability to use my laptop as a laptop. I use managed preferences to set up my user environment the way I like it for when I log on to other machines and when I change my password on my computer it propagates to the server and changes it everywhere. 

The best thing is that you can easily convert your current home directory to a mobile account directory. Simply backup (always backup first), then delete your user on your local machine. When it gives you the option you want to select "Don't change the home folder". Your home folder is then renamed to user.old. Log in with your mobile account. This will create your mobile account on your local computer and make a new home directory. Then log out and replace the newly created home directory with your old one, remembering to reset the ownership of all the items to your new user. (even though the users might have the same name they may have a different UID, and certainly a different UUID. The permissions need changing)

If you have any questions about local, remote or mobile accounts please leave them in the comments. It can be quite confusing at first but figure out what you want from your snow leopard server and then pick the account type to suit.

iCal to kerberos: Secretly I hate you

So last week iCal Server stopped authenticating via kerberos. My machines were getting tickets all fine for other services but calDAV just was refusing to authenticate. SSL off or on I kept getting the error:
"The server responded with “HTTP/1.1 401 Unauthorized” to operation CalDAVAccountRefreshQueueableOperation."
I read several help threads that seem to describe a myriad of things that you can do to help in this situation and just about all of them amount to voodoo.

Deleting my user's caches wouldn't work because it affects different users on the same machine.
Backup, Demotion and re-promotion of my Open Directory server is a drastic measure I don't want to take lightly.

To make the riddle more confusing I had the following log lines in the Password Service Server Log:
KERBEROS-LOGIN-CHECK: user {0x00000000000000000000000000000000, admin} is in good standing.
KERBEROS-LOGIN-CHECK: user {0x00000000000000000000000000000000, admin} authentication succeeded.
So authentication succeeded but something else was well and truly broken.

In the end, after a lot of head banging the solution for me was simple. To get authentication to my CalDAV server to start working again I had to type in the FQDN (fully qualified domain name) explicitly in server admin for the CalDAV service

Save, restart, all good. Why it was working previously for months without that explicitly in there is a mystery to me. Also a mystery is CalDAV in general. From reading the internet this issue probably isn't your issue at all but it is a nice quick fix to add to your arsenal before you rebuild your Open Directory.