Open Directory planning

Keeping information in shared directory domains gives you more control over your network, gives more users access to the information, and makes it easier to maintain the information. The amount of control and convenience depends on the effort you put into planning shared domains.

The goal of directory domain planning is to design the simplest arrangement of shared domains that gives your Mac users easy access to the network resources they need and that minimizes the time you spend maintaining user records and other administrative data.

Planning guidelines

If you don’t share user and resource information among multiple Mac computers, very little directory domain planning is necessary, because everything can be accessed from a local directory domain.

However, make sure that all individuals who use a Mac computer have user accounts on that computer. These user accounts reside in the local directory domain on the computer.

In addition, everyone who needs to use a OS X Server’s file service, mail service, or other services that require authentication must have a user account in the server’s local directory domain.

With this arrangement, each user has two accounts, one for logging in to a computer and one for accessing services of a OS X Server, as shown in the following figure.

When a user attempts to access the file service, the file server accesses the shared directory domain to verify the user account. Because the user computer and the file server are connected to the shared directory domain, the user account on the shared directory domain is used to access a computer and the file service without needing a local account on each computer.

The user logs in to the local directory domain of the Mac and then uses a different account to log in to the local directory domain of the file services server.

To share information among Mac computers and servers, you must set up at least one shared directory domain. With this arrangement, each user needs an account only in the shared directory domain.

With this one account, the user can log in to OS X on any computer that’s configured to access the shared directory domain. The user can also use this same account to access services of any OS X Server that’s configured to access the shared directory domain.

The following figure shows a configuration with a shared directory domain. The figure shows a user logging in to a Mac computer using a shared directory domain account. Then the shared directory domain account is also used to access a file service.

Login process with shared directory domain

In many organizations, a single shared directory domain is adequate. It can handle hundreds of thousands of users and thousands of computers sharing the same resources, such as printer queues, share points for home directories, share points for apps, and share points for documents.

You can replicate the shared directory domain to increase the capacity or performance of the directory system by configuring multiple servers to handle the directory system load for the network.

Larger, more complex organizations can benefit from extra shared directory domains. The following figure shows how one such complex organization might organize its directory domains.

If you have a large organization and you want to increase the performance and capacity of your network directory domain, you can add multiple directory domains to your network. Also, by using multiple directory domains you can load-balance your corporate directory domain.

There are different methods of configuring multiple directory domains. By analyzing your network topology you can determine the best method for your network. The following are optional configurations of multiple directory domains:

Open Directory with an existing domain: You can configure an Open Directory server on a network that has an existing directory domain such as an Active Directory or Open Directory domain.
For example, if your organization has an existing Active Directory server that supports Windows and Mac client computers, you can add an Open Directory server to better support Mac users. The two servers can exist on the same network and provide redundant directory domains for Windows and Mac clients.
You can also configure OS X Server to handle cross-domain authorization if a Kerberos realm exists.
If you have an existing Active Directory server, you can connect an Open Directory server to it and easily add users from the Active Directory server to your Open Directory server. These users are referred to as augment users.
Open Directory master server with replicas: You can create an Open Directory master server with replicas. The replica servers have a copy of the Open Directory master’s directory domain for load balancing and redundancy.
For example, your organization could have an Open Directory master at your headquarters and place replicas of that server at each remote location. This prevents users at remote locations from experiencing delayed logins.
Cascading replication: You can use cascading replication, where replicas of an Open Directory master have replicas. If a replica is a direct member of the Open Directory master and it has replicas it’s called a relay.
For example, if your organization has 32 replicas and you must add another replica, you can reorganize your network topology and have your replicas become relays by adding replicas to a replica (or relay).
Cascading replication load balances the Open Directory master by minimizing the number of replicas it must directly manage.

Estimate directory and authentication requirements

In addition to considering how to distribute directory data among multiple domains, you must also consider the capacity of each directory domain. The size of your directory domain depends on your network requirements.

One factor is the performance of the database that stores directory information. The LDAP directory domain of a OS X Server uses the Berkeley DB database, which remains efficient with 200,000 records. A server hosting a directory domain of that size must have sufficient hard disk space to store all the records.

The number of connections a directory service can handle is harder to measure because directory service connections occur in the context of the connections of all services the server provides. With OS X Server, a server dedicated to Open Directory has a limit of 1000 simultaneous client computer connections.

The Open Directory server can provide LDAP and authentication services to more client computers, because not all computers need these services at the same time. Each computer connects to the LDAP directory for up to two minutes, and connections to the Open Directory Password Server are even more brief.

Determining what the fraction is—the percentage of computers that make connections at the same time—can be difficult.

For example, computers that have a single user who spends all day working on graphics files need Open Directory services relatively infrequently.

In contrast, computers in a lab have many users logging in throughout the day, each with a different set of managed client preference settings, and these computers place a relatively high load on Open Directory services.

In general, you can correlate Open Directory usage with login and logout. These activities generally dominate directory and authentication services for any system.

The more frequently users log in and out, the fewer computers an Open Directory server (or any directory and authentication server) can support. You need more Open Directory servers if users log in frequently. You can get by with fewer Open Directory servers if work sessions are long and login is infrequent.