What is Open Directory and why is it important? It is the Apple multifunction directory services infrastructure. Open Directory consists of a number of different components that handle the information about all the users, groups, and computers on a Mac OS X computer or in a Mac OS X Server network. Open Directory sits as a layer of components between users, the Mac OS X file system, and any other processes running under Mac OS X. Each process or system relies on Open Directory to authenticate users based on their account information and authorizes them to access resources. Open Directory also acts as a gateway with other computing platforms.
In a Mac OS X Server infrastructure, Open Directory is the crucial repository of all user and computer information. Because it stores user accounts, information about computers and servers within the network, managed preferences, and password policies—just to name a few of its functions—it is one of the most mission-critical systems in a Mac network.
In a small network, there might be a single Mac OS X Server acting as an Open Directory server and also providing other services (such as file and print services). However, a large network might contain several Open Directory servers (many acting as replicas of a master server) and multiple master services, each hosting a directory domain that contains different sets of records for various departments or locations. A multiplatform network might even have customized Open Directory servers that actively exchange data with other directory servers for other computing platforms, such as Microsoft Active Directory or Novell eDirectory.
Because Open Directory is the most mission-critical component of a Mac OS X Server network, you must understand how to back up and restore its data.
Special Backup Concerns for Open Directory
Not only is Open Directory mission-critical for Mac OS X Server networks, it has some other special concerns as well. First, unlike the data on a file server (which is mostly static files instead of active databases), the data in Open Directory is constantly changing and (in larger networks) being passed between a master and replica servers. The data needs to conform to a specific blueprint known as the schema for it to be usable by the Open Directory servers. If any data becomes altered accidentally (or intentionally), individual records or the whole of an Open Directory domain can become corrupted. This introduces a level of concern for the data itself instead of hardware or operating system failure that goes beyond what you may need to worry about for other types of servers.
Overall, in its out-of-the-box format, Open Directory is not overly prone to corruption. It tends to handle discrepancies between data contained on master and replica servers well. It is also somewhat surprisingly good at reconciling discrepancies between its various component databases. However, given the complex interactions between those databases—including a primary database with user and computer records (which can store passwords in some rather insecure formats); a password server database that handles many forms of secure password transactions, but is stored separately from the main database with very limited points of congruity for very good security; and a Kerberos realm for secure single sign-on authentication—it’s no surprise that they can occasionally become out of sync.´ (Although usually this can be remedied by resetting a user password or password type using Workgroup Manager.)
If you begin customizing Open Directory by modifying the schema, which is often required to achieve heavy levels of integration with other platforms, you might create problems. I don’t advise anyone who is not adept at LDAP administration to even try to modify the schema on their own. Even some operating system updates that write changes to Open Directory can cause problems, particularly if you’ve modified the schema.
Open Directory is also permission-sensitive. You should not alter the permissions on any of its components unless you are very confident about what you’re doing. However, some installers (or well-meaning or malicious users) might try to alter those permissions, which can also create problems. Some of them can be resolved by using the Disk Utility Repair Permissions feature, but the changes can sometimes be more difficult to recover from. Adjusting Open Directory permissions might not only cause problems in operation but they can also compromise the security of user, password, and important network configuration information.
If you are making any changes to the schema or permissions of Open Directory, you should perform a backup beforehand. You should also perform a backup prior to installing any software updates. (Always a good idea, regardless of the role of a server.) Use a test environment when working with schema changes before rolling those changes out in a live network.
Backing Up Open Directory and Everything Else on a Server
The easiest way to make a backup of Open Directory is to rely on an enterprise-level backup tool designed for Mac OS X Server.
You can use these backup tools to back up your entire server, including the Open Directory components. However, if a dedicated Open Directory server is in constant use, it might be difficult to schedule a backup time that will not affect users. Backup tools can usually back up Open Directory while the server is in use, but there will still be a performance hit to the server during the backup operation. Testing the impact before rolling out the backup strategy is a good idea.
Another similar option is to clone the volumes (hard drives, partitions, and RAID arrays) that store the Open Directory databases and files. This is typically the server’s startup drive, although it is possible to customize a server configuration to store these files elsewhere. You can use tools such as the Apple Disk Utility, Carbon Copy Cloner, or SuperDuper to make clones to another volume that can act as complete copies of the original volume or to clone the volume to a disk image that can be saved for later use or restore. Again, you have the problem of choosing a time to perform a clone operation (it’s even more problematic than with a backup solution because the server will need to be taken offline and booted from an alternate startup volume).
Master and Replica Servers
In an environment in which there are master and replica servers for an Open Directory domain, you can use these roles in a backup process. The most obvious example is that clients can failover to a replica server while you make a backup of the master server’s databases as described above. The master server’s databases are those that are most critical. Although clients can authenticate based on replica servers, and password changes can be written to replica servers and then reconciled to the master server, replicas primarily exist to act as duplicates of the master server. (This is different from Microsoft Active Directory, in which all domain controller’ share responsibility for each piece of directory data.)
You can also promote an Open Directory replica to the role of Open Directory master. This process is most often done in the event of a hardware failure, however, because if you are trying to resolve an issue of corruption of Open Directory, the corruption probably has been populated to the replica(s). If you have a very slow replication schedule (usually for situations in which there is limited bandwidth between Open Directory servers), you might be able to verify the integrity of the data on the replica and then promote the replica. You would then need to reformat the original master server and add it back into the domain as a replica, which might not be an effective strategy depending on your network configuration.
Backing Up and Restoring Directory Data Manually
If you want to back up just the directory data of an LDAP master instead of cloning the entire drive, you should back up the domain database, the required configuration files, and the Open Directory Password Server database. You should also make copies of all these items at one time and with as little elapsed time between each item to ensure that the data from all three remain as in sync with each other as possible.
You can back up LDAP data while the domain is in active use (although to absolutely ensure consistency in your backup, you might want to stop the slapd service first). You cannot do a restore while the domain is in active use, however. You need to perform this process as root because only the root user has full access the requisite data. To stop the slapd service (and active use of the domain) before proceeding, use the following command:
/System/Library/StartupItems/LDAP/LDAP stop
- First, use the Unix slapcat command as follows to create a raw text dump of
all directory information (with the exception of data stored by the Open
Directory Password Server). Use the command as follows (you can substitute a
filename other than backup and can include a full path to a specific
backup location, although you have to include the. ldif extension):
slapcat –l backup.ldif
- Copy the LDAP configuration files (which are contained in the /etc/openldap directory on the server’s startup volume) and the host configuration file located at /etc/hostconfig.
- Copy the /Library/Preferences/DirectoryService folder, which contains information about Open Directory binding for the server (including binding to its own directory). If your server uses SSL support for LDAP, also copy your security certificate and private key files.
- Create a directory to store the backup of the Open Directory Password Server database.
- Use the mkpassdb command to create a backup of the database in the folder
you created for it, as follows:
mkpassdb -backupdb <path to folder>
- Create a directory to store the backup of your Kerberos realm database.
- Use the kdb5_util tool to create a backup dump of your Kerberos data in the
folder:
kdb5_util dump > <path to folder>/kbd5dump.bak
- To restore LDAP directory domain data, first stop the slapd service, as described earlier. Then, copy the configuration and host configuration files to the appropriate location. Do the same with the security certificate and private key files, if you backed these up as well.
- Use the Unix slapadd command to restore the domain data from the raw text
dump (if you changed the name from backup, substitute the appropriate
name and/or file path):
slapadd -c –l backup.ldif
- Use the mspassdb command to restore the Open Directory Password Server
data:
Mkpassdb –mergedb <path to folder>
- Use the kdb5_util tool to restore your Kerberos realm data:
kdb5_util load <path to folder>/kbd5dump.bak
- Restart the server and then start the LDAP service (if it does not restart
automatically). You will have stopped the server before attempting the restore
process. You can restart the LDAP service by using the following Unix
command:
/System/Library/StartupItems/LDAP/LDAP start