At the root of the problem is the /etc/authorization file, which outlines unique situations where users are granted escalated privileges, and which should be altered as part of the 10.5.7 update process. It appears, however, that the file is updated only on Intel-based machines, leaving managed users on the PPC architecture unable to login on their workstations or laptops.

The solution is to copy the file to a PPC machine booted into target mode from an updated Intel installation, taking care that the ownership and permissions remain the same as on the Intel version. Alternately, if you have multiple PowerPC machines updated and booted, the same idea can be applied en masse by pushing an updated Intel file out via Apple Remote Desktop, JAMF Casper Suite, LANrev, or your preferred third-party distribution tool.

Once the corrected file is in place, reboot the afflicted machines, and login should be restored.

The most basic method to controlling applications is to use the defaults command to write directly to the application preference list, as we’ve demonstrated repeatedly. This approach works fine for some settings, but there’s a problem: It permanently disables lockable preferences only for standard users (since administrative users can just unlock them) and most application preferences can’t be locked at all (so users can change them any time they like).

For any application that uses Apple’s .plist format, there’s a far better way to manage preferences across your network. A properly configured Open Directory domain can use MCX (Managed Client for OS X) settings to control any available user setting.

In Workgroup Manager, select the group for whom you’d like to manage an application’s preferences (in our example, that group includes all of our Macintosh users). First select “Preferences” from the toolbar above, then the “Details” tab on the right. Using the plus button, browse to the preferences file you’d like to control and click “Add”, selecting to manage imported preferences “Always” from the drop-down menu.

Double-click the preference name, and an editing window will open. Typically, you’ll wind up deleting the most of existing preferences from the editing window, keeping (or adding) only those you wish to manage.

Using this approach, you can take fine-grained control of most user-level settings, including managing application preferences more effectively. The result is preference settings that apply to standard and administrative users alike, controlled centrally through Open Directory even for third-party applications.

First, select a group from your Open Directory domain in the “Accounts” pane of Workgroup Manager. Then click the “Group Folders” button, and select a share point under which you’d like the group folders to appear. By default, Mac OS X uses /Groups, which comes pre-configured as a share on a new installation. Next, you’ll need to choose an owner for your new folder. Your directory administrator account makes the most sense here, as you’ll be using the group (not owner) attribute to determine access permissions. With these options configured, hit “Save”.

For whatever reason, you can’t actually use Workgroup Manager to create the folder you’ve just configured (as you can with user’s home directories). Instead, you’ll need to open the Terminal and type:

sudo CreateGroupFolder

This will build a folder for every group assigned a share point, not just the most recent, so if you’re deploying multiple group folders it makes sense to run this command after they’ve all been set up in Workgroup Manager. This also sets the permissions for each group folder as read-only to the group itself, and only read-write to the individual user defined as it’s owner. To remedy this in the Terminal, type the following, replacing PATH-TO-FOLDER with the full Unix path to each group folder:

cd PATH-TO-FOLDER
sudo chmod 770 Documents/ Library/

This will allow access by workgroups to their own group folders with a simple permissions scheme. For more complex sharing setups, you may wish to add an access control list as well, in the sharing pane of Server Admin.

Finally, if you’re utilizing managed preferences in an Open Directory environment, you can set group folders to automatically mount when a member of that group logs in to their workstation. Moving to the “Preferences” pane of Workgroup Manager, click the “Login” icon, then the Items button on the far right. Check “Mount share point with user’s name and password” and “Add group share point”, then click “Apply Now”.

Not only can each workgroup have their own private file share, but users will connect to those shares automatically when logging in to their Open Directory account.

Sharing Portable Home Directory Files:

In order to make your server-based home directories available to other machines, you’ll need to share them out to your network (preferably via AFP). In Leopard, the “File Sharing” settings reside in the Server Admin application. Open it, then select your server name, and choose the gear-shaped “Settings” button from the toolbar. You’ll see a collection of potential server features to enable (such as allowing SSH and ARD access) including a listing for “Server Side File Tracking”. Checking the box and clicking “Save” will allow Mac OS X server to cache file changes prior to synchronizing home directories, which should offer a significant performance boost over Tiger’s system of scanning and comparing home directory contents.

Next, select “File Sharing” from the Server Admin toolbar (or the equivalent settings in Tiger’s Workgroup Manager). If your server has fast redundant disk space available to hold your portable home directories, there’s not a compelling reason to not just share out /Users. If you have a large number of users (or a small boot disk), you’ll want to create a separate share on external storage. In either case, select the “Volumes” and “Browse” buttons below the toolbar and select the folder you’ll be using for your Portable Home Directories, then click the “Share” button right above the file browser and “Save” at the window’s bottom-right.

Once you share the directory, a new “Share Point” button will appear at the center of the “Sharing” pane. Select it, then check “Enable Automount”. You’ll then be asked to enter an administrative user name and password for your Open Directory domain. Keep the default setting of mounting user home folders over AFP by clicking “OK”, then move on to the “Protocol Options” button below it.

When Portable Home Directory deployments go wrong, it’s usually at this stage. In the AFP “Protocol Options”, be sure that “Allow AFP guest access” is checked (you’ll also want to uncheck the options to share via SMB, FTP, or NFS). If you have other AFP shares active (which you most likely do), be sure guest access is turned off on the rest of them. Then select “AFP” from the service list on the left of the Server Admin window, choose the “Access” pane, and check “Enable Guest access” there as well.

This may seem counterintuitive, as guest (or unauthenticated) access to the home directory share may sound like a terrible idea. In most cases you wouldn’t want any data shared out to network guests, and Apple even forces you to confirm the setting in two separate places. In the case of Portable Home Directories, however, the shared volume gets automounted prior to any user logging in. The data inside each home directory stays private, but the root of the share needs to be accessible to any machine bound to the Open Directory domain. Guest access is the mechanism through which this is achieved, and without it the remainder of your deployment process won’t get anywhere.

Assigning Portable Home Directories To User Accounts:

Now that your mobility preferences are set and your AFP share is set to automount, the final step is assign home directories to your existing users. Open Workgroup Manager and select “Accounts” from the toolbar, then highlight a test user from the left column and choose the “Home” pane. By default, two options are offered as home directory locations, /Users and None. Instead, click the “plus” button at the bottom of the list to add an additional option.

In the dialog sheet that appears, use the first field to enter the AFP address of the home directory share in URL format (such as afp://server.example.com/Users). In the second field, fill in just the name of the user’s home directory, which should be the same as their account “short name”. In the third field, enter the full path of the automounted home share as it will appear on client machines. This begins with /Network/Servers/, then the address from the first field minus the afp:// prefix, and finally the user’s short name. When all three fields are filled properly, click “OK”, then assign the user a disk quota (somewhere between 20-40GB is reasonable for most user environments) and hit “Save”.

With this first account done, you can now highlight all the users who’ll be getting mobile accounts, select your pre-configured share point, assign a quota, and save those settings to the entire list at once. If these are new accounts, you can even use the “Create Home Now” button to populate your AFP share with custom home directories. If you’ll be syncing existing home directories on client machines, you don’t have to create a home folder at all, instead allowing the data to copy to the server on their next network-based login.

Recommended Reading: For the full story on Portable Home Directory setup, try the essential Leopard User Management Guide [PDF - 2.5MB] at Apple.com.

Portable Home Directories make for simpler backup of user data, both by copying off the server rather than each client machine, and by allowing remote users to synchronize via VPN. They also free users from being tied to a single machine, allowing for greater flexibility and less service down-time. It’s because this functionality is so powerful that it’s often assumed to be difficult to put into practice. Instead, with the proper infrastructure already in place, deploying Portable Home Directories is practically the reward for having done everything else right.

Planning For Portable Home Directories:

Before you actually implement any kind of server-based account storage, you’ll want to make sure you have sufficient storage and bandwidth on an available OS X server. This may seem obvious to some, but for reasonable performance, fifty users with a 40GB quota requires at least 2TB of relatively high-speed (and hopefully redundant) disk attached to a gigabit network switch. This isn’t an exotic setup by any means, but it may be more than you just have lying around.

You’ll also need clients bound to a functioning Open Directory environment, complete with internal DNS. If you don’t yet have this set up, refer to our earlier series on how to master Open Directory. Once Directory Service users and groups are in place, Portable Home Directories are nothing more than cleverly deployed managed account preferences. There’s a lot to keep track of, but very little you wouldn’t already know how to do.

Configuring Portable Home Directory Preferences:

In Workgroup Manager, browse to the “LDAPv3″ directory (as opposed to the local user directory), then choose the multi-headed “Groups” button on the left and the “Preferences” icon from the toolbar. Select the group (or groups) you’re offering Portable Home Directories, then click the “Mobility” icon in the center of the window to configure that group’s settings. If you’re deploying this feature to all your users, you’re better off creating an all-encompassing “Employees” group to do so.

Beginning in the “Account Creation” tab with the “Creation” pane, choose to manage these Preferences “Always”, the check “Create mobile account when user logs in to network account”. Uncheck the box which requires confirmation, as this allows the user to skip the Portable Home Directory set up for their individual account. Below that, choose to “Create home” directories “with default sync settings”.

Next comes the Account Expiry tab, new to 10.5. By allowing you to set a time limit after which the client-side copy of a home directory expires, it helps clean up the occasional “orphaned” set of user data (a full home directory left, for instance, on a machine only used once by that user during maintenance on their own machine. This feature can reduce the chance of accidentally filling client machines with multiple unused accounts, but does so at the risk of letting the computer determine when data should be disposed of. If you enable it, do so with caution.

Finally, the “Rules” tab lets you set what data will synchronize and when. Start with the “Login & Logout Sync” pane and once again click the button to “Always” manage, then check the box to “Sync at login and logout”. The first list above allows you to set which directories you’ll sync, and unless you feel you can fully predict your users’ behavior the best approach is usually to select the entire home directory (as represented by the tilde symbol). You can then choose what not to sync in the second list below, including full paths, partial names, and even regular expressions. Be careful if you delete any of Apple’s pre-configured items to skip, especially ~/Library/Application Support/SyncServices, which can result in synchronization issues and potentially data loss. The “Merge with user’s settings” box allows you to decide if individuals can add or subtract to the list of data being synchronized.

The Background Sync pane, functions identically, and in most cases makes sense to configure identically as well. The only exceptions would be huge local files which change often, or live databases which won’t sync properly. The Entourage database, for instance, sits both criteria and should be excluded from background synchronization. The “Options” pane also allows you to choose how often background sync takes place. With your configuration decided, click the “Apply Now” button to save your settings.

Next week, in part two, we’ll set up the AFP share where your new Portable Home Directories reside and configure your Open Directory accounts to store user data there.

Recommended Reading: While I might not recommend implementing it in a production environment, Greg Neagle’s multi-part article on Portable Home Directory Without Open Directory provides fantastic under-the-hood information on exactly how Portable Home Directories function at his “Managing OS X” blog.

Ideally, you can simply click the “Kerberize” button in the “General” pane of Server Admin’s Open Directory settings. That should restart the service. This article for when you find yourself in less than ideal circumstances.

Why Kerberos Can Stop On OS X Server:

When the Kerberos service fails, the likely culprit is a DNS issue. This isn’t the only reason Kerberos can break, but it’s most common and the easiest to test for. The Kerberos KDC service (or Key Distribution Center), requires matching forward and reverse DNS lookups, and changing a server’s hostname or IP manually (or losing connection to your DNS servers) can require the machine to be re-Kerberized. Since Tiger, Mac OS X has also been designed to dynamically set a machine’s hostname on boot using a reverse lookup, meaning that external changes to a server’s DNS listings can cause it to change names and break its original Kerberos realm.

Before you try to restart Kerberos, you’ll want to know which (if any) of these things went wrong. If you aren’t sure how to go about this, check with whomever in your organization controls Domain Name Service, or use the procedure from the beginning of our article on setting up Open Directory.

How To Start Kerberos From The Command Line:

Once your server is properly registered in DNS, you can begin reconstructing your Kerberos realm. The first step is to create a new edu.mit.Kerberos file, which Mac OS X can fortunately do (somewhat) automatically. Open the Terminal and type:

sudo kerberosautoconfig -r REALM -m HOSTNAME

For this command, HOSTNAME is the fully qualified domain name of your server, such as server.example.com. REALM is the server’s DNS name again, but this time in all capital letters, like SERVER.EXAMPLE.COM. Next you’ll create a KDC database for the new Kerberos realm:

kdcsetup -f /LDAPv3/127.0.0.1 -w -a DIRADMIN -p PASSWORD REALM

Here DIRADMIN is the name of any user with directory administration privileges, and PASSWORD is their actual login password. Once that’s done, you can Kerberize the server’s Open Directory domain with the following:

sudo slapconfig -kerberize -f DIRADMIN REALM

Finally, configure the Single Sign On mechanism to utilize Kerberos authentication for all applicable OS X services.

sudo sso_util configure -r REALM -a DIRADMIN -p PASSWORD all

This should once again leave you with a fully-functioning Kerberos installation on your Open Directory server, all without ever having had to reboot the machine.

If you’re following this procedure, keep one additional things in mind: Because the kdcsetup and sso_util commands unfortunately requires that you provide a password on the command line (and therefore store that password in your command history), it’s good security practice to change that user’s password immediately after this process.

Recommended Reading: For an illustrated overview of the Kerberos authentication Process, there’s the handy Kerberos Chart [PDF - 72KB] at Computer World. For more depth into how Kerberos works on OS X, there’s an excellent three-part article at AFP548.com.

Open Workgroup Manager, and select the “Preferences” button from the toolbar at the top of the window. The panel on the right will change to display the preferences available for control through Open Directory. While you can manage preferences for individual accounts, it’s significantly more scalable (not to mention less confusing) to utilize groups for these purposes. Select the second button at the top of the left hand column (illustrated with three silhouettes) to do so.

Using the icons on the right, you can then choose which Applications users may or may not launch, determine their write privileges for external media, establish which System Preferences settings they can change, and more. These are the Managed Client for OS X (also known as MCX) preferences.

For most preferences, you can set the frequency to “Once” (meaning the setting is a default that can be overwritten by the user) or “Always” (meaning the user cannot change the settings at all). Many offer “Often” as well (meaning the setting is editable but reset on each login), useful for public machines but outgrown by Leopard’s new Guest account.

Some preferences, however, either can’t be set through user groups (such as Login and Energy Saver options), or make little sense on a per-user basis (like network proxies, available printers, or Software Update). For these settings, you’ll want to set machine-based preferences.

Leopard Server splits computer-based management into two panes, one for individual machine accounts (illustrated by a single box) and the second now just for machine “groups”.

You’ll create accounts by adding their name and MAC address (also called Ethernet ID). Machine accounts are also created dynamically when a computer binds to your Open Directory domain. Once your accounts are in place, you can add them to the groups, and manage preferences for every user on a given machine.

Combined with the locked administrative System Preferences on each workstation, managed account preferences allow administrators to truly define account policy for their Macintosh users.

Secure Open Directory Access:

By default, Open Directory will allow access to any machine on the network. This may work fine in an isolated academic environment, but most businesses have greater security requirements imposed upon them. Those requirements are fulfilled by Kerberos, an encrypted ticket-based authentication system developed at an isolated academic environment called MIT.

Open the Server Admin tool and select the “Open Directory” option from your server listing on the left. Click the “Settings” button in the Toolbar, followed by the “Policy” button on the strip below it, and the “Binding” button on the strip below that. Check the top two boxes to require authenticated binding for directory services, then the next four to enforce the strict Kerberos protocols for authentication.

Now click the “Passwords” button to define your organization’s minimum password requirements. An ideal policy varies widely depending on each individual environment, but keep in mind that overly strict policies often lead to weaker passwords overall (or complex passwords taped to monitors and under keyboards). Whatever you choose, be sure to check “be reset on first user login” password. This allows you to assign the same default password to all new and imported accounts, rather than assign each account a new password individually, then forces users to create a new one immediately.

Migrate Users To Open Directory:

Now that you can insure account information will be communicated securely, the next step Launch Workgroup Manager and log in under the directory administration account created in part one (diradmin by default) with the fully qualified domain name of your server (such as www.example.com).

This will open into the server’s /Local/Default directory, where non-network account information is stored. If you already have local user accounts, you’ll see them listed down the left column. Select those you’re transferring to the Open Directory service, then select “Export…” from the “Server” menu. The dialog will prompt you for a name and location to save your exported account listing. This export file will contain all the users’ existing account information except passwords, hence the importance of requiring new ones at login.

To move the accounts to Open Directory, click the tiny globe on the far left of the Workgroup Manager window, in the thin stripe just below the toolbar. Choose /LDAPv3/127.0.0.1, indicating that you’re now editing the LDAP (lightweight directory access protocol) settings. You should see your directory administrator account to the left, but no other users listed. Select “Import…” from the “Server” menu, and you’ll be presented with the dialog to re-import your accounts. If you’re moving accounts to an empty directory, you can safely leave these options at their defaults and click the “Import” button. Your exported local accounts should now be listed down the left hand side as Open Directory accounts. Only once you’re sure the new network accounts work properly should you then delete their local counterparts.

If you’re setting up a brand new server, there are no accounts to move around. Instead, just select the /LDAPv3/127.0.0.1 directory, and create your new users and groups.

Bind Clients To Open Directory:

Now that you’ve made accounts visible to the network, you’ll want to configure your other machines to utilize them. On your client machines, open Directory Utility, and click the plus sign at the bottom of the window. Leave “Open Directory” selected in the pulldown menu, then enter the fully qualified domain name of your Open Directory server and hit “OK”.

The window will then expand to accept credentials for the authenticated binding you’ve required. Enter the username and password of your directory administration account, as well as a unique machine identifier (most often the hostname or serial number), then hit OK again. If the binding process is successful, you’ll be greeted with a reassuring green light and a message that the Open Directory server “is responding normally”.

If you’re unsure if a computer bound properly, or has become unbound, the simplest test is to open the Terminal and type:

id diradmin

If you named your directory administrator account differently, just substitute that for diradmin, but be sure to use an account that exists only in the directory service and not on the local machine. The response should contain the UID, GID, and groups that user is a member of. Should the response instead be “no such user”, and the user exists on the server, then the machine has become unbound.

Now that you can login to all your machines with Open Directory network accounts, you can leverage those accounts for OS X security, collaboration, and management features.

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.

DNS and 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.

Deploy The Open Directory Service:

Now that you’ve confirmed your DNS is set up properly, open 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.

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.