Hands on: Setting up Mac OS X Open Directory

yxixi

　　Open Directory, Mac OS X's native directory service, allows users to both manage local accounts and to create shared directory domains hosted by Mac OS X Server. With shared directory domains, administrators can create network accounts that can be used to log into computers and to access server-based resources throughout an organization's network.
Open Directory leverages several powerful technologies, including OpenLDAP and Kerberos, to provide a secure and scalable environment. It provides single-sign on to services within a network, supplies powerful home directory options and sports an extremely comprehensive client management architecture. (For more details about the technologies that constitute Open Directory, see my earlier article: "Understanding Mac OS X Open Directory -- An Introduction to Directory Services in the Mac Environment.")
Despite the complex technologies that make up Open Directory, Apple has made an incredible effort to make the platform easy to set up and manage. While this article isn't a comprehensive manual for designing an Open Directory infrastructure, it is a guide to the basic configuration process.
Creating an Open Directory Master
An Open Directory Master is an organization's primary Open Directory server. It hosts the shared LDAP domain that stores network account information, a Kerberos realm and Open Directory password server for securely authenticating users. Any Mac OS X Server installation can serve as an Open Directory Master, though you will want to use a machine that is sufficiently powered to handle directory service requests. Ideally, for optimum performance and security, an Open Directory Master should not be used to provide other network services. You will also need to ensure that your DNS infrastructure is configured properly and successfully supports forward and reverse lookups.
To create an Open Directory domain and to configure domainwide settings, you will use Mac OS X Server's Server Admin utility. Launch Server Admin, connect to the appropriate server and select "Open Directory" in the "Computers and Services" list (see Figure 1).
Then click the "Settings" button at the lower right of the window to display the "Settings" pane. Choose "Open Directory Master" from the "Roles" dropdown menu. You will be asked to specify a domain administrator account -- this is the first account in the domain that will be given full administrative access to manage the domain and to create additional user accounts. This will be a separate account from the server administrator account, which is a local nonshared account for managing other aspects of the server.
You will also be asked to specify a search base for the domain and a Kerberos realm name.
　　Figure 1 - Selecting the Open Directory settings in Server Admin

　　The search base defines how clients will locate information in Open Directory's LDAP database. The Kerberos realm stores information that will be used to securely authenticate users. Provided your DNS infrastructure is configured properly, both these fields will be prepopulated based on the server's domain name. In most situations, you can accept these values. If your network has a pre-existing Kerberos infrastructure or you plan to customize your server's OpenLDAP configuration, you would need to enter the appropriate information rather than accepting the defaults.
　　Once you've entered the required information, Mac OS X Server will create an OpenLDAP configuration appropriate to Open Directory, a Kerberos realm and an Open Directory Password Server database. It will then begin the associated processes. While these are complex technologies that are being installed and configured on the server, Apple has made the setup routines extremely simple and reliable.
You can verify that the configuration was successful by checking the Open Directory "Overview" pane to see that the associated services are running. You can also check the related log files using the "Log" pane. The dscl and ldapsearch command-line tools can also be used to query the new domain.
Setting security options
There are several features built into Open Directory to create a secure infrastructure. Kerberos and the Open Directory Password Server do a very good job of limiting the number of times a password is sent over the network, and they encrypt the password as much as possible for each supported authentication method.
If you use only services that support Kerberos, a user's password will never need to be sent over the network. For nonkerberized services, the Open Directory Password Server manages authentication. Although it supports a broad range of authentication and encryption techniques, some are considered weak and should be disabled if they are not required. You can disable weaker and unused techniques by using the "Security" tab within the "Policy" pane of the Open Directory Master's "Settings" pane (see Figure 2).
　　Figure 2 - Choosing to enable/disable weaker authentication/encryption schemes

　　Another method to ensure password security is to require users to regularly change their passwords, use complex passwords that are not easy to guess and automatically disable an account after a number of failed log-in attempts. The "Passwords" tab on the "Open Directory Policy" pane allows you to configure global password policies (see Figure 3).
　　Figure 3 - Setting global password options

　　These global policies affect all users within a domain -- with the exception of administrator accounts, which are exempted from all password policies. You can also set user-specific policies that will take precedence over global policies by using Workgroup Manager.
　　　　Beyond securing passwords, the domain itself can also be secured to prevent unauthorized computers from binding to it, prevent computers from searching records in the domain and to prevent the interception of data being transmitted to or from client computers. Even though such attacks might not turn up usable password information, the attacks can be used to gain information about your infrastructure and about your users.
The first technique for preventing these attacks is to require SSL encryption of communication between clients and the server(s) hosting your domain, which can be configured in the "Protocols" pane of the "Open Directory settings" in Server Admin (see Figure 4). You can use any security certificate residing on the server for SSL or you can import one.
On this same tab, you can also limit the maximum number of results that will be returned for LDAP queries as well as specify a timeout for searches, which can reduce the risk of a denial-of-service attack being successful against a server.

　　Figure 4 - The Protocols tab for an Open Directory Master's settings

　　　　Additional options are found on the "Binding" tab in the "Policy" pane of the Open Directory settings. These include the ability to allow or require trusted binding, which allows clients and the directory server to establish their identity to each other. When trusted binding is in use, you will need to authenticate with a directory domain administrator account when you bind a computer to the domain. Trusted binding offers enhanced security, but it cannot be used with dynamic binding using DHCP.
Other security options include disabling any transmission of clear text passwords, encrypting all data -- which requires either SSL or Kerberos -- and the ability to digitally sign all packets and prevent man-in-the-middle attacks through the use of Kerberos.
Binding computers to Open Directory
Once you have set up your Open Directory domain, you will need to bind Mac OS X computers to the domain for them to use accounts in the domain for user log-in and single-sign on access to services in your network. You can bind computers to a domain by creating a static configuration on each computer, or you can dynamically bind computers using DHCP. For its part, DHCP eases the process because you don't need to configure each computer, but it also reduces the security options available to your domain and allows any computer on your network to access your domain.

　　Figure 5 - Configuring dynamic binding using Mac OS X Server
　　Note: DHCP binding does require that Mac OS X clients be configured to use an automatic search path and that the "Add DHCP-supplied LDAP servers to automatic search policies" option is enabled for the LDAPv3 plug-in in the "Directory Access" utility (see Figure 6).
Static binding is configured using the LDAPv3 plug-in to "Directory Access" (located in the "Utilities" folder). Select the plug-in and click "Configure" to add or change a configuration. Use the "New" button to create a new configuration (see Figure 6) and enter the IP address or the fully qualified domain name of the server.
Be sure that the "use for authentication" option is selected.
As an option, you can choose to require secure Open Directory communication using SSL. Another possibility is to use Open Directory to provide contact information to LDAP-aware applications such as Apple's Address Book. Depending on your security settings, you may be asked to authenticate to the domain.
Note: You can create custom LDAP record and attribute mappings or a custom search base and search scope. By default, Directory Access will query the domain to retrieve this information. This may be needed if you have customized the OpenLDAP configuration for your domain, though for most instances you will not need a manual configuration.
　　Figure 6 - Enabling the LDAP v3 plug-in for the Directory Access utility

　　Setting up search paths
Mac OS X can be bound to multiple Open Directory domains as well as to other types of directory services. Because of this, you need to specify a search path when configuring static binding. You can create a search path using the "Authentication" tab in Directory Access as shown in Figure 7; you can also configure a search path for contacts using the "Contacts" tab. From the Search pop-up menu select "Custom Path." If your configuration is not listed, click the "Add" button to display a dialog box containing all available directory service configurations.
　　To configure the search path, simply drag the listed configurations into the appropriate order from top to bottom; the computer's local NetInfo domain will always appear at the top of the list because it is always searched first. Once your search path is set up, restart the computer and log in using a network user account to ensure the computer is properly bound to the domain.
　　Figure 7 - Setting up a search path using Directory Access

　　Setting up replication
Open Directory supports load balancing and fault tolerance through the use of replicas. A replica is a server that maintains a complete read-only copy of the Open Directory domain as well as copies of the Kerberos realm and Password Server. Changes made to the records stored on the Open Directory Master are automatically copied using a secure shell connection to the replica(s) at varying intervals.
Although the domain itself is read-only on a replica, the Password Server and Kerberos realm can accept password changes on a replica, which are then copied to the master and from there to any other replicas.
Setting up replication is relatively simple. Open "Server Admin" and connect to the server that will become a replica. In the "Open Directory Settings" pane, select the "General" pane and choose "Open Directory Replica" from the Role pop-up menu.
You'll be asked to enter the IP address or domain name of the Open Directory Master. And you'll be asked to authenticate using a directory domain administrator account and to supply the root password for the master; this is required to establish the secure connection used for replication. The server will then be added to the domain's replication set, the required Open Directory configuration files will be created and the domain will be replicated to the new replica. Initial replication can take anywhere from a few minutes to a few hours, depending on the number of accounts in the domain and the speed of the network links between the servers.
You can configure a replication schedule independently for each replica. Replication schedules are set on the master using the "General" pane of the Open Directory Settings in Server Admin. You can select each replica in the Replicas list box and then select a radio button to choose whether to replicate changes immediately at recurring intervals, and you can choose the interval. You can also force replication using the "Replicate now" button, though this will force replication to all replicas and not just to the one that is currently selected.
Replication provides for situations where you have a particularly large or active Open Directory environment and for situations where you have multiple sites with slow network links between them. In such cases, you can bind computers to a local replica rather to the remote master. The system also supports automatic fail-over from the master to the next available replica. Because replicas can be promoted to become an Open Directory Master in the event of a complete failure of the Master, they also serve as backups of your domain.
　　Joining additional servers to Open Directory
To provide single-sign on access to services and to allow users to use a single account for accessing all resources within a network, you can join additional servers that are neither master nor replica to a network. These servers are referred to as member servers or as being bound to Open Directory or, in the designation used by Server Admin, as connected to a directory system.
There are two advantages to using servers in such a way. First, users need only remember one user account. Second, because of Kerberos and single sign-on, users will have seamless access and the integrity of their passwords is maintained throughout the network.
The process of configuring additional servers to rely on user accounts stored in Open Directory is, at least in part, the same as joining a workstation. First, select the "Connected to a directory system" role using the pop-up menu in the "General Open Directory Settings" pane in Server Admin. Then use the "Open Directory Access" button to launch Directory Access. Bind the server to the domain and configure a search path just as you would for any other computer.
In theory, you could stop at this point and the server would allow access to resources via accounts in Open Directory. However, additional steps are required if you want the server to use Kerberos authentication. This is because every server that relies on a Kerberos distribution center for authentication must maintain a copy of certain encrypted files, including the keytab file. The process of configuring a server for Kerberos authentication is referred to as joining it to the Kerberos realm.
Joining a server to the Kerberos realm involves several steps. First, you must bind it to Open Directory (as described above). Then you must create a computer record for it using Workgroup Manager. The computer record can be part of any computer list in your Open Directory domain, but its name must be listed as its fully qualified domain name.
Once the server has a computer account, connect to the Open Directory master using Server Admin and then click the "Add Kerberos Record" button in the "General" pane of the Open Directory Settings. You will be asked to authenticate as a domain administrator, provide the fully qualified domain name of the server -- referred to as the configuration record name -- and then to specify the user name(s) of one or more administrators who will have authority to join the server to the Kerberos realm. These people are referred to as delegated administrators. This will place the required information into the server's computer record in Open Directory.
　　The final step is to use Server Admin to connect to the member server and click the "Join Kerberos Realm" button in the "General" pane of the Open Directory Settings. You will be asked to select a realm from a list of known Kerberos realms -- typically, you will only see the realm on your Open Directory Master -- and to enter the user name and password of a delegated administrator. At this point, the required Kerberos files are copied to the server and, it is configured to support Kerberos authentication.
You can also use the "Logs" panel in Server Admin to view the various service logs used by Open Directory to ensure that all needed processes are running correctly. These logs can also be useful for troubleshooting problems, as well as for identifying potential network attacks or attempts by unauthorized users to log in to computers within your network. As such, it is a good practice to review them on a regular basis.