User manual APPLE LEOPARD - OPEN DIRECTORY ADMINISTRATION

Mac OS X Server Open Directory Administration For Version 10.5 Leopard Apple Inc. © 2007 Apple Inc. All rights reserved. The owner or authorized user of a valid copy of Mac OS X Server software may reproduce this publication for the purpose of learning to use such software. No part of this publication may be reproduced or transmitted for commercial purposes, such as selling copies of this publication or for providing paid-for support services. Every effort has been made to make sure that the information in this manual is correct. Apple Inc., is not responsible for printing or clerical errors. Apple 1 Infinite Loop Cupertino CA 95014-2084 www.apple.com The Apple logo is a trademark of Apple Inc., registered in the U.S. and other countries. Use of the "keyboard" Apple logo (Option-Shift-K) for commercial purposes without the prior written consent of Apple may constitute trademark infringement and unfair competition in violation of federal and state laws. Apple, the Apple logo, Mac, Macintosh, Xgrid, and Xserve are trademarks of Apple Inc., registered in the U.S. and other countries. Finder is a trademark of Apple Inc. Adobe and PostScript are trademarks of Adobe Systems Incorporated. UNIX is a registered trademark of The Open Group. Other company and product names mentioned herein are trademarks of their respective companies. Mention of third-party products is for informational purposes only and constitutes neither an endorsement nor a recommendation. Apple assumes no responsibility with regard to the performance or use of these products. 019-0935/2007-09-01 3 Contents Preface 11 12 12 14 14 15 16 16 17 17 19 19 20 21 21 23 24 25 25 27 28 28 29 30 30 31 32 33 33 33 34 About This Guide What's New in Version 10.5 What's in This Guide Using This Guide Using Onscreen Help Mac OS X Server Administration Guides Viewing PDF Guides on Screen Printing PDF Guides Getting Documentation Updates Getting Additional Information Directory Services with Open Directory Benefits of Using Directory Services Directory Services and Directory Domains A Historical Perspective Data Consolidation Data Distribution Uses of Directory Data Access to Directory Services Inside a Directory Domain Structure of LDAP Directory Information Local and Shared Directory Domains About the Local Directory Domain About Shared Directory Domains Shared Data in Existing Directory Domains SMB Services and Open Directory Open Directory as a Primary Domain Controller Open Directory as a BDC Open Directory Search Policies Search Policy Levels Local Directory Domain Search Policy Two-Level Search Policies Chapter 1 Chapter 2 3 35 36 38 38 Chapter 3 39 40 40 41 41 42 42 43 44 45 46 46 47 48 48 49 49 49 50 50 51 51 52 54 55 56 56 57 58 61 62 62 63 64 65 65 66 Multilevel Search Policies Automatic Search Policies Custom Search Policies Search Policies for Authentication and Contacts Open Directory Authentication Password Types Authentication and Authorization Open Directory Passwords Shadow Passwords Crypt Passwords Providing Secure Authentication for Windows Users Offline Attacks on Passwords Determining Which Authentication Option to Use Password Policies Single Sign-On Authentication Kerberos Authentication Breaking the Barriers to Kerberos Deployment Single Sign-On Experience Secure Authentication Ready to Move Beyond Passwords Multiplatform Authentication Centralized Authentication Kerberized Services Configuring Services for Kerberos After Upgrading Kerberos Principals and Realms Kerberos Authentication Process Open Directory Password Server and Shadow Password Authentication Methods Disabling Open Directory Authentication Methods Disabling Shadow Password Authentication Methods Contents of the Open Directory Password Server Database LDAP Bind Authentication Open Directory Planning and Management Tools General Planning Guidelines Estimating Directory and Authentication Requirements Identifying Servers for Hosting Shared Domains Replicating Open Directory Services Replica Sets Cascading Replication Planning the Upgrade of Multiple Open Directory Replicas Load Balancing in Small, Medium, and Large Environments Replication in a Multibuilding Campus Chapter 4 4 Contents 66 67 67 69 70 70 70 72 73 74 75 75 76 77 77 78 Chapter 5 79 79 80 81 81 81 83 85 85 86 87 87 88 90 91 91 92 93 94 95 97 98 99 100 102 Using an Open Directory Master, Replica, or Relay with NAT Open Directory Master and Replica Compatibility Mixing Active Directory and Open Directory Master and Replica Services Integrating with Existing Directory Domains Integrating Without Schema Changes Integrating with Schema Changes Avoiding Kerberos Conflicts with Multiple Directories Improving Performance and Redundancy Open Directory Security Service Access Control Lists (SACLs) Tiered Administration Tools for Managing Open Directory Services Server Admin Directory Utility Workgroup Manager Command-Line Tools Setting Up Open Directory Services Setup Overview Before You Begin Managing Open Directory on a Remote Server Turning Open Directory On Setting Up a Standalone Directory Service Setting Up an Open Directory Master Instructing Users How to Log In Setting Up a Primary Domain Controller Setting Up Windows Vista for Domain Login Setting Up Windows XP for Domain Login Setting Up Windows 2000 for Domain Login Setting Up an Open Directory Replica Creating Multiple Replicas of an Open Directory Master Setting Up Open Directory Relays for Cascading Replication Setting Up a Server as a BDC Setting Up Open Directory Failover Setting Up a Connection to a Directory Server Setting Up a Server as a Mac OS X Server PDC Domain Member Setting Up a Server as an Active Directory Domain Member Setting Up Single Sign-On Kerberos Authentication Setting Up an Open Directory Kerberos Realm Starting Kerberos After Setting Up an Open Directory Master Delegating Authority to Join an Open Directory Kerberos Realm Joining a Server to a Kerberos Realm Contents 5 Chapter 6 105 106 106 107 108 108 110 110 111 111 112 113 114 115 116 116 117 117 119 119 119 120 121 121 122 122 123 123 123 124 125 125 126 126 126 127 128 128 129 130 131 Managing User Authentication Composing a Password Changing a User's Password Resetting the Passwords of Multiple Users Changing a User's Password Type Changing the Password Type to Open Directory Changing the Password Type to Crypt Password Changing the Password Type to Shadow Password Enabling Single Sign-On Kerberos Authentication for a User Changing the Global Password Policy Setting Password Policies for Individual Users Selecting Authentication Methods for Shadow Password Users Selecting Authentication Methods for Open Directory Passwords Assigning Administrator Rights for Open Directory Authentication Keeping the Primary Administrator's Passwords in Sync Enabling LDAP Bind Authentication for a User Setting Passwords of Exported or Imported Users Migrating Passwords From Mac OS X Server v10.1 or Earlier Managing Directory Clients Connecting Clients to Directory Servers About Directory Server Connections Automated Client Configuration Adding an Active Directory Server Connection Adding an Open Directory Server Connection Removing a Directory Server Connection Editing a Directory Server Connection Monitoring Directory Server Connections Managing the Root User Account Enabling the Root User Account Changing the Root User Account Password Advanced Directory Client Settings About Advanced Directory Services Settings Setting Up Directory Utility on a Remote Server Configuring Mount Records for a Computer's Local Directory Domain Adding a Mount Record to the Local Directory Domain Removing a Mount Record from the Local Directory Domain Editing a Mount Record in the Local Directory Domain Using Advanced Search Policy Settings Defining Automatic Search Policies Defining Custom Search Policies Defining Local Directory Search Policies Chapter 7 Chapter 8 6 Contents 131 131 132 132 133 133 134 134 135 136 138 140 141 143 144 145 146 149 150 150 151 151 152 152 152 153 153 154 154 155 155 156 157 159 161 162 163 163 164 165 166 166 167 Waiting for a Search Policy Change to Take Effect Protecting Computers from a Malicious DHCP Server Using Advanced Directory Services Settings Enabling or Disabling Active Directory Service Enabling or Disabling LDAP Directory Services Using Advanced LDAP Service Settings Accessing LDAP Directories in Mail and Address Book Enabling or Disabling Use of a DHCP-Supplied LDAP Directory Showing or Hiding Configurations for LDAP Servers Configuring Access to an LDAP Directory Configuring Access to an LDAP Directory Manually Changing a Configuration for Accessing an LDAP Directory Duplicating a Configuration for Accessing an LDAP Directory Deleting a Configuration for Accessing an LDAP Directory Changing the Connection Settings for an LDAP Directory Changing the Security Policy for an LDAP Connection Configuring LDAP Searches and Mappings Setting Up Trusted Binding for an LDAP Directory Stopping Trusted Binding with an LDAP Directory Changing the Open/Close Timeout for an LDAP Connection Changing the Query Timeout for an LDAP Connection Changing the Rebind-Try Delay Time for an LDAP Connection Changing the Idle Timeout for an LDAP Connection Forcing Read-Only LDAPv2 Access Ignoring LDAP Server Referrals Authenticating an LDAP Connection Changing the Password Used for Authenticating an LDAP Connection Mapping Config Record Attributes for LDAP Directories Editing RFC 2307 Mapping to Enable Creating Users Preparing a Read-Only LDAP Directory for Mac OS X Populating LDAP Directories with Data for Mac OS X Using Advanced Active Directory Service Settings About Active Directory Access Configuring Access to an Active Directory Domain Setting Up Mobile User Accounts in Active Directory Setting Up Home Folders for Active Directory User Accounts Setting a UNIX Shell for Active Directory User Accounts Mapping the UID to an Active Directory Attribute Mapping the Primary Group ID to an Active Directory Attribute Mapping the Group ID in Group Accounts to an Active Directory Attribute Specifying a Preferred Active Directory Server Changing the Active Directory Groups That Can Administer the Computer Controlling Authentication from All Domains in the Active Directory Forest Contents 7 168 168 169 170 171 171 Chapter 9 173 173 174 174 175 176 177 177 177 178 178 179 179 180 180 180 181 182 183 183 184 184 186 186 187 187 188 189 189 190 190 190 193 194 195 Unbinding from the Active Directory Server Editing User Accounts and Other Records in Active Directory Setting Up LDAP Access to Active Directory Domains Specifying NIS Settings Specifying BSD Configuration File Settings Setting Up Data in BSD Configuration Files Maintaining Open Directory Services Controlling Access to Open Directory Servers and Services Controlling Access to a Server's Login Window Controlling Access to SSH Service Configuring Service Access Control Configuring Record Privileges Monitoring Open Directory Checking the Status of an Open Directory Server Monitoring Replicas and Replays of an Open Directory Master Viewing Open Directory Status and Logs Monitoring Open Directory Authentication Viewing and Editing Directory Data Showing the Directory Inspector Hiding the Directory Inspector Setting Directory Access Controls (DACs) Deleting Records Deleting Users or Computers Using Inspector or the Command Line Changing a User's Short Name Importing Records of Any Type Setting Options for an Open Directory Server Setting a Binding Policy for an Open Directory Server Setting a Security Policy for an Open Directory Server Changing the Location of an LDAP Database Limiting Search Results for LDAP Service Setting the Search Timeout Interval for LDAP Service Setting up SSL for LDAP Service Creating a Custom SSL Configuration for LDAP Managing Open Directory Replication Scheduling Replication of an Open Directory Master or Primary Domain Controller (PDC) Synchronizing an Open Directory Replica or BDC on Demand Making an Open Directory Replica into a Relay Promoting an Open Directory Replica Decommissioning an Open Directory Replica Archiving an Open Directory Master Restoring an Open Directory Master 8 Contents Chapter 10 199 199 199 200 200 200 200 201 201 201 201 201 202 202 202 202 203 203 205 205 206 Solving Open Directory Problems Solving Open Directory Master and Replica Problems If Kerberos Is Stopped on an Open Directory Master or Replica If You Can't Create an Open Directory Replica If You Can't Create an Open Directory Master or Replica from a Configuration File If You Can't Connect a Replica to Your Relay If You Can't Join an Open Directory Replica to an Open Directory that is a Subordinate of an Active Directory Server Solving Directory Connection Problems If a Delay Occurs During Startup Solving Authentication Problems If You Can't Change a User's Open Directory Password If a User Can't Access Some Services If a User Can't Authenticate for VPN Service If You Can't Change a User's Password Type to Open Directory If Users Relying on a Password Server Can't Log In If Users Can't Log In with Accounts in a Shared Directory Domain If You Can't Log In as an Active Directory User If Users Can't Authenticate Using Single Sign-On Kerberos If Users Can't Change Their Passwords If You Can't Join a Server to an Open Directory Kerberos Realm If You Must Reset an Administrator Password Mac OS X Directory Data Open Directory Extensions to LDAP Schema Object Classes in Open Directory LDAP Schema Attributes in Open Directory LDAP Schema Mapping Standard Record Types and Attributes to LDAP and Active Directory Mappings for Users Mappings for Groups Mappings for Mounts Mappings for Computers Mappings for ComputerLists Mappings for Config Mappings for People Mappings for PresetComputerLists Mappings for PresetGroups Mappings for PresetUsers Mappings for Printers Mappings for AutoServerSetup Mappings for Locations Standard Open Directory Record Types and Attributes Standard Attributes in User Records Appendix 207 208 209 217 237 238 241 242 243 244 245 246 248 248 249 251 252 253 253 253 Contents 9 258 259 260 261 262 Glossary Index 263 271 Standard Attributes in Group Records Standard Attributes in Computer Records Standard Attributes in Computer Group Records Standard Attributes in Mount Records Standard Attributes in Config Records 10 Contents This guide describes the directory and authentication services you can set up using Mac OS X Server. It also explains how to configure Mac OS X Server and Mac OS X client computers for directory services. Mac OS X Server's Open Directory provides directory and authentication services for mixed networks of Mac OS X, Windows, and UNIX computers. Open Directory uses OpenLDAP, the open source implementation of Lightweight Directory Access Protocol (LDAP), to provide directory services. It's compatible with other standards-based LDAP servers, and can be integrated with proprietary services such as Microsoft's Active Directory and Novell's eDirectory. For the LDAP database backend, Open Directory uses the open source Berkeley Database. It's a highly scalable database for high-performance indexing of hundreds of thousands of user accounts and other records. Open Directory plug-ins enable a Mac OS X client or Mac OS X Server computer to read and write authoritative information about users and network resources from any LDAP server--even Microsoft's proprietary Active Directory. The server can also access records in legacy directories such as NIS and local BSD configuration files (/etc). Open Directory also provides authentication service. It can securely store and validate the passwords of users who want to log in to client computers on your network or to use other network resources that require authentication. Open Directory can enforce such policies as password expiration and minimum length. Open Directory can also authenticate Windows computer users for domain log in, file service, and other Windows services (SMB services) provided by Mac OS X Server. An MIT Kerberos Key Distribution Center (KDC) is fully integrated with Open Directory and provides strong authentication with support for secure single sign-on. This means users can authenticate only once, with a single user name and password pair, for access to the range of Kerberos-enabled network services. Preface 11 About This Guide For services that don't accept Kerberos authentication, the integrated Secure Authentication and Service Layer (SASL) service negotiates the strongest possible authentication mechanism. In addition, directory and authentication replication maximizes availability and scalability. By creating replicas of Open Directory servers, you can easily maintain failover servers and remote servers for fast client interaction on distributed networks. What's New in Version 10.5 Mac OS X Server version 10.5 offers the following major enhancements in Open Directory:  Simplified configuration of LDAPv3 access: Directory Utility assists you in setting up a connection to an LDAP directory.  Improved Server Admin Interface: Server Admin has an easier-to-use interface.  Improved Authorization: You can have a Mac OS X Open Directory server join an Active Directory server and use cross-domain authorization.  Improved LDAP server: Mac OS X Server v10.5 uses OpenLDAP version 2.3.x and Berkeley DB version 4.2.52.  Improved local domain: Mac OS X uses a local directory domain for local computer authentication.  Improved replication: You can have a two-tier replication of a single master (also referred to as cascading replication). This gives you up to 1056 replicas of a single Open Directory master and more efficient replica sets or replica picking for password server, LDAP, and Kerberos.  Improved Administration: You can have more scalability of directory domain administration by using tiered administration.  Improved Application support: You can use Open Directory with applications such as Apple Wiki. What's in This Guide This guide includes the following chapters:  Chapter 1, "Directory Services with Open Directory," explains what directory domains are, how they are used, and how they are organized.  Chapter 2, "Open Directory Search Policies," describes search policies with one or more directory domains, and describes automatic, custom, and local-only search policies.  Chapter 3, "Open Directory Authentication," describes Open Directory authentication, shadow and crypt passwords, Kerberos, LDAP bind, and single sign-on. 12 Preface About This Guide  Chapter 4, "Open Directory Planning and Management Tools," helps you assess your directory domain needs, estimate directory and authentication requirements, identify servers for hosting shared domains, improve performance and redundancy, deal with replication in a multibuilding campus, and make your Open Directory services secure. This chapter also introduces the tools you use to manage Open Directory services.  Chapter 5, "Setting Up Open Directory Services," tells you how to set up an Open Directory server and explains the configurations and roles you can configure. This chapter also tells you how to set options of the LDAP service of an Open Directory master or replica and explains how to set up single sign-on Kerberos authentication on an Open Directory master.  Chapter 6, "Managing User Authentication," describes how to set password policies, change a user's password type, assign administrator rights for Open Directory authentication, reset passwords of imported user accounts, and migrate passwords to Open Directory authentication.  Chapter 7, "Managing Directory Clients," explains how to use Directory Utility to configure and manage how Mac OS X computers access directory services.  Chapter 8, "Advanced Directory Client Settings," explains how to use the Directory Utility application to enable, disable, and configure service discovery protocols. It also explains how to configure authentication and contacts search policies and explains how to configure access to directory domains, including LDAP, Active Directory, NIS, and BSD configuration files.  Chapter 9, "Maintaining Open Directory Services," tells you how to monitor Open Directory services, view and edit directory data with the Inspector, archive an Open Directory master, and perform other directory maintenance.  Chapter 10, "Solving Open Directory Problems," describes common problems and provides information on what to do if you encounter problems while working with Open Directory. In addition, the Appendix, "Mac OS X Directory Data," lists the Open Directory extensions to the LDAP schema and specifies the standard record types and attributes of Mac OS X. Finally, the Glossary defines terms you'll encounter as you read this guide. Note: Because Apple periodically releases new versions and updates to its software, images shown in this book may be different from what you see on your screen. Preface About This Guide 13 Using This Guide The chapters in this guide are arranged in the order that you're likely to need them when setting up and managing Open Directory on your server:  Read Chapter 1 through Chapter 3 to acquaint yourself with Open Directory concepts: directory services, search policies, and authentication.  Read Chapter 4 when you're ready to plan directory services and password authentication for your network.  After you finish planning, use the instructions in Chapter 5 to set up Open Directory services.  When you must set password policies or change password settings for a user account, look for instructions in Chapter 6.  To set up or change how a Mac OS X or Mac OS X Server computer accesses directory domains, follow the instructions in Chapter 7.  To configure advanced settings for users using Directory Utility, use Chapter 8.  For ongoing maintenance of directory and authentication services, use Chapter 9.  If you have problems with Open Directory, use Chapter 10 to investigate possible solutions. Using Onscreen Help You can get task instructions on screen in Help Viewer while you're managing Leopard Server. You can view help on a server or an administrator computer. (An administrator computer is a Mac OS X computer with Leopard Server administration software installed on it.) To get help for an advanced configuration of Leopard Server: m Open Server Admin or Workgroup Manager and then:  Use the Help menu to search for a task you want to perform.  Choose Help > Server Admin Help or Help > Workgroup Manager Help to browse and search the help topics. The onscreen help contains instructions taken from Server Administration and other advanced administration guides described in "Mac OS X Server Administration Guides" on page 15. To see the most recent server help topics: m Make sure the server or administrator computer is connected to the Internet while you're getting help. Help Viewer automatically retrieves and caches the most recent server help topics from the Internet. When not connected to the Internet, Help Viewer displays cached help topics. 14 Preface About This Guide Mac OS X Server Administration Guides Getting Started covers installation and setup for standard and workgroup configurations of Mac OS X Server. For advanced configurations, Server Administration covers planning, installation, setup, and general server administration. A suite of additional guides, listed below, covers advanced planning, setup, and management of individual services. You can get these guides in PDF format from the Mac OS X Server documentation website: www.apple.com/server/documentation This guide... Getting Started and Installation & Setup Worksheet Command-Line Administration File Services Administration iCal Service Administration iChat Service Administration Mac OS X Security Configuration Mac OS X Server Security Configuration Mail Service Administration Network Services Administration Open Directory Administration Podcast Producer Administration Print Service Administration QuickTime Streaming and Broadcasting Administration Server Administration tells you how to: Install Mac OS X Server and set it up for the first time. Install, set up, and manage Mac OS X Server using UNIX commandline tools and configuration files. Share selected server volumes or folders among server clients using the AFP, NFS, FTP, and SMB protocols. Set up and manage iCal shared calendar service. Set up and manage iChat instant messaging service. Make Mac OS X computers (clients) more secure, as required by enterprise and government customers. Make Mac OS X Server and the computer it's installed on more secure, as required by enterprise and government customers. Set up and manage IMAP, POP, and SMTP mail services on the server. Set up, configure, and administer DHCP, DNS, VPN, NTP, IP firewall, NAT, and RADIUS services on the server. Set up and manage directory and authentication services, and configure clients to access directory services. Set up and manage Podcast Producer service to record, process, and distribute podcasts. Host shared printers and manage their associated queues and print jobs. Capture and encode QuickTime content. Set up and manage QuickTime streaming service to deliver media streams live or on demand. Perform advanced installation and setup of server software, and manage options that apply to multiple services or to the server as a whole. Use NetBoot, NetInstall, and Software Update to automate the management of operating system and other software used by client computers. Use data and service settings from an earlier version of Mac OS X Server or Windows NT. System Imaging and Software Update Administration Upgrading and Migrating Preface About This Guide 15 This guide... User Management Web Technologies Administration Xgrid Administration and High Performance Computing Mac OS X Server Glossary tells you how to: Create and manage user accounts, groups, and computers. Set up managed preferences for Mac OS X clients. Set up and manage web technologies, including web, blog, webmail, wiki, MySQL, PHP, Ruby on Rails, and WebDAV. Set up and manage computational clusters of Xserve systems and Mac computers. Learn about terms used for server and storage products. Viewing PDF Guides on Screen While reading the PDF version of a guide onscreen:  Show bookmarks to see the guide's outline, and click a bookmark to jump to the corresponding section.  Search for a word or phrase to see a list of places where it appears in the document. Click a listed place to see the page where it occurs.  Click a cross-reference to jump to the referenced section. Click a web link to visit the website in your browser. Printing PDF Guides If you want to print a guide, you can take these steps to save paper and ink:  Save ink or toner by not printing the cover page.  Save color ink on a color printer by looking in the panes of the Print dialog for an option to print in grays or black and white.  Reduce the bulk of the printed document and save paper by printing more than one page per sheet of paper. In the Print dialog, change Scale to 115% (155% for Getting Started). Then choose Layout from the untitled pop-up menu. If your printer supports two-sided (duplex) printing, select one of the Two-Sided options. Otherwise, choose 2 from the Pages per Sheet pop-up menu, and optionally choose Single Hairline from the Border menu. (If you're using Mac OS X v10.4 or earlier, the Scale setting is in the Page Setup dialog and the Layout settings are in the Print dialog.) You may want to enlarge the printed pages even if you don't print double sided, because the PDF page size is smaller than standard printer paper. In the Print dialog or Page Setup dialog, try changing Scale to 115% (155% for Getting Started, which has CD-size pages). 16 Preface About This Guide Getting Documentation Updates Periodically, Apple posts revised help pages and new editions of guides. Some revised help pages update the latest editions of the guides.  To view new onscreen help topics for a server application, make sure your server or administrator computer is connected to the Internet and click "Latest help topics" or "Staying current" in the main help page for the application.  To download the latest guides in PDF format, go to the Mac OS X Server documentation website: www.apple.com/server/documentation Getting Additional Information For more information, consult these resources:  Read Me documents--important updates and special information. Look for them on the server discs.  Mac OS X Server website (www.apple.com/server/macosx)--gateway to extensive product and technology information.  Mac OS X Server Support website (www.apple.com/support/macosxserver)--access to hundreds of articles from Apple's support organization.  Apple Service & Support website (www.apple.com/support)--access to hundreds of articles from Apple's support organization.  Apple Training website (www.apple.com/training)--instructor-led and self-paced courses for honing your server administration skills.  Apple Discussions website (discussions.apple.com)--a way to share questions, knowledge, and advice with other administrators.  Apple Mailing Lists website (www.lists.apple.com)--subscribe to mailing lists so you can communicate with other administrators using email.  OpenLDAP website (www.openldap.org)--learn about the open source software that Open Directory uses to provide LDAP directory service.  MIT Kerberos website (web.mit.edu/kerberos/www)--get background information and specifications for the protocol that Open Directory uses to provide robust single signon authentication.  Berkeley DB website (www.sleepycat.com)--investigate feature descriptions and technical documentation for the open source database that Open Directory uses to store LDAP directory data.  RFC3377, "Lightweight Directory Access Protocol (v3): Technical Specification" (www.rfc-editor.org/rfc/rfc3377.txt)--lists a set of eight other Request for Comment (RFC) documents with overview information and detailed specifications for the LDAPv3 protocol. Preface About This Guide 17 18 Preface About This Guide 1 Directory Services with Open Directory 1 A directory service provides a central repository for information about computer users and network resources in an organization. Benefits of Using Directory Services Storing administrative data in a central repository has many benefits:  Reduces data entry effort  Certifies that network services and clients have consistent information about users and resources  Simplifies administration of users and resources  Provides identification, authentication, and authorization information for other network services In education and enterprise environments, directory services are the ideal way to manage users and computing resources. Organizations with as few as 10 people can benefit by deploying a directory service. Directory services are doubly beneficial: they simplify system and network administration, and they simplify a user's experience on the network. With directory services, administrators can maintain information about all users--such as their names, passwords, and locations of network home directories--centrally rather than on each computer. Directory services can also maintain centralized information about printers, computers, and other network resources. Centralizing information about users and resources can reduce the system administrator's information management burden, and each user has a centralized user account for logging in on any authorized computer on the network. With centralized directory service and file service set up to host network home folders, wherever a user logs in, the user gets the same home folder, personal desktop, and individual preferences. The user always has access to personal networked files and can easily locate and use authorized network resources. 19 Directory Services and Directory Domains A directory service acts as an intermediary between application and system software processes, which need information about users and resources, and the directory domains that store the information. As shown in the following illustration, Open Directory provides directory services for Mac OS X and Mac OS X Server. Users Groups Printers Open Directory Application and system software processes Computers Mounts Directory domains Open Directory can access information in one or several directory domains. A directory domain stores information in a specialized database that is optimized to handle many requests for information and to find and retrieve information quickly. Processes running on Mac OS X computers can use Open Directory services to save information in directory domains. For example, when you create a user account with Workgroup Manager, it has Open Directory store user name and other account information in a directory domain. You can then review user account information in Workgroup Manager, which uses Open Directory to retrieve the user information from a directory domain. 20 Chapter 1 Directory Services with Open Directory Other application and system software processes can also use the user account information stored in directory domains. When someone attempts to log in to a Mac OS X computer, the login process uses Open Directory services to validate the user name and password: Directory domain Workgroup Manager Open Directory A Historical Perspective Like Mac OS X, Open Directory has a UNIX heritage. Open Directory provides access to administrative data that UNIX systems have generally kept in configuration files, which require painstaking work to maintain. (Some UNIX systems still rely on configuration files.) Open Directory consolidates the data and distributes it for ease of access and maintenance. Data Consolidation For years, UNIX systems have stored administrative information in a collection of files located in the /etc directory, as show in the following illustration. /etc/hosts /etc/group UNIX processes /etc/master.passwd This scheme requires each UNIX computer to have its own set of files, and processes that are running on a UNIX computer read its files when they need administrative information. Chapter 1 Directory Services with Open Directory 21 If you're experienced with UNIX, you probably know about the files in the /etc directory--group, hosts, hosts.equiv, master.passwd, and so forth. For example, a UNIX process that needs a user's password consults the /etc/master.passwd file. The /etc/master.passwd file contains a record for each user account. A UNIX process that needs group information consults the /etc/group file. Open Directory consolidates administrative information, simplifying the interactions between processes and the administrative data they create and use: Open Directory Mac OS X processes Processes no longer need to know how and where administrative data is stored. Open Directory gets the data for them. If a process needs the location of a user's home folder, the process has Open Directory retrieve the information. Open Directory finds the requested information and then returns it, insulating the process from the details of how the information is stored, as shown in the following illustration. Directory domain Directory domain Open Directory Mac OS X processes If you set up Open Directory to access administrative data from more than one directory domain, Open Directory consults them as needed. Some data stored in a directory domain is identical to data stored in UNIX configuration files. For example, the home folder location, real name, user ID, and group ID are stored in the user records of a directory domain instead of the standard /etc/passwd file. 22 Chapter 1 Directory Services with Open Directory However, a directory domain stores much more data to support functions that are unique to Mac OS X, such as support for managing Mac OS X client computers. Data Distribution A characteristic of UNIX configuration files is that the administrative data they contain is available only to the computer they are stored on. Each computer has its own UNIX configuration files. With UNIX configuration files, each computer that someone wants to use must have that person's user account settings stored on it, and each computer must store the account settings for every person who can use the computer. To set up a computer's network settings, the administrator must to go to the computer and enter the IP address and other information that identifies the computer on the network. Similarly, when user or network information must be changed in UNIX configuration files, the administrator must make the changes on the computer where the files reside. Some changes, such as network settings, require the administrator to make the same changes on multiple computers. This approach becomes unwieldy as networks grow in size and complexity. Open Directory solves this problem by letting you store administrative data in a directory domain that can be managed by a network administrator from one location. Open Directory lets you distribute the information so it is visible on a network to the computers that need it and the administrator who manages it, as shown in the following illustration. Directory domain System administrator Open Directory Users Chapter 1 Directory Services with Open Directory 23 Uses of Directory Data Open Directory makes it possible to consolidate and maintain network information easily in a directory domain, but this information has value only if application and system software processes running on network computers access the information. Here are some ways in which Mac OS X system and application software use directory data:  Login: Workgroup Manager can create user records in a directory domain, and these records can be used to authenticate users who log in to Mac OS X computers and Windows computers. When a user specifies a name and a password in the Mac OS X login window, the login process asks Open Directory to authenticate the name and password. Open Directory uses the name to find the user's account record in a directory domain and uses other data in the user record to validate the password.  Folder and file access: After logging in, a user can access files and folders. Mac OS X uses other data from the user record to determine the user's access privileges for each file or folder.  Home folders: Each user record in a directory domain stores the location of the user's home folder. This is where the user keeps personal files, folders, and preferences. A user's home folder can be located on a computer the user always uses or it can be located on a network file server.  Automount share points: Share points can be configured to automount (appear automatically) in the /Network folder (the Network globe) in the Finder windows of client computers. Information about these automount share points is stored in a directory domain. Share points are folders, disks, or disk partitions you have made accessible over the network.  Mail account settings: Each user's record in a directory domain specifies whether the user has mail service, which mail protocols to use, how to present incoming mail, whether to alert the user when mail arrives, and so forth.  Resource usage: Disk, print, and mail quotas can be stored in each user record of a directory domain.  Managed client information: The administrator can manage the Mac OS X environment of users whose account records are stored in a directory domain. The administrator makes mandatory preference settings that are stored in the directory domain and override users' personal preferences.  Group management: In addition to user records, a directory domain also stores group records. Each group record affects all users who are in the group. Information in group records specifies preference settings for group members. Group records also determine access to files, folders, and computers. 24 Chapter 1 Directory Services with Open Directory  Managed network views: The administrator can set up custom views that users see when they select the Network icon in the sidebar of a Finder window. Because these managed network views are stored in a directory domain, they're available automatically when a user logs in. Access to Directory Services Open Directory can access directory domains for the following kinds of directory services:  Lightweight Directory Access Protocol (LDAP), an open standard common in mixed environments of Macintosh, UNIX, and Windows systems. LDAP is the native directory service for shared directories in Mac OS X Server.  Local directory domain, the local directory service for every Mac OS X and Mac OS X Server version 10.5 or later.  Active Directory, the directory service of Microsoft Windows 2000 and 2003 servers.  Network Information System (NIS), the directory service of many UNIX servers.  BSD flat files, the legacy directory service of UNIX systems. Inside a Directory Domain Information in a directory domain is organized by record type. Record types are specific categories of information, such as users, groups, and computers. For each record type, a directory domain can contain any number of records. Each record is a collection of attributes, and each attribute has one or more values. If you think of each record type as a spreadsheet that contains a category of information, then records are like the rows of the spreadsheet, attributes are like spreadsheet columns, and each spreadsheet cell contains one or more values. For example, when you define a user account by using Workgroup Manager, you are creating a user record (a record of the "user" record type). The settings you configure for the user account--short name, full name, home folder location, and so on-- become values of attributes in the user record. The user record and the values of its attributes reside in a directory domain. In some directory services, such as LDAP and Active Directory, directory information is organized by object class. Like record types, object classes define categories of information. An object class defines similar information, named entries, by specifying attributes that an entry must or may contain. For an object class, a directory domain can contain multiple entries, and each entry can contain multiple attributes. Some attributes have a single value, while others have multiple values. For example, the inetOrgPerson object class defines entries that contain user attributes. Chapter 1 Directory Services with Open Directory 25 The inetOrgPerson class is a standard LDAP class defined by RFC 2798. Other standard LDAP object classes and attributes are defined by RFC 2307. Open Directory's default object classes and attributes are based on these RFCs. A collection of attributes and record types or object classes provides a blueprint for the information in a directory domain. This blueprint is named the schema of the directory domain. However, Open Directory uses a directory-based schema that is different from a locally based stored schema. The challenge of using a locally based schema configuration file, with an Open Directory master that services replica servers, is that if you change or add an attribute to the locally based schema of a Open Directory master you must also make that change to each replica. Depending on the number of replicas you have, the manual update process might take an enormous amount of time. If you don't make the same schema change locally on each replica, your replica servers will generate errors and fail when values for the newly added attribute are sent to the replica servers. To eliminate this possibility of failure Mac OS X uses a directory-based schema that is stored in the directory database and is automatically updated for each replica server from the replicated directory database. This keeps the schema for all replicas synchronized and provides greater flexibility to make changes to the schema. 26 Chapter 1 Directory Services with Open Directory Structure of LDAP Directory Information In an LDAP directory, entries are arranged in a hierarchical treelike structure. In some LDAP directories, this structure is based on geographic and organizational boundaries. More commonly, the structure is based on Internet domain names. In a simple directory organization, entries representing users, groups, computers, and other object classes are immediately below the root level of the hierarchy, as shown here: dc=com dc=example cn=users cn=groups cn=computers uid=anne cn=Anne Johnson uid=juan cn=Juan Chavez An entry is referenced by its distinguished name (DN), which is constructed by taking the name of the entry, referred to as the relative distinguished name (RDN), and concatenating the names of its ancestor entries. For example, the entry for Anne Johnson could have an RDN of uid=anne and a DN of uid=anne, cn=users, dc=example, dc=com. The LDAP service retrieves data by searching the hierarchy of entries. The search can begin at any entry. The entry where the search begins is the search base. You can specify a search base by giving the distinguished name of an entry in the LDAP directory. For example, the search base cn=users, dc=example, dc=com specifies that the LDAP service begin searching at the entry whose cn attribute has a value of "users." You can also specify how much of the LDAP hierarchy to search below the search base. The search scope can include all subtrees below the search base or the first level of entries below the search base. If you use command-line tools to search an LDAP directory, you can also restrict the search scope to include only the search base entry. Chapter 1 Directory Services with Open Directory 27 Local and Shared Directory Domains Where you store your server's user information and other administrative data is determined by whether the data must be shared. This information can be stored in the server's local directory domain or in a shared directory domain. About the Local Directory Domain Every Mac OS X computer has a local directory domain. A local directory domain's administrative data is visible only to applications and system software running on the computer where the domain resides. It is the first domain consulted when a user logs in or performs some other operation that requires data stored in a directory domain. When the user logs in to a Mac OS X computer, Open Directory searches the computer's local directory domain for the user's record. If the local directory domain contains the user's record (and if the user entered the correct password), the login process proceeds and the user gets access to the computer. After login, the user could choose "Connect to Server" from the Go menu and connect to Mac OS X Server for file service. In this case, Open Directory on the server searches for the user's record in the server's local directory domain. If the server's local directory domain has a record for the user (and if the user enters the correct password), the server grants the user access to file services, as shown below: Log in to Mac OS X Local directory domain Connect to Mac OS X Server for file service Local directory domain When you set up a Mac OS X computer, its local directory domain is created and populated with records. For example, a user record is created for the user who performed the installation. It contains the user name and password entered during setup, and other information, such as a unique ID for the user and the location of the user's home folder. 28 Chapter 1 Directory Services with Open Directory About Shared Directory Domains Although Open Directory on any Mac OS X computer can store administrative data in the computer's local directory domain, the real power of Open Directory is that it lets multiple Mac OS X computers share administrative data by storing the data in shared directory domains. When a computer is configured to use a shared domain, administrative data in the shared domain is also visible to applications and system software running on that computer. If Open Directory does not find a user's record in the local directory domain of a Mac OS X computer, Open Directory can search for the user's record in any shared domains the computer has access to. In the following example, the user can access both computers because the shared domain accessible from both computers contains a record for the user. Shared directory domain Log in to Mac OS X Local directory domain Connect to Mac OS X Server for file service Local directory domain Shared domains generally reside on servers because directory domains store extremely important data, such as the data for authenticating users. Access to servers is usually tightly restricted to protect the data on them. In addition, directory data must always be available. Servers often have extra hardware features that enhance their reliability, and servers can be connected to uninterruptible power sources. Chapter 1 Directory Services with Open Directory 29 Shared Data in Existing Directory Domains Some organizations--such as universities and worldwide corporations--maintain user information and other administrative data in directory domains on UNIX or Windows servers. Open Directory can search these non-Apple domains and shared Open Directory domains of Mac OS X Server systems, as shown in the illustration below. Mac OS X Server Local directory domain Shared directory domain Windows server Active Directory domain Local directory domain Mac OS X user Mac OS X user Windows user The order in which Mac OS X searches directory domains is configurable. A search policy determines the order in which Mac OS X searches directory domains. Search policies are explained in Chapter 2, "Open Directory Search Policies." SMB Services and Open Directory You can configure your Mac OS X Server with Open Directory and SMB services to serve Windows based workstations. Using these to services together, you can configure your Mac OS X Server to be a primary domain controller (PDC) or a backup domain controller (BDC). 30 Chapter 1 Directory Services with Open Directory Open Directory as a Primary Domain Controller Mac OS X Server can be configured to serve as a Windows PDC, which enables users of Windows NT-compatible workstations to log in using domain accounts. A PDC gives each Windows user one user name and password for logging in from any Windows NT 4.x, Windows 2000, Windows XP, and Windows Vista workstation on the network. Then, instead of logging in with a user name and password that are defined locally on a workstation, each user can log in with the user name and password that are defined on the PDC. The same user account that can be used for logging in from a Windows workstation can also be used for logging in from a Mac OS X computer. Therefore, someone who uses both platforms can have the same home folder, mail account, and print quotas on both platforms. Users can change their passwords while logging in to the Windows domain. User accounts are stored in the server's LDAP directory with group, computer, and other information. The PDC has access to this directory information because you set up the PDC on a server that is an Open Directory master, which hosts an LDAP directory. Further, the PDC uses the Open Directory master's Password Server to authenticate users when they log in to the Windows domain. The Password Server can validate passwords using NTLMv2, NTLMv1, LAN Manager, and other authentication methods. The Open Directory master can also have a Kerberos Key Distribution Center (KDC). The PDC doesn't use Kerberos to authenticate users for Windows services, but mail and other services can be configured to use Kerberos to authenticate Windows workstation users who have accounts in the LDAP directory. To have its password validated by the Open Directory Password Server and Kerberos, a user account must have a password type of Open Directory. A user account with a password type of crypt password can't be used for Windows services because a crypt password isn't validated using the NTLMv2, NTLMv1, or LAN Manager authentication methods. The server can also have user accounts in its local directory domain. Every Mac OS X Server has one. The PDC doesn't use these accounts for Windows domain login, but the PDC can use these accounts to authenticate users for Windows file service and other services. User accounts in the local directory domain that have a password type of shadow password can be used for Windows services because a shadow password can be validated using NTLMv2, NTLMv1, LAN Manager, and other authentication methods. Chapter 1 Directory Services with Open Directory 31 For compatibility, Mac OS X Server supports user accounts that were configured to use the legacy Authentication Manager technology for password validation in Mac OS X Server versions 10.0­10.2. After upgrading a server to Mac OS X Server version 10.5, existing users can continue to use their same passwords. A user account uses Authentication Manager if the account is in a local directory domain that Authentication Manager has been enabled for, and if the account is set to use a crypt password. If you migrate a directory from NetInfo to LDAP, all user accounts that used Authentication Manager for password validation are converted to have a password type of Open Directory. When setting up Mac OS X Server as a PDC, make sure your network doesn't have another PDC with the same domain name. The network can have multiple Open Directory masters, but it can have only one PDC. Open Directory as a BDC Setting Mac OS X as a BDC provides failover and backup for the PDC. The PDC and BDC share Windows client requests for domain login and other directory and authentication services. If the Mac OS X Server PDC becomes unavailable, the Mac OS X Server BDC provides domain login and other directory and authentication services. The BDC has a synchronized copy of the PDC's user, group, computer, and other directory data. The PDC and BDC also have synchronized copies of authentication data. Mac OS X Server automatically synchronizes the directory and authentication data. Before setting up Mac OS X Server as a BDC, you must set up the server as an Open Directory replica. The BDC uses the read-only LDAP directory, Kerberos KDC, and Password Server of the Open Directory replica. Mac OS X Server synchronizes the PDC and BDC by automatically updating the Open Directory replica with changes made to the Open Directory master. You use Server Admin after installation to make Mac OS X Server an Open Directory replica and BDC. You can set up multiple BDCs, each on a separate Open Directory replica server. Important: You must not have duplicate PDCs on a network. 32 Chapter 1 Directory Services with Open Directory 2 Open Directory Search Policies 2 Each computer has a search policy that specifies directory domains and the sequence in which Open Directory searches them. Each Mac OS X computer has a search policy, also commonly referred to as a search path, that specifies which directory domains Open Directory can access, such as the computer's local directory domain and a particular shared directory. The search policy also specifies the order in which Open Directory accesses directory domains. Open Directory searches each directory domain and stops searching when it finds a match. For example, Open Directory stops searching for a user record when it finds a record whose user name matches the name it's looking for. Search Policy Levels A search policy can include only the local directory domain, the local directory domain and a shared directory, or the local directory domain and multiple shared directories. On a network with a shared directory, several computers generally access the shared directory. This arrangement can be depicted as a tree-like structure with the shared directory at the top and local directories at the bottom. Local Directory Domain Search Policy The simplest search policy consists only of a computer's local directory domain. In this case, Open Directory looks for user information and other administrative data only in the local directory domain of each computer. If a server on the network hosts a shared directory, Open Directory does not look there for user information or administrative data because the shared directory is not part of the computer's search policy. 33 The following illustration shows two computers on a network that only search their local directory domain for administrative data. Local directory domain Local directory domain Search Policy 1 English class computer Science class computer Two-Level Search Policies If one server on the network hosts a shared directory, all computers on the network can include the shared directory in their search policies. In this case, Open Directory looks for user information and other administrative data first in the local directory domain. If Open Directory doesn't find the information it needs in the local directory domain, it looks in the shared directory. The following illustration shows two computers and a shared directory domain on a network. The computers are connected to the shared directory domain and have it in their search policy. Local directory domain Shared directory domain Local directory domain Search Policy 1 2 English class computer Science class computer Here's a scenario in which a two-level search policy might be used: Local directory domain Shared directory domain Local directory domain Search Policy 1 2 English class computer Local directory domain Science class computer Math class computer 34 Chapter 2 Open Directory Search Policies Each class (English, math, science) has its own computer. The students in each class are defined as users in the local domain of that class's computer. All three of these local domains have the same shared domain, in which all instructors are defined. Instructors, as members of the shared domain, can log in to all class computers. The students in each local domain can log in to only the computer where their local account resides. Local domains reside on their respective computers but a shared domain resides on a server accessible from the local domain's computer. When an instructor logs in to any of the three class computers and cannot be found in the local domain, Open Directory searches the shared domain. In the following example, there is only one shared domain, but in more complex networks, there may be more shared domains. School Mac OS X Server Local directory domain Shared directory domain Science class computer Local directory domain Local directory domain English class computer Math class computer Local directory domain Multilevel Search Policies If more than one server on the network hosts a shared directory, the computers on the network can include two or more shared directories in their search policies. As with simpler search policies, Open Directory always looks for user information and other administrative data first in the local directory domain. If Open Directory does not find the information it needs in the local directory domain, it searches each shared directory in the sequence specified by the search policy. Chapter 2 Open Directory Search Policies 35 Here's a scenario in which more than one shared directory might be used: Math directory domain Search Policy 1 2 3 English directory domain School directory domain Science directory domain Each class (English, math, science) has a server that hosts a shared directory domain. Each classroom computer's search policy specifies the computer's local domain, the class's shared domain, and the school's shared domain. The students in each class are defined as users in the shared domain of that class's server, so each student can log in to any computer in the class. Because the instructors are defined in the shared domain of the school server, they can log in to any classroom computer. You can affect an entire network or a group of computers by choosing the domain in which to define administrative data. The higher the administrative data resides in a search policy, the fewer places it needs to be changed as users and system resources change. Probably the most important aspect of directory services for administrators is planning directory domains and search policies. These should reflect the resources you want to share, the users you want to share them among, and the way you want to manage your directory data. Automatic Search Policies Mac OS X computers can be configured to set search policies automatically. An automatic search policy consists of two parts, one of which is optional:  Local directory domain  Shared LDAP directory (optional) 36 Chapter 2 Open Directory Search Policies A computer's automatic search policy always begins with the computer's local directory domain. If a Mac OS X computer is not connected to a network, the computer searches its local directory domain for user accounts and other administrative data. The automatic search policy then determines whether the computer is configured to connect to a shared local directory domain. The computer can be connected to a shared local directory domain, which can in turn be connected to another shared local directory domain, and so on. A local directory domain connection, if any, constitutes the second part of the automatic search policy. For more information, see "About the Local Directory Domain" on page 28. Finally, a computer with an automatic search policy can connect to a shared LDAP directory. When the computer starts, it can get the address of an LDAP directory server from DHCP service. The DHCP service of Mac OS X Server can supply an LDAP server address in the same way it supplies the addresses of DNS servers and a router. (A non-Apple DHCP service can also supply an LDAP server address. This feature is known as DHCP option 95.) If you want the DHCP service of Mac OS X Server to supply clients with an LDAP server's address for automatic search policies, configure the LDAP options of DHCP service. For more information, see the DHCP chapter in Network Services Administration. If you want a Mac OS X computer to get the address of an LDAP server from DHCP service:  The computer must be configured to use an automatic search policy. This includes selecting the option to add DHCP-supplied LDAP directories. For more information, see "Using Advanced Search Policy Settings" on page 128 and "Enabling or Disabling Use of a DHCP-Supplied LDAP Directory" on page 134.  The computer's network preferences must be configured to use DHCP or DHCP with manual IP address. Mac OS X is initially configured to use DHCP. For information about setting network preferences, search Mac Help. An automatic search policy offers convenience and flexibility, especially for mobile computers. If a computer with an automatic search policy is disconnected from the network, connected to a different network, or moved to a different subnet, the automatic search policy can change. If the computer is disconnected from the network, it uses its local directory domain. If the computer is connected to a different network or subnet, it can automatically change its local directory domain connection and can get an LDAP server address from the DHCP service on the current subnet. Chapter 2 Open Directory Search Policies 37 With an automatic search policy, a computer doesn't need to be reconfigured to get directory and authentication services in its new location. Important: If you configure Mac OS X to use an automatic authentication search policy and a DHCP-supplied LDAP server or a DHCP-supplied local directory domain, you increase the risk of an attacker gaining control of your computer. The risk is higher if your computer is configured to connect to a wireless network. For more information, see "Protecting Computers from a Malicious DHCP Server" on page 131. Custom Search Policies If you don't want a Mac OS X computer to use the automatic search policy supplied by DHCP, you can define a custom search policy for the computer. For example, a custom search policy could specify that an Active Directory domain be searched before an Open Directory server's shared directory domain. Users can configure their computer to log in using their user records from the Active Directory domain and have their preferences managed by group and computer records from the Open Directory domain. A custom search policy generally does not work in multiple network locations or while not connected to a network because it relies on the availability of specific directory domains on a particular network. If a portable computer is disconnected from its usual network, it no longer has access to the shared directory domains on its custom search policy. However, the disconnected computer still has access to its own local directory domain because it is the first directory domain on every search policy. The portable computer user can log in using a user record from the local directory domain, which can include mobile user accounts. These mirror user accounts from the shared directory domain that the portable computer accesses when it's connected to its usual network. Search Policies for Authentication and Contacts A Mac OS X computer has a search policy for finding authentication information and it has a separate search policy for finding contact information:  Open Directory uses the authentication search policy to locate and retrieve user authentication information and other administrative data from directory domains.  Open Directory uses the contacts search policy to locate and retrieve name, address, and other contact information from directory domains. Mac OS X Address Book uses this contact information, and other applications can be programmed to use it as well. Each search policy can be automatic, custom, or local directory domain only. 38 Chapter 2 Open Directory Search Policies 3 Open Directory Authentication 3 Open Directory offers several options for authenticating users whose accounts are stored in directory domains on Mac OS X Server, including Kerberos and the traditional authentication methods that network services require. Open Directory can authenticate users by one or more of the following methods:  Kerberos authentication for single sign-on  Traditional authentication methods and a password stored securely in the Open Directory Password Server database  Traditional authentication methods and a shadow password stored in a secure shadow password file for each user  A crypt password stored directly in the user's account, for backward compatibility with legacy systems  A non-Apple LDAP server for LDAP bind authentication In addition, Open Directory lets you set up a password policy for all users and specific password policies for each user, such as automatic password expiration and minimum password length. (Password policies do not apply to administrators, crypt password authentication, or LDAP bind authentication.) 39 Password Types Each user account has a password type that determines how the user account is authenticated. In a local directory domain, the standard password type is shadow password. On a server upgraded from Mac OS X Server version 10.3, user accounts in the local directory domain can also have an Open Directory password type. For user accounts in the LDAP directory of Mac OS X Server, the standard password type is Open Directory. User accounts in the LDAP directory can also have a password type of crypt password. Authentication and Authorization Services such as the login window and Apple file service request user authentication from Open Directory. Authentication is part of the process by which a service determines whether it should grant a user access to a resource. Usually this process also requires authorization. Authentication proves a user's identity, and authorization determines what the authenticated user is permitted to do. A user typically authenticates by providing a valid name and password. A service can then authorize the authenticated user to access specific resources. For example, file service authorizes full access to folders and files that an authenticated user owns. You experience authentication and authorization when you use a credit card. The merchant authenticates you by comparing your signature on the sales slip to the signature on your credit card. Then the merchant submits your authorized credit card account number to the bank, which authorizes payment based on your account balance and credit limit. Open Directory authenticates user accounts, and service access control lists (SACLs) authorize use of services. If Open Directory authenticates you, the SACL for login window determines whether you can log in, the SACL for Apple Filing Protocol (AFP) service determines whether you can connect for file service, and so on. Some services also determine whether a user is authorized to access particular resources. This authorization can require retrieving other user account information from the directory domain. For example, AFP service needs the user ID and group membership information to determine which folders and files the user is authorized to read and write. 40 Chapter 3 Open Directory Authentication Open Directory Passwords When a user's account has a password type of Open Directory, the user can be authenticated by Kerberos or the Open Directory Password Server. Kerberos is a network authentication system that uses credentials issued by a trusted server. Open Directory Password Server supports the traditional password authentication methods that some clients of network services require. Neither Kerberos nor Open Directory Password Server stores the password in the user's account. Both Kerberos and Open Directory Password Server store passwords in secure databases apart from the directory domain, and passwords can never be read. Passwords can only be set and verified. Malicious users might attempt to log in over the network hoping to gain access to Kerberos and Open Directory Password Server. Open Directory logs can alert you to unsuccessful login attempts. (See "Viewing Open Directory Status and Logs" on page 178.) User accounts in the following directory domains can have Open Directory passwords:  The LDAP directory of Mac OS X Server  The local directory domain of Mac OS X Server Note: Open Directory passwords can't be used to log in to Mac OS X version 10.1 or earlier. Users who log in using the login window of Mac OS X v10.1 or earlier must be configured to use crypt passwords. The password type doesn't matter for other services. For example, a user of Mac OS X v10.1 could authenticate for Apple file service with an Open Directory password. Shadow Passwords Shadow passwords support the same traditional authentication methods as Open Directory Password Server. These authentication methods are used to send shadow passwords over the network in a scrambled form, or hash. A shadow password is stored as several hashes in a file on the same computer as the directory domain where the user account resides. Because the password is not stored in the user account, the password is not easy to capture over the network. Each user's shadow password is stored in a different file, named a shadow password file, and these files are protected so they can be read only by the root user account. Only user accounts that are stored in a computer's local directory domain can have a shadow password. User accounts that are stored in a shared directory can't have a shadow password. Shadow passwords also provide cached authentication for mobile user accounts. For complete information about mobile user accounts, see User Management. Chapter 3 Open Directory Authentication 41 Crypt Passwords A crypt password is stored in a hash in the user account. This strategy, historically named basic authentication, is most compatible with software that needs to access user records directly. For example, Mac OS X version 10.1 or earlier expect to find a crypt password stored in the user account. Crypt authentication supports a maximum password length of eight bytes (eight ASCII characters). If a longer password is entered in a user account, only the first eight bytes are used for crypt password validation. Shadow passwords and Open Directory passwords are not subject to this length limit. For secure transmission of passwords over a network, crypt supports the DHX authentication method. Providing Secure Authentication for Windows Users Mac OS X Server also offers the same types of secure passwords for Windows users:  Open Directory passwords are required for domain login from a Windows workstation to a Mac OS X Server PDC and can be used to authenticate for Windows file service. This type of password can be validated using many authentication methods, including NTLMv2, NTLMv1, and LAN Manager. Open Directory passwords are stored in a secure database, not in user accounts.  Shadow passwords can't be used for domain login but they can be used for Windows file service and other services. This type of password can also be validated using NTLMv2, NTLMv1, and LAN Manager authentication methods. Shadow passwords are stored in secure files, not in user accounts.  A crypt password with Authentication Manager enabled provides compatibility for user accounts on a server that has been upgraded from Mac OS X Server version 10.1. After upgrading the server to Mac OS X Server version 10.5, these user accounts should be changed to use Open Directory passwords, which are more secure than the legacy Authentication Manager. 42 Chapter 3 Open Directory Authentication Offline Attacks on Passwords Because crypt passwords are stored in user accounts, they are potentially subject to attack. User accounts in a shared directory domain are accessible on the network. Anyone on the network who has Workgroup Manager or knows how to use command-line tools can read the contents of user accounts, including crypt passwords stored in them. Open Directory passwords and shadow passwords aren't stored in user accounts, so these passwords can't be read from directory domains. A malicious attacker, or cracker, could use Workgroup Manager or UNIX commands to copy user records to a file. The cracker can then transport this file to a system and use various techniques to decode crypt passwords stored in the user records. After decoding a crypt password, the cracker can log in unnoticed with a legitimate user name and crypt password. This form of attack is known as an offline attack because it does not require successive login attempts to gain access to a system. An effective way to thwart password cracking is to use good passwords and avoid using crypt passwords. A password should contain letters, numbers, and symbols in combinations that can't be easily guessed by unauthorized users. Good passwords should not consist of actual words. They can include digits and symbols (such as # or $), or they can consist of the first letter of all words in a phrase. Use both uppercase and lowercase letters. Shadow passwords and Open Directory passwords are far less susceptible to offline attack because they are not stored in user records. Shadow passwords are stored in separate files that can be read only by someone who knows the password of the root user account (also known as the system administrator). Open Directory passwords are stored securely in the Kerberos KDC and in the Open Directory Password Server database. A user's Open Directory password can't be read by other users, not even by a user with administrator rights for Open Directory authentication. (This administrator can change only Open Directory passwords and password policies.) Chapter 3 Open Directory Authentication 43 Crypt passwords are not considered secure. They should be used only for user accounts that must be compatible with UNIX clients that require them, or for Mac OS X v10.1 clients. Being stored in user accounts, they're too accessible and therefore subject to offline attack (see "Offline Attacks on Passwords"). Although stored in an encoded form, they're relatively easy to decode. How Crypt Passwords Are Encrypted Crypt passwords are not stored in clear text; they are concealed and made unreadable by encryption. A crypt password is encrypted by supplying the clear text password with a random number to a mathematical function, known as a one-way hash function. A one-way hash function always generates the same encrypted value from particular input but cannot be used to recreate the original password from the encrypted output it generates. To validate a password using the encrypted value, Mac OS X applies the function to the password entered by the user and compares it with the value stored in the user account or shadow file. If the values match, the password is considered valid. Determining Which Authentication Option to Use To authenticate a user, Open Directory must determine which authentication option to use--Kerberos, Open Directory Password Server, shadow password, or crypt password. The user's account contains information that specifies which authentication option to use. This information is named the authentication authority attribute. Open Directory uses the name provided by the user to locate the user's account in the directory domain. Then Open Directory consults the authentication authority attribute in the user's account and learns which authentication option to use. You can change a user's authentication authority attribute by changing the password type in the Advanced pane of Workgroup Manager, as shown in the following table. For more information, see "Changing a User's Password Type" on page 108. Password type Open Directory Authentication authority Attribute in user record Open Directory Password Server Either or both: and Kerberos1  ;ApplePasswordServer;  ;Kerberosv5; Password file for each user, readable only by the root user account Encoded password in user record Either:  ;ShadowHash;2  ;ShadowHash; Either:  ;basic;  no attribute at all Shadow password Crypt password 1 User accounts from Mac OS X Server v10.2 must be reset to include the Kerberos authentication authority attribute. See "Enabling Single Sign-On Kerberos Authentication for a User" on page 111. 44 Chapter 3 Open Directory Authentication 2 If the attribute in the user record is;ShadowHash; without a list of enabled authentication methods, default authentication methods are enabled. The list of default authentication methods is different for Mac OS X Server and Mac OS X. The authentication authority attribute can specify multiple authentication options. For example, a user account with an Open Directory password type normally has an authentication authority attribute that specifies both Kerberos and Open Directory Password Server. A user account doesn't need to include an authentication authority attribute. If a user's account contains no authentication authority attribute, Mac OS X Server assumes a crypt password is stored in the user's account. For example, user accounts created using Mac OS X version 10.1 or earlier contain a crypt password but not an authentication authority attribute. Password Policies Open Directory enforces password policies for users whose password type is Open Directory or shadow password. For example, a user's password policy can specify a password expiration interval. If the user is logging in and Open Directory determines that the user's password has expired, the user must replace the expired password. Then Open Directory can authenticate the user. Password policies can disable a user account on a certain date, after a number of days, after a period of inactivity, or after a number of failed login attempts. Password policies can also require passwords to be a minimum length, contain at least one letter, contain at least one numeral, differ from the account name, differ from recent passwords, or be changed periodically. The password policy for a mobile user account applies when the account is used while disconnected from the network and while connected to the network. A mobile user account's password policy is cached for use while offline. For more information about mobile user accounts, see User Management. Password policies do not affect administrator accounts. Administrators are exempt from password policies because they can change the policies at will. In addition, enforcing password policies on administrators could subject them to denial-of-service attacks. Kerberos and Open Directory Password Server maintain password policies separately. An Open Directory server synchronizes the Kerberos password policy rules with Open Directory Password Server password policy rules. Chapter 3 Open Directory Authentication 45 Single Sign-On Authentication Mac OS X Server uses Kerberos for single sign-on authentication, which relieves users from entering a name and password separately for every service. With single sign-on, a user always enters a name and password in the login window. Thereafter, the user does not need to enter a name and password for Apple file service, mail service, or other services that use Kerberos authentication. To take advantage of single sign-on, users and services must be Kerberized--configured for Kerberos authentication--and use the same Kerberos KDC server. User accounts that reside in an LDAP directory of Mac OS X Server and have a password type of Open Directory use the server's built-in KDC. These user accounts are automatically configured for Kerberos and single sign-on. The server's Kerberized services use the server's built-in KDC and are configured for single sign-on. This Mac OS X Server KDC can also authenticate users for services provided by other servers. Having more servers with Mac OS X Server use the Mac OS X Server KDC requires only minimal configuration. Kerberos Authentication Kerberos was developed at MIT to provide secure authentication and communication over open networks like the Internet. It's named for the three-headed dog that guarded the entrance to the underworld of Greek mythology. Kerberos provides proof of identity for two parties. It enables you to prove who you are to network services you want to use. It also proves to your applications that network services are genuine, not spoofed. Like other authentication systems, Kerberos does not provide authorization. Each network service determines what you are permitted to do based on your proven identity. Kerberos permits a client and a server to identify each other much more securely than typical challenge-response password authentication methods. Kerberos also provides a single sign-on environment where users authenticate only once a day, week, or other period of time, thereby easing authentication frequency. Mac OS X Server offers integrated Kerberos support that virtually anyone can deploy. In fact, Kerberos deployment is so automatic that users and administrators may not realize it's deployed. Mac OS X v10.3 and later use Kerberos automatically when someone logs in using an account set for Open Directory authentication. It is the default setting for user accounts in the Mac OS X Server LDAP directory. Other services provided by the LDAP directory server, such as AFP and mail service, also use Kerberos automatically. 46 Chapter 3 Open Directory Authentication If your network has other servers with Mac OS X Server v10.5, joining them to the Kerberos server is easy, and most of their services use Kerberos automatically. Alternatively, if your network has a Kerberos system such as Microsoft Active Directory, you can set up your Mac OS X Server and Mac OS X computers to use it for authentication. Mac OS X Server and Mac OS X version 10.3 or later support Kerberos version 5. Mac OS X Server and Mac OS X version 10.5 do not support Kerberos version 4. Breaking the Barriers to Kerberos Deployment Until recently Kerberos was a technology for universities and government sites. It wasn't more widely deployed because adoption barriers needed to be taken down. Mac OS X and Mac OS X Server v10.3 or later eliminate the following historical barriers to adoption of Kerberos:  An Administrator had to set up a Kerberos KDC. This was difficult to deploy and administer.  There was no standard integration with a directory system. Kerberos only does authentication. It doesn't store user account data such as user ID (UID), home folder location, or group membership. The administrator had to determine how to integrate Kerberos with a directory system.  Servers had to be registered with the Kerberos KDC. This added an extra step to the server setup process.  After setting up a Kerberos server, the administrator had to visit all client computers and configure each one to use Kerberos. This was time-consuming and required editing configuration files and using command-line tools.  You needed a suite of Kerberized applications (server and client software). Some of the basics were available but porting them and adapting them to work with your environment was difficult.  Not all network protocols used for client-server authentication are Kerberosenabled. Some network protocols still require traditional challenge-response authentication methods and there is no standard way to integrate Kerberos with these legacy network authentication methods.  Kerberos client supports failover so if one KDC is offline it can use a replica, but the administrator had to figure out how to set up a Kerberos replica.  Administration tools were never integrated. Tools for creating and editing user accounts in the directory domain didn't know anything about Kerberos, and the Kerberos tools knew nothing about user accounts in directories. Setting up a user record was a site-specific operation based on how the KDC was integrated with the directory system. Chapter 3 Open Directory Authentication 47 Single Sign-On Experience Kerberos is a credential or ticket-based system. The user logs in once to the Kerberos system and is issued a ticket with a life span. During the life span of this ticket the user doesn't need to authenticate again to access a Kerberized service. The user's Kerberized client software, such as the Mac OS X Mail application, presents a valid Kerberos ticket to authenticate the user for a Kerberized service. This provides a single sign-on experience. A Kerberos ticket is like a press pass to a jazz festival held at multiple nightclubs over a three-day weekend. You prove your identity once to get the pass. Until the pass expires, you can show it at any nightclub to get a ticket for a performance. All participating nightclubs accept your pass without seeing your proof of identity again. Secure Authentication The Internet is inherently insecure, yet few authentication protocols provide real security. Malicious hackers can use readily available software tools to intercept passwords being sent over a network. Many applications send passwords unencrypted, and these are ready to use as soon as they're intercepted. Even encrypted passwords are not completely safe. Given enough time and computing power, encrypted passwords can be cracked. To isolate passwords on your private network you can use a firewall can be used, but this does not solve all problems. For example, a firewall does not provide security against disgruntled or malicious insiders. Kerberos was designed to solve network security problems. It never transmits the user's password across the network, nor does it save the password in the user's computer memory or on disk. Therefore, even if the Kerberos credentials are cracked or compromised, the attacker does not learn the original password, so he or she can potentially compromise only a small portion of the network. In addition to superior password management, Kerberos is also mutually authenticated. The client authenticates to the service, and the service authenticates to the client. A man-in-the-middle or spoofing attack is impossible when you are using Kerberized services, and that means users can trust the services they are accessing. 48 Chapter 3 Open Directory Authentication Ready to Move Beyond Passwords Network authentication is difficult: To deploy a network authentication method both the client and server must agree on the authentication method. And although it is possible for client/server processes to agree on a custom authentication method, getting pervasive adoption across a suite of network protocols, platforms, and clients is virtually impossible. For example, suppose you wanted to deploy smart cards as a network authentication method. Without Kerberos, you'd have to change every client/server protocol to support the new method. The list of protocols includes SMTP, POP, IMAP, AFP, SMB, HTTP, FTP, IPP, SSH, QuickTime Streaming, DNS, LDAP, local directory domain, RPC, NFS, AFS, WebDAV, and LPR, and goes on and on. Considering all the software that does network authentication, deploying a new authentication method across the entire suite of network protocols would be a daunting task. Although this might be feasible for software from one vendor, you'd be unlikely to get all vendors to change their client software to use your new method. Furthermore, you'd probably also want your authentication to work on multiple platforms (such as Mac OS X, Windows, and UNIX). Due to the design of Kerberos, a client/server binary/protocol that supports Kerberos doesn't even know how the user proves identity. Therefore you only need to change the Kerberos client and the Kerberos server to accept a new proof of identity such as a smart card. As a result, your entire Kerberos network has now adopted the new proofof-identity method, without deploying new versions of client and server software. Multiplatform Authentication Kerberos is available on every major platform, including Mac OS X, Windows, Linux, and other UNIX variants. Centralized Authentication Kerberos provides a central authentication authority for the network. All Kerberosenabled services and clients use this central authority. Administrators can centrally audit and control authentication policies and operations. Chapter 3 Open Directory Authentication 49 Kerberized Services Kerberos can authenticate users for the following services of Mac OS X Server:  Login window  Mail service  AFP file service  FTP file service  SMB file service (as a member of an Active Directory Kerberos realm)  VPN service  Apache web service  LDAP directory service  iChat service  Print service  NFS file service  Xgrid These services have been Kerberized whether they are running or not. Only services that have been Kerberized can use Kerberos to authenticate a user. Mac OS X Server includes command-line tools for Kerberizing other services that are compatible with MIT-based Kerberos. For more information, see the Open Directory chapter of Command-Line Administration. Configuring Services for Kerberos After Upgrading After upgrading to Mac OS X Server version 10.5, you may need to configure some services to use single sign-on Kerberos authentication. These services either weren't configured to use Kerberos or weren't included with the earlier version of Mac OS X Server. If this condition exists, a message about it appears when you connect to the server in Server Admin. The message appears in the Overview pane when you select the server (not a service) in the Servers list. To configure new and upgraded services to use Kerberos: 1 Open Server Admin and connect to the upgraded server. 2 Click the triangle to the left of the server. The list of services appears. 3 From the expanded Servers list, select Open Directory. 4 Click Settings, then click General. 5 Click Kerberize Services, then enter the name and password of an LDAP directory administrator account. Services that were already configured to use Kerberos are not affected. 50 Chapter 3 Open Directory Authentication