Chapter 2. Directory Services Clients

In Chapter 1, we discussed Directory Services and the various types of information that a Directory Service can provide. In contrast, this chapter focuses on utilizing a centralized Directory Service for user and group resolution and authentication. Utilizing a centralized Directory Service is absolutely essential to the efficient management of your fleet of computers and eliminates the need to synchronize user and group databases across all of your computers.

Lightweight Directory Access Protocol (LDAP) is the building block for most modern directory services solutions. Whether you are using Microsoft's Active Directory or Apple's Open Directory, to a large degree the basis for their implementation lies in the LDAPv3 specification. As such, LDAP in this context consists of a communication protocol, a data scheme that is used to store directory information, and the replication infrastructure to distribute that data across multiple remote data stores. Because Mac OS X is built from the ground up to accommodate for LDAP, there are myriad of options in terms of automation and management functionality that can be provided to Mac OS X clients. This isn't to say that you can't leverage the same LDAP structures built in Chapter 1 in order to provide directory services to Microsoft Windows, but the context for this chapter will focus primarily on Mac OS X directory service clients. In Chapter 9, we will look at providing some aspects of directory services to Windows clients.

When a client is added to a directory services environment this is often referred to as binding. There are two general types of binding that can be performed by an OS X client. The first kind is referred to as a trusted, or authenticated, bind. With a trusted bind the client computer creates a representative computer object in the LDAP store, which contains the same AuthenticationAuthority record familiar to an OS X user account. From here on, the computer itself must use a locally stored key to authenticate to the directory in order to receive directory data. By authenticating, the computer proves that it is a member of the network, and thereby has certain elevated access, based on the trust relationship created at bind time. Trusted binding requires a password to establish this trust. The second type of binding is not necessarily binding at all; it simply involves configuring the client so that it should query a certain directory server for certain data, such as user names, passwords, and even policies. This type of bind is sometimes referred to as an anonymous bind. In these configurations, a client computer need not have an associated computer object in LDAP.

In Chapter 1, I covered setting up and using localized directory services. In Chapter 2, I'm going to dive into leveraging the Mac OS X Open Directory environment and other non-Microsoft based directory services solutions that leverage LDAP in order to provide a centralized directory service to client computers. I will begin by looking at binding to LDAP and then delve into the topics that will allow you to automate LDAP, mass deploy LDAP settings, and realize the full potential of your directory services solution. This chapter will end with a cursory glance at leveraging both NIS and BSD flat files for those environments still committed to 1990s style networking (although I refuse to cover Banyan Vines for posterities sake).