nerdnet

When it comes to running a network with mixed OS clients, there really is no "easy" solution when it comes to serving files, printers, and other network resources. Throw in access control, user management, and network monitoring and things can get to be really tough.

The company I work for as a network engineer has used Novell for the last 15 years or so, and once its set up and running properly, it does a great job of blending everything together into a homogeneous system. Unfortunately, it works best with Windows clients, and as of late, its Linux client is catching up. Still, getting Novell to provide the same services to any OS client, at login time, via single sign-on, can be torturous, expensive and time consuming. The cost of licensing and upgrading strains the relationship. So, for us, it was time to figure out how to break with the past and step out of the comfort zone a bit.

Our network consists of Windows and Linux client machines, and we are starting to look at Mac OS X machines as well, so whatever system we end up replacing Novell with, it has to be able to support those client operating systems. Our clients need to be able to log in, get their drives and printers mapped automatically, and get to work. Users expect this behavior at every login.

After a bit of research, we decided on evaluating Mac OS X Server as replacement for our Novell infrastructure. We purchased a shiny new Xserve with dual Xeons and 2GB of RAM, installed it in our rack, and I set about trying to make it do everything our Novell system was doing for us. According to Apple, Mac OS X server is capable of giving us everything we need, for OS X, Linux and Windows clients.

I'd never administered an OS X Server before, and even though I know Linux and networking, OS X Server is still different enough that I had to do my homework before I got started. I think the biggest problem I ran into is that Mac OS X Server is relatively new in the enterprise arena, and it was tough finding others who were trying to tackle the same problems we are, let alone people who had written anything about how they had overcome some of them. Luckily, the Internet is a wealth of information, it just takes time to find exactly what your looking for. I also have many years of experience managing most of the services OS X Server provides on other platforms.

One major benefit of OS X Server is that is utilizes a lot of open source software I am already very familiar with, and it ties them all together nicely and makes administration tasks relatively pain-free. Many of the systems OS X Server uses are built on existing open source projects, such as OpenLDAP, Kerberos, Samba, and CUPS, just to name a few. I've worked with every one of these in depth on Linux servers before, and one could argue that I could effectively build a system that has all the functionality of the OS X Server with a Linux box and some free software. What we wouldn't have, however, is an administration front-end that ties all these pieces together. This was a big selling point for us with the Xserve.

Installing the Xserve and getting OS X Server up and running was a snap. After we had it set up and installed in our rack, we added more RAM and 500GB hard drive. For the first couple of days, I spent time getting familiar with the operation of OS X Server and reading over documentation and articles. Once I felt comfortable in the OS, it was time to migrate some of our network services over to the new Xserve.

I started with our core network services. Just like most companies, we use DHCP, DNS, and NTP on our network. Setting these up in OS X Server was very intuitive, and within a few days we moved these services from the Novell server to the Xserve. The biggest problem we ran into here was with DHCP. Windows clients don't often like to give up their DHCP leases, and so for a couple of days we had IP address conflicts that required sorting out. Also, our Novell DHCP service was set up to give all the Windows machines its NTP server address, and in the DHCP tool under Server Admin in OS X Server, you cannot specify an NTP server to be sent out with DHCP. A bit of research directed me to the Netinfo Manager utility in Mac OS X Server. You can drill down into dhcpd configs and add the directive dhcp_network_time_protocol_servers and set the IP address of the local time server. One thing to keep in mind, if you're running ntpd on OS X Server, it sometimes starts several instances of itself. While this isn't a huge problem, the server may throw file descriptor errors in the log files. I'm still not sure how or why this happens, but killing all but one ntpd process usually solves the problem. From my experience with other operating systems, ntpd only ever needs one instance to provide network time.

My next task was to migrate our current CUPS print queues over to the Xserve. We were running CUPS on an old Linux box mainly for the benefit of our Linux clients on the network, Novell was handling printing for all the Windows clients. Print services on OS X Server are very easy to set up and administer. You enable the service, create a new queue, point it to the network printer via LPR, and tell it how you want it shared. Since we don't require a lot of printer security, and we need every client to be able to access our printers, I set up our queues to be shared via IPP/SMB and LPR. One thing I feel is lacking here is the ability to specify printer make, model, driver and other options that other clients rely on. You can go into the Mac OS X system printing preferences pane and add more detail to all of your printers, but in most cases that won't provide any drivers to connecting clients. This isn't a big problem for Linux or Mac OS X clients, but for Windows clients it can be a problem, especially since we are setting our Xserve up to act as a primary domain controller (PDC) for the Windows clients.

I had a huge problem seeing the printers shared by OS X Server over the Windows network, until I discovered by accident that the smb.conf file in /etc on the Xserve was missing an important section:

[printers]
printable = yes
path = /tmp

Once this was added and samba (Windows services) restarted, I could find the printers on the network from any Windows client.

Once I was satisfied that DNS, DHCP, NTP and CUPS were working properly across our network, it was time to get Open Directory and Kerberos working. I set up the Xserve to act as an Open Directory master with Kerberos for authentication. Again, with the Server Admin tool this was relatively simple. It is very important that DNS is set up and working before Kerberos is set up. If DNS isn't working, Kerberos will not start. The machine must be resolvable by host name and in reverse by IP address. You can test this by opening a terminal and running the command 'changeip -checkhostname' - it will let you know if there is a problem.

Windows services were next. As I mentioned, we needed a PDC for the Windows clients, so I configured Windows services to act as a PDC without guest access, and started the service. This service provides file / print via SMB/CIFS and it ties directly into the Print and Open Directory services on OS X Server. One thing I learned early on with OS X Server is to make sure that inter-dependent services were running. The Server Admin tool usually alerts the user that the dependency exists, which is helpful.

OS X Server uses the 'Workgroup Manager' or WGM to handle the task of user, group, share and preference management. I've found this to be a very useful tool. I set up network shares for user's home directories, group specific directories, a roaming profile directory for Windows users, and a print$ share for Windows print driver services. I created groups and a couple of test user accounts and decided to test authentication from a couple different operating systems.

I started with Linux. We use OpenSuSE 10.2 as much as possible. It's a good Linux distro and there is the obvious benefit of the Novell connection. From what I can tell, the Novell Client for Linux only works with Novell SLED/SuSE and with OpenSuSE, and we need this functionality for our current system. Another thing I really like about OpenSuSE is the Yast tool. When it came time to set up LDAP / Kerberos authentication in Linux, it was easy to use and it worked great. I set up the Linux client to authenticate via Kerberos and share LDAP information with the Xserve. Logging out and logging back in with one of the test accounts I created worked just fine. With a little more work and some reading, I was able to set up automounted home directory shares via NFS from the Xserve, as well. Printers are just as easily set up in Yast, and since its handled with CUPS, I just tell the system to listen for CUPS broadcasts and printers are automatically found and available.

Next, I wanted to test Windows clients with the PDC. I set up Windows XP SP2 running on VMWare Workstation. VMWare is a great way to create test clients and put them through their paces without affecting anything else. Once I had XP running in a virtual machine I tried to attach to the domain, only to find I was unable to do so. After checking over logs and doing some more reading, I discovered that the machine has to have a machine record in WGM, or the directory administrator has to attach it to the domain first before any user can walk up to it and log in. Since I had never administered a Windows domain before, I wasn't aware of this, and the documentation I have isn't entirely clear on this. Once I got past this, I started working on network login scripts for windows users. Each user can have a network login script assigned to them in WGM and it lives in the directory /etc/netlogon on an OS X Server. For a Windows client, this will be a .bat file using Windows login script commands.

For example, this will map the share “Development” to drive letter I: on a Windows client:
rem Map Network Drive Shares - remove any previous assignments first
net use i: /delete
net use i: \\Directory\Development

And this will set up a printer for a user:
rundll32 printui.dll,PrintUIEntry /in /n "\\directory\Accounting" /q

Here is another “gotcha” with sharing printers to Windows clients over SMB in a domain controller environment. When you log into a PDC from a Windows client, chances are you don't have rights to add your own printers to the system. Windows servers and clients have whats called 'Point and Print' restrictions and they need to be disabled on the workstation as the system administrator. Even with this disabled I found that users, when logging in, cannot get printers automatically set up for them. I ran into a couple of errors that indicated to me that permissions or access rights were not available to the user to allow them to add a printer. The errors I got were very misleading; it turns out that its a problem with missing drivers on the print$ share.

In order to get past this, I had to log in as the Directory Administrator, browse to the shared printers, right click on them and select “Properties.” It immediately asks if I'd like to install a driver, to which I say no, and then, once in properties, install the driver from the Advanced tab. Once a driver is selected from here it gets installed back to the OS X Server's print$ share I created in WGM, and then, every time a user logs into the PDC from a Windows machine, the printers are allowed to be added via login script. After a couple of days of trial and error, I determined that the drivers should be digitally signed, installed before hand as the Directory administrator, and that the printer name should match the queue name it was set up as in the Server Admin tool (when you install the driver via the Advanced tab, its going to try to rename your printer to the name of the printer driver, change it back to the queue name!)

This is as far as I've gotten with the system so far. I have yet to try an OS X client but should have that going in a week or so when I get to it. Right now, I'm very pleased that I am getting Linux and Windows users to authenticate and map drives and printers automatically. It took a lot of research and a lot of headaches to get to this point. I think that Apple can do a lot better job of documenting methods of setting up various clients to work with the services provided by OS X Server. Below, I have listed a list of several resources I found incredibly helpful.

Over all, the Xserve running OS X Server has been quite reliable, although it has rebooted itself due to kernel panic on a couple of occasions, for no apparent or obvious reason. In the future, we also want to integrate e-mail and calendar services, as well. We have yet to migrate our users off of Novell, but hopefully I will be able to prove that this system will be a viable alternative. Right now, I'm not ready to commit 200 users to an entirely new system until I feel I can trust it completely.

What this experience has taught me, if anything, is that we are still a long way from having a “universal” client – server system that just “works.”

Here are some of the best sources of info I used to make this system work:

http://www.macdevcenter.com/pub/a/mac/2007/06/01/discover-the-power-of-open-directory.html
http://www.macdevcenter.com/pub/a/mac/2007/06/27/discover-the-power-of-open-directory-part-2.html
http://www.macdevcenter.com/pub/a/mac/2007/07/18/discover-the-power-of-open-directory-part-3.html
http://www.mactech.com/articles/mactech/Vol.21/21.07/MacOSXServer10.4/index.html
http://www.paulmcgrath.net/e107_plugins/content/content.php?content.6

http://discussions.apple.com/category.jspa?categoryID=96
http://www.afp548.com/forum/index.php
http://www.apple.com/itpro/
http://www.apple.com/support/macosxserver/
http://www.apple.com/server/documentation/
http://macenterprise.org/
http://support.microsoft.com/kb/319939

Thanks to everyone who answered my questions on Apple Discussions and AFP548.