Apple Mac OS X Server Open Directory Administration

© 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

12 What’s New in Version 10.5 12 What’s in This Guide 14 Using This Guide 14 Using Onscreen Help 15 Mac OS X Server Administration Guides 16 Viewing PDF Guides on Screen 16 Printing PDF Guides 17 Getting Documentation Updates 17 Getting Additional Information Chapter 1 19 Directory Services with Open Directory 19 Benefits of Using Directory Services 20 Directory Services and Directory Domains 21 A Historical Perspective 21 Data Consolidation 23 Data Distribution 24 Uses of Directory Data 25 Access to Directory Services 25 Inside a Directory Domain 27 Structure of LDAP Directory Information 28 Local and Shared Directory Domains 28 About the Local Directory Domain 29 About Shared Directory Domains 30 Shared Data in Existing Directory Domains 30 SMB Services and Open Directory 31 Open Directory as a Primary Domain Controller 32 Open Directory as a BDC Chapter 2 33 Open Directory Search Policies 33 Search Policy Levels 33 Local Directory Domain Search Policy 34 Two-Level Search Policies

36 Automatic Search Policies 38 Custom Search Policies 38 Search Policies for Authentication and Contacts Chapter 3 39 Open Directory Authentication 40 Password Types 40 Authentication and Authorization 41 Open Directory Passwords 41 Shadow Passwords 42 Crypt Passwords 42 Providing Secure Authentication for Windows Users 43 Offline Attacks on Passwords 44 Determining Which Authentication Option to Use 45 Password Policies 46 Single Sign-On Authentication 46 Kerberos Authentication 47 Breaking the Barriers to Kerberos Deployment 48 Single Sign-On Experience 48 Secure Authentication 49 Ready to Move Beyond Passwords 49 Multiplatform Authentication 49 Centralized Authentication 50 Kerberized Services 50 Configuring Services for Kerberos After Upgrading 51 Kerberos Principals and Realms 51 Kerberos Authentication Process 52 Open Directory Password Server and Shadow Password Authentication Methods 54 Disabling Open Directory Authentication Methods 55 Disabling Shadow Password Authentication Methods 56 Contents of the Open Directory Password Server Database 56 LDAP Bind Authentication Chapter 4 57 Open Directory Planning and Management Tools 58 General Planning Guidelines 61 Estimating Directory and Authentication Requirements 62 Identifying Servers for Hosting Shared Domains 62 Replicating Open Directory Services 63 Replica Sets 64 Cascading Replication 65 Planning the Upgrade of Multiple Open Directory Replicas 65 Load Balancing in Small, Medium, and Large Environments 66 Replication in a Multibuilding Campus

67 Open Directory Master and Replica Compatibility 67 Mixing Active Directory and Open Directory Master and Replica Services 69 Integrating with Existing Directory Domains 70 Integrating Without Schema Changes 70 Integrating with Schema Changes 70 Avoiding Kerberos Conflicts with Multiple Directories 72 Improving Performance and Redundancy 73 Open Directory Security 74 Service Access Control Lists (SACLs) 75 Tiered Administration 75 Tools for Managing Open Directory Services 76 Server Admin 77 Directory Utility 77 Workgroup Manager 78 Command-Line Tools Chapter 5 79 Setting Up Open Directory Services 79 Setup Overview 80 Before You Begin 81 Managing Open Directory on a Remote Server 81 Turning Open Directory On 81 Setting Up a Standalone Directory Service 83 Setting Up an Open Directory Master 85 Instructing Users How to Log In 85 Setting Up a Primary Domain Controller 86 Setting Up Windows Vista for Domain Login 87 Setting Up Windows XP for Domain Login 87 Setting Up Windows 2000 for Domain Login 88 Setting Up an Open Directory Replica 90 Creating Multiple Replicas of an Open Directory Master 91 Setting Up Open Directory Relays for Cascading Replication 91 Setting Up a Server as a BDC 92 Setting Up Open Directory Failover 93 Setting Up a Connection to a Directory Server 94 Setting Up a Server as a Mac OS X Server PDC Domain Member 95 Setting Up a Server as an Active Directory Domain Member 97 Setting Up Single Sign-On Kerberos Authentication 98 Setting Up an Open Directory Kerberos Realm 99 Starting Kerberos After Setting Up an Open Directory Master 100 Delegating Authority to Join an Open Directory Kerberos Realm 102 Joining a Server to a Kerberos Realm

106 Composing a Password 106 Changing a User’s Password 107 Resetting the Passwords of Multiple Users 108 Changing a User’s Password Type 108 Changing the Password Type to Open Directory 110 Changing the Password Type to Crypt Password 110 Changing the Password Type to Shadow Password 111 Enabling Single Sign-On Kerberos Authentication for a User 111 Changing the Global Password Policy 112 Setting Password Policies for Individual Users 113 Selecting Authentication Methods for Shadow Password Users 114 Selecting Authentication Methods for Open Directory Passwords 115 Assigning Administrator Rights for Open Directory Authentication 116 Keeping the Primary Administrator’s Passwords in Sync 116 Enabling LDAP Bind Authentication for a User 117 Setting Passwords of Exported or Imported Users 117 Migrating Passwords From Mac OS X Server v10.1 or Earlier Chapter 7 119 Managing Directory Clients 119 Connecting Clients to Directory Servers 119 About Directory Server Connections 120 Automated Client Configuration 121 Adding an Active Directory Server Connection 121 Adding an Open Directory Server Connection 122 Removing a Directory Server Connection 122 Editing a Directory Server Connection 123 Monitoring Directory Server Connections 123 Managing the Root User Account 123 Enabling the Root User Account 124 Changing the Root User Account Password Chapter 8 125 Advanced Directory Client Settings 125 About Advanced Directory Services Settings 126 Setting Up Directory Utility on a Remote Server 126 Configuring Mount Records for a Computer’s Local Directory Domain 126 Adding a Mount Record to the Local Directory Domain 127 Removing a Mount Record from the Local Directory Domain 128 Editing a Mount Record in the Local Directory Domain 128 Using Advanced Search Policy Settings 129 Defining Automatic Search Policies 130 Defining Custom Search Policies 131 Defining Local Directory Search Policies

131 Protecting Computers from a Malicious DHCP Server 132 Using Advanced Directory Services Settings 132 Enabling or Disabling Active Directory Service 133 Enabling or Disabling LDAP Directory Services 133 Using Advanced LDAP Service Settings 134 Accessing LDAP Directories in Mail and Address Book 134 Enabling or Disabling Use of a DHCP-Supplied LDAP Directory 135 Showing or Hiding Configurations for LDAP Servers 136 Configuring Access to an LDAP Directory 138 Configuring Access to an LDAP Directory Manually 140 Changing a Configuration for Accessing an LDAP Directory 141 Duplicating a Configuration for Accessing an LDAP Directory 143 Deleting a Configuration for Accessing an LDAP Directory 144 Changing the Connection Settings for an LDAP Directory 145 Changing the Security Policy for an LDAP Connection 146 Configuring LDAP Searches and Mappings 149 Setting Up Trusted Binding for an LDAP Directory 150 Stopping Trusted Binding with an LDAP Directory 150 Changing the Open/Close Timeout for an LDAP Connection 151 Changing the Query Timeout for an LDAP Connection 151 Changing the Rebind-Try Delay Time for an LDAP Connection 152 Changing the Idle Timeout for an LDAP Connection 152 Forcing Read-Only LDAPv2 Access 152 Ignoring LDAP Server Referrals 153 Authenticating an LDAP Connection 153 Changing the Password Used for Authenticating an LDAP Connection 154 Mapping Config Record Attributes for LDAP Directories 154 Editing RFC 2307 Mapping to Enable Creating Users 155 Preparing a Read-Only LDAP Directory for Mac OS X 155 Populating LDAP Directories with Data for Mac OS X 156 Using Advanced Active Directory Service Settings 157 About Active Directory Access 159 Configuring Access to an Active Directory Domain 161 Setting Up Mobile User Accounts in Active Directory 162 Setting Up Home Folders for Active Directory User Accounts 163 Setting a UNIX Shell for Active Directory User Accounts 163 Mapping the UID to an Active Directory Attribute 164 Mapping the Primary Group ID to an Active Directory Attribute 165 Mapping the Group ID in Group Accounts to an Active Directory Attribute 166 Specifying a Preferred Active Directory Server 166 Changing the Active Directory Groups That Can Administer the Computer 167 Controlling Authentication from All Domains in the Active Directory Forest

168 Editing User Accounts and Other Records in Active Directory 169 Setting Up LDAP Access to Active Directory Domains 170 Specifying NIS Settings 171 Specifying BSD Configuration File Settings 171 Setting Up Data in BSD Configuration Files Chapter 9 173 Maintaining Open Directory Services 173 Controlling Access to Open Directory Servers and Services 174 Controlling Access to a Server’s Login Window 174 Controlling Access to SSH Service 175 Configuring Service Access Control 176 Configuring Record Privileges 177 Monitoring Open Directory 177 Checking the Status of an Open Directory Server 177 Monitoring Replicas and Replays of an Open Directory Master 178 Viewing Open Directory Status and Logs 178 Monitoring Open Directory Authentication 179 Viewing and Editing Directory Data 179 Showing the Directory Inspector 180 Hiding the Directory Inspector 180 Setting Directory Access Controls (DACs) 180 Deleting Records 181 Deleting Users or Computers Using Inspector or the Command Line 182 Changing a User’s Short Name 183 Importing Records of Any Type 183 Setting Options for an Open Directory Server 184 Setting a Binding Policy for an Open Directory Server 184 Setting a Security Policy for an Open Directory Server 186 Changing the Location of an LDAP Database 186 Limiting Search Results for LDAP Service 187 Setting the Search Timeout Interval for LDAP Service 187 Setting up SSL for LDAP Service 188 Creating a Custom SSL Configuration for LDAP 189 Managing Open Directory Replication 189 Scheduling Replication of an Open Directory Master or Primary Domain Controller (PDC) 190 Synchronizing an Open Directory Replica or BDC on Demand 190 Making an Open Directory Replica into a Relay 190 Promoting an Open Directory Replica 193 Decommissioning an Open Directory Replica 194 Archiving an Open Directory Master 195 Restoring an Open Directory Master

199 Solving Open Directory Master and Replica Problems 199 If Kerberos Is Stopped on an Open Directory Master or Replica 200 If You Can’t Create an Open Directory Replica 200 If You Can’t Create an Open Directory Master or Replica from a Configuration File 200 If You Can’t Connect a Replica to Your Relay 200 If You Can’t Join an Open Directory Replica to an Open Directory that is a Subordinate of an Active Directory Server 201 Solving Directory Connection Problems 201 If a Delay Occurs During Startup 201 Solving Authentication Problems 201 If You Can’t Change a User’s Open Directory Password 201 If a User Can’t Access Some Services 202 If a User Can’t Authenticate for VPN Service 202 If You Can’t Change a User’s Password Type to Open Directory 202 If Users Relying on a Password Server Can’t Log In 202 If Users Can’t Log In with Accounts in a Shared Directory Domain 203 If You Can’t Log In as an Active Directory User 203 If Users Can’t Authenticate Using Single Sign-On Kerberos 205 If Users Can’t Change Their Passwords 205 If You Can’t Join a Server to an Open Directory Kerberos Realm 206 If You Must Reset an Administrator Password Appendix 207 Mac OS X Directory Data 208 Open Directory Extensions to LDAP Schema 209 Object Classes in Open Directory LDAP Schema 217 Attributes in Open Directory LDAP Schema 237 Mapping Standard Record Types and Attributes to LDAP and Active Directory 238 Mappings for Users 241 Mappings for Groups 242 Mappings for Mounts 243 Mappings for Computers 244 Mappings for ComputerLists 245 Mappings for Config 246 Mappings for People 248 Mappings for PresetComputerLists 248 Mappings for PresetGroups 249 Mappings for PresetUsers 251 Mappings for Printers 252 Mappings for AutoServerSetup 253 Mappings for Locations 253 Standard Open Directory Record Types and Attributes 253 Standard Attributes in User Records

259 Standard Attributes in Computer Records 260 Standard Attributes in Computer Group Records 261 Standard Attributes in Mount Records 262 Standard Attributes in Config Records Glossary 263 Index 271

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.

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.

13 Â 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.

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.

15 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... tells you how to: Getting Started and Installation & Setup Worksheet Install Mac OS X Server and set it up for the first time. Command-Line Administration Install, set up, and manage Mac OS X Server using UNIX command- line tools and configuration files. File Services Administration Share selected server volumes or folders among server clients using the AFP, NFS, FTP, and SMB protocols. iCal Service Administration Set up and manage iCal shared calendar service. iChat Service Administration Set up and manage iChat instant messaging service. Mac OS X Security Configuration Make Mac OS X computers (clients) more secure, as required by enterprise and government customers. Mac OS X Server Security Configuration Make Mac OS X Server and the computer it’s installed on more secure, as required by enterprise and government customers. Mail Service Administration Set up and manage IMAP, POP, and SMTP mail services on the server. Network Services Administration Set up, configure, and administer DHCP, DNS, VPN, NTP, IP firewall, NAT, and RADIUS services on the server. Open Directory Administration Set up and manage directory and authentication services, and configure clients to access directory services. Podcast Producer Administration Set up and manage Podcast Producer service to record, process, and distribute podcasts. Print Service Administration Host shared printers and manage their associated queues and print jobs. QuickTime Streaming and Broadcasting Administration Capture and encode QuickTime content. Set up and manage QuickTime streaming service to deliver media streams live or on demand. Server Administration Perform advanced installation and setup of server software, and manage options that apply to multiple services or to the server as a whole. System Imaging and Software Update Administration Use NetBoot, NetInstall, and Software Update to automate the management of operating system and other software used by client computers. Upgrading and Migrating Use data and service settings from an earlier version of Mac OS X Server or Windows NT.

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). User Management Create and manage user accounts, groups, and computers. Set up managed preferences for Mac OS X clients. Web Technologies Administration Set up and manage web technologies, including web, blog, webmail, wiki, MySQL, PHP, Ruby on Rails, and WebDAV. Xgrid Administration and High Performance Computing Set up and manage computational clusters of Xserve systems and Mac computers. Mac OS X Server Glossary Learn about terms used for server and storage products. This guide... tells you how to:

17 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 sign- on 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.

Directory 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.

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. 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. Printers Groups Computers Users Application and system software processes Mounts Directory domains Open Directory

21 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: 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. 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. Workgroup Manager Open Directory Directory domain UNIX processes /etc/master.passwd /etc/hosts /etc/group

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: 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. 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. Mac OS X processes Open Directory Directory domain Directory domain Open Directory Mac OS X processes

23 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. System administrator Users Directory domain Open Directory

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.

25 Â 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.

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.

27 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: 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. dc=com dc=example cn=users cn=groups cn=computers uid=anne cn=Anne Johnson uid=juan cn=Juan Chavez

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: 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. Local directory domain Local directory domain Log in to Mac OS X Connect to Mac OS X Server for file service

29 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 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. Shared directory domain Local directory domain Local directory domain Log in to Mac OS X Connect to Mac OS X Server for file service

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. 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). Mac OS X user Mac OS X user Windows user Mac OS X Server Windows server Active Directory domain Shared directory domain Local directory domain Local directory domain

31 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.

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.

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.

The following illustration shows two computers on a network that only search their local directory domain for administrative data. 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. Here’s a scenario in which a two-level search policy might be used: Local directory domain Science class computer English class computer 1 Search Policy Local directory domain Shared directory domain Local directory domain Science class computer English class computer 1 Search Policy 2 Local directory domain Shared directory domain Local directory domain Science class computer English class computer 1 Search Policy Local directory domain Math class computer 2 Local directory domain

35 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. 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. School Mac OS X Server English class computer Math class computer Science class computer Local directory domain Local directory domain Local directory domain Local directory domain Shared directory domain

Here’s a scenario in which more than one shared directory might be used: 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) School directory domain Science directory domain 1 Search Policy 2 English directory domain 3 Math directory domain

37 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.

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.

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.)

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.

41 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.

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.

43 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.)

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 Authentication authority Attribute in user record Open Directory Open Directory Password Server and Kerberos1 Either or both: Â ;ApplePasswordServer; Â ;Kerberosv5; Shadow password Password file for each user, readable only by the root user account Either: Â ;ShadowHash;2 Â ;ShadowHash; Crypt password Encoded password in user record Either: Â ;basic; Â no attribute at all 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.

45 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. 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.

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.

47 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 Kerberos- enabled. 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.

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.

49 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 proof- of-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 Kerberos- enabled services and clients use this central authority. Administrators can centrally audit and control authentication policies and operations.

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.

51 Kerberos Principals and Realms Kerberized services are configured to authenticate principals who are known to a particular Kerberos realm. You can think of a realm as a particular Kerberos database or authentication domain, which contains validation data for users, services, and sometimes servers, which are all known as principals. For example, a realm contains principals’ secret keys, which are the result of a one-way function applied to passwords. Service principals are generally based on randomly generated secrets rather than passwords. Here are examples of realm and principal names. Realm names are capitalized by convention to distinguish them from DNS domain names: Â Realm: MYREALM.EXAMPLE.COM Â User principal: [email protected] Â Service principal: afpserver/[email protected] Kerberos Authentication Process There are several phases to Kerberos authentication. In the first phase, the client obtains credentials to be used to request access to Kerberized services. In the second phase, the client requests authentication for a specific service. In the final phase, the client presents those credentials to the service. The following illustration summarizes these activities. The service and the client can be the same entity (such as the login window) or two different entities (such as a mail client and the mail server). 1 The client authenticates to a Kerberos KDC, which interacts with realms to access authentication data. This is the only step in which passwords and associated password policy information are be checked. 2 The KDC issues a ticket-granting ticket to the client. The ticket is the credential needed when the client wants to use Kerberized services and is good for a configurable period of time, but it can be revoked before expiration. It is cached on the client until it expires. Key Distribution Center (KDC) Kerberized service 1 2 3 4 5 6 Client

3 The client contacts the KDC with the ticket-granting ticket when it wants to use a Kerberized service. 4 The KDC issues a ticket for that service. 5 The client presents the ticket to the service. 6 The service authenticates the client by verifying that the ticket is valid. After authenticating the client, the service determines if the client is authorized to use the service. Kerberos only authenticates clients; it does not authorize them to use services. For example, many services use Mac OS X Server’s service access control lists (SACLs) to determine whether a client is authorized to use the service. Kerberos never sends a password or password policy information to a service. After a ticket-granting ticket is obtained, no password information is provided. Time is very important with Kerberos. If the client and the KDC are out of sync by more than a few minutes, the client will fail to achieve authentication with the KDC. The date, time, and time zone information must be correct on the KDC server and clients, and the server and clients should all use the same network time service to keep their clocks in sync. For more information about Kerberos, go to the MIT Kerberos website at web.mit.edu/ kerberos/www/index.html. Open Directory Password Server and Shadow Password Authentication Methods For compatibility with various services, Mac OS X Server can use several authentication methods to validate Open Directory passwords and shadow passwords. For Open Directory passwords, Mac OS X Server uses the standard Simple Authentication and Security Layer (SASL) mechanism to negotiate an authentication method between a client and a service. For shadow passwords, the use of SASL depends on the network protocol. The following authentication methods are supported: Method Network security Storage security Uses APOP Encrypted, with clear text fallback Clear text POP mail service CRAM-MD5 Encrypted, with clear text fallback Encrypted IMAP mail service, LDAP service

53 Open Directory supports many authentication methods because each service that requires authentication uses some methods but not others. For example, File service uses one set of authentication methods, Web service uses another set of methods, mail service uses another set, and so on. Some authentication methods are more secure than others. The more secure methods use stronger algorithms to encode the information they transmit between client and server. The more secure authentication methods also store hashes, which can’t easily be recovered from the server. Less secure methods store a recoverable, clear text password. No one—including an administrator and the root user account—can recover encrypted passwords by reading them from the database. An administrator can use Workgroup Manager to set a user’s password, but the administrator can’t read a user’s password. If you connect Mac OS X Server v10.4 or later to a directory domain of Mac OS X Server v10.3 or earlier, users defined in the older directory domain cannot be authenticated with the NTLMv2 method. This method may be required to securely authenticate some Windows users for the Windows services of Mac OS X Server v10.4 or later. Open Directory Password Server in Mac OS X Server v10.4 or later supports NTLMv2 authentication, but Password Server in Mac OS X Server v10.3 or earlier does not support NTLMv2. If you connect Mac OS X Server v10.3 or later to a directory domain of Mac OS X Server v10.2 or earlier, users defined in the older directory domain cannot be authenticated with the MS-CHAPv2 method. This method may be required to securely authenticate users for the VPN service of Mac OS X Server v10.3 or later. DHX Encrypted Encrypted AFP file service, Open Directory administration Digest-MD5 Encrypted Encrypted Login window, mail service MS-CHAPv2 Encrypted Encrypted VPN service NTLMv1 and NTLMv2 Encrypted Encrypted SMB services (Windows NT/98 or later) LAN Manager Encrypted Encrypted SMB services (Windows 95) WebDAV-Digest Encrypted Clear text WebDAV file service (iDisk) Method Network security Storage security Uses

Open Directory Password Server in Mac OS X Server v10.3 or later supports MS-CHAPv2 authentication, but Password Server in Mac OS X Server v10.2 does not support MS-CHAPv2. Disabling Open Directory Authentication Methods To make Open Directory password storage on the server more secure, you can selectively disable authentication methods. For example, if no clients are going to use Windows services, you can disable the NTLMv1, NTLMv2, and LAN Manager authentication methods to prevent storing passwords on the server using these methods. Then someone who gains unauthorized access to the server’s password database can’t exploit weaknesses in these authentication methods to crack passwords. Important: If you disable an authentication method, its hash is removed from the password database the next time the user authenticates. If you enable an authentication method that was disabled, every Open Directory password must be reset to add the newly enabled method’s hash to the password database. Users can reset their own passwords, or a directory administrator can do it. Disabling an authentication method makes the Open Directory Password Server database more secure if an unauthorized user gains physical access to an Open Directory server (master or replica) or to media containing a backup of the Open Directory master. Someone who gains access to the password database can try to crack a user’s password by attacking the hash or recoverable text stored in the password database by any authentication method. Nothing is stored in the password database by a disabled authentication method, leaving one less avenue of attack open to a cracker who has physical access to the Open Directory server or a backup of it. Some hashes stored in the password database are easier to crack than others. Recoverable authentication methods store clear (plainly readable) text. Disabling authentication methods that store clear text or weaker hashes increases password database security more than disabling methods that store stronger hashes. If you believe your Open Directory master, replicas, and backups are secure, select all authentication methods. If you’re concerned about the physical security of any Open Directory server or its backup media, disable some methods. Note: Disabling authentication methods does not increase the security of passwords while they are transmitted over the network. Only the password database security is affected. In fact, disabling some authentication methods may require clients to configure their software to send passwords over the network in clear text, thereby compromising password security in a different way.

55 Disabling Shadow Password Authentication Methods You can selectively disable authentication methods to make passwords stored in shadow password files more secure. For example, if a user doesn’t use mail service or web services, you can disable the WebDAV-Digest and APOP methods for the user. Then someone who gains access to the shadow password files on a server can’t recover the user’s password. Important: If you disable a shadow password authentication method, its hash is removed from a user’s shadow password file the next time the user authenticates. If you enable an authentication method that was disabled, the newly enabled method’s hash is added to the user’s shadow password file the next time the user authenticates for a service that can use a clear text password, such as login window or AFP. Alternatively, you can reset the user’s password to add the newly enabled method’s hash. The user can reset the password, or a directory administrator can do it. Disabling an authentication method makes the shadow password more secure if a malicious user gains physical access to a server’s shadow password files or to media containing a backup of the shadow password files. Someone who gains access to the password files can try to crack a user’s password by attacking the hash or recoverable text stored by any authentication method. Nothing is stored by a disabled authentication method, leaving one less avenue of attack open to a cracker who has physical access to a server’s shadow password files or a backup of them. Hashes stored by some authentication methods are easier to crack than others. With recoverable authentication methods, original clear text password can be reconstructed from what is stored in the file. Disabling the authentication methods that store recoverable or weaker hashes increases shadow password file security more than disabling methods that store stronger hashes. If you believe a server’s shadow password files and backups are secure, select all authentication methods. If you’re concerned about the physical security of the server or its backup media, disable unused methods. Note: Disabling authentication methods does not increase the security of passwords while they are transmitted over the network; only the password storage security is affected. Disabling some authentication methods may require clients to configure their software to send passwords over the network in clear text, thereby compromising password security in a different way.

Contents of the Open Directory Password Server Database Open Directory Password Server maintains an authentication database separate from the directory domain. Open Directory tightly restricts access to the authentication database. Open Directory Password Server stores the following information in its authentication database for each user account that has a password type of Open Directory: Â The user’s password ID, a 128-bit value assigned when the password is created. It is also stored in the user’s record in the directory domain and is used as a key for finding a user’s record in the Open Directory Password Server database. Â The password, stored in recoverable (clear text) or hashed (encrypted) forms. The form depends on the authentication method. A recoverable password is stored for the APOP and WebDAV authentication methods. For all other methods, the record stores a hashed (encrypted) password. If no authentication method requiring a clear text password is enabled, the Open Directory authentication database stores only hashes of passwords. Â The user’s short name, for use in log messages viewable in Server Admin. Â Password policy data. Â Time stamps and other usage information, such as last login time, last failed validation time, count of failed validations, and replication information. LDAP Bind Authentication For user accounts that reside in an LDAP directory on a non-Apple server, Open Directory attempts to use LDAP bind authentication. Open Directory sends the LDAP directory server the name and password supplied by the authenticating user. If the LDAP server finds a matching user record and password, authentication succeeds. If the LDAP directory service and the client computer’s connection to it are configured to send clear text passwords over the network, LDAP bind authentication can be insecure. Open Directory tries to use a secure authentication method with the LDAP directory. If the directory doesn’t support secure LDAP bind and the client’s LDAPv3 connection permits sending a clear text password, Open Directory reverts to simple LDAP bind. To prevent clear text authentication make sure your LDAP servers don’t accept clear text passwords. In this case, you can secure simple LDAP bind authentication by setting up access to the LDAP directory through the Secure Sockets Layer (SSL) protocol. SSL makes access secure by encrypting all communications with the LDAP directory. For more information, see “Changing the Security Policy for an LDAP Connection” on page 145 and “Changing the Connection Settings for an LDAP Directory” on page 144.

Management Tools This chapter presents guidelines for planning Open Directory services and describes tools for managing them. Like the plumbing and wiring in a building, directory services for a network must be planned in advance, not on an ad hoc basis. Keeping information in shared directory domains gives you more control over your network, gives more users access to the information, and makes it easier to maintain the information. The amount of control and convenience depends on the effort you put into planning your shared domains. The goal of directory domain planning is to design the simplest arrangement of shared domains that gives your Mac OS X users easy access to the network resources they need and that minimizes the time you spend maintaining user records and other administrative data.

General Planning Guidelines If you do not share user and resource information among multiple Mac OS X computers, very little directory domain planning is necessary, because everything can be accessed from a local directory domain. However, make sure that all individuals who use a particular Mac OS X computer have user accounts on that computer. These user accounts reside in the local directory domain on the computer. In addition, everyone who needs to use Mac OS X Server’s file service, mail service, or other services that require authentication must have a user account in the server’s local directory domain. With this arrangement, each user has two accounts, one for logging in to a computer and one for accessing services of Mac OS X Server, as illustrated in the following figure. The user logs in to the local directory domain of the Mac OS X computer then uses a different account to log in to the local directory domain of the file services server. To share information among Mac OS X computers and servers, you must set up at least one shared directory domain. With this arrangement, each user needs an account only in the shared directory domain. With this one account, the user can log in to Mac OS X on any computer that’s configured to access the shared directory domain. The user can also use this same account to access services of any Mac OS X Server that’s configured to access the shared directory domain. Local directory domain Local directory domain Log in to Mac OS X Connect to Mac OS X Server for file service

59 The following figure illustrates a configuration with a shared directory domain. The figure shows a user logging in to a Mac OS X computer using a shared directory domain account. Then the shared directory domain account is also used to access a file service. When the user attempts to access the file service, file services server accesses the shared directory domain to verify the user account. Because both the user computer and file services computer are connected to the shared directory domain, the user account on the shared directory domain is used to access both a computer and services without having to have a local account on each computer. In many organizations, a single shared directory domain is adequate. It can handle hundreds of thousands of users and thousands of computers sharing the same resources, such as printer queues, share points for home directories, share points for applications, and share points for documents. Replicating the shared directory domain can increase the capacity or performance of the directory system by configuring multiple servers to handle the directory system load for the network. Shared directory domain Local directory domain Local directory domain Log in to Mac OS X Connect to Mac OS X Server for file service

Larger, more complex organizations can benefit from extra shared directory domains. The following figure shows how one such complex organization might organize its directory domains. If you have a large organization and you want to increase the performance and capacity of your network directory domain, you can add multiple directory domains to your network. Also, by using multiple directory domains you can load balance your corporate directory domain. There are different methods of configuring multiple directory domains. By analyzing your network topology you can determine the best method for your network. The following are optional configurations of multiple directory domains: Â Open Directory with a preexisting domain. You can configure a Mac OS X Open Directory server on a network that has a preexisting directory domain such as an Active Directory or Open Directory domain. For example, if your organization has a preexisting Active Directory server that supports Windows and Mac OS X client computers you can add a Mac OS X Open Directory server to better support your Mac users. The two servers can exist on the same network and provide redundant directory domains for both Windows and Mac OS X clients. You also configure the Mac OS X Server to handle cross-domain authorization if a Kerberos realm exists. If you set up your Mac OS X server with the workgroup configuration, you can easily add it to your preexisting directory domain. Using the workgroup configuration of Mac OS X you can easily import users from your preexisting directory domain into your workgroup server. These imported users are referred to as augmented users. For more information about augmented users and workgroup or standard configuration of Mac OS X server, see Getting Started and User Management. Mac OS X user Windows user Mac OS X Server Windows server Active Directory domain Local directory domain Shared directory domain Local directory domain

61 Â Open Directory Master Server with replicas. You can also create a Mac OS X Open Directory master server with replicas. The replica servers have a copy of the Open Directory master’s directory domain for load balancing and redundancy. Â For example, your organization could have an Open Directory master at your headquarters and place replicas of that server at each remote location. This prevents users at remote locations from experiencing delayed logins. Â Cascading replication. You can also use cascading replication, where replicas of an Open Directory master have replicas. If a replica is a direct member of the Open Directory master and it has replicas it is called a relay. For example, If your organization has 32 replicas and you must add another replica, you can reorganize your network topology and have your replicas become relays by adding replicas to a replica (or relay). Cascading replication load balances the Open Directory master by minimizing the number of replicas it must directly manage. Estimating Directory and Authentication Requirements In addition to considering how you want to distribute directory data among multiple domains, you must also consider the capacity of each directory domain. The size of your directory domain depends on your network requirements. One factor is the performance of the database that stores directory information. The LDAP directory domain of Mac OS X Server uses the Berkeley DB database, which remains efficient with 200,000 records. A server hosting a directory domain of that size must have sufficient hard disk space to store all the records. The number of connections a directory service can handle is harder to measure because directory service connections occur in the context of the connections of all services the server provides. With Mac OS X Server, a server dedicated to Open Directory has a limit of 1000 simultaneous client computer connections. The Open Directory server can provide LDAP and authentication services to more client computers, because not all computers need these services at the same time. Each computer connects to the LDAP directory for up to two minutes, and connections to the Open Directory Password Server are even more brief. Determining what the fraction is—what percentage of computers will make connections at the same time—can be difficult. For example, computers that each have a single user who spends all day working on graphics files will need Open Directory services relatively infrequently.

In contrast, computers in a lab will have many users logging in throughout the day, each with a different set of managed client preference settings, and these computers will place a relatively high load on Open Directory services. In general, you can correlate Open Directory usage with login and logout. These activities generally dominate directory and authentication services for any system. The more frequently users log in and out, the fewer computers an Open Directory server (or any directory and authentication server) can support. You need more Open Directory servers if users log in frequently. You can get by with fewer Open Directory servers if work sessions are long and login is infrequent. Identifying Servers for Hosting Shared Domains If you need more than one shared domain, identify the servers where the shared domains should reside. Shared domains affect many users, so they should reside on Mac OS X Server computers that have the following characteristics:  Restricted physical access  Limited network access  High-availability technologies, such as uninterruptible power supplies Select computers that will not be replaced frequently and that have adequate capacity for expanding directory domains. Although you can move a shared domain after it is set up, it might be necessary to reconfigure the search policies of computers that connect to the shared domain so users can continue to log in. Replicating Open Directory Services Mac OS X Server supports replication of the LDAP directory service, the Open Directory Password Server, and the Kerberos KDC. By replicating your directory and authentication services you can:  Move directory information closer to a population of users in a geographically distributed network, improving performance of directory and authentication services to these users.  Achieve redundancy, so users see little disruption in service if a directory system fails or becomes unreachable. One server has a primary copy of the shared LDAP directory domain, Open Directory Password Server, and Kerberos KDC. This server is referred to as an Open Directory master. Each Open Directory replica is a separate server with a copy of the master’s LDAP directory, Open Directory Password Server, and Kerberos KDC. A Mac OS X Open Directory Server can have up to 32 replicas. Each replica can have 32 replicas of itself, providing you with1056 replicas in a two-tier hierarchy.

63 Access to the LDAP directory on a replica is read only. Changes to user records and other account information in the LDAP directory can be made only on the Open Directory master. The Open Directory master updates its replicas when there are changes to the LDAP directory. The master can update replicas every time a change occurs, or you can set up a schedule so updates occur at regular intervals. The fixed schedule option is best if replicas are connected to the master by a slow network link. Passwords and password policies can be changed on any replica. If a user’s password or password policy are changed on more than one replica, the most recent change prevails. The updating of replicas relies on the clocks of the master and replicas being in sync. If replicas and the master have different times, updating could be arbitrary. The date, time, and time zone information must be correct on the master and replicas, and they should use the same network time service to keep their clocks in sync. Avoid having only one replica on either side of a slow network link. If a replica is separated from all other replicas by a slow network link and the one replica fails, clients of the replica will fail over to a replica on the other side of the slow network link. As a result, their directory services may slow markedly. If your network has a mix of Mac OS X Server versions 10.4 and 10.5, one version can’t be a replica of a master of the other version. An Open Directory master of v10.5 won’t replicate to v10.4, nor will an Open Directory master of v10.4 replicate to v10.5: Replica Sets A replica set is an automatic configuration that requires each service that Open Directory manages (LDAP, Password server, and Kerberos) to look for and use the same replica server. This helps ensure that client computers choose the same replica server when using Open Directory services and helps prevent slow login. Replica version Mac OS X Server v10.5 master Mac OS X Server v10.4 master Mac OS X Server v10.5 replica Yes No Mac OS X Server v10.4 replica No Yes

Cascading Replication Mac OS X v10.4 used a hub-spoke model for replicating Open Directory master servers. This required each Open Directory master to maintain a transaction record for each replica server. The following illustration shows the hub-spoke model used for replication in Mac OS X v10.4. In addition, there was no predefined limit to how many replica servers an Open Directory master could manage. If an Open Directory master had 1000 replicas to manage, it could have performance issues if replicas continued to be added. This is similar to having one manager for 1000 employees, which is an unmanageable situation. Mac OS X Server v10.5 uses cascading replication to improve scalability and resolve performance issues with the older hub-spoke model of replication. The use of cascading replication helps limit the number of replica servers that can be supported by a single Open Directory master server. A single Open Directory master server can have up to 32 replicas and each of those replicas can have up to 32 replicas, which gives you 1056 replicas of a single Open Directory master server. This creates a two-tier hierarchy of replica servers. The first tier of replicas, which are the direct members of the Open Directory master, are called relays if they have replicas, because they relay the data to the second tier of replicas. Also, cascading replication does not require that a single Open Directory master server maintain a transaction record of each replica server. The master server only keeps a maximum of 32 replica transaction records, which improves performance. Replica Replica Replica Replica Replica Replica Open Directory Master

65 The following illustration shows the two-tier hierarchy of the cascading replication model. Planning the Upgrade of Multiple Open Directory Replicas If your Open Directory master manages more than 32 replicas, your organization must migrate to a cascading replication. The cascading replication model will improve your Open Directory server performance. When planning for your migration consider the locations of your replica servers and your network topology to help determine how to reorganize your replicas into a hierarchal structure. For example, you would not want to have an Open Directory master on the West coast replicating out to a replica on the East coast. Note: If your Open Directory master has fewer than 32 replicas, a migration is not necessary. Load Balancing in Small, Medium, and Large Environments Do not use service load-balancing software from third parties with Open Directory servers. Load-balancing software can cause unpredictable problems for Open Directory computers. It can interfere with the automatic load balancing and failover behavior of Open Directory in Mac OS X and Mac OS X Server. Mac OS X computers seek the nearest available Open Directory server—master or replica. A computer’s nearest Open Directory master or replica is the one that responds most quickly to the computer’s request for an Open Directory connection. Replica Replica Replica Replica Replica Replica Replica Replica Open Directory Master Relay (Replica) Relay (Replica) Relay (Replica) Relay (Replica)

Replication in a Multibuilding Campus A network that spans multiple buildings may have slower network links between buildings than the link within each building. The network links between buildings may also be overloaded. These conditions can adversely affect the performance of computers that get Open Directory services from a server in another building. As a result, you may want to set up an Open Directory replica in each building. Depending on need, you may even want to set up an Open Directory replica on each floor of a multistory building. Each replica provides efficient directory and authentication services to client computers in its vicinity. The computers do not need to make connections with an Open Directory server across the slow, crowded network link between buildings. Having more replicas has a disadvantage. Replicas communicate with each other and with the master over the network. This network communication overhead increases as you add replicas. Adding too many replicas can add more network traffic between buildings in the form of replication updates than it removes in the form of Open Directory client communications. When deciding how many replicas to deploy, consider how heavily the computers will use Open Directory services. If the computers are relatively light users of Open Directory services and your buildings are connected by fairly fast network links (such as 100 Mbit/s Ethernet), you probably do not need a replica in each building. You can reduce the communication overhead between Open Directory replicas and the master by scheduling how often the Open Directory master updates the replicas. You might not need the replicas updated every time a change occurs in the master. Scheduling less frequent updates of replicas will improve network performance. Using an Open Directory Master, Replica, or Relay with NAT If your network has an Open Directory server on the private network side of a network address translation (NAT) router (or gateway), including the NAT router of Mac OS X Server, only computers on the private network side of the NAT router can connect to the Open Directory server’s LDAP directory domain. Computers on the public network side of the NAT router can’t connect to the LDAP directory domain of an Open Directory master or replica that’s on the private network side. If an Open Directory server is on the public network side of a NAT router, computers on the private network and the public network sides of the NAT router can connect to the Open Directory server’s LDAP directory.

67 If your network supports mobile clients such as MacBooks that will move between the private LAN of your NAT gateway and the Internet, you must set up VPN service for mobile users so they can use a VPN to connect to the private network and the Open Directory domain. Open Directory Master and Replica Compatibility The Open Directory master and its replicas must use the same version of Mac OS X Server. In addition: Â An Open Directory master using Mac OS X Server v10.5 won’t replicate to Mac OS X Server v10.4. Â Mac OS X Server v10.5 can’t be a replica of an Open Directory master using Mac OS X Server v10.4. Â An Open Directory master using Mac OS X Server v10.5 can replicate to an Open Directory replica using Mac OS X Server v10.5. If you have an Open Directory master and replicas that use Mac OS X Server v10.4, upgrade them to v10.5 at the same time. First, upgrade the master; then, upgrade the replicas. Clients of the master and replicas will continue to receive directory and authentication services during the upgrade. While you are upgrading the master, its clients will fail over to the nearest replica. When you upgrade replicas one at a time, clients will fail back to the upgraded master. Upgrading an Open Directory master from Mac OS X Server v10.4 to v10.5 will sever ties to existing replicas. After upgrading each Open Directory replica to Mac OS X Server v10.5, it will be a standalone directory service and you’ll need to make it a replica again. For more information about upgrading to Mac OS X Server v10.5, see Upgrading and Migrating. Mixing Active Directory and Open Directory Master and Replica Services There are some special considerations when introducing Open Directory Servers into an Active Directory environment. If precautions are not taken, mixed results will occur on client experience and server functionality. Also, avoid mixing Authenticated Directory Binding and Active Directory on the same client or server. Authenticated binding makes use of Kerberos as does Active Directory. Using both will cause unexpected behavior or nonfunctioning authentication services unless care is taken as detailed below.

When mixing Open Directory and Active Directory, you will only be able to use Kerberos credentials from one system or another for single sign-on purposes. You cannot have users exist in Active Directory and Open Directory and use both Kerberos credentials to Single Sign-on onto a server that is Kerberized for particular server. In other words, you cannot sign into Active Directory account and expect to use single sign-on with a server that is part of the Open Directory Kerberos realm. Kerberos is used in both Active Directory and Open Directory environments. Kerberos makes certain assumptions about determining the realm of a particular server when Kerberos tickets are to be used. The following is an example of mixing an Active Directory kerberos realm with an Open Directory master kerberos realm:  Active Directory Domain = company.com  Active Directory Kerberos realm = COMPANY.COM  Open Directory Server master = server1.company.com  Open Directory Kerberos realm = SERVER1.COMPANY.COM When kerberos attempts to obtain a TGS for using LDAP with server1.company.com, it will request “ldap/server1. [email protected]” unless domain_realm is present in the configuration. The “domain_realm” for Open Directory assumes that all “.company.com” belongs to “SERVER1.DEMOTREE.COM”. This would prevent all connectivity to the Active Directory domain named “company.com”. If you wish to mix Authenticated Directory Binding and Active Directory, then your Active Directory Domain and Open Directory realms and servers must be in a different hierarchy. For example:  Active Directory Domain = company.com  Active Directory Kerberos realm = COMPANY.COM  Open Directory Server master = server1.od.company.com  Open Directory Server realm = “OD.COMPANY.COM” Or  Active Directory Domain = ads.company.com  Active Directory Kerberos realm = ADS.COMPANY.COM  Open Directory Server master = server1.od.company.com  Open Directory Kerberos realm = OD.COMPANY.COM In both examples, a new DNS domain zone needs to be created and both forward and reverse DNS entries need to exist for the servers so that if an IP address is used for the Open Directory server, it will get the name expected. For example, IP address “server1.od.company.com” = 10.1.1.1, so lookup of 10.1.1.1 should be equal to “server1.od.company.com”, not “server1.company.com”.

69 Integrating with Existing Directory Domains If your network already has a directory domain, you can add another directory domain server to your network that uses your existing directory domain’s database to authorize users access. This configuration is referred to as cross-domain authorization and requires that your servers support Kerberos. If you use cross-domain authorization, one server will be a pseudomaster server and the other will be a subordinate server. All users will authenticate to the pseudomaster server using a method of authentication, so if a user authenticates, he or she will receive a Kerberos ticket. When the user attempts to access a service that is offered by the subordinate server, the subordinate server accepts and validates the user’s Kerberos ticket, which was given by the pseudomaster server, to authorize the user. The Kerberos ticket has Privilege Attribute Certificate (PAC) information, which contains the user name, user IDs (UIDs), and group membership IDs (GIDs). The subordinate server uses this information to verify that the user is authorized to use the service, by comparing the UID or GID to the access control list (ACL) of the service the user is requesting to access. Using cross-domain authorization keeps you from needing to create different user names and passwords for your subordinate directory domain server. You can use the same user names and passwords from the corporate directory domain along with the PAC information to authorize user access. Cross-domain authorization is an ideal configuration if you are not permitted to directly edit groups in the corporate directory domain. You can use cross-domain authorization between an Active Directory server and a Mac OS X v10.5 Open Directory server or between two Mac OS X v10.5 Open Directory servers. Cross-domain authorization does not work on a Mac OS X v10.4 server. To use PAC information, the pseudomaster server must have a Kerberos realm for the subordinate server to join. To become a subordinate for a directory system you must use Directory Utility to join your server to an Active Directory or Open Directory server that has Kerberos configured and running. Then, using Server Admin, you must promote your Open Directory server to an Open Directory master. The subordinate server automatically determines that it is subordinate to an Active Directory or Open Directory server and configures itself accordingly. You can also have a replica of your subordinate Open Directory server. To create a replica of a subordinate directory server, join your server to the pseudomaster and subordinate server using Directory Utility. Then configure the server to be a replica of the subordinate server.

If you don’t join the server to both the pseudomaster and subordinate server, it will be blocked or fail to become a replica. Integrating Without Schema Changes Mac OS X and Mac OS X Server integrate with most LDAP-based directories without needing to change the schema of your directory server. However, some record types may not be recognized or maintained by your server’s directory schema. When you integrate Mac OS X computers with your directory server, you might want to add a new record type or object class to the directory schema to better mange and support your Mac OS X client computers. For example, by default there may not be a Picture record type in your directory schema for your Mac OS X users, but you can add it to your directory schema so Picture records can be stored in the directory database. If you want to add records or attributes to your directory schema, consult your directory domain administrator for instructions. Integrating with Schema Changes If you are adding Mac OS X computers to your existing directory domain, you can make schema changes to your directory domain server to better support Mac OS X client computers. When you add a record type or attribute to your schema, investigate whether you already have a record type or attribute that can easily map to it in your existing directory schema. If you don’t have a similar record type or attribute that you can map to, you can add the record type or attribute to your schema. This is referred to as extending your schema. When you extend your schema you might need to change the default Access Control List (ACL) of specific attributes so computer accounts can read the user properties. For example, you can configure Mac OS X to access basic user account information in an Active Directory domain of a Windows 2000 or Windows 2003 or later server. For more information about extending your schema, see the Appendix, “Mac OS X Directory Data.” Avoiding Kerberos Conflicts with Multiple Directories If you set up an Open Directory master on a network that has an Active Directory domain, your network will have two Kerberos realms: An Open Directory Kerberos realm and an Active Directory Kerberos realm. For all practical purposes, other servers on the network can use only one Kerberos realm. When you set up a file server, mail server, or other server that can use Kerberos authentication, you must choose one Kerberos realm.

71 Mac OS X Server must belong to the same Kerberos realm as its client users. The realm has only one authoritative Kerberos server, which is responsible for all Kerberos authentication in the realm. The Kerberos server can only authenticate clients and servers in its realm. The Kerberos server can’t authenticate clients or services that are part of a different realm. Only user accounts in the chosen Kerberos realm will have single sign-on abilities. User accounts in the other realm can still authenticate, but they won’t have single sign-on. If you’re configuring a server to access multiple directory systems each with a Kerberos realm, plan carefully for the user accounts that will use Kerberized services. You must know the intent of having access to two directory services. You must join the server to the realm whose companion directory domain contains the user accounts that must use Kerberos and single sign-on. For example, you might want to configure access to an Active Directory realm for its user records and an Open Directory LDAP directory for the Mac OS X records and attributes that aren’t in Active Directory, such as group and computer records. Other servers could join the Active Directory Kerberos realm or the Open Directory Kerberos realm. In this case, the other servers should join the Active Directory Kerberos realm so the Active Directory user accounts have single sign-on. If you also have user accounts in the Open Directory server’s LDAP directory, users can still authenticate to them, but the Open Directory user accounts won’t use Kerberos or have single sign-on. They’ll use Open Directory Password Server authentication methods. You could put all Mac users in the Open Directory domain and all Windows users in the Active Directory domain, and they could all authenticate, but only one of the populations could use Kerberos. Important: Do not configure an Open Directory master or replica to also access an Active Directory domain (or any other directory domain with a Kerberos realm). If you do, the Open Directory Kerberos realm and the Active Directory Kerberos realm will try to use the same configuration files on the Open Directory server, which will disrupt Open Directory Kerberos authentication. To avoid a Kerberos configuration file conflict, don’t use an Open Directory server as a workstation for managing users in another Kerberos server’s directory domain, such as an Active Directory domain. Instead, use an administrator computer (a Mac OS X computer with server administration tools installed) that’s configured to access the related directory domains.

If you must use an Open Directory server to manage users in another server’s directory domain, make sure the other directory domain is not part of the Open Directory server’s authentication search policy. To further avoid a Kerberos configuration file conflict, don’t use an Open Directory server to provide services that access a different Kerberos server’s directory domain. For example, if you configure AFP file service to access both Open Directory and Active Directory, don’t use an Open Directory server to provide the file service. Use another server and join it to the Kerberos realm of one directory service or the other. Theoretically, servers or clients can belong to two Kerberos realms, such as an Open Directory realm and an Active Directory realm. Multiple-realm Kerberos authentication requires very advanced configuration, which includes setting up the Kerberos servers and clients for cross-realm authentication, and revising Kerberized service software so it can belong to multiple realms. Improving Performance and Redundancy You can improve the performance of Open Directory services by adding memory to the server and having it provide fewer services. This strategy also applies to every other service of Mac OS X Server. The more you can dedicate an individual server to a particular task, the better its performance will be. Beyond that general strategy, you can also improve Open Directory server performance by assigning the LDAP database to its own disk and the Open Directory logs to another disk. If your network includes replicas of an Open Directory master, you can improve network performance by scheduling less-frequent updates of replicas. Updating less frequently means the replicas have less up-to-date directory data, so you must strike a balance between higher network performance and less accuracy in your replicas. For greater redundancy of Open Directory services, set up extra servers as Open Directory replicas or use servers with RAID sets.

73 Open Directory Security With Mac OS X Server, a server with a shared LDAP directory domain also provides Open Directory authentication. It is important to protect the authentication data stored by Open Directory. This authentication data includes the Open Directory Password Server database and the Kerberos database, which must also be protected. Therefore, make sure an Open Directory master and all Open Directory replicas are secure by following these guidelines: Â Physical security of a server that is an Open Directory master or replica is paramount. Keep it behind a locked door, and always log it out. Â Secure the media you use to back up an Open Directory Password Server database and a Kerberos database. Having your Open Directory servers behind locked doors won’t protect a backup tape that you leave on your desk. Â Do not use a server that is an Open Directory master or replica to provide other services. If you can’t dedicate servers to be Open Directory master and replicas, minimize the number of services they provide. One of the other services could have a security breach that gives someone access to the Kerberos or Open Directory Password Server databases. Dedicating servers to provide Open Directory services is an optimal practice but is not required. Â Set up service access control lists (SACLs) for the login window and secure shell (SSH) to limit who can log in to an Open Directory master or replica. Â Avoid using a RAID volume that’s shared with other computers as the startup volume of a server that is an Open Directory master or replica. A security breach on one of the other computers could jeopardize the security of the Open Directory authentication information. Â Set up IP firewall service to block all ports except those used for the following directory, authentication, and administration protocols: Â Open Directory Password Server uses ports 106 and 3659. Â The Kerberos KDC uses TCP/UDP port 88, and TCP/UDP port 749 is used for Kerberos administration. Â The shared LDAP directory uses TCP port 389 for an ordinary connection and TCP port 636 for an SSL connection. Â When creating an Open Directory replica, keep port 22 open between the master and prospective replica. This port is used for secure shell (SSH) data transfer, which is used to transfer a complete, up-to-date copy of the LDAP database. After initial replica setup, only the LDAP port (389 or 636) is used for replication. Â Workgroup Manager uses TCP port 311 and 625. Â Server Admin uses TCP port 311. Â SMB uses TCP/UDP ports 137, 138, 139, and 445. Â Equip the Open Directory master computer with an uninterruptible power supply.

In summary, the most secure and best practice is to: Â Dedicate each server that is an Open Directory master or replica to provide only Open Directory services. Â Set up a firewall on these servers to provide only the following: directory access, authentication, and administration protocols (LDAP, Password Server, Kerberos, Workgroup Manager, and Server Manager.) Â Physically secure each Open Directory server and all backup media used with it. Replicating directory and authentication data over the network is a minimal security risk. Password data is securely replicated using random keys negotiated during each replication session. The authentication portion of replication traffic—the Open Directory Password Server and the Kerberos KDC—is fully encrypted. For extra security, configure network connections between Open Directory servers to use network switches rather than hubs. This isolates authentication replication traffic to trusted network segments. Service Access Control Lists (SACLs) Mac OS X uses SACLs to authorize user access to a service. SACLs are made up of access control entries (ACEs) that are used to determine the access privileges a user has to a service. You can use SACLs to allow or deny user access to an Open Directory master or replica by setting SACLs for the login window and SSH. This restricts access to the service. You can also use SACLs to set administrator access to Open Directory. This does not restrict access to the service; instead, it specifies who can administer or monitor the service. For more information about setting administrator SACLs, see “Configuring Service Access Control” on page 175. SACLs provide you with greater control over specifying the administrators that have access to monitor and manage the service. Only users and groups listed in an SACL have access to its corresponding service. For example, if you want to give administrator access to users or groups for the Open Directory service on your server, add them to the Open Directory SACL as an ACE.

75 Tiered Administration Mac OS X Server does not use organizational units (OUs) for user or group privileges in directory services. Privileges are independent of how you organize your directory database. Mac OS X Server v10.5 uses tiered administration for greater granularity of user read/write privileges for records in the directory database. User privileges are controlled by organizing users or groups into an ACL and granting users read/write privileges to records. The entries of users or groups in ACLs are referred to as ACEs. By using tiered administration you can easily organize your users within groups and specify the records a group can administer. If you use tiered administration, consider the following:  Who is going to be in the group  The privileges you want to give each group  The records you want your group to administer You can give users or groups full or limited control over domain administration. When giving limited administrative control, you can choose which users and groups a user or group can administer. You can also specify the control the user has over those users and groups. For example, granting a user full control gives that user unrestricted control of the directory domain. You can only change a user’s domain privileges for LDAPv3 directory domains. You can’t change privileges for a local directory domain account or for an account stored in a non-LDAPv3 directory domain. Full and limited administrators use Workgroup Manager to administrate and manage users. For more information, see User Management. Tools for Managing Open Directory Services The Server Admin, Directory Utility, and Workgroup Manager applications provide a graphical interface for managing Open Directory services in Mac OS X Server. In addition, you can manage Open Directory services from the command line by using Terminal. All these applications are included with Mac OS X Server and can be installed on another computer with Mac OS X v10.5 or later, making that computer an administrator computer. For more information about setting up an administrator computer, see the Server Administration chapter of Getting Started.

Server Admin The Server Admin application provides access to tools you use to set up, manage, and monitor Open Directory services and other services. You use Server Admin to:  Set up Mac OS X Server as an Open Directory master, an Open Directory replica, a server that’s connected to a directory system, or a standalone directory service with only a local directory domain. For more information, see Chapter 5, “Setting Up Open Directory Services.”  Set up more Mac OS X Server systems to use the Kerberos KDC of an Open Directory master or replica. For more information, see Chapter 5.  Configure LDAP options on an Open Directory master. For more information, see Chapter 5.  Configure DHCP service to supply an LDAP server address to Mac OS X computers with automatic search policies. For more information, see the DHCP chapter of Network Services Administration.  Set up password policies that apply to all users who don’t have overriding individual password policies. For more information, see Chapter 6, “Managing User Authentication.” (To set up individual password policies, use Workgroup Manager; see Chapter 6.)  Monitor Open Directory services. For more information, see Chapter 9, “Maintaining Open Directory Services.” For basic information about using Server Admin, see the Server Administration chapter in Getting Started. This chapter explains the following:  Opening and authenticating in Server Admin  Working with servers  Administering services  Controlling access to services  Using SSL for remote server administration  Customizing the Server Admin environment Server Admin is in /Applications/Server/.

77 Directory Utility Directory Utility determines how a Mac OS X computer uses directory services, discovers network services, and searches directory services for authentication and contacts information. You use Directory Utility to:  Configure access to LDAP directories, an Active Directory domain, and Network Information Services (NIS) domain  Configure data mapping for LDAP directories  Define policies for searching multiple directory services for authentication and contact information  Enable or disable types of directory services and types of network service discovery Directory Utility can connect to other servers on your network so you can configure them remotely. For more information about using Directory Utility, see Chapter 7, “Managing Directory Clients.” Directory Utility is installed on every Mac OS X computer in /Applications/Utilities/. Workgroup Manager The Workgroup Manager application provides comprehensive management of Mac OS X Server clients. You use Workgroup Manager to:  Set up and manage user accounts, group accounts, and computer groups. For more information about managing user authentication, see Chapter 6, “Managing User Authentication.” For more information about other user, group, and computer management topics, see User Management.  Manage share points for file services and user home folders. For more information, see the chapters on share points and SMB services in File Services Administration and the chapter on home folders in User Management.  Control what Mac OS X users see when they select the Network globe in a Finder sidebar. For more information, see the chapter on managing network views in User Management.  View directory entries in raw form by using the Inspector. For more information, see “Viewing and Editing Directory Data” on page 179. For basic information about using Workgroup Manager, see the chapter on server administration in Getting Started. This chapter explains the following:  Opening and authenticating in Workgroup Manager  Administering accounts  Customizing the Workgroup Manager environment Workgroup Manager is installed in /Applications/Server/.

Command-Line Tools A full range of command-line tools is available for administrators who prefer to use command-driven server administration. For remote server management, submit commands in a secure shell (SSH) session. You can enter commands on Mac OS X servers and computers using the Terminal application, located in /Applications/Utilities/. For more information, see Command-Line Administration.

Open Directory Services Open Directory services—directory services and authentication services—are an essential part of a network’s infrastructure. These services have a significant effect on other network services and on users. Therefore you must set up Open Directory correctly from the beginning. Setup Overview Here is a summary of the major tasks you perform to set up Open Directory services. For detailed information about each step, see the pages indicated. Step 1: Before you begin, do some planning For a list of items to think about before you configure Open Directory on Mac OS X Server, see “Before You Begin” on page 80. Step 2: Turn on Open Directory service Use Server Admin to turn the Open Directory service on. After the service is turned on you can configure Open Directory service settings. For more information about turning on Open Directory service, see “Turning Open Directory On” on page 81. Step 3: Set up a standalone directory service To set up servers that won’t get authentication and other administrative information from a directory service, see “Setting Up a Standalone Directory Service” on page 81. Step 4: Set up an Open Directory master To set up a server to provide directory and authentication services, see “Open Directory Master and Replica Compatibility” on page 67 and “Setting Up an Open Directory Master” on page 83. Step 5: Set up a Primary Domain Controller To set up a server to provide directory and authentication services for Windows and Mac OS X platforms, see “Setting Up a Primary Domain Controller” on page 85.

Step 6: Set up an Open Directory replica To set up servers to provide failover directory and authentication services or remote directory and authentication services for fast client interaction on distributed networks, see “Setting Up an Open Directory Replica” on page 88. Step 7: Set up Open Directory Relays for Cascading Replication To set up a server to be a replica or relay of an Open Directory master so it can provide directory information and authentication information to computers, see “Setting Up Open Directory Relays for Cascading Replication” on page 91. Step 8: Set up a Server as a Backup Domain Controller To set up servers to provide failover support for your Primary Domain Controller, see “Setting Up a Server as a BDC” on page 91. Step 9: Set up servers that connect to other directory systems If you have file servers or other servers that access directory and authentication services, see “Setting Up a Connection to a Directory Server” on page 93. Step 10: Set up single sign-on Kerberos authentication If you have an Open Directory master, you can configure other servers to join its Kerberos realm. If you set up an Open Directory master without Kerberos, you can set up Kerberos later. For more information, see “Setting Up Single Sign-On Kerberos Authentication” on page 97. Step 11: Set up client computers to connect to directory services If you have an Open Directory master, you must configure client computers to access its directory domain. You can also configure computers to access other directory services such as Microsoft Active Directory. See Chapter 7, “Managing Directory Clients.” and Chapter 8, “Advanced Directory Client Settings.” Step 12: Instruct users how to log in See “Instructing Users How to Log In” on page 85. Before You Begin Before setting up Open Directory services for the first time: Â Understand the uses of directory data and assess your directory needs. Identify the services that require data from directory domains and determine which users need access to those services. Users whose information can be managed most easily on a server should be defined in the shared LDAP directory of a Mac OS X Server that is an Open Directory master. Some of these users can be defined in directory domains on other servers, such as an Active Directory domain on a Windows server. These concepts are discussed in Chapter 1, “Directory Services with Open Directory.”

81 Â Assess whether you need more than one shared domain. If so, decide which users will be defined in each shared domain. For more information, see “Multilevel Search Policies” on page 35. Â Determine which authentication options users need. For available options, see Chapter 3, “Open Directory Authentication.” Decide whether to have replicas of your Open Directory master or to have a BDC of your PDC. Chapter 4, “Open Directory Planning and Management Tools,” provides guidelines. Â Select server administrators carefully. Provide administrator passwords only to people you trust. Have as few administrators as possible. Don’t delegate administrator access for minor tasks, such as changing settings in a user record. Directory information vitally affects everyone whose computers use it. Managing Open Directory on a Remote Server You can install Server Admin on a computer with Mac OS X v10.4 or later and use it to manage Open Directory on any server on your local network and beyond. You can also manage Open Directory remotely by using command-line tools from a Mac OS X computer or a non-Macintosh computer. For more information, see the Server Administration chapter of Getting Started. Turning Open Directory On Before you can configure Open Directory settings, you must turn on Open Directory service in Server Admin. To turn Open Directory service on: 1 Open Server Admin and connect to the server. 2 Click Settings. 3 Click Services. 4 Select the Open Directory checkbox. 5 Click Save. Setting Up a Standalone Directory Service Using Server Admin, you can set up Mac OS X Server to use only the server’s local directory domain. The server does not provide directory information to other computers or get directory information from an existing system. (The local directory domain cannot be shared.)

If you change Mac OS X Server to get directory information only from its local directory domain, user records and other information that the server retrieved from a shared directory domain becomes unavailable. The user records and other information in the shared directory domain are deleted. Files and folders on the server may become unavailable to users whose accounts are in the shared directory domain. If the server was an Open Directory master and other servers were connected to it, the following can occur: Â Services can be disrupted on the connected servers when the user accounts and other information in the shared directory domain become unavailable. Â Users whose accounts are in the shared directory domain may not be able to access files and folders on the Open Directory master and on other servers that were connected to its shared LDAP directory domain. You can archive a copy of the Open Directory master’s directory and authentication data before changing it to an Open Directory standalone directory service. For more information, see “Archiving an Open Directory Master” on page 194. You can also export users, groups, and computer groups from the Open Directory master before changing it to a standalone directory service. For more information, see User Management. To configure a server to use only its own nonshared local directory domain: 1 Open Server Admin and connect to the 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 Change. The Service Configuration Assistant opens. 6 Choose Standalone, then click Continue. 7 Confirm the Open Directory configuration setting, then click Continue. 8 If you are sure that users and services no longer need access to the directory data stored in the shared directory domain that the server has been hosting or is connected to, click Close.

83 Setting Up an Open Directory Master Using Server Admin, you can set up Mac OS X Server to be an Open Directory master so it can provide directory information and authentication information to other systems. Mac OS X Server provides directory information by hosting a shared LDAP directory domain. In addition, the server authenticates users whose accounts are stored in the shared LDAP directory domain. An Open Directory master has an Open Directory password server, which supports all conventional authentication methods required by Mac OS X Server services. In addition, an Open Directory master can provide Kerberos authentication for single sign-on. If you want the Open Directory master to provide Kerberos authentication for single sign-on, DNS must be available on the network and must be correctly configured to resolve the fully qualified DNS name of the Open Directory master server to its IP address. DNS must also be configured to resolve the IP address to the server’s fully qualified DNS name. Important: If you’re changing an Open Directory replica to an Open Directory master, the procedure you follow depends on whether the replica will replace the master or become an extra master: Â To promote a replica to replace a nonfunctional master, follow the instructions in “Promoting an Open Directory Replica” on page 190 instead of the instructions here. Â To change a replica to an extra master, first decommission the replica as described in “Decommissioning an Open Directory Replica” on page 193, then make it a master by following the steps in this topic. Note: If Mac OS X Server was connected to a directory system and you make the server an Open Directory master, it remains connected to the other directory system. The server will search for user records and other information in its shared LDAP directory domain before searching in other directory systems it is connected to. To configure a server to be an Open Directory master: 1 Open Server Admin and connect to the 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. If the Role option is set to Open Directory Replica and you want to make a new Open Directory master, you must change the server role to Standalone. For more information, see “Setting Up a Standalone Directory Service” on page 81.

If you don’t change an Open Directory replica to a standalone server before making it a master, you promote the replica to be a master instead of making a new master. For more information, see “Promoting an Open Directory Replica” on page 190. 5 Click Change. This opens the Service Configuration Assistant. 6 Select Open Directory Master, then click Continue. 7 Enter the following Master Domain Administrator information, then click Continue. Â Name, Short Name, User ID, Password: You must create a user account for the primary administrator of the LDAP directory. This account is not a copy of the administrator account in the server’s local directory domain. Make the names and user ID of the LDAP directory administrator different from the names and user IDs of user accounts in the local directory domain. Also, if you want to prevent the directory administrator account from being listed in the login window, you should assign the directory administrator account a user ID below 100. Accounts with user IDs below 100 are not listed in the login window. Note: If you plan to connect your Open Directory Master to other directory domains, pick a unique name and user ID for each domain. Don’t use the suggested diradmin user ID. Use a name that helps you distinguish the directory domain that the directory administrator controls. 8 Enter the following Master Domain information, then click Continue: Â Kerberos Realm: This field is preset to be the same as the server’s DNS name, converted to capital letters. This is the convention for naming a Kerberos realm. You can enter a different name if necessary. Â Search Base: This field is preset to a search base suffix for the new LDAP directory, derived from the domain portion of the server’s DNS name. You can enter a different search base suffix or leave it blank. If you leave this field blank, the LDAP directory’s default search base suffix is used. 9 Confirm settings, then click Close. 10 Confirm that the Open Directory master is functioning properly by clicking Overview (near the top of the Server Admin window, with Open Directory selected in the Servers list). The status of all items listed in the Open Directory overview pane should say “Running.” If Kerberos remains stopped and you want it running, see “If Kerberos Is Stopped on an Open Directory Master or Replica” on page 199. After setting up a Mac OS X Server computer to be an Open Directory master, you can change its binding policy, security policy, password policy, replication frequency, and LDAP protocol options. For more information, see “Setting Options for an Open Directory Server” on page 183.

85 You can configure other computers with Mac OS X or Mac OS X Server to access the server’s shared LDAP directory domain. For more information, see “Using Advanced LDAP Service Settings” on page 133. Instructing Users How to Log In When a Mac OS X computer is connected to a directory domain and is configured to display a list of users in the Mac OS X login window, the list may include “Other.” Tell users who have never logged in with a network account that they must click Other and then enter the account name and password. Users can configure their computers to not display a list of users in the login window. Users change this setting in the Accounts pane of System Preferences by clicking Login Options. You can have a computer’s login window show network users in its list, or you can prevent the list from appearing by managing computer preferences. Use Workgroup Manager to configure login preference settings for the computer group account that includes the computer. To manage computers that are not part of a particular computer group account, configure login preference settings for the Guest Computers account. For more information, see User Management. Setting Up a Primary Domain Controller Using Server Admin, you can set up Mac OS X Server as a Windows primary domain controller (PDC). The PDC hosts a Windows domain and provides authentication services to other domain members, including authentication for domain login on Windows workstations. If no domain member server is available, the PDC server can provide Windows file and print services, and it can host user profiles and home folders for users who have user accounts on the PDC. Important: When setting up Mac OS X Server as a PDC, make sure your network doesn’t have another PDC with the same domain name. To set up more domain controllers, make them backup domain controllers (BDCs). To set up a Windows PDC: 1 Make sure the server is an Open Directory master. To determine whether a server is an Open Directory master, open Server Admin, click the triangle (to the left of the server), select Open Directory in the expanded list of services, then click Overview. The first line of status information states the role of the Open Directory server.

2 Open Server Admin and connect to the server. 3 Click Settings, then click Services 4 Select the SMB checkbox, then click Save. 5 Click the triangle to left of the server. The list of services appears. 6 From the Servers list, select SMB. 7 Click Settings, then click General. 8 From the Role pop-up menu, choose Primary Domain Controller (PDC), then enter the following: Â Description: This description appears in the Network Places window on Windows computers and is optional. Â Computer Name: Enter the name you want Windows users to see when they connect to the server. This is the server’s NetBIOS name. The name should contain no more than 15 characters, no special characters, and no punctuation. If practical, make the server name match its unqualified DNS host name. For example, if your DNS server has an entry for your server as “server.example.com,” give your server the name “server.” Â Domain: Enter the name of the Windows domain that the server will host. The domain name cannot exceed 15 characters and cannot be “workgroup.” 9 Click Save. 10 Enter the name and password of an LDAP directory administrator account, then click OK. When authenticating, you must use an LDAP directory administrator account. You can’t use a local administrator account, such as the primary server administrator account (user ID 501), to create a PDC. After setting up a PDC, you can change access restrictions, logging detail level, code page, domain browsing, or WINS registration. Then if Windows services aren’t running, you can start them. For more information, see Network Services Administration. Setting Up Windows Vista for Domain Login You can enable domain login on a Windows Vista computer by joining it to the Windows domain of a Mac OS X Server PDC. Joining the Windows domain requires the name and password of an LDAP directory administrator account. You can delegate this task to someone with a local administrator account on the Windows computer. In this case, you may want to create a temporary LDAP directory administrator account with limited privileges. For more information, see User Management.

87 Note: Only Windows Vista Ultimate and Business edition can be connected to a domain. To join a Windows Vista computer to a Windows domain: 1 Log in to Windows Vista using a local administrator account. 2 Open the Control Panel, then open System. 3 Click Change Settings. 4 Click Computer Name, then click Change. 5 Enter a computer name, click Domain, enter the domain name of the Mac OS X Server PDC, and click OK. To look up the domain name of the server, open Server Admin on the server or an administrator computer, select SMB in the Servers list, click Settings, then click General. 6 Enter the name and password of an LDAP directory administrator and click OK. Setting Up Windows XP for Domain Login You can enable domain login on a Windows XP computer by joining it to the Windows domain of a Mac OS X Server PDC. Joining the Windows domain requires the name and password of an LDAP directory administrator account. You can delegate this task to someone with a local administrator account on the Windows computer. In this case, you may want to create a temporary LDAP directory administrator account with limited privileges. For more information, see User Management. To join a Windows XP computer to a Windows domain: 1 Log in to Windows XP using a local administrator account. 2 Open the Control Panel, then open System. 3 Click Computer Name, then click Change. 4 Enter a computer name, click Domain, enter the domain name of the Mac OS X Server PDC, and click OK. To look up the domain name of the server, open Server Admin on the server or an administrator computer, select SMB in the Servers list, click Settings, then click General. 5 Enter the name and password of an LDAP directory administrator and click OK. Setting Up Windows 2000 for Domain Login You can enable domain login on a Windows 2000 computer by joining it to the Windows domain of a Mac OS X Server PDC. Joining the Windows domain requires the name and password of an LDAP directory administrator account.

You can delegate this task to someone with a local administrator account on the Windows computer. In this case, you may want to create a temporary LDAP directory administrator account with limited privileges. For more information, see User Management. To join a Windows 2000 computer to a Windows domain: 1 Log in to Windows 2000 using a local administrator account. 2 Open the Control Panel, then open System. 3 Click Network Identification, then click Properties. 4 Enter a computer name, click Domain, enter the domain name of the Mac OS X Server PDC, and click OK. To look up the domain name of the server, open Server Admin on the server or an administrator computer, select SMB in the Servers list, click Settings, then click General. 5 Enter the name and password of an LDAP directory administrator and click OK. Setting Up an Open Directory Replica Using Server Admin, you can set up Mac OS X Server to be a replica of an Open Directory master so it can provide the same directory information and authentication information to other systems as the master. The replica server hosts a read-only copy of the master’s LDAP directory domain. The replica server also hosts a read/write copy of the Open Directory Password Server and the Kerberos Key Distribution Center (KDC). Open Directory replicas provide these benefits: Â In a wide area network (WAN) of local area networks (LANs) interconnected by slow links, replicas on the LANs provide servers and client computers with fast access to user accounts and other directory information. Â A replica provides redundancy. If the Open Directory master fails, computers connected to it switch to a nearby replica. This automatic failover behavior is a feature of Mac OS X and Mac OS X Server v10.4 and 10.5. Note: If your network has a mix of Mac OS X Server versions 10.4 and 10.5, one version can’t be a replica of a master of the other version. An Open Directory master of v10.5 won’t replicate to Mac OS X Server v10.4, nor will an Open Directory master of Mac OS X Server v10.4 replicate to Mac OS X Server v10.5. When you set up an Open Directory replica, all directory and authentication data must be copied to it from the Open Directory master. Replication can take several seconds or several minutes, depending on the size of the directory domain. Replication over a slow network link can take a long time.

89 During replication, the master cannot provide directory or authentication services. You can’t use user accounts in the master LDAP directory to log in or authenticate for services until replication is finished. To minimize the disruption of directory service, set up a replica before the master LDAP directory is fully populated or at a time of day when the directory service is not needed. Having another replica set up will insulate clients of directory service from problems if the master becomes unavailable. If you change a Mac OS X Server computer that was connected to another directory system to be an Open Directory replica, the server remains connected to the other directory system. The server searches for user records and other information in its shared LDAP directory domain before searching in other directory systems it is connected to. To configure a server to host a replica of an Open Directory master: 1 Make sure the master, the prospective replica, and every firewall between them is configured to permit SSH communications (port 22). You can enable SSH for Mac OS X Server in Server Admin. Select the server in the Servers list, click Settings, click General, then select the Remote Login (SSH) option. Make sure that SSH access is not restricted to certain users or groups (using SACLs) on the prospective master. This will cause Server Admin to not have the necessary permissions during creation of the replica. You can temporarily disable SACLs in Server Admin under Settings > Access. For more information about SSH, see Getting Started. For more information about permitting SSH communications through the Mac OS X Server firewall, see Network Services Administration. 2 Open Server Admin and connect to the server. 3 Click the triangle to the left of the server. The list of services appears. 4 From the expanded Servers list, select Open Directory. 5 Click Settings, then click General. 6 Click Change. The Service Configuration Assistant opens. 7 Choose Open Directory Replica, then click Continue. 8 Enter the following requested information: Â IP address or DNS name of Open Directory master: Enter the IP address or DNS name of the server that is the Open Directory master. Â Root password on Open Directory master: Enter the password of the Open Directory master system’s root user (user name system administrator).

 Domain administrator’s short name: Enter the name of an LDAP directory domain administrator account.  Domain administrator’s password: Enter the password of the administrator account whose name you entered. 9 Click Continue. 10 Confirm the Open Directory configuration settings, then click Continue. 11 Click Close. 12 Make sure the date, time, and time zone are correct on the replica and the master. The replica and the master should use the same network time service so their clocks remain in sync. After you set up an Open Directory replica, other computers will connect to it as needed. Computers with v10.3 or v10.4 of Mac OS X or Mac OS X Server maintain a list of Open Directory replicas. If one of these computers can’t contact the Open Directory master for directory and authentication services, the computer connects to the nearest replica of the master. You can configure Mac OS X computers to connect to an Open Directory replica instead of the Open Directory master for directory and authentication services. On each Mac OS X computer, you can use Directory Utility to create an LDAPv3 configuration for accessing the replica’s LDAP directory. You can also configure a DHCP service to supply the replica’s LDAP directory to Mac OS X computers that get the address of an LDAP server from the DHCP service. See “Using Advanced LDAP Service Settings” on page 133 and “Defining Automatic Search Policies” on page 129. The Open Directory master updates the replica. You can configure the master to update its replicas at a specific interval or whenever the master directory changes. For more information, see “Scheduling Replication of an Open Directory Master or Primary Domain Controller (PDC)” on page 189. Creating Multiple Replicas of an Open Directory Master To make more than one server a replica of an Open Directory master, create the replicas one at a time. If you try to create two replicas simultaneously, one attempt will succeed and the other will fail. A subsequent attempt to establish the second replica should succeed. You can have up to 32 replicas of an Open Directory master. These direct members of the Open Directory master server are known as relays. Each relay can have up to 32 replicas of itself, giving you 1056 replicas in a two-tier hierarchy.

91 Setting Up Open Directory Relays for Cascading Replication Using Server Admin, you can set up Mac OS X Server to be a replica or relay of an Open Directory master so it can provide the same directory information and authentication information to other computers as the master. A relay has the following two conditions: Â It is a replica of an Open Directory master (a direct member). Â It has replicas (supports up to 32 replicas). The process of configuring a replica of a relay is the same as configuring a replica of an Open Directory master. For more information, see “Setting Up an Open Directory Replica” on page 88. Setting Up a Server as a BDC Using Server Admin, you can set up Mac OS X Server as a Windows BDC. The BDC provides automatic failover and backup of Windows domain login and other Windows client requests for authentication and directory services. The BDC server can provide other Windows services (SMB services), including file, print, browsing, and Windows Internet Name Service (WINS). The BDC can host home folders for users who have user accounts on the PDC/BDC. To set up a Windows BDC: 1 Make sure the server is an Open Directory replica. To determine whether a server is an Open Directory replica, open Server Admin and connect to the server, click the triangle to the left of the server (to expand the list), select Open Directory from the expanded services list, then click Overview. The first line of status information states the server’s Open Directory role. 2 Open Server Admin and connect to the server. 3 Click the triangle to the left of the server. The list of services appears. 4 From the expanded Servers list, select SMB. 5 Click Settings, then click General. 6 From the Role pop-up menu, choose Backup Domain Controller (BDC), then enter the following: Â Description: This description appears in the Network Places window on Windows computers and is optional.

 Computer Name: Enter the name you want Windows users to see when they connect to the server. This is the server’s NetBIOS name. The name should contain no more than 15 characters, no special characters, and no punctuation. If practical, make the server name match its unqualified DNS host name. For example, if your DNS server has an entry for your server as “server.example.com,” give your server the name “server.”  Domain: Enter the name of the Windows domain that the server will host. The domain name cannot exceed 15 characters and cannot be “workgroup.” 7 Click Save. 8 Enter the name and password of a user account that can administer the LDAP directory on the server, then click OK. When authenticating, you must use an LDAP directory administrator account. You can’t use a local administrator account, such as the primary server administrator account (user ID 501), to create a BDC. After setting up a BDC, you may want to change access restrictions, logging detail level, code page, domain browsing, or WINS registration. Then if Windows services aren’t running, you can start them. For more information, see Network Services Administration. Setting Up Open Directory Failover If an Open Directory master or its replicas become unavailable, its client computers with version 10.3–10.5 of Mac OS X or Mac OS X Server automatically find an available replica and connect to it. Replicas only permit clients to read directory information. Directory information about a replica can’t be modified with administration tools such as Workgroup Manager. Users whose password type is Open Directory can change their passwords on computers that are connected to Open Directory replicas. The replicas synchronize password changes with the master. If the master is unavailable for a while, the replicas synchronize password changes with the master when it becomes available again. If the Open Directory master fails permanently and you have a current archive of its data, you can restore the data to a new master. Alternatively, you can promote a replica to be the master. For more information, see “Restoring an Open Directory Master” on page 195 and “Promoting an Open Directory Replica” on page 190. Note: If a failed Open Directory master or replica had client computers with Mac OS X or Mac OS X Server v10.2 or earlier, the v10.2 computers and servers do not automatically fail over to another replica.

93 If you replace a failed master by promoting a replica to be the master, you can manually reconfigure each computer and server to connect to this new master or one of its replicas. You do this by using Directory Utility on each computer or server to create an LDAPv3 configuration that specifies how the computer accesses the new master or an available replica. For more information, see “Using Advanced LDAP Service Settings” on page 133. Setting Up a Connection to a Directory Server Using Server Admin, you can set up Mac OS X Server to get user records and other directory information from another server’s shared directory domain. The other server also provides authentication for its directory information. Mac OS X Server still gets directory information from its own local directory domain and provides authentication for this local directory information. Important: Changing Mac OS X Server to be connected to another directory system instead of being an Open Directory master will turn off its shared LDAP directory domain, with the following ramifications: Â User records and other information in the shared directory domain are deleted. Â If other servers were connected to the master directory domain, their services may be disrupted when the user accounts and other information in the deactivated directory domain become unavailable. Â Users who had accounts in the deactivated directory domain may no longer be able to access files and folders on the Open Directory master and on other servers that were connected to the master directory domain. To configure a server to get directory services from an existing system: 1 Open Server Admin and connect to the 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 Change. The Service Configuration Assistant opens. 6 Choose “Connected to a directory server,” then click Continue. 7 Confirm the Open Directory configuration settings, then click Continue. 8 If the server was an Open Directory master and you are sure that users and services no longer need access to the directory data stored in the shared directory domain that the server has been hosting, click Close.

9 Click the Open Directory Utility button to configure access to one or more directory systems. For more information about configuring access to a particular kind of directory service, see Chapter 7, “Managing Directory Clients.” If you connect Mac OS X Server v10.4 or later to a directory domain of Mac OS X Server v10.3 or earlier, users defined in the older directory domain cannot be authenticated with the NTLMv2 method. This method may be required to securely authenticate some Windows users for the Windows services of Mac OS X Server v10.4 or later. Open Directory Password Server in Mac OS X Server v10.4 or later supports NTLMv2 authentication, but Password Server in Mac OS X Server v10.3 or earlier does not support NTLMv2. Similarly, if you configure Mac OS X Server v10.4 or later to access a directory domain of Mac OS X Server version 10.2 or earlier, users defined in the older directory domain cannot be authenticated with the MS-CHAPv2 method. This method may be required to securely authenticate users for the VPN service of Mac OS X Server v10.4 or later. Open Directory in Mac OS X Server v10.4 supports MS-CHAPv2 authentication, but Password Server in Mac OS X Server version 10.2 does not support MS-CHAPv2. 10 If the server you’re configuring has access to a directory system that also hosts a Kerberos realm, you can join the server to the Kerberos realm. To join the Kerberos realm, you need the name and password of a Kerberos administrator or a user who has been delegated the authority to join the realm. For more information, see “Joining a Server to a Kerberos Realm” on page 102. Setting Up a Server as a Mac OS X Server PDC Domain Member Using Server Admin, you can set up Mac OS X Server to join a Windows domain hosted by a Mac OS X Server PDC. A server that joins a Windows domain can provide file, print, and other services to users with accounts on the PDC. The domain member server gets authentication services from the PDC or a backup domain controller. The server can host user profiles and home folders for users who have user accounts on the PDC. The domain member server does not provide authentication services to other domain member servers. To join Mac OS X Server to the Windows domain of a Mac OS X Server PDC: 1 Open Server Admin and connect to the server. 2 Click the triangle to the left of the server. The list of services appears. 3 From the expanded Servers list, select SMB. 4 Click Settings, then click General. 5 From the Role pop-up menu, choose Domain Member, then enter the following:

95 Â Description: This description appears in the My Network Places window of Windows XP and 2000 (the Network Neighborhood window of Windows 95, 98, or ME), and is optional. Â Computer Name: Enter the name you want Windows users to see when they connect to the server. This is the server’s NetBIOS name. The name should contain no more than 15 characters, no special characters, and no punctuation. If practical, make the server name match its unqualified DNS host name. For example, if your DNS server has an entry for your server as “server.example.com,” give your server the name “server.” Â Domain: Enter the name of the Windows domain that the server will join. The domain must be hosted by a Mac OS X Server PDC. The name cannot exceed 15 characters and cannot be “workgroup.” 6 Click Save. 7 Enter the name and password of an LDAP directory administrator account, then click OK. When authenticating, you must use an LDAP directory administrator account. You can’t use a local administrator account, such as the primary server administrator account (user ID 501), to join a Windows domain. After setting up a Windows domain member, you can change access restrictions, logging detail level, code page, domain browsing, or WINS registration. Then if Windows services aren’t running, you can start them. For more information, see Network Services Administration. Setting Up a Server as an Active Directory Domain Member Using Server Admin and Directory Utility, you can set up Mac OS X Server to join an Active Directory domain hosted by a Windows 2000 or 2003 server. A server that joins an Active Directory domain can provide file, print, and other services to users with accounts in the Active Directory domain. The domain member server gets authentication services from Active Directory. The domain member server does not provide authentication services to other domain member servers. To join Mac OS X Server to the Active Directory domain of a Windows server: 1 Open Server Admin and connect to the 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 Setting, then click General.

5 Click Change. The Service Configuration Assistant opens. 6 Choose “Connected to a directory server,” then click Continue. 7 Confirm the Open Directory configuration settings, then click Continue. 8 Click Close. 9 Click Open Directory Utility. 10 In the lower left corner of Directory Utility, click the lock and authenticate when prompted. 11 Click Show Advanced Settings. 12 Click Directory Servers (at the top). 13 Click the Add (+) button. 14 From the “Add a new directory of type” pop-up menu, choose Active Directory, then enter the following: Â Active Directory Domain: This is the DNS name or IP address of the Active Directory server. Â Computer ID: Optionally edit the ID you want Active Directory to use for your server. This is the server’s NetBIOS name. The name should contain no more than 15 characters, no special characters, and no punctuation. If practical, make the server name match its unqualified DNS host name. For example, if your DNS server has an entry for your server as “server.example.com,” give your server the name “server.” Â AD Administrator Username and Password: Enter the user name and password of the Active Directory administrator. 15 Click OK and close Directory Utility. 16 Click Join Kerberos to join the server to the Active Directory Kerberos realm. 17 Enter the following information: Â Administrator Name: Enter the Kerberos server administrator’s user name. Â Password: Enter the Kerberos server administrator password. Â Realm Name: Enter the realm name of the Kerberos server. Â DNS/Bonjour Name of KDC: Enter the DNS or Bonjour name of the Kerberos server. 18 Click OK. 19 From the Servers list, select SMB. 20 Click Settings, then click General. 21 Verify that the server is now a member of the Active Directory domain. You can change the server’s optional description, which appears in the Network Places window on Windows computers.

97 After setting up an Active Directory domain member, you may want to change access restrictions, logging detail level, code page, domain browsing, or WINS registration. Then if Windows services aren’t already running, you can start them. For more information, see Network Services Administration. Setting Up Single Sign-On Kerberos Authentication Setting up single sign-on Kerberos authentication involves these tasks: Â DNS must be made available on the network and must be configured to resolve the fully qualified DNS name of the Open Directory master server (or other Kerberos server) to its IP address. DNS must also be configured to resolve the IP address to the server’s fully qualified DNS name. Â An administrator must set up a directory system to host a Kerberos realm. For more information about setting up Mac OS X Server to host a Kerberos realm, see “Setting Up an Open Directory Kerberos Realm” on page 98. Â A Kerberos administrator of an Open Directory master can delegate the authority to join servers to the Open Directory master’s Kerberos realm. (The administrator does not need delegated authority. A Kerberos administrator has implicit authority to join any server to the Kerberos realm.) See “Delegating Authority to Join an Open Directory Kerberos Realm” on page 100. Â A Kerberos administrator or users with delegated authority must join servers to the Kerberos realm, which then provides single sign-on Kerberos authentication for services provided by the servers that have joined. See “Joining a Server to a Kerberos Realm” on page 102. Â All computers using Kerberos must be set to the correct date, time, and time zone, and they must be configured to use the same network time server. Kerberos depends on the clocks of all participating computers being in sync. When you are configuring an Open Directory master, make sure your DNS is correctly configured and running before you start Open Directory service for the first time. If DNS is not configured properly or is not running when you start Open Directory, Kerberos will not function properly. When Open Directory is started for the first time, Kerberos uses DNS service to generate configuration settings. If your DNS server is not available when Kerberos is initially started, its configurations will be invalid and it will not work properly. After Kerberos is running and has generated its configuration file, it will no longer completely depend on DNS and changes to DNS will not affect Kerberos. The individual services of Mac OS X Server do not require configuration for single sign- on or Kerberos.

The following services are ready for single sign-on Kerberos authentication on every server with Mac OS X Server version 10.5 or later that has joined or is an Open Directory master or replica:  Login window  Mail service  AFP  FTP  SMB (as a member of an Active Directory Kerberos realm)  iChat  Print service  NFS  Xgrid service  VPN  Apache web service  LDAPv3 directory service (on an Open Directory master or replica). Setting Up an Open Directory Kerberos Realm You can provide single sign-on Kerberos authentication on your network by setting up an Open Directory master. You can set up an Open Directory master during initial configuration that follows installation of Mac OS X Server, but if you set up Mac OS X Server to have a different Open Directory role, you can change its role to that of Open Directory master by using Server Admin. For more information, see “Setting Up an Open Directory Master” on page 83 and “Starting Kerberos After Setting Up an Open Directory Master” on page 99. A server that is an Open Directory master requires no other configuration to support single sign-on Kerberos authentication for Kerberized services that the server provides. The server can also support single sign-on Kerberos authentication for Kerberized services of other servers on the network. The other servers must be set up to join the Open Directory Kerberos realm. For more information, see “Delegating Authority to Join an Open Directory Kerberos Realm” on page 100, and “Joining a Server to a Kerberos Realm” on page 102. Important: An Open Directory master requires DNS to be properly configured so it can provide Kerberos and single sign-on authentication. In addition:

99 Â DNS service must be configured to resolve the fully qualified DNS names of all servers (including the Open Directory master) to their IP addresses and to provide the corresponding reverse lookups. For more information about setting up DNS service, see Network Services Administration. Â The Open Directory master server’s Network preferences must be configured to use the DNS server that resolves the server’s name. (If the Open Directory master server provides its own DNS service, its Network preferences must be configured to use itself as a DNS server.) Starting Kerberos After Setting Up an Open Directory Master If Kerberos doesn’t start when you set up an Open Directory master, you can use Server Admin to start it manually, but first you must fix the problem that prevented Kerberos from starting. Usually the problem is that the DNS service isn’t correctly configured or isn’t running. Note: After you manually start Kerberos, users whose accounts have Open Directory passwords and were created in the Open Directory master’s LDAP directory while Kerberos was stopped may need to reset their passwords the next time they log in. A user account is therefore affected only if all recoverable authentication methods for Open Directory passwords were disabled while Kerberos was stopped. To start Kerberos manually on an Open Directory master: 1 Open Server Admin and connect to the 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 Refresh (or choose View > Refresh) and verify the status of Kerberos as reported in the Overview pane. If Kerberos is running, there’s nothing more to do. 5 Use Network Utility (in /Applications/Utilities/) to do a DNS lookup of the Open Directory master’s DNS name and a reverse lookup of the IP address. If the server’s DNS name or IP address doesn’t resolve correctly: Â In the Network pane of System Preferences, look at the TCP/IP settings for the server’s primary network interface (usually built-in Ethernet). Make sure the first DNS server listed is the one that resolves the Open Directory server’s name. Â Check the configuration of DNS service and make sure it’s running. 6 In Server Admin, select Open Directory for the master server, click Settings, then click General. 7 Click Kerberize, then enter the following information:

 Administrator Name and Password: You must authenticate as an administrator of the Open Directory master’s LDAP directory.  Realm Name: This field is preset to be the same as the server’s DNS name converted to capital letters. This is the convention for naming a Kerberos realm. If necessary, you can enter a different name. Delegating Authority to Join an Open Directory Kerberos Realm Using Server Admin, you can delegate the authority to join a server to an Open Directory master server for single sign-on Kerberos authentication. You can delegate authority to one or more user accounts. The user accounts you delegate authority to must have a password type of Open Directory and must reside in the LDAP directory of the Open Directory master server. The dependent server you are delegating authority for must have Mac OS X Server v10.3 or later. Note: If an account with delegated Kerberos authority is deleted and recreated on the Open Directory master server, the new account will not have authority to join the dependent server to the Open Directory master’s Kerberos realm. A Kerberos administrator (that is, an Open Directory LDAP administrator) doesn’t need delegated authority to join dependent servers to the Open Directory Kerberos realm. A Kerberos administrator has implicit authority to join any server to the Kerberos realm. To delegate authority to join an Open Directory Kerberos realm: 1 In Workgroup Manager, create a computer group in the LDAP directory domain of the Open Directory master server, or select an existing computer group in this directory:  To select an existing computer group, click Accounts or choose View > Accounts, click the Computer Group button (above the accounts list), and select the computer group you want to use.  If the LDAP server doesn’t have a computer group that you want to add the dependent server to, you can create one: Click Accounts, then click the Computers button (above the accounts list). Click the small globe icon above the list of accounts and use the pop-up menu to open the Open Directory master’s LDAP directory. Click the lock and authenticate as an administrator of the LDAP directory. Click Computers Group button (above the accounts list), then click New Computer Group or choose Server > New Computer Group. Enter a list name (for example, Kerberized Servers). 2 Click Members, then click the Add (+) button and enter the following: