The Problems with Apple OS X (10.6.4) Server

Monday

Jul122010

Monday, July 12, 2010 at 12:44

It has finally been done. I've switched off the old Windows 2003 server at home and officially replaced it with an Apple Mac mini server. For now... And with 'for now' I really mean for now. It turns out that Apple OS X Server doesn't resemble its client counterpart at all. Where the client is stable and intuitive, the server edition lacks both.

I'll try to explain why I think there's lots of room for improvement. Mainly stuff I ran into while configuring the server/services.
Since the Windows fulfilled several functions, I needed these functions to be available on the OS X server as well. These were;

Networking services like DNS and DHCP
Webserver
Mailserver
MySQL Database
SSH Server
File sharing on the internal network
Public Key Infrastructure for issuing certificates
Download station

Evaluating these functions, one would think that this shouldn't be a problem. Well it actually is.... At least some of those features.

The following experiences are with a Mac mini (mid-2010 edition) server with a legal OS X server edition. The installation is/was clean and default. So there is no inheritance of older applications or OS related settings.

Server Admin and Workgroup Manager

Server AdminThe problem is that the tooling for managing these services is crappy to say the least. I'm talking about the Server Admin tool and the Workgroup Manager.
For some reason the communication between the tool and the actual services/daemons fails regularly. This means that when I launch the app, it can't connect to the server. Weird, since it run on the server. So network-wise this shouldn't be a problem. Also, the tooling connects to the localhost. So no resolving problems one should think.

The Workgroup Manager is fast one time, and other times it takes about 3 minutes just to show the users. The GUI access the Open Directory server on the localhost. Just to avoid any DNS or networking issues. And the 'fun' part is that a generic LDAP tool (e.g. SoftTerra LDAP Administrator) could connect just fine across the network.

Thankfully, I only run a small home network. I can't image how a sysadmin with dozens of users would feel.

Internal OS X Firewall

when I browsed through the logging of the server with Splunk I saw that the SSHd can work with the OS X firewall to automatically block IP address that are trying to get in (bruteforce attacks).

Jul 11 16:35:35 zeus emond[87]: Host at 174.121.101.100 will be blocked for at least 15.00 minutes

Jul 11 16:35:36 zeus afctl[17545]: Firewall not running or managed by another entity, rule not added

Since I hadn't enabled the firewall, I thought that this might be a good idea, since I didn't the DenyHosts add-on to realize such a feature.

The OS X firewall differentiates based on defined networks. So I made sure that internal hosts were allowed to communicate with the server without restrictions, and that the sources on the Internet could connect only to those ports I had opened on my router (mail, web, ssh). This should enable the automatic blocking of those who try to get in.

After restarting (and rebooting the servers, since the Server Admin tool lost all connections to the localhost) everything looked oke.... until I rebooted my computers/mobile devices on the local network. None of them seemed to be able to get an IP address from the DHCP server. Turned out that the allowed everything isn't really allowing everything. After a second reboot (????) everything worked oke?
This OS X server is just like the older Windows operating systems; Reboot for the changes to take effect. If that doesn't work; reboot again.

Certificate 'services'

When I did some research wether I should buy a Mac mini server I didn't research the PKI capabilities of the system. Turns out that the OS hasn't any. Well, that not entirely true. There is the possibility to create a CA and create certificates signed by that CA. All this in a nice GUI with even a wizard.

The first GUI I discovered is in the (crappy) Server Admin tool. Selecting the server in the left pane shows a certificate button in the right pane. This interface offers you the possibility to import and create certificates. Using this interface has the following problems;

Creating a CA through the wizard creates a CA which expires in 1 year. Strange setting, since an issued certificate may NOT expire after its issuer (just check the PKI RFC's). So creating a CA and creating an SSL certificate after that renders the SSL certificate basically useless.

Using the 'override defaults' setting results in nothing but disappointments. Everytime the wizard end with an error. No way of creating a decent certificate (CA or SSL) through that interface. After this, it was time for some research, and in the official documentation, I found that the 'official' way is to use the Keychain Access app with the Certificate Assistant to create and manage certificates.

The GUI is basically the same (and also available on the regular OS X clients) as if you would access it through the Server Admin tool. Only difference is that this one works (sort of). I was able to create a CA that expires in 2030. I also was able to create a SSL certificate for my mailserver. Things went sour when I tried to create a different certificate for my webserver. The wizard kept exiting with an error that there already was such an item in my Keychain....

Another disappointing thing was that the default location in the Keychain where the certificates (incl. private keys) couldn't be set to System. Everything had to go in the (user) Login part. Problem is that when the user logs off, the access to the certificates is also gone.
Dragging the certificates (incl. keys) to the System 'container' only worked for the CA certificate. No way of getting the mail certificate into the System container. Everytime the error that the item already existed there. Well, it wasn't.

xCA GUITime to search for an alternative, which I found in xCA. A free opensource certificate management tool (available on different platform). With this application I could create my own CA (with every attribute I could ever wish) and the two certificates. After exporting the certificates I was able to import them into the server (Keychain and Server Admin). Don't forget to put a password on the exported p12 files. Somehow OS X needs a password when you try to import them.

The way to import them into OS X is this; Rename the exported p12 file extension to pfx. Eventhough P12 is a correct extension, OS X can't handle it. Weird, since the p12 naming is the Linux way. Microsoft uses the PFX by default. Secondly, don't try to import directly into the System container. This won't work. Import them into the Login container and move them (by dragging) to the System container.
Adding them to the Server Admin tool is easier. Just as long as you use the pfx file extension on the certiciate+private key file.

Food for Thought

The OS X server platform (10.6.4) isn't anyway near the Windows 2003 (or newer) servers in term of;

Management, and
PKI Services

The management interface is nice and has logical look-and-feel to it, but what's that when you can't access it? This might happen if you run these apps across the network, but on the localhost should these tools be available at all times without crashing and without delays. This goes for both the Server Admin and Workgroup Manager tool.

It's clear that PKI services aren't important (yet) for Apple. Reading through the Admin guides confirms this, since they direct you to commercial certificate vendors like VeriSign etc. The problem is that not every can afford these certificates, and you don't need those if you control your user-base. In many cases, an internal PKI environment will work perfectly. Too bad Apple doesn't see this.
Microsoft on the other hand has the capability of creating (complex) Public Key Infrastructure with a few clicks of the mouse-button. Including all the (graphical) tools to manage it.

Finally, I must mention that this isn't my way of bashing Apple. It's just that (in my opinion) Apple has a long way to go on the server platform in regards to the stability of (critical) management tools, and enterprise readiness.

Update on Monday, July 12, 2010 at 21:48 by