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 (Click image for larger view) 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 (Click image for larger view)
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 (Click image for larger view)
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 (Click image for larger view)
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.
To set up DHCP binding when using Mac OS X Server as your DHCP server, you can select the DHCP service in the "Computers and Services" list and use the "LDAP" tab for each DHCP subnet where you want to use dynamic binding in Server Admin (see Figure 5). If you are using the same server for DHCP, it will automatically populate the Open Directory information for you.
You can configure other DHCP servers by configuring DHCP option 95 to provide this information.
Figure 5 – Configuring Dynamic Binding Using Mac OS X Server DHCP Server (Click image for larger view)
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 (Click image for larger view)
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 (Click image for larger view)
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.