Mac OS X Server 10.4
Volume Number: 21 (2005)
Issue Number: 7
Column Tag: Programming
Mac OS X Server 10.4
by John C. Welch
Tiger Server, An Overview, Pt. 1
Well, Mac OS X 10.4 Server, Tiger Server, is finally here! And there are a ton of changes. Enough so that
most administrators are going to want to take their time upgrading, because Apple has given us what is the
biggest upgrade since Server 10.0 came out. Literally, there is not one part of Server that has not been
changed in some fashion.
It's not just existing feature changes and bug fixes either. New stuff, stuff you've never seen before in
Mac OS X Server without installing a lot of software and doing a lot of work on your own is here. Chat
servers, Weblog servers, Software Update Servers, it's all there. This is one upgrade that's going to be worth
the money, on pretty much any level you want.
However, like any kind of review, we need to focus on what we're going to cover, so, for the sake of some
vague attempt at not turning this into "Tiger and Peace" we'll let the new server administration tools be our
One thing to note here, by "Server" I'm not just restricting this to Xserves. I'm talking about any machine
able to run Mac OS X Server 10.4. If I mention an Xserve-only feature, I'll make sure to note it as such.
Server Admin is the heart of the GUI toolset for managing Mac OS X Server, and as such, is the primary tool
of the server administrator. Any changes in Server have to be reflected here, and because Server or not, it's
still a Mac, the GUI has to work right the first time. Server Admin is not however a client management tool.
That's Workgroup Manager, which we'll be looking at a little later on. Server Admin is only here to let you
run your Mac OS X server installations. If you think about Server Admin's reach ending at the network
interface, you're on the right track.
One new feature in Server Admin, and one that I'm very happy with, is the ability to turn SSH on and off.
With earlier versions, you had to use other applications to remotely manage SSH, such as ARD or physically
logging into the server. Considering the advantages of using headless servers, (no monitor), being able to
remotely control SSH without having SSH on is a necessity, so making it a checkbox is a welcome feature.
The serial number in Mac OS X Server has changed as well. Each copy of server now checks on the network to
ensure that you aren't running multiple copies of server with a single copy serial number. It only checks on
the local area network, not back to Apple. While this is inconvenient, it's not going to hurt anyone playing
by the rules. As well, if you are going to buy multiple copies of server, and want to automatically set them
up so that you don't have to manually enter separate serial numbers, Apple will provide serial numbers in that
case which don't use this feature, so that someone trying to set up a couple hundred servers via remote
install doesn't lose their mind.
Date and Time now contains both the Date and Time settings, along with the Time Zone settings, so they're
grouped together in a way that makes a little more sense. This consolidation of settings has been implemented
throughout Server Admin, so if you're used to Panther's Server Admin, Tiger's will take a little getting used
to, but I've found it to be a much nicer tool once I did.
Two changes in this part of Server Admin are how you manage SSL and access to services. In Panther, SSL
management was done in the individual service settings. So, for SSL web services, you had to tell the web
service about any certificates, set them up, etc. In the email service, your only option was to use SSL or
not. If you wanted to do more with SSL in email, you had to leave Server admin and use the command line. In
Tiger, SSL is more properly integrated in with the various services that use it. In Tiger, basic certificate
setup is done at the server level, and you then tell the services which certificate you want to use. So you
can have multiple certificates set up if need be, and then just select the certificate you wish to use within
the service. If you want or need to use a service - specific setup that is different from the certificates
you've set up in the main SSL settings, you can do that too.
Mac OS X 10.4 Server has changed how you set access to various services, and this revolves around one of
the biggest changes in Tiger as an OS, namely Access Control Lists, or ACLs. See Ed Marczak's May Mac In The
Shell for more great coverage of ACLs!
With Panther and earlier, permissions were simple. Every file, or folder had one owner, one assigned group,
and everyone else. Each file or folder had three options, read, write, or execute. (In Unix, when you list the
contents of a folder, you are 'executing' it.) While this is simple, and reasonably universal, it's also very
limiting. To change access for various people, you have to start getting complicated with group memberships.
Of course, if you get too complicated, then you run into problems, because you can only belong to 16 groups
prior to Tiger. (If this sounds like a lot, it really isn't. The first user on an OS X system belongs to two
groups by default, their own, and admin. In a university or business environment, you can hit the
sixteen-group limit with ease.)
Aside from the group limit, three permissions caused other problems. If you have write access to a file,
but not the folder, while you couldn't delete the file, you could open it up and delete every bit of data in
the file. Even with other options, like the sticky bit or the chflags command, the traditional Unix
permissions scheme became very hard to administer if you needed to use things in a way that they simply
weren't designed to handle.
Enter ACLs. ACLs approach permissions differently, and allow for greater flexibility. An ACL is just that;
a list that defines who can access a given file or folder, and how. The big advantage to ACLs is that who can
access a folder, and what they can do is not as limited. For example, let's say I have a folder and I have
three groups of people who need different access to a folder, and the contents of the folder. Under Panther,
I'd have to do a lot of workarounds to deal with multiple groups needing different access. With Tiger and
ACLs, I can just assign each of the three groups to the folder and files and set their access accordingly. I
can set individual user access separately too. I can also specify how inheritance works, too, so that a given
ACL can apply to every subfolder a given user or group creates, and all the items that will ever be inside
those subfolders, only the immediate children of that folder, or I can kill inheritance entirely.
Write access is now no longer a binary issue with ACLs. I can specify that a user can delete a file, but
they can't modify the contents. I can allow a user to administer the permissions on a folder without making
them the owner, and without making them an admin. I can have someone who can modify existing files but can't
delete them. While smaller entities may not need this level of control, even a company with only a hundred
users or so can easily get into some pretty complex rights management issues, and Tiger allows you to manage
this outside of any sort of third party software.
Now there are some caveats here. Officially, ACLs are only supported on Mac OS X Server, and you have to
use Workgroup Manager to manage them. You can observe ACLs in the Finder, but you can't set or change them.
For most, this will work. However, if you want command line access to ACLs, you can use chmod to set ACLs, and
fsaclctl to enable or disable ACLs on a given volume. By default, they are enabled for Tiger Server, and
disabled in client. While you can enable ACLs in client, if you don't need to, I'd recommend not doing it. You
can get very complex permissions structures with ACLs, and you can accidentally open some large holes. It's
also going to take a little bit before third party software knows what to do when a user has write access but
not delete access. (This comes into play if a file saves by creating an entirely new file, and deleting the
old one. With the finer - grained controls of ACLs, it's trivial to break this if you aren't careful.)
A part of ACLs, are the Access Control Entities, or ACEs. An ACE is part of an ACL, and is the actual line
in the ACL that specifies what a user or group can do. (The best way to think of it is that an ACL is a list
of ACEs, and each ACE lists a single person or group's Access Control setting(s)). The ACE contains 4 items:
1. User/Group: Who the ACE refers to, identified by a 128-bit Universally Unique ID, (UUID) number. UUID's
avoid the problem of "Which John are we talking about"
2. Permission Type: Is this ACE allowing or denying a set of permissions
3. Permission: Which of the 13 possible permissions are being used and how
4. Inherited: Is this ACL inherited from its parent, or explicitly set
Explicit ACLs are set manually in Workgroup Manager or via chmod. With the Tiger Server ACL model, there are four kinds of inheritance. "Apply to this folder" means just that. They only apply to the specific folder. "Apply to child folders" means apply these settings to subfolders, but not files. "Apple to child files" means apply these settings to files in the folder, but not subfolders. "Apply to all descendants" means apply these settings to everything. (Note that if you really want "Apply to all descendants to apply to ALL descendants without question, you have to check all of the last three options.) While it may seem silly to have to specifically apply permissions to the current folder, there's some sense. In the case of a school, you can have a master school folder that only administrators have access to, but a series of class(room) folders that have different permissions and inheritance settings. (I said it before, and I'll say it again, be careful with ACLs. There are 98,304 possible combinations of ACL permissions, before you take complex folder hierarchies into account. You can create some really bizarre problems with them if you just slap them on like paint.)
When you use ACLs, you also have to keep in mind that there are rules of precedence for ACLs/ACEs:
1. If an object has no ACEs, then traditional Unix, (or more correctly, POSIX) permissions are used
2. If an object has multiple ACEs, then Tiger Server starts at the first one, and works its way down the
list until the requested permission is allowed or denied. It then uses that ACE, along with the POSIX
permissions, to determine access
3. Deny permissions overrule Allow permissions. So if someone has allow as part of a group and deny as an
individual, the Deny wins. Tiger Server also reorders ACLs so that Deny rules come first. (Did I mention that
ACLs can get complicated?)
4. Allow permissions are cumulative, so Allow permissions are the union of all allow permissions, including
In addition to local file/folder ACLs, both Apple File Protocol, (AFP) and Server Message Block, (SMB) file
sharing protocols support ACLs, and you have to be using HFS+ to use ACLs.
Finally, Tiger's ACLs are compatible with Windows 200X ACLs. While this may not make many in the open
source community happy, for anyone working in an Active Directory environment, this is huge, since you can now
use your Active Directory tools to manage permissions on Tiger Server Windows share points. As we will see in
the Windows section, this creates some really cool capabilities.
However, those are just file system ACLs. With Tiger Server, we also get Service ACLs, or SACLs, set in the
Access tab of the main server settings in Server Admin. SACLs allow you to split out access to various
services in Tiger Server. So you can, for example, only allow your domain admin groups to physically log into
a server and use SSH to that server, but allow anyone to use file sharing via Apple File Protocol, or AFP.
While this could be done in Panther, it was a manual process, and tended to complicate things. Tiger greatly
simplifies this. Just like with file ACLs, you can add multiple groups or users, however, with SACLs they'll
all have the same setting, so there's less of a point in doing this in general.
Figure 1: Service ACLs in Server Admin
With Tiger Server, AFP is now at version 3.2, and includes a few new features such as support for Unicode
file names, ACLs, and 64-bit file sizes. The maximum AFP volume size is 2TB, which, while well under a 64-bit
size, is still a good size for a volume type that you'll only see over a network. The truth is, AFP is a
mature protocol that already supported Kerberos, SSH tunneling, and most of the other features that Mac users
need, so there's not much to change in Tiger, and Apple has wisely chosen to leave that which works alone. The
one complaint I do have is that you can't force SSH connections, which is a nice option for those with a need
for high security.
DHCP as a protocol hasn't changed much in quite a while, so there's not a lot for Apple to change at the
protocol level. From a management point of view, the big "new" feature is the ability to assign static
addresses to a specific machine. (While you could do this in Panther, Tiger integrates this into Server
Admin.) While static addresses may seem to be at odds with the idea of DHCP, it really isn't. Static
addressing allows you to automate router assignment, subnet mask settings, DNS and LDAP settings, but still
keep the IP address the same. This can be useful for servers, test machines that you want to always have the
same address without having to manually assign the rest, etc. It's also handy for shops running their own DNS
without the benefits of Dynamic DNS, aka DDNS. The client is still set to DHCP, they just simply always get
the same IP address is all. One thing to note here, if you have a machine that uses multiple interfaces, like
Ethernet and AirPort, you'll need an entry for each interface on that machine, since static DHCP uses the
Media Access Control (MAC) address to identify the machine, and every network interface has a unique MAC
DNS is, in many ways, the most critical service in a Mac OS X network. While the Apple documentation talks
about it in polite terms, I'll say this up front: If your DNS is not working correctly, you are going to have
nothing but pain with Mac OS X Server. Period. A badly configured DNS will not only cause you problems, but
can, and quite often will, reach out and cause problems for people all over the Internet. DNS is a place that
you do not ever want to go without a good solid guide, and while Apple's documentation is good for enabling
and managing DNS on Apple servers, you really, really, REALLY want to buy and become one with the O'Reilly
book on DNS and BIND. It is the "bible" for DNS administration, and no one running their own DNS should be
There, that's out of the way. In Tiger, Apple is using version 9.2.2 of the Berkeley Internet Name Domain,
(aka BIND. DNS is the service humans use, BIND is the server that implements those services. BIND is also not
a single process, but rather a collection of services, including the name daemon, or named.) While the version
of DNS/BIND that Apple uses should normally support Dynamic DNS, (DDNS, that is, DNS names tied to your
machine, not your IP address, so even if your address changes due to DHCP, you still have the same DNS name),
there's no support for this in Apple's implementation, so if you want to use DDNS on a Mac OS X Server box,
you have to install and configure DNS on your own without Server Admin. This is, by the way, a glaring
deficiency in Apple's DNS implementation, and something that will make many network administrators choose a
different OS base for their DNS services.
The only real change in Server Admin here is the addition of a Secondary Zones tab, which makes setting
those up and monitoring them a little easier.
IP Firewall Service
Tiger's firewall has gotten quite a few updates over Panther's, although it is still based on IPFW. One
change is semantic in nature, but just enough to make talking to someone remotely a bit confusing is that
where Panther called firewall entries "Filters", Tiger calls them "Rules". Same thing, different name, but
just enough to drive you insane on a remote support call.
The UI in Server Admin has changed quite a bit though. One change is that Active Rules are no longer shown
on the first screen of the Firewall section. Instead, you get basic statistics for the firewall operation.
Active Rules now have their own tab.
Setting up the Tiger Firewall is different as well. There is now a "Services" tab, which contains presets
for the services that are running or can run on the Server. Address groups now have their own section as well,
as opposed to Panther, which combined these two functions in the "General" tab. The Services tab in Tiger has
far more entries, including explicit entries for Apple Remote Desktop's (ARD) functions, both 2.x and 1.X, as
opposed to Panther, which only has a default entry for ARD 1.2's single port setting. This allows
administrators quick access to enabling or disabling various OS X services with ease. One welcome addition is
that iTunes Internet Radio streams have their own entry, (Ports 42000-42999 TCP), so allowing local network
iTunes sharing but disabling Internet Radio streaming is a snap. A new feature of the Services tab is that
you can create, edit, and delete Service entries in the GUI, something that you could not do in Panther. (You
can't do it with Tiger's Server Admin tools against a Panther server either.) This allows you to add your own
service entries without having to do so in the "Advanced" tab.
The Advanced tab hasn't changed its basic functionality much. It's still the place where you create very
specific rules for the firewall. The UI does now show you which rules are locked and not editable in the GUI,
a very welcome change from Panther's "surprise" mode for such things. The other changes here are controls for
"Stealth Mode". When enabled for TCP, UDP, or both, a computer attempting a connection on a closed port
doesn't get a failure message. Instead the packets for that port are dropped, and for all practical intents,
you don't exist. This is a nice addition to the security features of Tiger, since if a server isn't seen it's
much harder to attack. Even a negative answer is a positive answer if all you care about is the answer's
existence, and not the content.
Figure 2: The new Firewall Services tab
One welcome addition is not in Server Admin, but in the documentation for Network Services under Tiger,
where Apple gives you step-by-step instructions on how to reset your firewall back to the defaults, in case
you did something silly, like kill all external network access to your server. For a new admin, this is
something they will need, and having it documented is A Good Thing. Another change that may or may not be
welcome is the elimination of the sample command line rules from the IP Firewall Service documentation in the
Network Services manual. They're still documented, but are now part of the newer command line reference
Tiger's FTP service is, like FTP, essentially unchanged. The only "new" feature is that the FTP service
enforces ACL settings. Other than that, it's what it was in Panther.
The iChat server is however, completely new to Tiger, and has no analogue at all in Panther, so we don't
have to care about any changes. The iChat server in Tiger is not an AIM server, but rather Jabber server.
Jabber is, according to the Jabber organization, (at http://www.jabber.org/)...best known as "the Linux of
instant messaging" -- an open, secure, ad-free alternative to consumer IM services like AIM, ICQ, MSN, and
Yahoo. Jabber is also extensible, so, with a little work, you can use Jabber to talk to pretty much every IM
network on the planet.
Setting up the iChat server in Mac OS X is, for basic functionality, ridiculously simple. You set up the
Host domain, usually the DNS name of your server, set up a welcome message, and decide if you want to use SSL.
If you do, you select the certificate you want to use, save your settings and click the "Start Service"
button. That's it, you're now an iChat server. Jabber supports all the basic IM functions, but not every
client supports every function the same way.
Out of the box, iChat in Tiger can (obviously) hook up to an iChat Server. As long as you have an account
on the iChat Server, you can log into the iChat Server. You just create a new Jabber account to do so. When
using Jabber, there are some unique aspects of Jabber to be aware of. First, your Jabber userID looks like an
email address, and is shortusername@ichatserverjabberhostname So, if your short user name is jwelch and your
iChat server name is jabber.mactech.com, then the Jabber user ID is email@example.com. Since Jabber
doesn't support Kerberos as a standard feature, and there are, as a result, not a lot of Jabber clients that
support Kerberos, you can't use the iChat Server in a single-signon environment. What this means is that when
you're setting up Jabber clients, whether iChat or not, you're going to have to enter the password into that
setup, even though it's the same password you use in Tiger Server's single signon environment.
Figure 3: iChat Server Settings
Another caveat is that if you use iChat, the only version of iChat that supports the iChat server is
version 3.0, so if you're using an older version of iChat, you'll have to use a separate Jabber client to talk
to the iChat Server. While the iChat Server supports using SSL for security, it's not all encompassing. Only
the text conversations are encrypted. Your login session, file transfers, and any audio or video chats are not
encrypted. So if you need an extremely high security setting for IM, you're going to have to do that work
As I said before, not all Jabber clients support ever Jabber configuration the same. So sometimes, even a
really neat Jabber client won't work with every feature of iChat's Jabber implementation. For Windows and
Linux, the client I found that worked the best with the iChat Server was Psi,
was easy to set up, and supported file transfers well. PSI's interface is a bit too ICQ-ish for my tastes, but
it works well. Psi runs on Mac OS X/Windows/Linux, so if you want a "standard" environment, it's an option. It
supports GPG and PGP for file encryption, one way of dealing with the iChat Server's lack of security here. If
you want a pretty client for Windows/Linux, Gush, from 2entwine is an option. It doesn't support file
transfer, but it's very pretty, which is always nice.
For Palm device users, your best bet is Chatopus,
(http://www.chatopus.com/), which supports SSL
connections. (I wasn't able to test Chatopus since I don't have a Palm device. However, anyone wishing to send
me a Treo 650, feel free to do so, and I'll happily test it for you.)
For Pocket PC/Windows Mobile devices, I found imov,
be a good choice. It works well with iChat server, and in my tests on a Sprint PPC-6600, was easy to set up
and use, although file transfer isn't supported. This is probably not a major problem for most PDA/Smartphone
users. There are a number of clients for the Blackberry and Symbian devices, but I have no idea about which
ones work best. (Although like my Treo offer, if you want to send me a BlackBerry or a Sony p910/Nokia 93XX
device, I'll test it for you, no problem)
One thing the iChat Server doesn't do is automatically log the contents of IM conversations. This can be an
issue for companies in this day and age of Sarbanes-Oxley and other regulations. The only way I could find to
do this is a third party plugin, Bandersnatch, from Funky Penguin,
It's not a dead simple setup, but if you have the
need, and some basic MySQL skills, then it can log all iChat Server conversations. (This is one of those
things that can be used for good or evil, but there are cases where it's necessary, and in that case, you
either use it, or don't use iChat Server.)
While not new in Tiger, the Mail Service has been the recipient of a number of changes, fixes and new
features at almost every level. Two critical new features are the integration of SpamAssassin and ClamAV for
anti-spam and virus detection. While there are still no native Mac OS X viruses, and less than a handful of
trojans, when you run an email server, you don't know what platform is going to be connecting, so it's better
to have extra protection than not enough. Virtual Hosts are now supported in Server Admin, so you aren't
forced to the command line for this. This is something of no small importance to ISPs. Sieve scripting, for
creating server-side mail rules is supported in Tiger, and even documented. While you could implement Sieve in
Panther, you had to do it from third - party documentation. Server rules are an important part of enterprise
mail services, so it was important that Apple do more for things like Sieve.
For administrators with large email setups, you can now split mail stores across multiple partitions or
even remote filesystems mounted locally on the server, so that a single hard drive incident doesn't cause a
loss of service for your users, or so you can load - balance the storage duties of user email. Tiger's mail
service also supports the new Service ACLs, so you can have better control over who has access to the email
service on any given server. This can create some confusion as to what a given user can really do when you
have separate user account settings in Workgroup Manager for mail access. The simple rule of thumb is, if a
user has email service enabled either in Workgroup Manager or in the Mail SACL in Server Admin, then they have
access to Tiger Server's Email service. If you want to make sure a user doesn't have access, then they have to
be denied access in both locations.
With Tiger, you now have two options for email aliases. You can either use Workgroup Manager's ability to
create login aliases and use those for email aliases too, or create them manually in /etc/postfix/aliases. The
biggest difference between the two is that aliases created in Workgroup Manager won't work with Sieve scripts.
Yet Another New Tiger Email Feature is that you can now manage mail quota handling in Server Admin.
Postfix, Cyrus, and SquirrelMail are still used for SMTP, POP/IMAP, and Webmail respectively, so there's no
changes to the root servers that make up the email service beyond version numbers.
The Mail service module in Server Admin has been redesigned up and down to give Mail administrators more
power outside of the Command line. Along with this greater power, the Mail service documentation has been
extensively revamped and rewritten so that mail administrators can get a lot more use from Reading The Fine
Manual. The mailing list section alone goes into more detail in its first section than Panther's documentation
did for the entire mailing list entry, including solid information on what you use the web interface for as
opposed to Server Admin, a welcome change and an important improvement to Tiger Server.
As I've been noting, Server Admin's Mail Service module has been extensively revamped, to give the GUI the
kind of power that an email admin needs. Outside of new settings, there's a "Maintenance" panel, that allows
you to handle basic mail, well, maintenance functions. So things like the mail database repair function can be
run from Server Admin with a click. The Database tab here also allows you to view basic information on all the
mail stores a server is using, (important, since Tiger lets you have multiple mail stores in multiple
locations). Mail Queue management is another feature of Tiger, allowing you to view the current mail queues
and either delete or retry messages that are having problems. The Migration Tab allows you to import any Mac
OS X Server 10.1 or 10.2 mail databases from Server admin, giving you the option of migrating selected users
or every user.
Figure 4: Mail Database Maintenance tab
The Settings panel has a metric ton of new capabilities, all aimed at making the GUI more useful. In the
General tab, you can now set the mail server to deliver to /var/mail when you turn off POP and IMAP services.
This can be useful if you need to receive mail without delivering it, and not cause email to bounce. The
controls for enabling SMTP are also where you specify the domain and host names for the email server. Along
with enabling SMTP/POP/IMAP, you can now separately start or stop incoming and outgoing mail here. This is a
real convenience for everything from troubleshooting to dealing with network congestion problems.
The Relay tab is new, and has the functions of the "Filters" tab in Panther's Server Admin. With the
separate anti-spam and anti-virus capabilities of Tiger, and the fact that the settings in this tab are more
focused on relaying settings, adding this tab just makes for a more logical and more intuitive UI for
The Filters tab is now where you control your anti-spam and anti-virus settings. SpamAssassin's junk mail
score setting, accepted languages, locations, what to do with junkmail, how to handle it if you forward it are
all here. The Virus settings are pretty simple: Turn AV on/off, what to do with infected email, and who to
notify of infected email. You can also set the frequency of daily updates to your anti-spam and anti-virus
databases here. Once a day is probably the slowest you'd ever want to set this.
Figure 5: Mail Filters tab
The Quotas tab is a new feature in Tiger, and works with the Quota settings in Workgroup Manager. This is
where you set things like maximum incoming message size, and how to handle users near quota or over quota.
The Mailing List tab is unchanged, an island of familiarity in the newness of Tiger's admin tools. The
Logging tab adds detail level settings for the Junk Mail and AV features, along with finer control of the
logging levels for SMTP logs and POP/IMAP logs.
The Advanced tab is now split into three sections. The security section is where you set your
authentication methods for SMTP/POP/IMAP, and your SSL usage for SMTP and POP/IMAP. SSL usage now allows you
to specify the certificate used, instead of just the Use/Don't Use/Require settings in Panther. The Hosting
section is where the Virtual Domains and Virtual Host settings are contained. Finally, the Database section is
where you specify the mail database location, the main mail store location, and the location of any additional
Keep in mind that any command line options you used in Panther are still there. None of the GUI
improvements are coming at the expense of the UI. You just now have a better GUI to use along with the command
line if you want.
Like FTP and AFP, Network Address Translation hasn't changed much in concept or practice in a while. Server
Admin in Tiger adds the convenience of being able to set the NAT service to just act as an IP Forwarder, or to
perform IP Forwarding and NAT.
While Tiger doesn't do anything radical to NetBoot/Netinstall, there are some small, yet welcome changes.
The number of AFP connections has been increased to whatever the resources on your server limit it to, nice
for those administrators with high-powered setups. Network install images can now be created as block - copy
images instead of file - copy images, which result in much faster installation speeds. The previous
command-line only option for setting up images on remote servers is now a part of the GUI tools. Images can
now be created with Directory Services settings configured in the image, so that as soon as the machine boots,
it's configured correctly without needing to use the DHCP LDAP settings. (You could do this in Panther, but
you had to copy /Library/Preferences/DirectoryServices/ from the machine you were creating the image from to
the image. In Tiger, this is integrated into the toolset.)
Since so much of NetBoot/NetInstall revolves around image creation, we should start with a look at the new
features in the System Image Utility, formerly the Network Image Utility. One thing administrators will
notice right off is what's missing: Information on creating Mac OS 9 boot images. Considering how dead OS 9 is
to Apple, along with the fact that Intel - based Macs can't run Classic, much less boot OS 9, this is no
surprise, but it means that if you still need to create new OS 9 install images, you should consider keeping a
machine running Panther Server around.
The basic functions of the System Image Utility haven't changed, but the implementation has been expanded
somewhat. You can now explicitly assign the protocol to use to serve the image, although NFS is the preferred
method still. You can, as I said earlier set up a machine as an image server and let NetBoot serve from there.
You have to create the image locally, and manually copy it to the specified location, but once it's there, you
can serve it from there. While this would seem to make it an ideal candidate for an Xsan and a few front end
Xserves, that's not the type of use an Xsan's optimized for. That's not to say you physically cannot do it,
but you would really want to test this out first before buying the gear. A new option for install images is
the "Change ByHost preferences to match client after install" feature, which allows administrators to create
ByHost preferences, (preferences tied to the Media Access Control, or MAC number of the main network interface
card.) This takes the ByHost of the image source, and when pushed down to the client, will change the
preference to match the client. Considering that preferences like screensaver settings, iTunes settings, .Mac
and Classic settings, et al use ByHost, this saves a lot of work on the back end of the install for
One new trick that rates high on my "cool list" is the Model Filter setting for both install and boot
images. This allows you to tie an image to specific models of Mac. This is very important in situations where
you have different images for portables versus desktops. This avoids someone accidentally or deliberately
installing the wrong image on a type of hardware that you don't want it installed on.
Figure 6: System Image Utility Model Filter tab
Another problem that Tiger makes easier to solve is naming imaged machines. If you have to image a dozen or
so machines, giving them all unique sharing names can be tedious. Tiger's System Image Utility gives you two
options right in the UI for doing this. If you want them all to have the same name, with the MAC address
grafted on then you just enter that name (sans MAC address) in the "Computer Name" field in the "Sharing
Prefs" tab for boot or install images. If you leave it blank, then they either get -AUTOMATIC- or DNS names
from the network based on their IP address. You can also create a tab-delimited text file that has the desired
name for each machine and the corresponding MAC address, and tell the System Image utility where the file is
in the "File Path" field. When you image the machines, if they have a MAC address that's on the list, they get
the name you give them. If they don't have an address in the list, then they get the name from the setting in
Once you've created the image, then you can use some of the new tricks in the NetBoot service to make
managing them easier. One thing administrators love is information on our servers. We love knowing all the
details, and we hate having to spend a lot of time sussing them out. Server Admin in Tiger does that for
NetBoot far better than Panther did. The first screen in the NetBoot service tells you which images are
enabled, and if the necessary protocols are running for each type of image, (AFP/NFS/HTTP/DHCP).
Monitoring NetBoot clients is easier with Tiger too, as you get, in addition to all the info that Panther
provided, information like the System Type of the client, handy if you have a couple thousand machines and
haven't yet memorized every detail of every system.
The settings haven't changed much. You can set the maximum number of AFP connections, you can have Server
Admin look up MAC addresses for you based on the client's IP address or DNS name, and you can set the logging
Tiger's NFS service is generally unchanged from Panther's. If you want to do more than turn it on/off,
select the number of daemons, and the connection type, you're going to need to use the command line and become
one with the various NFS books.
Open Directory Service
There are many, many changes in Open Directory, especially in the areas of Windows integration, and they
are both welcome, and needed. Open Directory is literally the heart of Mac OS X Server. Every service, every
feature at some point deals with Open Directory, so improvements here ripple out into every other part of
Tiger Server. However, it's important to remember that Open Directory, (OD) isn't just one thing. It's not
like Microsoft's Active Directory, which is a single, albeit, complex product. Open Directory is more of a
collection of technologies, integrated so that they all work together for Mac administrators. By default, Open
Directory is primarily OpenLDAP on a BerkeleyDB datastore, with a MIT Kerberos Domain Controller for primary
authentication and Single-Signon.
But OD is not just that. In fact, it's really nothing more than a container. LDAPv3, NetInfo, Active
Directory, NIS, etc. are all just plugins to OD. Apple provides a base set of plugins with Tiger, including:
Active Directory, AppleTalk, Bonjour (nee Rendezvous), BSD Flat Files & NIS, LDAPv3, NetInfo, SLP, and
SMB/CIFS. You can also get a number of third party plugins that add features, like direct support for Novell's
eDirectory, or provide additional features for things like Active Directory that Apple's plugins don't give
With Tiger Server, Apple has further refined Open Directory so that it provides not just improved features,
but better security as well. Improvements include things like Trusted LDAPv3 binding, where not only does your
system have to authenticate to the server, the server has to prove it's the right server to your system. This
is a critical feature, one that makes using directory services a much more secure proposition. With this, and
the various features in Mac OS X 10.4 Server, such as Kerberos signing and SSL encryption of Open Directory
server communications to the client, doing things like creating a bogus Open Directory Master is effectively
impossible, since the server will be unable to authenticate itself to the client. (If the only authentication
is client to server, then creating a bogus server that can root your clients is much simpler. It's not child's
play, but it gets a lot easier.) Now, if you implement Trusted binding, then you can't use the DHCP discovery
of Open Directory Masters, but until there's a standard for trusted DHCP, that option isn't a great idea
anyway. The only reason to use the DHCP Option 95 LDAP server discovery was so that you didn't have to set up
directory bindings on each client. However, since the new NetBoot/Netinstall features in Mac OS X 10.4 take
care of this, that's no longer as much of an issue.
Active Directory integration is much better, thanks not only to ACLs, but also to support for using AD info
for home directories, and better directory information mapping between OD and Active Directory. Along with
that, many of the options for Active Directory that were formerly only accessible via the dsconfigad command
line tool are now in the UI. Binding a Tiger Server to an Active Directory realm is far simpler, and finally
gives you the benefits that it should have in Panther. You can store the LDAP scheme in the directory for
convenience, and improved replication.
Looking at the new Directory Access application, in /Applications/Utilities/ there's some obvious changes,
mainly the renaming of "Rendezvous" to "Bonjour", which keeps Tibco off of Apple's back, and still keeps the
company's Francophilism firmly intact. (Personally, I thought Achtung! would have been better, but only if
Apple also bought the rights to "Hogan's Heros")
The Active Directory plugin, now at version 1.5, as I said earlier, has had a GUI revamp. Options that were
previously only settable or readable from the command line are now in the GUI, such as the mount style for
network home locations and whether to force local home directories. New options allow you to set the default
shell for a user, more fine-grained control over attribute mapping, using the UNC path in Active Directory
settings for a user to set the network home directory location, and a much nicer UI for entering in Active
Directory administrative groups. AppleTalk is still the same, and like before, only controls your ability to
browse via Appletalk protocols. (AFP file transfer in Mac OS X 10.4 should be assumed to be AFP over TCP/IP
Figure 7: Directory Access Active
The BSD Flat File and NIS plugin has received only minor adjustments, but as that is clearly a legacy
technology to Apple, this isn't surprising.
Bonjour/nee Rendezvous Service Discovery is now permanently on in Directory Access. If you want to disable
that, you can't do it from the GUI. Note that this is not enabling/disabling all the Zeroconf technologies
that Bonjour encompasses, just the ability to find other Bonjour services.
Given all the changes in Mac OS X 10.4 Server's Open Directory infrastructure, one would expect that the
GUI for LDAPv3 in Mac OS X 10.4 to have radically changed. But it hasn't, instead getting some minimal changes
to improve usability and account for new features. Setting up an LDAP server is more automated, and the UI for
options is clearer. For example the initial screen when you add a new server lets you set up SSL,
authentication and contact options right away. The manual options have new features as well.
Figure 8: Adding an LDAP server to
The Connection tab now lets you set rebind attempt periods and idle timeouts, and gives you the option to
ignore server referrals, (Server referrals are where the LDAP server you connect to can tell you to look on
other LDAP servers for different information. If you have a lot of referrals or a wonky network, this can
greatly increase your login time.) or use LDAPv2 in read only mode.
The Search & Mappings tab adds the ability to save custom mappings out as a template so you can get to them
easier next time you need to.
The Security tab is new to Mac OS X 10.4, and incorporates the "Use authentication when connecting" option
in Panther's Connection tab, but adds in the new options for the trusted binding options. Within the new
Security Policy options, you can avoid rogue LDAP servers compromising your network. The new options are:
- Disable clear text passwords: This one's obvious. It means that you can't use unencrypted passwords to
communicate with the LDAP server. From a security POV, this one should be a default.
- Digitally sign all packets (requires Kerberos): If you are using a wide area LDAP implementation, this
option is critical. It allows you to ensure that the packet you get is the packet that was sent, unmodified
and unmolested. If the packet is changed enroute, then the digital signature will be wrong, and the packet
won't be accepted. This option requires that you use Kerberos.
- Encrypt all packets (requires SSL or Kerberos): Again, fairly obvious, and goes along with disabling clear
text passwords. This ensures that all data between client and directory server is encrypted.
- Block man-in-the-middle attacks (requires Kerberos): This option works with the digital signing option to
prevent someone from setting up a rogue server posing as an LDAP domain controller.
Note that you can override any of these options at the server level, which is always a good idea on a managed network.
Figure 9: Directory Access LDAP options
I know that some of you are thinking "Well, I've got a really good firewall, why should I worry?" Firewalls
aren't magic. For example, do you require every machine on your network to meet a specific security profile
before it can use your network? If so, how do you force that? You can do this with Windows, but Mac OS X
support for this kind of thing is still as yet unimplemented. A single badly configured machine inside the
firewall can leave you open to attack. Firewalls also don't do much about disgruntled/paid off employees. This
is not to say that firewalls are not good, useful things, but that they are only a part of a good security
policy. Avoiding unencrypted, unsigned data transmissions wherever possible only enhances your security, and
gives you additional layers of protection.
Server Admin has new features to make a Mac administrator smile as well. The Log tab in Server Admin's Open
Directory settings in Mac OS X 10.4 Server adds in the kadmin & kdc kerberos logs, a Password Service
Replication log, and slapconfig log. This helps answer one of the most frustrating things about Mac OS X 10.3
Server. Logs are the best way an administrator has to troubleshoot problems on their network. The fact that
Mac OS X 10.3 didn't log Kerberos - specific events by default was one of the most frustrating things about
that version. Kerberos troubleshooting can be extremely tricky on a good day, and no logs are not the way to a
good day by any definition. There's also a search/spotlight window built into the Log tab, (indeed, it's in
all the Log tabs in Server Admin), which allows you to filter a log for specific conditions. Another new, and
very welcome application - wide change in Server Admin is the inclusion of the path to the log you're viewing,
so if you want to look at a log outside of Server Admin, finding the specific log file is much simpler.
The Archive tab is a new Mac OS X 10.4 feature for Server Admin. It allows you to quickly back up and
restore Open Directory Master settings, including:
- LDAP directory database and configuration files
- Open Directory Password Server database
- Kerberos database and configuration files
- Local NetInfo domain and shadow password database
This is designed as a supplement to using a proper Open Directory replica setup, or in cases where replicas
are not possible or practical.
The Settings tab has gained new capabilities, particularly with regard to security and joining other
directory systems. In my tests, joining a Windows 2000 Active Directory realm was a three or four - click
process in Server Admin, and about 3 minutes in Directory Access and you were done. Once you've finished that,
it just works, no fuss, no muss, with far less pain than Mac OS X 10.3, and thanks to new Windows features and
ACLs, you get a much nicer level of integration than ever before. The "Authentication" pane in Settings is now
"Policy, and has three sections. The "Policy" section is much the same as it was in Mac OS X 10.3. The binding
settings are about the same as in Directory Access, however they will override client Directory Access
settings. You can also disallow binding if need be. Finally, the "Security" pane allows you to set various
security methods. Before you go shutting things off or turning things on here, you'll want to be very careful
to make sure that you aren't accidentally killing access for clients that can't use the settings you want. A
network that can't be used may be secure, but it's also useless.
Figure 10: Open Directory Server
One final note: Apple has released a new Open Directory manual that clocks in at over 242 pages. Even if
you have been running Open Directory for a while now, read it, take notes, annotate the PDF. A couple days of
planning in this manual, and the other manuals available on the Mac OS X 10.4 Server Documentation page can
save you months of pain down the line. I also highly urge you, if possible, to take Apple's server classes,
which should already be updated for Mac OS X 10.4. They aren't cheap, but the time you save will more than
make up for the cost of the class within months, which is not a bad ROI at all.
Considering that Mac OS X 10.3 Server's print service was, to be kind, suboptimal, almost any improvement
in Mac OS X 10.4 is welcome. The big news is that instead of ignoring CUPS, (version 1.1.23 in Mac OS X 10.4
Server, from Mac OS X 10.3 Server's 1.1.20) at all but the lowest levels, ala Mac OS X 10.3, Mac OS X 10.4
Server is integrated with CUPs pretty much from to to bottom. This pays off in a number of ways, such as
sharing via IPP and better logging, (the CUPS logs are actually useful now). You can set cover sheets in
Server Admin, (although custom cover sheets still require some work in CUPS, to create custom sheets and get
them in the right spot.).
Another bonus to having the print service better integrated with CUPS is that it makes it easier to use
CUPS for the settings that Server Admin or the Apple command line tools don't handle. So, if you want to go
beyond what Server Admin gives you, or you want to use different CUPS features, it's a much nicer time to do
There's still a couple of annoyances here, such as the only support for authenticated printing in Server
Admin is still only via SMB. You can do authenticated printing with CUPS and IPP, but it should be in the
Server Admin UI too. Adding shared printers and queues to Open Directory is still a manual operation, which is
puzzling. Using Open Directory to manage printers is something that should be automatic. The printer entries
should be created as you set them up in Server Admin. Open Directory Printers have to be LPR queues, another
annoyance. Bonjour printing is LPR only, however, finding IPP printers shared by Mac OS X 10.4 Server from a
Mac OS X 10.4 client is pretty braindead, (They show up in the Printer Browser that comes up when you click
"Add" in Printer Setup Utility with a connection type of "Shared Printer"), so it's not as big of an annoyance
as it could be. While you can't auto-download Windows client print drivers by default, setting this up is
pretty straightforward (and I go over it in the Windows Services section), so Mac OS X 10.4 is a much nicer
Windows client print server too. The UI in Server Admin hasn't changed noticeably, other than the
aforementioned Cover Sheet and IPP additions. Most of the changes here are under the surface.
QuickTime Streaming Service
While there are a ton of changes in QuickTime itself, hence QuickTime 7, the QuickTime Streaming Server
tools having changed as much from Mac OS X 10.3. The biggest changes are to reflect new features in QuickTime,
such as H.264, HD Streaming and 3GPP features. The Server Admin UI is about the same as in Mac OS X 10.3, as
is the QuickTime Streaming Server Web UI.
QTSS Publisher has had some work done on its UI, mostly to support ease of use and user home directory
streaming. There is one big change, and it is not only welcome, but fits the workflow of QTSS Publisher
perfectly: AppleScript. QTSS Publisher joins Server Admin and the Gateway Setup Assistant as the only server
administration applications from Apple with AppleScript implementations, and QTSS Publisher's is by far the
best thought-out and most useful. This is a refreshing change from the first generation AppleScript
dictionaries seen of late from Apple, (I'm thinking of Keynote and GarageBand in particular), which are mostly
read - only, and of not a great amount of real use. The QTSS Publisher dictionary is full-featured and looks
to have been created by folks who not only know what AppleScript can do, but have used AppleScript themselves.
The terms are explained, and looking at the object model in Script Debugger's browser, it looks clean and
neat. Good job folks!
Figure 11: QTSS Publisher
Software Update Service
The first thing that must be said about the new Software Update service is best quoted from the Mac OS X
10.4 Server documentation:
Note: You can't use Software Update service to provide third-party software updates.
The second thing that must be said about Software Update service, also from the Software Update service
You can't make your own Software Update packages. For security considerations and to protect attackers from
faking packages, the Software Update package installer won't install a package unless it's signed by Apple. In
addition, Software Update service will work only with the new package format supported in Mac OS X Server
v10.4 or later.
The right or wrong of these items is best left to debate elsewhere, but as of Mac OS X 10.4.0, Software
Update service is only for Apple Software Updates, and only for software updates using the new Mac OS X 10.4
package format created by and signed by Apple.
When you connect to Apple's main update servers with your own Software Update service server, Apple does
collect the following data from your server:
So Apple's not doing any deep, evil data mining on your Software Update service server. Having said that,
Software Update service is not useless by a long shot. If you have 100 machines, or even ten machines, a way
to ensure that your clients only get the updates you approve and don't all have to go out on the Internet to
get them is A Good Thing. Yes, you can do this with Apple Remote Desktop, but that's a manual process, and
doesn't allow you to assign Software Update service servers to specific clients. It also allows you to better
compensate for revoked updates, that Apple may pull for a variety of reasons, since those packages are not
presented to users. So, while Software Update service isn't everything, it's better than nothing.
Clients must be running Mac OS X 10.4, which is a bit of annoyance for system administrators who were
hoping to use this without having to upgrade their clients to Mac OS X 10.4. As well, you'll want to think
about capacity planning well, since pushing out a 50MB update to 500 clients on a 100MB line will make your
network cry. If you have a large number of clients, you'll want to consider multiple Software Update service
servers, and use Workgroup Manager to assign groups of clients to specific servers.
Looking at Software Update service in Server Admin, you have the Overview Tab, which allows you to see the
current status of Software Update service, such as last check, the number of updates that are Mirroredor
copied and stored locally for clients, and the number of updates that are Enabled, or made available to
clients. You also get the status of the Auto-Mirror and Auto-Enable functions.The Log tab shows you the
current contents of the Software Update service log.
The Settings tab has two parts. The first part, "General" allows you to enable or disable automatic
mirroring and automatic enabling. Note that the auto-enable is a binary setting. It's on or off, there's no
"only on for some updates". You can limit bandwidth between the Software Update service server and client
Macs, and you specify the port you're going to provide the updates on here as well. The "Updates" tab shows
you the updates you are currently mirroring and their status.
I will agree that Software Update service is not a complete, full solution for Enterprise IT needs by a
long shot, but it can help you manage Apple updates a lot better than was previously possible. That's a win,
even if it isn't everything it should be.
This has not changed by huge amounts from Mac OS X 10.3 Server. In Mac OS X 10.4's Server Admin, there are
new options for LT2P, such as being able to user MS-CHAPv2 or Kerberos Authentication, and you set the IPSec
authentication options for L2TP to either shared secret or SSL Certificates. PPTP is unchanged in Server
Admin. Logging and Client Information options remain unchanged from Mac OS X 10.3 Server.
Unsurprisingly, the web services in Mac OS X 10.4 Server have their share of updates, the most obvious one
being the new Weblog functionality, based on Blojsom, the java - based weblog software. The weblog service
gives you fire and forget weblog setup, however, if you're looking for something that gives you point & click
functionality on a par with a standard Blojsom install, or MovableType, you'll not be terribly happy with Mac
OS X 10.4's implementation. But, if you're looking for a weblog that would be good for smaller children, or
you want a simple, basic weblog, then Mac OS X 10.4's weblog is great for that. One thing that is important to
note if you plan on hosting multiple sites from a single server: If you turn on weblogs, they're on for every
site on your server so be careful there. Finally, using the Weblog service with clients like ecto is far more
tedious to set up than it should be.
Figure 12: Weblog Settings
There are new authentication options for Apache, most notably Kerberos via Microsoft's SPNEGO protocol. So
you can now user Kerberos authentication for not just web pages, but for realms as well. SSL support in Mac OS
X 10.4 Server supports SSLv2, SSLv3, and TLSv1, although not every other application is guaranteed to support
these versions. The primary version of Apache in Server is at 1.3.33. Apache 2 is provided for testing, in
/opt/apache2/. Like every other service on Mac OS X 10.4 Server, Web Services support SACLS.
As we noted earlier, SSL certificate handling is better at all levels, including web services. The way that
Apple has made using SSL in the various services in Mac OS X 10.4 Server will make the use of more secure
websites much more prevalent.
The performance cache is still in Mac OS X 10.4 Server, but has changed its behavior somewhat, in that you
no longer have to keep port 16080 open, since Apache in Mac OS X 10.4 Server handles the performance cache a
little more gracefully. If you need to use SSL or Keep-Alive, you can't use the performance cache, and any
request containing cookie headers will not have its responses cached. You'll also want to disable the cache
for any sites with WebDAV enabled; as it can conflict with uploads.
You can set up search pages in Mac OS X 10.4 Server that can talk to Spotlight. While Spotlight is disabled
by default on Server, you can turn it on by changing the Spotlight line in /etc/hostconfig from SPOTLIGHT=-NO-
to SPOTLIGHT=-YES-, then start the Spotlight metadata process with sudo SystemStarter start "MetaData Search",
or restart the Server. From there, you have to set up the searches for the site/pages, but this is all
explained in the Web Technologies Admin Guide from Apple.
WebMail in Mac OS X 10.4 Server is still SquirrelMail, version 1.4.1.
Server Admin hasn't changed much with Mac OS X 10.4 Server, mostly just to handle some of the new features.
The "General" area in the Settings now has controls for Allow Persistent Connections, so you can set the
number of persistent connections and their timeouts. The "Weblogs" area has all the settings for the Weblog
service, which consist of: Enable/Disable Weblogs, set the Default Theme, set the Weblog folder, and the Email
domain for emails generated by the Weblog(s). Like I said, it's there, and it's easy. Sophisticated it ain't.
The "Sites" area has had the most changes overall. The Options pane now has a specific Server-Side Include
(SSI) setting, and the order has changed. As I said earlier, realms can now use Kerberos authentication, which
also requires SSL, and this is in Realms pane. The Security pane has changed to reflect the new SSL
integration, like everything else in Server Admin. Finally, the Aliases pane now has different settings for
Web Server aliases vs. URL Aliases and Redirects.
The WebObjects service is new in Mac OS X 10.4 Server, although WebObjects is hardly new to Mac OS X. Since
all this service does is control the WebObjects application server, there's not much to do with it in Server
Admin, nor would there be, since WebObjects is more the realm of Xcode. You can get an overview of what's
going on with WebObjects if it's running, and you can set the ports that the WebObjects Monitor, and the
wotaskd process run on. You can also enable/disable the monitor.
In a stunning surprise, nothing has changed for Windows services...no, I'm lying, but I'm also running out
of ways to say "There's been a lot of changes to . But, once again, there's a lot of new features in
the Windows Services in Mac OS X 10.4, and they're stuff that I missed dearly in Mac OS X 10.3.
For sysadmins who aren't using Active Directory, but want to migrate their domains off of Windows NT 4, Mac
OS X 10.4 Server supports Backup Domain Controller, (BDC) functionality along with the Primary Domain
Controller, (PDC) functions in Mac OS X 10.3 Server. This requires you, (somewhat obviously) to set up the PDC
Mac as an Open Directory Master, and the BDC Mac(s) as Open Directory Replicas. All the information is then
stored in Open Directory's LDAP store. One thing to note here, since this is for NT4 domains, not Active
Directory realms, you have to deal with NetBIOS name restrictions for your network. Machine names should be no
more than 15 characters, no special characters or punctuation. This is also a good policy for SMB shares in an
Mac OS X 10.4 Server is now able to be an Active Directory member server with greater ease and better
reliability than before. As I mentioned in the Open Directory section, the setup for this is much simpler and
more reliable than in Mac OS X 10.3 Server, and thanks to the ACL support in Mac OS X 10.4 Server, dealing
with permissions is far simpler. Thanks to Apple using Windows - compatible semantics in Mac OS X 10.4 Server,
you can change ACLs from a Windows box, a plus for people managing AD networks with Macs. Thanks to ACLs, you
can finally have nested Windows or Mac groups with access to a share or service, and not run into Unix
permissions problems, or the 16 - group limit that Unix permissions forced on you. As with the other services
in Mac OS X 10.4 Server, you can also use SACLs to restrict access to the service itself.
Mac OS X 10.4 Server's file locking is improved, so if you enable strict locking for any SMB shares, you
should be able to avoid some of the file locking issues that were a problem in Mac OS X 10.3 Server when you
had people hitting the same file with different protocols. While Mac OS X 10.4 Server does support oplocks for
SMB shares, you should only use those if Windows clients are the only machines that will be using that share.
On the authentication side, Mac OS X 10.4 Server now supports NTLMv2 and Kerberos for Windows clients. It
also supports using Kerberos for Macs accessing other Windows shares, so Mac OS X 10.4 users get Single-Signon
for SMB too. As we'll see, you can force NTLMv2 and Kerberos authentication for clients connecting to Mac OS X
10.4 Server, but you should be careful of doing that if you have older Windows boxes, since you have to be
running Windows 98 or greater to use NTLMv2 & Kerberos.
Figure 13: Windows Access Settings
One benefit to all of this is that using Mac OS X 10.4 Server to host roaming profiles, the Windows version
of Mac OS X 10.4 Server's mobile home directories is much easier than it was in Mac OS X 10.3 Server. One
caveat with roaming profiles: If you're going to use them for Windows clients, you have to be rather
hard-nosed about profile size quotas. With Windows, a Roaming Profile downloads to the client on login, and
uploads from the client at logout. If you have a large profile size, (mine is about a GB and a half or so),
login and logout on anything but a very fast network can take a long, long, long, time. Enough to where people
will think something crashed. Watch your sizes on roaming profiles.
As before with Mac OS X 10.3 Server, Mac OS X 10.4 Server is able to act as a print server for Windows
boxes, and can even provide automatic driver download for Windows clients, so they don't have to worry about
installing drivers when printing to a Mac OS X 10.4 Server print queue. While the basic documentation is
available on the Samba site, as it turns out, doing this in Mac OS X 10.4 Server is a good deal simpler than
the Samba howtos show:
1. Add the printer you want shared to Mac OS X Server via Printer Setup Utility
2. Share it out in Server Admin via IPP and SMB (Win2000 and later can use IPP too, but SMB is much easier
to use here for a number of reasons. IPP is just better for your Mac clients, but if you won't have any
needing to get to this printer, then you can just use SMB)
3. In Workgroup Manager, (WGM) create a share with an SMB name of print$. It must have that exact name as
the share name in WGM for SMB sharing, as this is hardcoded into Windows 2000/XP for this function. Make sure
you set up the proper ACLs for it, at least giving Domain and Enterprise Admins full control. This is one case
where you really want to be one with ACLs, it will make life much easier for windows users and administrators.
4. Create the following subdirectories in print$ in WGM
a. W32X86 for NT/2000/XP
b. WIN40 for 9X/ME (Note: The procedure I'm detailing only works for Windows NT/2000/XP clients. You can set it up
for 9X clients, but it's much more tedious, and those machines are a bigger hindrance than a help anyway)
From a Windows 2000/XP machine, navigate to the "Printers and Faxes" share on the Mac server, and select
"Properties" on the printer you want
a. When asked to install the driver select "No"
b. In the Advanced tab, click "New Driver..."
c. Run the Add Printer Driver Wizard (note, if run from an XP machine, this only installs drivers for NT/2000/XP, NOT 9X)
d. The drivers actually install into the "3" subdirectory in the W32X86 directory (There's a long explanation of why,
has to do with earlier versions of NT print drivers living in the kernel. In Windows 2000 and later they aren't.
This is all handled automatically for you. )
e. Configure the standard settings on the printer. Note that device settings will be pre-set this way, but not
print job settings, even though you can set them here.
6. Add the printers to the clients either via the printer wizard, or just connecting to them in "Network Places".
That should do it. You can also publish OS X Server's printers in Active Directory via the Active Directory
tools, a good idea, since it allows you to just search AD for them. (AD's printer search is pretty weak, but
that's MS's problem) One reason why I recommend ACLs here is that they're a better way to lock down access to
a printer, and you can do this from AD tools, which are still a lot nicer to deal with than OD tools. As with
computer and share names, watch the 15 - character limit for print share names.
As far as Server Admin goes, there aren't a lot changes. The Overview tab no longer shows you the logging
status. In the Settings tab, the "General" panel adds an option to set up your server as a BDC, and shows you
the name of the Active Directory realm if you're joined to one. The "Settings" pane now has a selector for
Authentication options: NTLMv2 & Kerberos, NTLM, and LAN Manager. You can select these in any combination you
Xgrid is Apple's implementation of Grid Computing. Grid computing is a lot of things to a lot of people,
but at it's heart, it's just a way to split a task or group of tasks up between multiple computers. Xgrid is
not, however, a magic "Make it faster" spell. The job has to be designed for multiple computers to work on.
3-D Rendering, ala Pixar is an example of a job type that can benefit from Xgrid. Burning a DVD is an example
of a job type that won't benefit from Xgrid. Grid computing is very big in the scientific community, where
jobs are easily set up to benefit from Xgrid or similar implementations. (SETI@Home is an early grid computing
Within Xgrid, you have a controller, a client, and an agent. The client submits the task to the controller,
which then parcels out the job to a grid, which contains multiple agents. (Yes, you probably could have a
single-agent grid, but what's the point?). Apple has two pieces of software that ship with Mac OS X 10.4
Server to help you with Xgrid. The first is the Xgrid Admin utility, the management utility for your grids,
which allows you to set up a machine as a controller, and control which grids run which jobs on which agents.
Note that while you can have multiple grids run by a single controller, you can only have an agent in a single
grid at a time, and a job can only run on one grid at a time. You also can't move an agent between grids while
it's running a job, nor can you move a running job between grids.
To avoid problems with rogue agents, there are three levels of security in Xgrid. The highest is Kerberos
authentication, which uses Open Directory's Single-Signon to handle authentication. Then there's Password,
where you set a single password on the agents, and then set up the controllers and the clients with that same
password. There's also no security at all, but that's a bad idea for many reasons. Many, many, reasons.
Within Server Admin, the controls for the Xgrid Service are pretty simple. The Agent Tab allows you to set
up the server as an agent, decide how you want to pick your controller, and which controller to connect to if
you're picking a specific controller. You can also set how you accept tasks, and what type of controller
authentication you want to use. The Controller tab lets you set up that server as a controller, and set up the
client and agent authentication types you want to use.
You can have a single server acting as an agent and a controller, (and a client too, for that matter), but
it's not a great way to get maximum performance. Note that job submission is done by the xgrid command line
utility, but if you're using Xgrid, the command line is not going to be anything to worry about.
If you think this is it, well, you're wrong, but unless you want this issue of MacTech to be the "John C.
Welch Memorial Issue", we'll end this month's column here. Next month, we'll take a look at Mac OS X 10.4
Server from the Workgroup Manager POV.
Bibliography and References
Almost everything in this article can be found in Apple's Server Documentation, at
What little isn't there, I pried from the ridiculously busy
brains of people like Schoun Regan of I.T. Instruction, Michael Bartosh of 4am Media, and Joel Rennich of
AFP548.com. Schoun and Michael are the authors of the two best books on Mac OS X Server available, the Visual
Quickstart Guide to Mac OS X Server, and Essential Mac OS X Server Administration, respectively. Buy them
both, they're great books. If you read any of my columns and don't regularly read AFP548.com, then you're
missing out on a fantastic resource. All three of these guys, Schoun, Michael, and Joel are Apple Trainers
too, a great reason to take the Apple courses if you haven't yet. Those courses are taught by some of the best
folks in the Mac market, and well worth the cost.
John Welch (firstname.lastname@example.org) is the Unix/Open
Systems Admin for Kansas City Life Insurance, a Technical Strategist for Provar, (http://www.provar.com/) and the Chief Know-It-All for TackyShirt,
(http://www.tackyshirt.com/). He has over fifteen years of
experience at making Macs work with other computer systems. John specializes in figuring out ways
in which to make the Mac do what nobody thinks it can, showing that the Mac is a superior
administrative platform, and teaching others how to use it in interesting, if sometimes frightening
ways. He also does things that don't involve computertry on occasion, or at least that's the rumor.