How-to: Understanding Mac OS X Open Directory

worker321

　　
An introduction to directory services in the Mac environment.
　　Directory services are a critical component of any enterpriseenvironment. These services provide a database for central accountmanagement for both user and computer, as well as a framework forsharing that information among workstations and servers. Mac OS X'snative directory service is called Open Directory.

Every MacOS X computer includes a local Open Directory database -- referred toas a domain -- that stores information about local user accounts. Thislocal domain allows each user to have a computing experience and homedirectory, and the local domain works with the file system to managepermissions on files and folders. Mac OS X Server relies on shared OpenDirectory domains to provide network user accounts that can be used tolog into computers that are bound to a shared domain. The shared domaincan also allow users to access resources on other servers that arebound to the domain. Shared domains also allow systems administratorsto define custom user environments.

Open Directory is amultipart architecture that performs the basic functions of anydirectory service in addition to providing mechanisms for accessingnon-native directory services platforms such as Microsoft Corp.'sActive Directory and Unix Network Information Service servers. It alsohas components that manage Mac OS X's access to self-discoveringnetwork protocols including Apple Computer Inc.'s Bonjour, MicrosoftCorp.'s Server Message Block/Common Internet File System and the openstandard Service Location Protocol. When discussing Open Directory,however, the phrase typically refers to its function as Mac OS X'snative directory service.

NetInfo -- The local Open Directory domain

Each Mac OS X computer, including Mac OS X Server, has a local OpenDirectory domain. This domain stores all information about local usersas well as information about the machine itself. The local domain forMac OS X is a NetInfo domain. NetInfo is a proprietary directoryservice originally developed by NeXT Computer Inc. that originallyserved as Mac OS X's native directory service. As Mac OS X Serverevolved, Apple replaced NetInfo with a service based on the LightweightDirectory Access Protocol (LDAP) that is often referred to as simplyOpen Directory.
　　There is little administration that needs tobe done with the local NetInfo domain on Mac OS X computers. However,it is important to understand that the local domain is always the firstsource in which a Mac OS X computer will look for user information. Itis also important to know that the local domain is visible in Mac OS XServer's Workgroup Manager; this is the tool used for managing user, group and computer accounts. Userand group accounts stored in a server's local domain can accessresources on the server, including share points, print queues andInternet services. Local accounts are not part of a shared domain,however, so they can't be used for log-in at Mac OS X computers.
　　
Search paths for shared domains

Mac OS X computers can be bound to multiple directory domains (bothOpen Directory and domains of other platforms such as ActiveDirectory). This requires that a search path be established thatdefines the order in which available domains will be searched foraccount information. This is different from a Windows environment, inwhich a list of available domains is part of the log-in dialog. Asmentioned above, the local NetInfo domain will always be first in thesearch path on Mac OS X. However, you can place any other domains inany order that you choose.

Search paths can be useful in anumber of ways. They allow you to have separate containers fordifferent groups of users and/or computers. They also allow you tobuild support for multiple directory service platforms that can mix andmatch advantages of each system. For example, you could rely on useraccounts stored in Active Directory but manage computers using accountsstored in Open Directory, which enables you take advantage of Apple'sclient management architecture. Search paths are powerful tools, but itis important to recognize that if you have users with the same name intwo domains in a search path, only the account in the first domain ofthe search path will actually be found.

Directory binding

Mac OS X computers can be bound to Open Directory domains in two ways.The first, and simplest, is Dynamic Host Configuration Protocol (DHCP).Mac OS X Server can include information about a domain with otherinformation in response to a computer's DHCP request. By default, MacOS X will accept and use Open Directory configurations received byDHCP. This is helpful both because it saves the time and effort ofmanually configuring each computer in a network.

For staticbinding, you configure access to directory domains using the DirectoryAccess utility, which is located in the Utilities folder inside Mac OSX's Applications folder. Directory Access includes plug-in modules thatcan be configured for each of Open Directory's features. For instance,the LDAP v3 plug-in manages Open Directory domain configuration andbinding.

Search paths are set by using the Authentication tab in Directory Access. You can choose to use an automatic search thatincludes DHCP-supplied domains and the local domain; local-only, inwhich only the local domain is used; and custom, which allows you tomanually configure and set the search path of available domains. Youcan also use the Contacts tab to set up LDAP search paths of domainsfor Mac OS X's Address Book application.
　　
Managing shared domains

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

An OpenDirectory Replica is a server that hosts a read-only copy of thedomain. Replicas allow for load balancing and support remote locationswhere a slow network link makes direct access to the Open DirectoryMaster impractical. Replicas also allow for fail-over in the case of afailure of the master.

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

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

As complexas Open Directory is, both as a whole and in the structure ofindividual domains, Apple has made the setup process extremely simple,provided you have DNS and other network services set up properlybeforehand. You can easily change an existing server into an OpenDirectory Master by simply selecting that role from a pop-up menu inMac OS X Server's "Server Admin" utility. Then you enter basic information about the domain, including an account that will haveadministrative authority over the domain, the LDAP search base for thedomain and the Kerberos realm that the domain will use.
　　
Youcan elect to set additional features at this time (or later) as well,including default domain password policies, whether computers mustcommunicate with the domain over secure connections, and whethercomputers accessing the domain must be bound to it. All of theseoptions can substantially increase security.

Setting upreplica servers and binding other servers to the domain are equallysimple. There are, of course, more advanced tools for someadministrative tasks, many of them being command-line tools that arebeyond the scope of this article. However, for most environments, thegraphical tools in Server Admin are all you need to get an OpenDirectory infrastructure up and running.

Kerberos and the Open Directory password server

Open Directory provides multiple mechanisms for securing passwords. Theoriginal mechanism used by Mac OS X Server was to store passwords as anattribute of the user account object. This feature is referred to as"basic passwords" and is still supported for backwards compatibilitywith older versions of Mac OS X and Mac OS X Server, though it must bechosen as a specific option for each user account.

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

Open Directory alsooffers the default Open Directory password type. This technique storesuser passwords outside of the domain itself in two places. The first isin a Kerberos realm. The second is in the Open Directory PasswordServer database.

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

By default, when a server is set up as an OpenDirectory Master, it is also set up as a Kerberos Key DistributionCenter (KDC). This makes Mac OS X Server one of the easiest platformsto set up as a KDC because the process is almost entirely automated. Itis also possible to use an alternate KDC -- including an ActiveDirectory domain controller, which is helpful in a multiplatformenvironment.

In addition to securing password storage, Kerberos offers significant passwordsecurity for user connections because it relies on tickets to authorizeaccess to any "Kerberized" services within a network. Thus, a user'spassword is transmitted only when he first logs in.
　　
Kerberosalso provides a seamless, single sign-on environment where users willnot be repeatedly asked to authenticate as they connect to servers andbrowse for Kerberized services. Under Mac OS X Server, these Kerberizedservices include the Mac OS X log-in window, e-mail, Apple FilingProtocol and Server Message Block protocols for Mac and Windowsfile/printer sharing, virtual private networks, file transfer protocolservices, Apache and Secure Shell access.
Because Mac OS X Serveruses a standard Kerberos installation, you can offer additionalKerberized services within your network using servers and clients ofother platforms, including Unix. Telnet and Rlogon are two examples ofUnix services that can now be used with Kerberos.

The OpenDirectory Password Server is good for those situations when Kerberosisn't an option. This can be useful for applications and services thatdon't support Kerberos as well as for times when there is a Kerberosfailure. The Open Directory Password Server supports a broad range ofstandard encryption types for interaction with a range of platforms andservices. Although it doesn't offer the secure and single sign-onadvantages of Kerberos, the Open Directory Password Server providessolid security that is much better than basic passwords.

Bydefault, when a user's password type is set to Open Directory, OpenDirectory will attempt to authenticate the user using Kerberos firstand only use the password server in those instances where Kerberosisn't available.

Managed client environment

Open Directory offers a rich managed client environment that can beused to secure and define the user environment for all users andcomputers. Virtually every aspect of the Mac OS X user experience canbe preset for new users or can be permanently defined so that it can'tbe modified.

When using Mac OS X Server 10.4 (Tiger) withcomputers running the same Mac OS X release, it is also possible tocreate preference manifests. These are XML files that can be used todefine the preferences settings of virtually any Mac OS X application.Managed preferences under Mac OS X can be set for individual users,groups or lists of computers.

Integrating with other directory service platforms

Active Directory integration is often the easiest, and there areseveral easy methods of integration for both Mac OS X computers and Mac OS X Server. Beyond Active Directory, Open Directory can be integratedwith almost any platform that is LDAP-based or supports LDAP queries.In fact, true integration between Open Directory and Active Directoryis often done using LDAP.
　　
Integrating directory servicesplatforms often begins with modifying the schema of the platformsinvolved to be able to support the additional objects and attributesthat make up Open Directory's schema. Often, the Open Directory schemawill also be modified to accommodate the needs of the other platform.By supporting the additional information types, it becomes possible tonot only perform queries between the platforms but also to store datafor specific features, such as managed preferences. While this is adaunting task, the rewards can be worth it in large environments thatneed a broad solution for differing types of systems.

Hosting a Windows Domain

For those environments that need to support authentication from Windowsworkstations, Open Directory can host a Windows NT-style domain. Inthese scenarios, the Open Directory Master acts as a Primary DomainController, and replicas function as Backup Domain Controllers. Thissetup is not always perfect, and the hosted domain is not an ActiveDirectory domain. However, it does provide for authentication andallows for the hosting of home directories and Windows profiles. And itworks well in many environments.