So You Want to Be a Mac OS X Server Admin? Understanding the Building Blocks of Open Directory and Mac OS X User Management
- Understanding Open Directory
- What About Older Macs Running Mac OS 9?
- Replication: What to Do When One Server Isnt Enough
- Keeping Passwords and Your Infrastructure Safe and Secure
- The Basics of Setting Up an Open Directory Server
- Getting Practical About Open Directory and User Accounts
- Users in Workgroup Manager: The Mac OS X Server Tool for Account Management
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
For more information on the Macintosh, visit our Macintosh Reference Guide or sign up for our Macintosh Newsletter.
Managing user accounts is a fundamental task for any systems administrator. Working with user and computer accounts in a network is often a common part of many IT and technical support jobs as well. To manage user accounts in a Mac OS X environment, it helps to understand how they are stored and accessed on both individual workstations and in shared directories in Mac OS X Server.
This article covers the conceptual and practical aspects of how Mac OS X workstations and servers use Apple’s Open Directory architecture to store and make use of user account information. It also includes information about computers and other resources within a network. First, I’ll explain what Open Directory is, how it works, and the basics of an Open Directory infrastructure. Then, I’ll move on the practical steps involved in creating and editing user accounts within Open Directory under Mac OS X Server.
Understanding Open Directory
Directory services are one of the backbones of a network operating system. Each major network operating system includes at least one type of directory service that stores information about users, servers and workstations, and network resources. A directory service is essentially a database that contains predetermined fields for storing information. This predetermined structure is called the service’s schema. Each type of directory service has a unique schema that formats data about users, groups, computers, printers, and so forth. It’s possible for an administrator to modify that schema if the fields included in it don’t provide enough flexibility for resources in a network, although this is usually done only if one needs to integrate multiple directory services in a single network (such as Apple’s Open Directory and Microsoft’s Active Directory).
In modern operating systems designed for use in a network, such as Mac OS X, a directory service exists on each computer to support multiple users of that computer. This local directory service typically includes just a list of user accounts that can be used for multiple users to log in to the computer, each with his or her own computing experience and using a folder on the local hard drive as each user’s home directory or home folder. The local directory service can also store information about which components of the computer a particular user is allowed to access.
Network operating systems, such as Mac OS X Server, include much more robust directory services. At a server level, directory services provide administrators with several important capabilities. The most significant of these is that they centralize the data that could be stored in the directory services of individual workstations in a single place.
Beyond storing directory data in a central place, network-based directory services allow that data to be shared with all the workstations and servers within a network. Users can authenticate against a shared directory for access to any workstation on the network, not just the one in their office or classroom. The user account can also be used for ownership of any files that they create anywhere within the network. Likewise, it can be used for setting access restrictions for not only files created by other users but also to files and folders created by the system administrator, to whole share points, to printers and other shared devices, and to establish predefined preferences and restrictions for any workstation or application to which the user has access. By incorporating home directories with directory services, users can maintain a consistent user experience across all workstations and have a secure place to store their files that can be accessed from any workstation.
Directory services under Mac OS X and Mac OS X Server are part of a multipart architecture called Open Directory. Open Directory goes beyond being a single directory service and truly goes beyond the basic functions of a directory service. It includes a series of components that manage access to multiple types of directory services (Apple’s LDAP implementation—which is often referred to simply and slightly confusingly as Open Directory, other LDAP directory types, Apple’s legacy NetInfo directory service, Microsoft’s Active Directory, and Unix NIS servers and BSD configuration files). Open Directory components also manage Mac OS X’s interaction with self-discovering network protocols such as AppleTalk, Rendezvous/Bon Jour, Microsoft’s SMB, and the open standard SLP protocol. In both the client and server versions of Mac OS X, you can manage each of these components by using the Directory Access application.
Although Open Directory is a very robust collection of network components, discussion of Open Directory generally refers to the Apple LDAP or NetInfo directory databases, which are used for storing and sharing directory data. Apple’s LDAP and NetInfo directory databases are the two that can be considered native to Mac OS X; that is, the operating system is designed specifically to interact with them and with their particular schema for storing directory information.
Open Directory is a central piece of Mac OS X, which was designed from the ground up as a multiuser and network operating system. The majority of Mac OS X components and applications interact with Open Directory. For example, the Mac OS X Login Window application, which authenticates user access to a computer, interacts with Open Directory whenever a user attempts the login. Login Window simply passes the username and password to Open Directory; Open Directory attempts to locate an entry in one of its databases (a user entry in a directory database can also be referred to as a user object or a user account) that matches the username entered and, assuming that it finds a match, verifies the password. The results are then passed back to the Login Window, which either processes the user’s login or rejects it.
For another example, the Mac OS X file system allows users to be designated as owners of the folders and files they create and enables access rights to be assigned to folders and files for other users. The file system isn’t concerned with usernames or passwords; it is concerned solely with user ID numbers that are associated as having access to or ownership of a folder or the group ID numbers that are specified as having some level of access to the folder. When a user tries to access the folder, the file system looks to Open Directory for the user ID number to know whether the user is the folder’s owner. If not, it looks to Open Directory to know whether the user has permission to access the folder or is a member of a group designated with access rights to the folder. The file system doesn’t need to know the user’s name or which groups the user belongs to. Open Directory has that information stored as part of the user object, along with the relevant user ID and group ID numbers.
Open Directory doesn’t just act as a moderator for user information. It can contain entries or objects for groups of users, workgroups (groups that have managed preferences settings), computers, computer lists, print queues, share points that are auto-mounted by computers, and varying kinds of presets. Each of these objects has a series of unique attributes that contain identification or configuration information. A user object, for example includes attributes (or database fields) for user ID number, full user name, shortname(s), password and password type, home directory location and storage quota, group membership, printer access and quotas, managed preferences configurations, email information, and administrative rights and options. Through the broad range of information that Open Directory stores, it acts as a perfect repository for the information that various operating system and application components might need to access. Keeping this information independent of the components or processes that need access to it ensures its integrity and availability. It also allows the information to be centrally stored and managed, whether on a local workstation or in a shared directory stored on a Mac OS X Server Open Directory server.
Apple calls individual Open Directory databases domains (they are also commonly called shared directories or shared domains). Each Mac OS X computer contains a built-in local Open Directory domain. This domain is a NetInfo domain that contains information about local users and local resources for that computer. Local domains provide you the ability to create multiple user accounts on a single computer. Those user accounts are limited to that particular computer. They can be used to connect to the computer over a network for file sharing, although this is accomplished using the Connect to Server option from the Finder’s Go menu. What happens when you use the Connect to Server command (if it is not part of a shared domain) is that the computer you are using establishes a connection to the requested computer (a server or a workstation with file sharing enabled) using a file sharing protocol, which will prompt you for a username password if both computers are not part of a shared directory domain. The file sharing protocol on the requested computer then accesses its local directory domain to determine whether you are allowed access to any shared folders.
This process is very different from a shared directory domain. A shared domain is an LDAP domain that is hosted on an Open Directory server (for older Mac OS X Server infrastructures, the domain may also be a shared NetInfo domain, although using shared NetInfo domains has been significantly discouraged in the two Mac OS X Server versions). The domain is shared over TCP/IP with other computers. When you log in to a computer that is configured to access a shared domain, the computer first looks for your user entry in its local NetInfo domain and, if it doesn’t find a match, looks to the shared domain. When you log in, specified share points can be mounted automatically, giving you access to a network home directory and possibly other shared folders as well. If you use the Connect to Server command to access resources on a server that is also part of the same directory domain (whether you are connecting the same server that is hosting the domain or another server that is part of the domain), your user account is verified based on the shared domain without you needing to provide any separate information for the server.
Shared domains are the basis of Mac OS X administration. They are where you store user accounts, create user groups, configure managed preferences, set up auto-mounting of share points, configure access to group folders and resources, and ca publish print queues to which your users can have access to and to which you can restrict their use. You can have a single shared domain or you can have several. If you have multiple directory domains, you need to determine the order in which Mac OS X computers will search them for Open Directory information. This process is called establishing a search path.
A search path exists for all Mac OS X computers. Even those with only local NetInfo domains have a search path, although their search path only contains the local domain. If you have a single shared domain, the search path would be first the local domain and then the shared domain. If you have more than one shared domain, the search path designates which shared domain to search first (and then second, third, and so on). Search paths can be configured in a number of ways.
Located in the /Applications/Utilities folder of any Mac OS X installation, Directory Access is the utility that allows you to configure which components of Open Directory are active and how those components interact with shared resources and shared directory domains. Directory Access allows you to configure access to a shared domain for a workstation (or, in certain situations, a server) and allows you to specify the workstation’s search path.
Directory Access consists of three tabs: Services, Authentication, and Contacts. The Services tab contains a list of all the modules that are part of Open Directory. Each of these modules relates either to a self-discovering network protocol or a directory service type. The Authentication tab allows you to specify the Open Directory search path. The Contacts tab allows you to specify a search path for contact information (which can also be stored in an LDAP directory). The Search path specified in the Contacts tab can theoretically be accessed by a number of Mac OS X applications, although only the Address Book and (because of its integration with Address Book) the Mac OS X Mail application make use of a Contacts search path in any practical method. Contacts search paths are configured in the same way as Authentication search paths.
Each Open Directory module listed on the Services tab can be enabled or disabled using the checkbox next to it. Note: you will need to authenticate using a local administrator account for the workstation using the padlock button to make changes in Directory Access, and you will need to click the Apply button to save and activate changes. Disabling those modules related to self-discovering protocols can help you restrict user access to those protocols. However, Open Directory modules don’t provide full control of all of these services. Those modules that provide directory services should be disabled only if you are certain that you will not provide authentication or user information based on those services.
By default, the search path is defined automatically as the local NetInfo domain and any shared domains specified by a DHCP server. You can manually configure a search path or you can set Directory Access to create one automatically using the Authentication tab. The Authentication tab contains a Search pop-up menu and a Directory Domain list. The Search menu allows you to configure an automatic search path (the default) in which shared domains provided by a DHCP server are searched after the local NetInfo domain (which is always first in any search path), a local directory search path that searches only the local NetInfo domain regardless of Open Directory module configurations, and a custom search path in which you manually specify which shared directories are included in the Directory Node list and the order in which they are searched.
To create a custom search path, you should first configure the appropriate Open Directory modules in the Services tab to access the directories you want to include in the search path. For Open Directory LDAP domains (those hosted by Mac OS X Server version 10.2 and higher), you would enable and configure the LDAPv3 module. With each version of Mac OS X, configuring this module has gotten significantly easier. In Mac OS X Tiger, it is simply a matter of clicking the New button and entering the IP address or DNS name of the Open Directory server (along with choosing whether SSL will be used to secure the connection, which requires SSL configuration of the server, and whether the directory domain will be used for user authentication and access and/or for contact search paths). Depending on the version of Mac OS X, you might also need to select Open Directory as the LDAP mappings for the domain, which specifies that the Open Directory schema is used by the domain, and enter the domain’s search base (which I’ll explain in a bit). Depending on the Mac OS X version, you might also need to configure the LDAPv3 module to allow automatic search paths to include domains specified by a DHCP server, as shown in the following figure.
)
Once access to the directories is configured, select Custom Path from the Authentication tab’s Search pop-up menu. Depending on the type of directories you choose, they can be listed automatically in the Directory Node list. If they are not, click the Add button. All available directories (that is, those you have configured and that the workstation can locate over the network) should be listed in the Available Directories dialog box that is displayed. Select the directories you want to include in your search path and click OK. They will be added to the Directory Domain list. Drag the directories into the appropriate order (top being first) to create your search path, noting that the local NetInfo/root directory is grayed-out because it is always searched first. If there are any directories in the Directory Domain list that you don’t want included, select them and click the Remove button. When you have configured your search path, click the Apply button to save and activate it. Restart the computer, and the new search path will be implemented.