Understanding Mac OS X Open Directory

Managing shared domains

Mac OS X Server supports four Open Directory roles: stand-alone, Open Directory Master, Open Directory Replica and Connected to a Directory System. A stand-alone server relies solely on its local NetInfo domain and is typically not used as a file or print server. An Open Directory Master is a server that is hosting a shared domain.

An Open Directory Replica is a server that hosts a read-only copy of the domain. Replicas allow for load balancing and support remote locations where a slow network link makes direct access to the Open Directory Master impractical. Replicas also allow for fail-over in the case of a failure of the master.

"Connected to a directory system" refers to a server that's bound to a shared domain but that is not providing directory services. Users can access servers connected to a directory system using accounts stored in the shared domain. Typically file, print and e-mail servers will use this role. In smaller environments, however, a server might offer these services in addition to being an Open Directory master or replica.

Open Directory domains rely on the Domain Name System (DNS) to function. For this reason, ensuring that you have a fully functioning DNS infrastructure is critical to setting up Open Directory in a network. Frequently, Open Directory failures can be traced back to problems with DNS. One of the pitfalls of simply walking through Mac OS X Server's "Server Assistant" tool, which runs automatically after a basic installation, is that the Assistant offers you the option of setting up a new Open Directory domain. This can cause problems if the server you are setting up will serve as an Open Directory Master and DNS server.

As complex as Open Directory is, both as a whole and in the structure of individual domains, Apple has made the set-up process extremely simple, provided you have DNS and other network services set up properly beforehand. You can easily change an existing server into an Open Directory Master by simply selecting that role from a pop-up menu in Mac OS X Server's "Server Admin" utility. Then you enter basic information about the domain, including an account that will have administrative authority over the domain, the LDAP search base for the domain and the Kerberos realm that the domain will use.

You can elect to set additional features at this time (or later) as well, including default domain password policies, whether computers must communicate with the domain over secure connections, and whether computers accessing the domain must be bound to it. All of these options can substantially increase security.

Setting up replica servers and binding other servers to the domain are equally simple. There are, of course, more advanced tools for some administrative tasks, many of them being command-line tools that are beyond the scope of this article. However, for most environments, the graphical tools in Server Admin are all you need to get an Open Directory infrastructure up and running.

Kerberos and the Open Directory password server

Open Directory provides multiple mechanisms for securing passwords. The original mechanism used by Mac OS X Server was to store passwords as an attribute of the user account object. This feature is referred to as "basic passwords" and is still supported for backwards compatibility with older versions of Mac OS X and Mac OS X Server, though it must be chosen as a specific option for each user account.

Basic passwords are stored and transmitted in encrypted form. However, because they are stored in Open Directory domains, basic passwords are susceptible to offline security attacks using either Workgroup Manager or command-line Open Directory tools.

Open Directory also offers the default Open Directory password type. This technique stores user passwords outside of the domain itself in two places. The first is in a Kerberos realm. The second is in the Open Directory Password Server database.

Both offer enhanced security because the password is only set and verified and is never actually read by Open Directory. When these password types are used, only hashed information identifying the location of a user's password in either the Kerberos realm or Open Directory Password Server is physically stored in the user record.

By default, when a server is set up as an Open Directory Master, it is also set up as a Kerberos Key Distribution Center (KDC). This makes Mac OS X Server one of the easiest platforms to set up as a KDC because the process is almost entirely automated. It is also possible to use an alternate KDC -- including an Active Directory domain controller, which is helpful in a multiplatform environment.

In addition to securing password storage, Kerberos offers significant password security for user connections because it relies on tickets to authorize access to any "Kerberized" services within a network. Thus, a user's password is transmitted only when he first logs in.

Kerberos also provides a seamless, single sign-on environment where users will not be repeatedly asked to authenticate as they connect to servers and browse for Kerberized services. Under Mac OS X Server, these Kerberized services include the Mac OS X log-in window, e-mail, Apple Filing Protocol and Server Message Block protocols for Mac and Windows file/printer sharing, virtual private networks, file transfer protocol services, Apache and Secure Shell access.

Because Mac OS X Server uses a standard Kerberos installation, you can offer additional Kerberized services within your network using servers and clients of other platforms, including Unix. Telnet and Rlogon are two examples of Unix services that can now be used with Kerberos.

The Open Directory Password Server is good for those situations when Kerberos isn't an option. This can be useful for applications and services that don't support Kerberos as well as for times when there is a Kerberos failure. The Open Directory Password Server supports a broad range of standard encryption types for interaction with a range of platforms and services. Although it doesn't offer the secure and single sign-on advantages of Kerberos, the Open Directory Password Server provides solid security that is much better than basic passwords.

By default, when a user's password type is set to Open Directory, Open Directory will attempt to authenticate the user using Kerberos first and only use the password server in those instances where Kerberos isn't available.