Master Open Directory — Part 1

It can control your company’s user accounts, their password policies and preferences. It allows access to home directories from anywhere on the network, and mirror that data safely to your server. It forms the basis for features like shared calendaring and contacts, single sign-on to computing resources, and enterprise-level security for all your network services. In the past, Open Directory may have been Apple’s best-kept secret, but it’s now the essential element of business-class Macintosh deployment.

System administrators rely on services like Open Directory to keep down per-person support costs and prevent the need for repetitive tasks and individual maintenance. For users, however, Open Directory finally delivers on the promise of a Macintosh corporate network that “just works”. In this two-part series, we'll make that happen.

Configure DNS For Open Directory:

Like anything designed to look effortless, Open Directory implementation depends on a series of precise and carefully preformed steps. In the event of an error, most of those steps can be retraced, but having flawless Domain Name Service is essential to a successful Open Directory deployment. Improperly configured DNS isn’t just the reason Open Directory can fail at the very start, it’s most often the reason it fails during or even after the job is completed.

The most important determination to make is how DNS is controlled in your individual environment. If this is someone else’s responsibility and has been pre-configured, you’ll need to coordinate with them to be sure their name servers provide both forward and reverse listings for your planned Open Directory server. You can test this by opening the Terminal and typing:

nslookup HOSTNAME

Here HOSTNAME is replaced by the fully-qualified domain name of your server, such as server.makemacwork.com. This should return the IP address of the machine in question, without any error messages. Now repeat the test, replacing IP below with the IP address you just received:

nslookup IP

If reverse lookups are operating properly, the command will return the hostname you began with. If not, you’ll have to find a way to get it reconfigured, or take on the responsibility of configuring it yourself. If it’s your job to set up Open Directory, the authoritative server for your domain should likely be under your control.

To configure DNS for Open Directory, launch Server Admin, and select your server from the column to the left. Choose the “Settings” button on the top right (represented by the gear icon), then the “Services” pane from the far right of the top strip of buttons. Check the box marking “DNS”, then click “Save” at the bottom of the window.

Now select “DNS” below your server on the far left, and choose the “Zones” button (represented by the network globe) across the top. This is where you’ll build a very short listing of the domains for which the your server offers domain name service. Find the row marked “Primary Zone” and double-click the domain name. By default this will be example.com, but you’ll change it to your own domain. Likewise, below it is a single “Machine” listing named ns. Change this to the name of the machine you’re editing, making sure that the “Nameservers” list in the primary zone matches.

If the server you’re configuring will be the primary name server for your internal domain, it’s best to have the service configured on a secondary machine as well, providing uninterrupted and redundant service. With the configuration completed, you can push the “Start DNS” button at the bottom of the window.

Before you move on, open the “Network” pane in the System Preferences. Confirm the network settings are manually configured and add the server’s own IP to the “DNS Server” listing (in front of any external IPs) and your Open Directory domain name to the “Search Domains” field. Now open the Terminal one last time and type:

hostname

If you get a fully-qualified response which includes your domain name, the server is properly identifying itself. If you receive a name ending in “.local”, then the DNS is improperly configured and needs to be repaired before proceeding to the next stage.

Deploy The Open Directory Service:

Now that you’ve laid the groundwork with DNS, return to the service “Settings” in Server Admin, check the box for Open Directory, and save. This will bring you to the first configuration pane, reading "Role: Standalone Server". Click the "Change..." button and you'll be prompted to choose an Open Directory configuration. For basic set up, select "Open Directory Master" and hit "Continue".

The Open Directory assistant will ask you to create a new user specifically to administer the network directory domain. By default, the username is diradmin and the UID is 1000, but you can change these to whatever best fits your existing management scheme. Once the directory service is in place, the right to administer it can be assigned to an existing user or divided amongst your management team.

The next window assigns both the Kerberos Realm (which controls the Open Directory security components) and the Search Base for your master domain. These should both fill in automatically. The realm is identical to your fully qualified host name, and should appear in capital letters. The search base is identical, except that each period is replaced by "dc=", defining each portion of the name as a domain component. Double-check the information is correct and hit "Continue". The assistant should confirm that your server has been promoted to an Open Directory Master.

With this foundation is in place, you can begin building on Open Directory to take control of your Macintosh network.

Next week in part two, we'll secure Open Directory to restrict access, migrate user accounts to the directory service, and configure your machines to utilize them.

Office Won’t Save To Server

The Art Department is cranking out proposals. Marketing is knee deep in spreadsheets. Everybody's working furiously, when suddenly the panicked phone calls start. The Macintosh users can't save their Office documents, and these cryptic messages appear when they try:

There has been a network or file permission error.
Save not completed. File rename failed.

No matter what you do, you can't seem to get Word or Excel to save to your network shares. You've gone over the machines repeatedly, and everything is set up properly. Worse still, the problem's intermittent. Your users swear it happens when they're busiest, but sometimes it doesn't happen for days.

There is an explanation. What they're suffering from is an unfortunate side-effect of how Microsoft Office handles temporary files, and the more users that are on the server at one time the more likely this is to bring work to a screaming halt.

Why Office for Macintosh breaks some offices:

Most modern applications utilize temporary files, to guard against data loss or free up working memory. Traditionally, Unix operating systems have saved these files in /tmp (though Mac OS X utilizes /private/tmp), and have included random numbers in their names to prevent accidental duplication. Adobe Creative Suite uses a similar method, saving temporary files in the same directory as the open file being edited, but again using a pseudo-random string like ~file~ve_kv.idlk.

Microsoft Office, on the other hand, saves temporary files at the root of the server volume you're working on, in a folder named .TemporaryItems/folders.UID (where UID is the user's account number on their local client machine). This is client-side behavior on the application's part, and can happen when saving to AFP (Macintosh) or SMB (Windows) volumes.

The problem is that users often all have the same UID on their client machine, because Macintosh computers in an unmanaged environment assign a default UID of 501 to the first account created. That means every Microsoft Office user is trying to read and write to the same temporary folder. That works fine until the original user logs out of their system, at which point they automatically and unintentionally delete that folder, and the remaining users can no longer save their documents to that volume. The problem exists in Office 2004 and the newer 2008.

There are two approaches to eliminate this problem, one utilizing directory services on the server side, the other using the Terminal on each individual client machine.

Office for Macintosh in enterprise settings:

In a server setting, Apple expects user accounts to utilize a directory service like Microsoft's Active Directory or their own Open Directory system. Most Mac users expect that they can set up their office machines in the same easy way they've set up their home machines for years. It's these conflicting expectations, wrapped up in Microsoft's predictable file-naming scheme, that create this problem Office users have been left trying to work around for years.

The best solution is to leverage Open Directory on your OS X server and migrate your client machines to a unified, managed login scheme. This not only solves this Office problem but brings a wide range of additional features with it. It's the management structure that allows control of System Preferences and Software Updates for every Macintosh in the organization, enables a company-wide address book for contact management and collaboration, and provides the highest level of security for network resources. In this situation, each user has a unique account not just on their own machine but across the entire network, sidestepping the Office UID conflict entirely.

In environments without a Macintosh server the same principle still applies. Open Directory can integrate seamlessly into an Active Directory domain, allowing Windows administrators a greater level of management control through group policy setup. Instead of using local accounts on each client machine, you can also avoid potential UID conflicts by binding the Macintosh clients to the AD domain and having users log in with their Active Directory domain accounts.

Changing individual UIDs manually:

If you're not quite ready to take that leap, it's relatively simple to change the UIDs on each client machine to match those on the server. It can also potentially destroy a system, so you'll want a recent backup handy and some comfort with the Unix command line. Remember that you'll need to perform these steps for every user on every machine that accesses your server.

Log in as a local administrative user (and not the user whose UID you're changing), and from the Terminal type:

id -u USERNAME

Here USERNAME is the short name of the user to whom you're assigning a new account number. This will give you their current UID. To change that UID on Mac OS X 10.4 type:

sudo niutil -createprop . /users/USERNAME uid NEWUID

On version 10.5, niutil has been deprecated, and instead you'll need to input:

sudo dscl . -change /users/USERNAME UniqueID OLDUID NEWUID

Above, OLDUID is the current account number that the previous command provided, most likely 501 or 502. NEWUID is the new and unique account number you're assigning. Finally, type:

sudo find / -user OLDUID -exec chown NEWUID {} \;

This last command will locate and assign ownership of all the user's files to their new account number. It can take quite a while, depending on how much data belongs to each user. If you use external hard disks or USB drives you'll have to repeat this step for them as well, replacing / with /Volumes/DEVICE (where DEVICE is the name of the external volume).

Once you're done, your users will finally be able to save Office documents dependably.