Windows Security and Directory Services for UNIX

Transcription

1 Solution Guide for Windows Security and Directory Services for UNIX Building Security and Directory Solutions for UNIX Using the Windows Server 2003 Active Directory Kerberos and LDAP Services Version 0.9

2 The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This guide is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. Unless otherwise noted, the example companies, organizations, products, domain names, addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, address, logo, person, place or event is intended or should be inferred Microsoft Corporation. All rights reserved. Microsoft, Active Directory, Outlook, Visual Basic, Visual C++, Win32, Windows, Windows NT, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

3 Table of Contents Preface... 7 Overview... 7 Intended Audience... 8 How to Use This Solution... 9 Contributors Part 0: Introduction Chapter 1: Overview of Network Security and Directory Services Introduction Overview of Authentication and Authorization Overview of Directory Services and Identity Management Standards-based Security and Directory Services Microsoft Active Directory Vintela Authentication Services Summary Chapter 2: Authentication and Authorization in UNIX and Windows Environments Introduction UNIX and Linux Authentication and Authorization Services Windows Authentication and Authorization Models Microsoft Windows Server 2003 Kerberos Summary Chapter 3: Active Directory and LDAP as Identity Stores in UNIX Introduction UNIX and Linux Identity Management and Directory Services Microsoft Windows Directory Services Windows Server 2003 LDAP Implementation Common Uses of Directory Services Summary Part 1: Plan Chapter 4: Envisioning Heterogeneous Security and Directory Solutions Introduction and Goals Set Up a Team Define the Project Structure Define the Business Goals Assess the Current Security and Directory Systems Create the Vision and Define the Scope for the Project Define High-Level Requirements and User Profiles Develop the Solution Concept Assess Project Risks Close the Envisioning Phase Summary

4 Chapter 5: Planning Heterogeneous Security and Directory Solutions Introduction and Goals Develop the Solution Design and Architecture Validate the Technology Create the Functional Specification Develop the Project Plans Set Up the Development and Test Environments Close the Planning Phase Key Milestone: Project Plans Approved Summary Part 2: Build Chapter 6: Developing the Infrastructure for Heterogeneous Security Introduction Building the Solution Configuring the Domain Name System Configuring the Windows Server 2003 Active Directory Domain Controllers Configuring Time Services Summary Chapter 7: Developing Heterogeneous Kerberos Security Solutions Introduction Prerequisites Configuring the Windows KDC Configuring the UNIX and Linux KDC Establishing Cross-Realm Trusts Migrating Users Configuring Clients, Applications and Services Summary Chapter 8: Developing the LDAP Security and Directory Infrastructure Introduction Configuring Active Directory, UNIX, and Linux to Support LDAP Security Building the LDAP Authentication and Authorization Infrastructure Building the Active Directory Identity Store Summary Chapter 9: Testing Windows-based Security and Directory Services Introduction and Goals Testing the Solution Summary Part 3: Deploy Chapter 10: Deploying a Windows-based Security and Directory Solution Introduction and Goals Complete Deployment Preparations Create Operations Procedures Deploy the Solution Stabilize the Deployment Transfer Ownership to Operations Closing the Deploying Phase Deployment Complete Milestone

5 Part 4: Commercial Solutions Chapter 11: Vintela Authentication Services Introduction How VAS Works The Benefits of Using VAS Overview of the VAS Installation Process Summary Appendices Appendix A: Pertinent RFCs Appendix B: Kerberos Error Messages Appendix C: LDAP Error Messages Appendix D: Acronym List Appendix E: Bibliography

6

7 Preface Overview Welcome to the Windows Security and Directory Services for UNIX solution guide. As the world becomes more and more connected, the vision of information being available anywhere, at any time, and on any device comes closer to reality. But organizations and their partners will only trust such an interconnected environment to store their sensitive data if they can verify the identity of the user who is requesting the information. And no organization would want to allow even a recognized user unlimited access to all of its information assets. The people entrusted with ensuring the security of data have developed increasingly complex methods of supporting the necessary level of trust within an interconnected environment. These methods take the form of security functions within operating systems and applications, as well as dedicated security software. This development has been largely evolutionary in nature, with specific features and functions developed for each technology. Bodies, such as the Internet Engineering Task Force (IETF), have developed protocols and standards that are not technology-specific to facilitate the interconnectivity desired. However, the deployment of these various technologies and enabling protocols in a secure and efficient operational network is a complex and time-consuming task. This guide is intended to help you perform this task when the interconnected environment consists of Windows and UNIX or Linux operating system platforms. The solution presented in this guide focuses on the use of Microsoft Windows Server 2003 Active Directory to provide centralized security and directory functionality for the whole environment, regardless of the platform accessed by the user. The centralized security and directory functionality presented in this guide is based on the Windows Server 2003 Active Directory Kerberos and Lightweight Directory Access Protocol (LDAP) services. The UNIX and Linux operating systems are configured to use these services with either open source software, such as MIT Kerberos and PADL's LDAP modules, or commercial software, such as the Vintela Authentication Services product. 7

8 Intended Audience This guide is primarily intended for consultants, security specialists, systems architects, and information technology (IT) professionals who are responsible for the planning stages of application or infrastructure development and deployment of Windows Server 2003 and Microsoft Windows XP Professional workstations in an enterprise environment. It is also intended for those with a background in either Windows or UNIX or Linux development who are charged with the administration, integration, or migration of a heterogeneous environment. These roles include the following common job descriptions: Architects and planners who are responsible for driving the architecture efforts for the workstations in their organizations. IT security specialists who are focused on providing security across platforms within an organization. Business analysts and business decision makers who have critical business objectives and requirements that depend on desktop or laptop support. Consultants, from both Microsoft Worldwide Services and partners, who need knowledge-transfer tools for enterprise customers and partners. Knowledge Prerequisites This guide assumes that its users will have a basic understanding of both the Windows and UNIX or Linux operating systems, as well as a sound knowledge of information security terminology and techniques. Users should read the UNIX Migration Project Guide (UMPG), which is discussed under the following heading. 8

9 How to Use This Solution The organization of this guide is based on the industry-proven need to manage IT projects according to a disciplined process that improves the odds of project success. For this reason, the technical and solution-specific information in this guide is provided in the linear context of a project-based sequence. Microsoft Solutions Framework Specifically, the guide follows the structure of the Microsoft Solutions Framework (MSF). This is a milestone-based framework for IT projects that defines distinct project phases: Envisioning, Planning, Developing (or Migrating), Stabilizing, and Deploying. The guide presents information in the order that it is needed in a project (information needed for the initial decision-making is in the Envisioning chapter, detailed procedures and scripts are in the Developing chapters, and so on). UNIX Migration Project Guide The Windows Security and Directory Services for UNIX Solution Guide is designed to be used in conjunction with the UNIX Migration Project Guide, a component of most UNIX Migration Solution Accelerators. The UMPG begins with an overview of MSF, and then it describes the processes that belong to each phase and the team roles responsible for them; it is essentially "MSF for UNIX migration projects." The UMPG is organized by MSF phase, in parallel with this guide, so that readers can consult it if they have questions about how to apply the technology-specific information provided here. For example, while this guide may give specific guidance about setting up a development environment for a Windows Security and Directory Services for UNIX migration project, the UMPG offers more general guidance about the considerations to think about, the steps involved, and the team roles that are responsible for the work that needs to be done. The reason for separating general "people and process" guidance in the UMPG from the technology and more project-specific guidance provided here is to keep this guide as lean as possible. Microsoft recognizes that some readers need to focus narrowly on project tasks, while persons with project management and team lead responsibilities need to digest the UMPG guidance and apply it to the project. For interested readers, indepth information about MSF is available on the Microsoft Solutions Framework website at Note Although the two guides are designed to be used together, the UMPG is not necessary if your organization has an alternative project methodology in place. In that case, the MSF phases and team structure can be mapped to the elements of the organization's methodology. Readers who will use this guide to implement a project should read at least the overview of MSF in the UMPG to familiarize themselves with the MSF Process Model and the MSF Team Model. 9

10 Solution Stages The following table associates the major solution stages with the MSF Process Model phases for this guide. Table 0.1: Solution Stages and the MSF Process Model Solution Stage MSF Process Model Focus Phase Plan Envisioning The team defines the vision and the scope of the project based on the business need, organizes the project, and delivers an approved vision/scope document. Plan Planning The team develops the conceptual, logical, and physical designs and creates the functional specification. It also develops project plans addressing development, testing, communication, and other tasks, and creates and delivers the master project schedule. Build Developing The team builds and tests the solution components. Build Stabilizing The team completes testing the solution and performs pilots and reviews. Deploy Deploying The team deploys the solution and ensures that it is stable and usable. Responsibility then shifts to operations and support teams. Organization by Chapter The chapters in this guide largely reflect the structure of both MSF and the UMPG, modified by the need to address certain topics in parallel instead of sequentially and according to the specific requirements of the subject matter. Chapters 1 through 3 provide technical material that contextualizes the security and directory solutions presented in this guide. The final chapter stands outside this framework because it addresses a specific commercial solution relevant to all the preceding chapters. Chapter 1 "Overview of Network Security and Directory Services" provides a general introduction to the concepts of authentication and authorization, identity management and directory stores, and some of the key technologies in this area. Chapter 2 "Authentication and Authorization in UNIX and Windows Environments" provides details of the technologies that have been developed to provide security for UNIX, Linux, and Windows environments. In particular, it addresses the Kerberos 5 protocol. Chapter 3 "Active Directory and LDAP as Identity Stores in UNIX and Windows Environments" delineates the different techniques used to store the information used by UNIX, Linux, and Windows operating systems and the applications that run on them. 10

11 Chapter 4 "Envisioning Heterogeneous Security and Directory Solutions" provides guidance on how to identify all the work required to complete the solutions using Windows Server 2003 Active Directory. Chapter 5 "Planning Heterogeneous Security and Directory Solutions" addresses the creation of a solution architecture and design, a project plan, and a project solution; this phase of the project is when the initial vision is translated into practical plans for how to achieve it. Chapter 6 "Developing the Infrastructure for Heterogeneous Security and Directory Solutions" provides guidance on the implementation of an infrastructure that will support the security and directory solution. Chapter 7 "Developing Heterogeneous Kerberos Security Solutions" deals specifically with the Kerberos infrastructure and how it should be configured. Chapter 8 "Developing the LDAP Security and Directory Infrastructure" parallels the preceding chapter, but focuses on implementing an infrastructure for UNIX and Linux clients using the Active Directory LDAP service. Chapter 9 "Testing Windows-based Security and Directory Services" provides guidance on how to test a Windows Server 2003-based security and directory services solution. It includes a comprehensive overview of the Windows, UNIX, and Linux tools used to test security and directory services and guidance on how to use these tools. Chapter 10 "Deploying a Windows-based Security and Directory Solution" provides guidance for deploying a security and directory infrastructure for UNIX and Linux clients using Active Directory LDAP and Kerberos services. During the Deployment Phase, you deploy the core technology and site components, stabilize the deployment, pass the project to operations and support, and obtain final approval of the project. Chapter 11 "Vintela Authentication Services" provides details of Vintela Authentication Services (VAS), a set of components designed to integrate the UNIX and Linux-based elements of a heterogeneous environment with elements based on Windows Server Document Conventions This guide uses the style conventions shown in Table 0.2. Table 0.2: Document Conventions Text Element Bold text Italic text Monospace font Monospace bold font Meaning Bold text is used for commands; literal arguments to commands (including paths when they form part of the command); switches; and programming elements, such as methods, functions, UNIX and Linux system calls, LDAP object classes, LDAP attribute names, data types, and data structures. User interface elements are also identified with bold font. Italic text is used for variables to be replaced by the user. It is also used to emphasize important information, such as a key term used for the first time. Used for excerpts from configuration files, code examples, and terminal sessions. Used to represent commands or other text that the user types exactly as shown. 11

12 Text Element Monospace italic font Note Important Warning Meaning Used to represent variables the reader supplies in command line examples and terminal sessions. Used to indicate neutral or positive information that emphasizes or supplements important points of the main text. Used to provide information that is essential to the completion of a task. Used to advise users that failure to take or avoid a specific action could result in damage to software, hardware, or data. 12

13 Solution Overview Diagram The solutions in this guide are summarized in Figure 0.1. Figure 0.1 Overview diagram of the solutions presented by this guide 13

14 Software Requirements for This Solution Note This solution guide does not include the Microsoft products listed in the next section. You will need to license these products separately. The solution builds upon and extends these products. The following are the technical requirements for the products and distributions discussed in this guide: Windows Server 2003 Depending on business requirements, UNIX and Linux solutions that include one or more of the following: Massachusetts Institute of Technology's (MIT's) Kerberos 5 release or higher LDAPv3-compliant LDAP libraries and client tools Microsoft Services for UNIX 3.5 The Vintela Authentication Services Contributors The Microsoft Solutions for UNIX Migration (MSUM) group would like to acknowledge and thank the team that produced the Windows Security and Directory Services for UNIX guide. The following people were either directly responsible, or made a substantial contribution to the writing, development, and testing of this solution. Authors David Holder (Content Master) Simon Biles (Content Master) Tim O'Brien (Content Master) Alistair Matthews (Content Master) Editors Thomas Olsen (Volt) Christine Waresak (Volt) Susan Joly (Volt) Testers Peter Himmelfarb (Excell Data Corporation) Jeffery Piccolo (Volt) Program Managers Alison Woolford (Content Master) Mark Short (Microsoft) 14

15 Reviewers David Lawler Christiansen (Microsoft) Sergei Rousakov (Cisco Systems, Inc.) Other Contributors Jason D. Zions (Microsoft) Paul Cayley (Microsoft) Hank Voight (Microsoft) Robert Pierce (Microsoft) Matthew Peterson (Vintela) David Wilson (Vintela) Doug Miller (Microsoft) 15

16

17 Part 0: Introduction 17

18

19 1 Overview of Network Security and Directory Services Introduction In this chapter you will learn about the basic principles of network security and directory services. You will also learn about the security and directory services standards described in this guide: Kerberos and the Lightweight Directory Access Protocol (LDAP). This chapter is intended as a brief introduction to these subjects. More detailed information is presented in later chapters, and a fuller discussion of these subjects can be found by reading the references provided. This chapter is divided into three sections: An introduction to the security principles of authentication and authorization An introduction to the concepts of directory services and identity management Security and directory services standards 19

20 Overview of Authentication and Authorization When discussing computer security, there are key concepts that are universal regardless of operating system and implementation. Three principal requirements for the security of data are: Confidentiality Integrity Availability An example from the realm of personal banking provides a simple illustration of these concepts. Confidentiality is the restriction of the distribution of an item of information to a selected group of people typically, your bank balance is available to only you. Integrity is the restriction of the ability to alter that information someone else is not able to move money from your bank account. And availability is the capability to provide the information when required you are able to pay your bills on time. The same basic requirements for bank accounts are necessary for computer security. The steps to ensure that all these requirements are met are detailed throughout the remainder of this guide. The Principle of Authentication Authentication is the process of verifying the identity of an entity, be it a user, a computer, or a program. This process ensures that the entity is who or what it claims to be so that the three principles of confidentiality, integrity, and availability can be correctly applied. The ways in which authentication can be achieved can be classified into three groups. The first group is dependent upon knowledge held by the entity. The simplest example in this group is the password. This is a piece of knowledge which is known only to the entity attempting authentication, and it is verifiable as correct by the authenticator. Other more complex systems include challenge-response systems that ask a question to which only the entity knows the answer. The limitation of this method of authentication is that someone who obtains the knowledge held is able to pose as the entity and pass through the authentication process. People are notoriously bad at remembering passwords, so their choice of password is often something simple to guess, such as a name or date of birth, and the password is often written down to ensure that it is remembered. The second group is dependent upon an object. This object can be some form of smart card or key tag that is unique and that can be used by the entity for identification. The limitation of this method of identification is that the theft of the object immediately gives the identity of the entity to the person with the object. The third group is dependent upon a unique identifier that is a natural feature of an entity. In the majority of cases, the entity in this group is a person and the natural, unique feature is some aspect of that person's body. These methods of authentication include biometric access controls such as retinal scans and fingerprinting. They can also include how the person carries out tasks, such as writing a signature, which is difficult for another person to replicate. It is possible to construct an authentication process that uses a combination of any or all of these methods. Depending upon how many of these methods are used, this can also be known as one-factor, two-factor, three-factor, or multi-factor authentication. The more tests that are included, the more secure you can be about the verification of the identity of the entity. Without accurate authentication, authorization is impossible to control. 20

21 The Principle of Authorization After an entity has been authenticated and proved its identity to the satisfaction of the authenticator, it is able to carry out tasks. The extent to which the entity is permitted access to resources is known as authorization. An entity with limited access will be allowed to perform a selection of specific tasks. A record of these tasks is held by the authorizer. This selection may include permission to read, write, or modify a file; permission to print; or permission to access another computer on the network. Without proper authentication, authorization is useless because any user would easily be able to imitate another user with more extensive permissions. However, in conjunction with proper authentication, authorization further limits a user's ability to access restricted resources, and thus improves the security of the system and its data. Authentication and Authorization in a Network Environment Using a network adds significant complexity to the process of authentication and authorization. In addition to the generic weaknesses inherent in the various methods of authentication, there are also new problems resulting from the introduction of the network. These problems include: The difficulty of carrying the authentication and authorization data across the network without detection or interference Proving the identity of the remote client entity Cryptographic techniques are widely used within network authentication systems to encrypt the data in such a way that it is computationally unfeasible to make use of it. These techniques alone, however, are not adequate to provide an effective network authentication system. Network authentication systems also need to address issues relating to ease-of-use, single sign on, and key creation and distribution. Solutions to these problems are typically complex, as is demonstrated later in this chapter with the introduction of Kerberos. 21

22 Overview of Directory Services and Identity Management You and your organization require information to carry out your activities. For example, when you want to contact someone by telephone, you must first obtain that person's telephone number by some mechanism, usually by looking in a telephone directory. Similarly, when your organization wants to provide an employee with access to its computer systems, the system administrator must be able to store the employee's credentials and authorization details somewhere, typically in a user database on a centralized network server. A telephone directory and network server user database are just two places where information about individuals can be stored. Many other places exist that you or your organization can store information about individuals, organizations, or things. Examples include address books, Personal Digital Assistants (PDAs), product catalogs, and human resource databases. Ideally, you would store all of this information in a single place. Storing the data in one place allows you to: Avoid duplicate data, which eliminates the need to keep data in different locations synchronized. Simplify management of the data, through replacing different data management systems and techniques with one single system. Improve data security through a single point of access to the data and implementation of consistent access control methods. Reduce costs by eliminating multiple storage formats and systems. Directory services and identity management standards aim to make it possible to have a unified directory service that allows you to profit from the benefits just listed. The following subsections describe the technologies and standards that make implementing a unified directory service possible. The Need for Directory Services The wide range of information used by your organization can be appreciated by quantifying the number of different telephone directories, address books, and product catalogs it holds. In addition to these, your organization's computer systems also store a wide range of information, including account details, addresses, computer configuration settings, network information, and references to services provided by your computer systems. Organizations have gained significant benefits from storing these different types of information in computer-based systems. The information is then readily available for use in applications. For example, address books that are stored in a computer database make it easy for computer users to search for a recipient's address and send an to that recipient. Unfortunately, even with such a widely used application as , many different methods of storing addresses have been developed that are incompatible with each other. The solution might seem to be to create a standard directory service for storing addresses. While this is useful, and standards do exist for this particular application, a standard that only stores addresses and does not allow other personal information to be consolidated in the same place results in the duplication of data and, consequently, additional administrative overhead. 22

23 To achieve the benefits of a single, unified data store, a directory service must be capable of being used for an unlimited range of data. The directory service should also be standard across all operating systems and applications. Directory services have evolved to allow the storage of a wide range of data types in an accessible way. Modern directory services provide you with at least the following: A method of organizing an object (person, organization, or thing) into a hierarchical structure. A hierarchical structure allows objects with something in common to be grouped together, which eases management of the objects and increases your ability to locate objects in the directory. A common method of describing what can be stored in the directory. This is often referred to as the directory schema, which is a model of the information that can be stored in the directory. The schema defines what characteristics each object has, including the information it can store, how it can be found in the directory, and rules about how it behaves. A security model allowing fine-grained access controls to be applied to objects. A resilient distributed service. The directory must be resilient to faults and to heavy load. Distributing the service over more than one server helps facilitate this. A distributed service also allows portions of the directory to be administered independently. Each of these concepts is explained in more detail in later parts of this guide. Identity Management Directory services provide a foundation for identity management. Identity management covers information that relates to individuals. Identity management includes the management of computer user accounts, the contact details of those user accounts, door entry system user accounts, application user accounts, system user addresses and accounts, and much more. In a typical organization, this information is stored in various ways on a range of different and often incompatible systems. It is difficult to keep the information relating to an individual synchronized across systems; for example, when an individual transfers to a different department, a number of directories may need to be modified. The administrative overhead for handling such modifications in a large organization can be significant. In some circumstances, it can also be difficult to ensure consistency across systems, particularly in relation to security and access control for a specific individual. Identity management solves these problems. Individual information is stored in one place and administered in a consistent manner. The LDAP standard discussed later in this chapter defines a directory service that can be used as the basis for identity management solutions, such as the ones covered in this guide. 23

24 Standards-based Security and Directory Services The following sections cover the development and use of the Kerberos and Lightweight Directory Access Protocols, which are used for security and directory services, respectively. These two standards used together form the basis of the heterogeneous security and directory solutions presented in this guide. The Kerberos Protocol This section covers the emergence of the Kerberos protocol as a standard and its use as a network authentication service. Kerberos is designed to provide strong authentication within a client/server network environment. The basis of the protocol is a shared secret key cryptography system that allows clients to verify their identity to a server. The History of Kerberos In 1983, Massachusetts Institute of Technology (MIT) embarked on a large-scale network project. Project Athena differed from the standard implementation of networked systems of the time by taking advantage of the client/server model. Earlier network implementations used a time-sharing model, where all terminals attached directly to a centralized computer through serial lines. Figure 1.1 illustrates this model. Figure 1.1 Time-sharing model 24

25 This model has a simple user administration structure: there is one computer, and all accounts are controlled on it. There is little to be concerned about in the way of communications security because the terminals are linked only to the time-sharing computer, and so eavesdropping would require a physical tap on the serial line. As long as the system administrators can control access to the serial lines and ensure that they are not compromised, the security of communication is assured. In the more recent client/server model, the user has access to a computer on his or her desk. This computer is connected to all of the other computers within the network and provides access to shared resources. Figure 1.2 illustrates this model. Figure 1.2 Client/server model This change of model presented a significant problem: without the security provided by the direct serial links, the client computers could no longer be trusted. Existing security procedures and applications were inadequate for the new model because they were not designed for the untrusted environment. To overcome this problem, Kerberos was developed. The protocol is based around a secure authentication system described in the following article: "Using Encryption for Authentication in Large Networks of Computers" (Needham and Schroder, 1978). Kerberos versions 1, 2, and 3 were used for internal development and testing only. The first release of Kerberos that was not a part of the Athena Project was Kerberos Version 4. Kerberos 4 is described in the following article: "Kerberos Authentication and Authorization System" (Miller, Neuman, Schiller, and Salzer, 1988). This document is available for download from the MIT Kerberos website at Kerberos 5 is the most recent version of Kerberos. Both versions 4 and 5 are discussed in this chapter. Overview of Kerberos 4 Kerberos makes use of cryptographic techniques to secure its network messages. Kerberos network messages are encrypted and decrypted using encryption algorithms that translate the Kerberos data into a form that is very difficult to decode into its original form. A secret encryption key is used to encrypt the data and to decrypt the data. Kerberos also uses mathematical techniques called hashes to ensure the integrity of any data that is not encrypted. 25

26 Kerberos 4 contains a number of specific terms and ideas that are important to know: Principals. All entities within Kerberos, including users, computers, and services, are known as principals. Principal names are unique, and to ensure uniqueness, there is a hierarchical naming structure for principals. Realms. The principal is a member of a realm. By convention, a realm name is the DNS name converted to uppercase, so, for example, the example.com domain becomes the EXAMPLE.COM realm. Although uppercase realms are not obligatory, using a different case simplifies differentiating between domain names and realms. Ticket. A ticket is the fundamental unit of Kerberos authentication. It is a carefully constructed message passed between computers that contains the authentication information. Tickets and their structure are described in more depth later in this section. Key Distribution Center. The Key Distribution Center (KDC) is made up of three components: A database of principals, containing users, computers, and services An authentication server, which issues Ticket Granting Tickets (TGTs) A Ticket Granting Service (TGS), which issues service tickets granting clients access to specific services The function of the authentication server and the TGS is covered in more detail later in this section. Each realm requires at least one KDC to operate. Kerberos authentication relies on the use of tickets, which are passed between the client, the KDC, and the required server to confirm authentication and authorization. 26

27 Figure 1.3 shows the exchanges that take place during authentication using the Kerberos protocol: Figure 1.3 Kerberos authentication server exchange 27

28 Initially, a client contacts the authentication server component of the KDC. The client sends the authentication server a request that contains the following: The principal name A time stamp The lifetime of the ticket requested by the client The name of the Ticket Granting Service (TGS) The authentication server then generates a session key and makes two copies of it: one for the client, and the other for the TGS. The authentication server then sends back to the client a Ticket Granting Ticket (TGT) that contains the following: A copy of the session key The identity of the client A time stamp Details of the Internet Protocol (IP) address of the client Details of the ticket lifetime The TGT is returned to the client, which has been encrypted using the key of the TGS. At the same time as returning the encrypted TGT to the client, the authentication server also returns: A copy of the session key The principal name of the TGS The lifetime of the ticket This whole response to the client is encrypted using the client key before being returned to the client. 28

29 Figure 1.4 Formats of the exchanged tickets The client receives the information in this encrypted reply, and because it was encrypted with the client's key, it is capable of decrypting it. This gives the client its session key and a TGT that is still encrypted by the key of the TGS. 29

30 The client now forwards the TGT to the ticket granting server, along with a request for the service to be accessed and a time stamp encrypted with the session key obtained from the authentication server. This time stamp serves to prevent replay attacks, which occur when a request for a service from the client is captured by a hacker and re-sent at a later date. Note Attacks against the Kerberos protocol are explained in Chapter 2, "Authentication and Authorization in UNIX and Windows Environments." The TGS processes this request and responds with the following: A new set of session keys The principal name of the service requested The lifetime of the ticket A service ticket encrypted with the service key The service ticket is similar to the TGT; it contains the following: A new session key The principal name of the client The ticket lifetime A time stamp The client's IP address All of this is then encrypted with the key of the client and returned. The final stage of the authentication procedure differs depending on the service and server being requested because each application defines its own methods for the exchange of the service ticket. An example of a service is the Network File System (NFS). NFS allows for a host to access ("mount") directories that are held on a remote server. Assuming that the NFS server has had Kerberos authentication enabled, the process of accessing the Kerberosprotected NFS service is as follows: 1. On the client computer, the user obtains a Kerberos ticket for the root user (mounting a file system normally requires the permissions of root), using the kinit command. 2. The user mounts the remote file system, and the Kerberos daemon on the client computer automatically obtains a service ticket on behalf of the client from the Ticket Granting Service on the Key Distribution Center. 3. The client computer now has two valid tickets, one for root and the other for the NFS service. The client computer uses the obtained service ticket to authenticate to the NFS server, and the client computer mounts the directory. 4. When the user is finished with the directory, it is un-mounted and the tickets are destroyed to prevent their reuse by using the kdestroy command. 30

31 Kerberos 5 Kerberos 5 is an extension of Kerberos 4 that contains all of the functionality of the earlier version; however, Kerberos 5 also includes many enhancements: Support for credential forwarding. When the client connects to the application server, it forwards a copy of its TGT so that the user can transparently authenticate to other Kerberos services from the application server. Under Kerberos 4, the user would have to request a new TGT to authenticate from the application server. Multiple encryption types. Kerberos 4 was restricted to the use of the Data Encryption Standard (DES) encryption algorithm. Kerberos 5 allows the implementation of different encryption types to enhance security. Renewable tickets. Ticket lifetimes under Kerberos 4 were finite, and at expiration a new ticket had to be obtained. Under Kerberos 5, a ticket may be renewed by resubmission to the KDC before its lifetime expires. This process may be repeated until the renewal lifetime has expired. Preauthentication. In Kerberos 4, the KDC responds to any request with a ticket encrypted with the key of the requesting principal. This makes it susceptible to an attack that attempts to determine the principal's secret key. A malicious user can forge a request, and then attempt to crack the returned encrypted key. Kerberos 5 improves this situation by introducing preauthentication; this involves the principal proving the user's identity before the KDC will issue a ticket. This is done by sending a time stamp encrypted with the user's key. Distributions of Kerberos 5 include a utility called krb524 that is used to translate tickets between Kerberos 5 and 4 so that Kerberos 5 tickets can be used to authenticate to Kerberos 4 services. The krb524 utility runs as a daemon (UNIX system service) that accepts a request from a client, decrypts the Kerberos 5 service key, and creates a new Kerberos 4 service key using the session key from the original ticket. Warning Microsoft does not recommend the use of the krb524 utility because of security problems inherent in Kerberos 4. Kerberos 5 is the default method of network authentication for services and applications in Windows Server Pertinent RFCs The following Requests for Comments (RFCs) describe the Kerberos protocol and the methods of using Kerberos through the Generic Security Service Application Programming Interface (GSS-API): RFC 1510, "The Kerberos Network Authentication Service (Version 5)" RFC 1964, "The Kerberos Version 5 GSS-API Mechanism" Kerberos Distributions A large number of distributions of the Kerberos protocol are available, both commercial and open source. Most major UNIX distributions contain an implementation of Kerberos as part of a standard installation. There are also two open source Kerberos 5 distributions: MIT and Heimdal. MIT's Kerberos 5 open source distribution and Windows Server 2003 implementation of the Kerberos 5 protocol are discussed in this guide. Heimdal is not covered in this guide, but information about it is available at 31

32 MIT is where Kerberos was originally developed, and MIT still maintains and develops an open source version. At the time of writing, MIT Kerberos Version is the most current version. MIT Kerberos is simple to compile across all platforms and works well with all other implementations. While precompiled versions are available for download from other sources, it is recommended that you download and verify the integrity of the source to ensure security. MIT Kerberos is freely available for download from Note Some countries have restrictions on the use of cryptography. It is recommended that you confirm that Kerberos is acceptable under your country's cryptographic restrictions before implementing a Kerberos solution. The Lightweight Directory Access Protocol This section discusses the emergence of LDAP as a standard and its use for authentication and as a directory service. The development of the OSI directory service X.500 and the creation of LDAP as a simple method of accessing X.500 directories are described. The section concludes with a brief overview of the LDAP protocol and LDAP directory services. The History of LDAP LDAP is built on a number of standards developed jointly by the International Telegraph and Telephone Consultative Committee (CCITT), which is now known as the International Telecommunications Union (ITU) and the International Organization for Standardization (ISO). The aim of the ITU and ISO was to define a general-purpose directory standard that would encompass as broad a range of directory services as possible. The standard developed would form the directory service for the Open Systems Interconnect (OSI) network model developed by the CCITT and ITU. When developing the directory standard, the ITU and ISO members of the standards committees had different priorities. The majority of the ITU members were national telecommunications operators who looked for a standard that would provide a directory service for telephone numbers and addresses. In contrast, the ISO members were mostly interested in providing a naming service for OSI applications. The resulting standard X.500 was a complex and comprehensive standard that was difficult and expensive to implement and required the complex OSI network protocols to operate. The Emergence of X.500 The standard is designed to have one worldwide distributed directory with a standard access interface. The X.500 directory standard is extremely complex. The OSI network protocols over which it was designed to operate are also much more complex than the Transmission Control Protocol/Internet Protocol (TCP/IP) suite commonly used today. The X.500 standard was originally published by the CCITT in 1990 as the X.500 Blue Book Recommendations and in 1991 by ISO as ISO/IEC 9594: The Directory. Since then, X.500 has been developed and enhanced, with updates of the standard occurring in 1993 and

33 X.500 has four core component models: Information model The information model defines how the directory stores information. X.500 stores information in attributes, which are members of object classes. Each attribute has a syntax definition, search rules, and ordering rules. Naming model The naming model defines how each entry can be referenced. In an LDAP directory, entries are organized in a hierarchical tree called a Directory Information Tree (DIT). Functional model The functional model is the method by which a directory client can communicate with the directory. In X.500, a client called a Directory User Agent (DUA) communicates with the directory server called a Directory System Agent (DSA) using a complex protocol called the Directory Access Protocol (DAP). DAP operates over the OSI network protocol stack. Security model The security model provides methods for authenticating against the directory and for authorizing client access to the directory. The majority of the features in the preceding list have been transferred to LDAP. Their implementation and relevance to LDAP are discussed in more detail in the next section and in Chapter 3, "Active Directory and LDAP as Identity Stores in UNIX and Windows Environments." The Transition to LDAP The main problem with X.500 acceptance and implementation was its complexity and the costs associated with implementation and administration. To increase the acceptability of X.500 directories, it was decided by the Internet Engineering Task Force (IETF) to define new access protocols that were simpler, did not depend on the OSI stack, and that made use of the TCP/IP stack. This resulted in two new protocols: the Directory Assistance Service (DAS) and the Directory Interface to X.500 Implemented Efficiently (DIXIE). The problem with DAS and DIXIE is that they are designed to work with one specific implementation of X.500. LDAP was developed by the IETF to overcome this limitation. LDAP uses TCP/IP as its network transport, is independent of the directory implementation, and uses a small subset of the operations available with DAP. LDAP was intended as a lightweight method of accessing X.500 directories. However, over time it became apparent that the majority of access to X.500 directory servers was through the LDAP protocol. When this became clear, directory servers were designed and implemented that could be accessed only through LDAP. These servers no longer required the complexity found within X.500 directory servers and were less expensive to implement and manage. As a side effect, LDAP servers also have superior performance to X.500 directory servers. The current version of LDAP is LDAPv3. LDAPv1 was never released as a standard. LDAPv2 was published in March 1995 and is defined in three RFCs: RFC 1777, RFC 1778 and RFC LDAPv2 was retired to historic status in RFC

34 LDAPv3 is a result of work by the Access, Searching, and Indexing of Directories (ASID) working group within the IETF. The enhancements from LDAPv2 in LDAPv3 are: The use of UTF-8 for all text string attributes to support extended character sets. Operational attributes that the directory maintains for its own use (for example, to log the date and time when another attribute is modified). Referrals, which allow a server to direct a client to another server that might have the information the client is requesting. An LDAP server can return a referral to an LDAP client when the operation presented by the client cannot be serviced locally and the LDAP server has knowledge of other LDAP servers that can handle the operation. Schema publishing with the directory, which allows a client to discover what object classes and attributes a server supports. This is provided through an object on the root object (rootdse) for use by clients. The majority of the X.500 (93) schema is used. Note X.500 (93) refers to the version of X.500 released in This is the method used to refer to versions of the standard in the OSI community. Extended searching operations that allow paging and sorting of results and clientdefined searching and sorting controls. Stronger security through a Simple Authentication and Security Layer (SASL) mechanism. Extended operations and controls are now supported that allow LDAPv3 to be extended without changing the standard protocol. LDAPv3 is backward-compatible with LDAPv2. A requirement of an LDAPv3 server is that an LDAPv2 client be capable of connecting to it. LDAPv3 is widely implemented as a part of operating systems, network operating systems, directory services, applications such as servers, and client applications. LDAPv3 is a core component of Windows Server 2003 Active Directory. The implementation of LDAPv3 found in Active Directory is fully integrated with a standardscompliant security system based on Kerberos and Microsoft Windows operating systems. Active Directory is covered in more detail in the section "Microsoft Active Directory" in this chapter and in Chapter 3, "Active Directory and LDAP as Identity Stores in UNIX and Windows Environments." Overview of the LDAP Directory Service LDAP is a standard for a directory access protocol. It defines the operations used to communicate with a directory service, how to refer to an entity in the directory, how to describe the attributes of an entity and, finally, the security features that can be used to authenticate to the directory and control access to the entities within the directory. How the information is stored on the directory server is not defined in the LDAP standards. Many different technologies are used to implement LDAP servers. These technologies include simple flat files, indexed files, and relational databases. Regardless of the technology used to implement the directory, all access to the directory from an LDAP client uses the same standard protocol: LDAP. For this reason, and despite the different internal structures, such directories are referred to as LDAP directory servers. 34

35 The following key aspects characterize the LDAP protocol: The protocol is carried directly over TCP for connection-oriented transport (receipt of data is acknowledged) and UDP for connectionless transport (no acknowledgment upon sending or receiving data). Most protocol data elements can be encoded as ordinary strings (for example, distinguished names). Referrals to other servers can be returned to the client. SASL mechanisms can be used with LDAP to provide associated security services. Attribute values and distinguished names can be internationalized through the use of the International Organization for Standardization (ISO) character set. The protocol can be extended to support new operations, and controls can be used to extend existing operations. The schema is published through an attribute on the root object for use by clients. The component models defined in LDAP are the same as those defined in X.500, and they are explained in the following sections. The Information Model A directory must have a method of storing information about an entry. An entry is the basic unit of the directory. The information model provides the data structures and data types necessary to describe the attributes of an entry. Each attribute has a name and either a single value or multiple values. The values must adhere to a specific syntax that is defined for that particular attribute. Examples of attribute syntaxes are Unicode string, binary, and integer. In addition to this, a directory also requires that it is possible to search for specific entries by their attribute values. To facilitate this, matching rules for each attribute can be defined. These rules specify: How a search will match the values contained in the attribute. A definition of how the attributes are ordered. The attributes and the characteristics associated with an entry are defined in the entry's object classes. The definition of object classes and attributes is held in the schema. Three types of object class definitions are used in LDAP directory servers: Structural object class A structural object class represents a real-world object, such as a person. An entity must belong to one and only one structural object class. Auxiliary object class An auxiliary object class is used to extend a structural object class. It has no meaning on its own. Abstract object class The abstract object class is used only as an ancestor of a derived class. The Naming Model The naming model defines how each entry can be referenced. In an LDAP directory, entries are organized in a hierarchical tree called a Directory Information Tree (DIT). Each node in the tree is an entry that can both store information and be a container for other entries. There are two methods of referencing an entry in the tree: using its relative distinguished name (RDN) or its distinguished name (DN). An RDN is unique within a directory and a DN is globally unique. 35

36 An RDN for an attribute might be the common name (cn) of an object as shown here: cn="michael Allen" An RDN could also be made up of more than one attribute value when uniqueness cannot be ensured by simply using a single attribute; for example: cn="michael Allen"+ou="Engineering" The plus (+) symbol in this example makes it clear that the RDN is multi-valued. The practicality of multi-valued RDNs is clear when your organization has two employees named Michael Allen. If they are in two different departments, they can have RDNs that are uniquely qualified by department, as defined in the example by the organizational unit (ou) attribute. The DN for Michael Allen's entry might be: cn="michael Allen",dc="example",dc="com" In this case, the object is uniquely defined, not only in the local directory, but also globally. The domain component (dc) attribute values are used to uniquely define the DNS domain name of the directory server. In LDAP, the naming context for a directory can be defined either in a geographical or a domain name format. The geographical format was the primary method of locating a directory in X.500, and it is still used with LDAP servers. However, it is common to use the domain name of an LDAP server as its naming context because domain names are globally unique on the Internet. 36

37 In Figure 1.5, the naming context of the directory server is the domain name example.com, or the DN dc=example,dc=com. Figure 1.5 The Directory Information Tree (DIT) In Figure 1.5, the DN uses ou="users" instead of cn="users". This interchangeability of cn and ou in this case is a result of the fact that the common name of an organizational unit is identical to the name of the organizational unit. The Functional Model The functional model is the method by which a directory client can communicate with the directory. This is the LDAP protocol itself. LDAP provides the following operations: Interrogation searching the directory Modification updating, adding, or deleting entries in the directory Authentication and control authenticating to the directory (the bind operation) 37

38 The Security Model The security model provides methods for authenticating against the directory and for authorizing client access control to the directory. There are two components to the security model: Authentication using LDAP binds Access control to objects in the directory Authentication to LDAP is introduced later in this section under the heading "Using LDAP for Network Authentication." After it is authenticated, a client can use the LDAP directory only as defined by the directory's Access Control Lists (ACLs). The implementation of ACLs in an LDAP directory is implementation-dependent. The LDAP Interchange Format LDAP directories can exchange data and schema definitions using a standard notation. This notation is called the LDAP Interchange Format (LDIF). LDIF has a simple text file format consisting of: Entries separated by blank lines representing a single entity Comments beginning with the # character Assignments of values to attributes Directives that instruct the LDIF parser on how to interpret the entries An example LDIF file showing the definition of a person entity is given in the following example. This LDIF file could be used to create the entity in an LDAP directory. # This is a comment dn: cn=michael Allen,cn=Users,dc=example,dc=com objectclass: person cn: Michael Allen sn: Reid telephonenumber: The last line is a blank line. This file defines an entity with the DN: cn=michael Allen,cn=Users,dc=example,dc=com The entry is a member of object class person. Object class person contains many attributes, including the common name (cn) of a person, a person's surname (sn), and a person's telephone number (telephonenumber). LDIF can also be used to define an LDAP directory's schema. For this to be possible, special entries in the LDIF file called LDIF directives are used to create object classes and their attributes. For each attribute, LDIF has directives that allow the syntax, search matching rules, and order rules to be defined. LDAP Object Identifiers LDAP uses Object Identifiers (OIDs) to uniquely reference attributes, syntaxes, object classes, and extended controls. OIDs are a series of period separated integers (or string identifiers) and are allocated by the Internet Assigned Numbers Authority (IANA). LDAP OIDs are identical to the OIDs used by Simple Network Management Protocol (SNMP) Management Information Bases (MIBs) that many network administrators are familiar with. 38

39 OIDs must be unique; if you need to make a custom schema for your own organization, you should obtain a private enterprise number from the IANA. After you have a private enterprise number, you can create your own schemas without conflicting with any standard or private schemas already in existence. Note More information regarding OIDs can be found on the IANA's website at You should look for the enterprise numbers entry under "E." Pertinent RFCs The following RFCs describe the LDAP protocol, the representation of standard attributes within LDAP, and the relationship between LDAP and X500. You should only need to read the RFCs if you need to clarify the detail of a particular standard. RFC 1777, "Lightweight Directory Access Protocol" RFC 1778, "The String Representation of Standard Attribute Syntaxes" RFC 1779, "A String Representation of Distinguished Names" RFC 2247, "Using Domains in LDAP/X.500 Distinguished Names" RFC 2251, Lightweight Directory Access Protocol (v3) RFC 2252, Attribute Syntax Definitions RFC 2253, UTF-8 String Representation of Distinguished Names RFC 2254, A String Representation of LDAP Search Filters RFC 2255, The LDAP URL Format RFC 2256, A Summary of the X.500(96) User Schema for use with LDAPv3 Using LDAP for Network Authentication LDAP authentication involves an entity binding to the LDAP server. The success of the bind operation is determined by the acceptance or rejection of the entity's credentials. If the bind is successful, the entity is authenticated; if it is unsuccessful, the entity is not authenticated. In order for LDAP to be used for UNIX and Linux login or service authentication, it needs to be coupled with the LDAP Pluggable Authentication Module (PAM). PAM and its use for LDAP authentication is discussed in detail in Chapter 2, "Authentication and Authorization in UNIX and Windows Environments." Unlike Kerberos, which is designed as an authentication mechanism, LDAP authentication is designed specifically for securing directory transactions. Using LDAP authentication for purposes other than LDAP directory access can lead to performance problems. This is because LDAP directory services are not designed to handle large numbers of authentication requests, but are instead tuned to perform well when handling directory transactions. 39

40 Microsoft Active Directory Active Directory is an essential and inseparable part of the network architecture that improved on the domain architecture of the Microsoft Windows NT 4.0 operating system to provide a directory service designed for distributed networking environments. It was introduced in Windows 2000 and is an integral part of Windows Server Active Directory lets organizations efficiently share and manage information about network resources and users. In addition, Active Directory acts as the central authority for network security, letting the operating system readily verify a user's identity and control his or her access to network resources. Equally important, Active Directory acts as an integration point for bringing systems together and consolidating management tasks. Active Directory is based around the Kerberos 5 and LDAPv3 protocols and, as such, is compatible with Kerberos 5 clients and LDAPv3 clients across all platforms. This allows for Windows Active Directory servers to provide security and directory services in a heterogeneous network. Active Directory and its relationship to the Kerberos 5 protocol is covered in more detail in Chapter 2, "Authentication and Authorization in UNIX and Windows Environments," and its relationship to the LDAPv3 protocol is covered in more detail in Chapter 3, "Active Directory and LDAP as Identity Stores in UNIX and Windows Environments." Combined, these capabilities let organizations apply standardized business rules to distributed applications and network resources without requiring administrators to maintain a variety of specialized directories. An overview of Active Directory is shown in Figure 1.6. Figure 1.6 Overview of Microsoft Active Directory 40

41 Active Directory provides a single point of management for Windows-based user accounts, clients, servers, and applications. It also helps organizations integrate systems not using Windows with Windows-based applications and Windows-compatible devices, thus consolidating directories and easing management of the entire network operating system. Companies can also use Active Directory to extend systems securely to the Internet. Active Directory thus increases the value of an organization's existing network investments and lowers the overall costs of computing by making the Windows network operating system more manageable, secure, and interoperable. 41

42 Vintela Authentication Services As with Active Directory, UNIX and Linux systems typically include implementations of the Kerberos and LDAP protocols. Although these implementations of the Kerberos and LDAP protocols can interoperate with Active Directory, they are typically implemented without consideration of the way that Microsoft has integrated the two standards in Active Directory. To some extent, this is true of the PADL modules used later in this guide to integrate UNIX and Linux Kerberos and LDAP with Active Directory. The Vintela Authentication Services (VAS) product implements Kerberos and LDAP functionality on UNIX and Linux systems that can fully integrate with Active Directory. VAS is a commercial product and is discussed in Chapter 11, "The Vintela Authentication Services." The benefits of using VAS include the following: UNIX and Linux users and computers are managed through the Active Directory Users and Computers MMC snap-in. Kerberos is used to secure LDAP traffic. Performance is tuned to work effectively with Active Directory. The VAS product allows UNIX and Linux clients to operate within an Active Directory domain in an equivalent manner to Windows clients. 42

43 Summary In this chapter you have been shown how your computer security is defined in terms of confidentiality, integrity, and availability, and how authentication and authorization control access to your data, allowing only those entities with the correct credentials past the security controls. The advent of networked computers has created a new set of challenges with regard to authentication and authorization. The old tools used for authentication and authorization were not secure in this new environment. The result was the development of new tools that make use of complex encryption and exchange methods. As an open standard, Kerberos soon became widely adopted and is now is used extensively across all platforms and is the default authentication method for Microsoft Windows products since Windows This new network infrastructure also created challenges for providing data across a wide range of computers. Directory services address this challenge and provide a central repository of data which is accessible across the network. LDAP, now the most prevalent directory service, evolved from the overly complex X.500 standard, and is the foundation of the Microsoft Active Directory service. In subsequent chapters, each of these protocols and concepts will be expanded upon to show how you can use these technologies to produce a heterogeneous UNIX and Windows security and directory service. 43

44

45 2 Authentication and Authorization in UNIX and Windows Environments Introduction Authentication and authorization methods have evolved over time to deal with the requirements of the systems that they run on. From the initial logon of users over serial cable-connected dumb terminals to complex international networks, a number of methods and standards have evolved to ensure the integrity of the authentication and authorization processes. This chapter discusses some of the methods that have evolved, both in the UNIX and Linux environment and in the Microsoft Windows environment. It particularly focuses on the Kerberos 5 protocol, which is in common use across all platforms and provides a secure, encrypted authentication and authorization solution. Microsoft Windows Server 2003 Active Directory is fully Kerberos 5-compliant and can be used to create a heterogeneous security solution, as is demonstrated in later chapters of this guide. 45

46 UNIX and Linux Authentication and Authorization Services The UNIX operating system was originally developed to operate on a centralized computer with terminals connected to it by serial lines. Over the years, it has evolved into the networked operating system that it is today. Linux is derived from UNIX and has evolved alongside UNIX over recent years. This section looks at the different methods of authorization and authentication used in UNIX and Linux. The technologies covered here are summarized in Table 2.1. Table 2.1: UNIX and Linux Authentication and Authorization Technologies Domain Structure Local Files Single realm NIS NIS+ Kerberos LDAP Flat multiple realm Data Store Flat files Two column tables Server Types Encryption Network Protocol Scope N/A Password field only N/A Local computer Master, slave Password field only TCP/IP Local LAN Local LAN Hierarchical Multiple column tables Root master, master, replica Optional full encryption Nonhierarchical multiple realm Kerberos database Master, slave Encryption Hierarchical Various indexed databases Master, replica, or multimaster, replica Choice of methods available TCP/IP TCP/IP TCP/IP Has issues with global operation Platform UNIX/Linux UNIX/Linux UNIX and Linux support incomplete Extensible security mechanisms Global Global No No No Yes Yes Platformindependent Platformindependent Note The Vintela Authentication Service (VAS) incorporates Kerberos and the Lightweight Directory Access Protocol (LDAP), but only uses Kerberos for authentication by UNIX and Linux users. VAS authenticates to the LDAP service using Kerberos. VAS is covered in more detail in Chapter 11, "The Vintela Authentication Service." 46

47 These technologies and the terms associated with them are described in greater depth in the following sections. Local, File-based Systems Historically, the UNIX and Linux operating systems have stored authentication and authorization information in text files. These files, along with a large selection of other system configuration files, are located in the /etc directory. The ultimate source of user account information is the /etc/passwd file. On a system with no other authentication sources, this file contains entries for all users of the system, and even on systems augmented by some of the authentication methods listed in Table 2.2, this file is still essential for the correct operation of the system. Each entry occupies a single line and is a list of fields separated by colons that takes the following form: account:password:uid:gid:gecos:directory:shell These fields are explained in Table 2.2. Table 2.2: Standard Fields for UNIX and Linux passwd Files Field Name account password UID GID GECOS directory shell Description The unique name of the user on the system. Lowercase only. The encrypted password of the user. On most UNIX and Linux implementations, this field contains an asterisk character (*) and the password is actually stored in the /etc/shadow file. The User Identification number. The UID is represented either by a 16-bit or 32-bit integer. Because of the historical use of 16-bit integers for representing UIDs, the maximum UID number on some systems is The Group Identification number. The GID is represented either by a 16-bit or 32-bit integer. Because of the historical use of 16-bit integers for representing GIDs, the maximum GID number on some systems is The General Electric Comprehensive Operating System field. The name of this field is historical. This field is usually used for the full name of the user or for a comment. The home directory for the user. This is the directory that the user process is placed in at login. The login shell for the user. Shell is the term used to describe the command line user interfaces on UNIX and Linux operating systems. This is set to the path of the binary for the user's login shell. Defaults to /bin/sh the Bourne shell. Can be set to /bin/false to disable logins. An example of a typical line from a password file looks like this: mike:dli3ii6fuk7bs:512:45:michael Allen:/home/mike:/etc/sh 47

48 The shadow password file, /etc/shadow, was developed to improve security of the encrypted UNIX or Linux password. Because the /etc/passwd file contains the information required by user programs to map user names to UID numbers, it must be worldreadable. However, this makes the password field of the passwd file available to be read by all users, and while the encryption algorithms used are irreversible, it is quite straightforward to carry out a brute force attack to guess the passwords if the encrypted form of the password is available. This problem is resolved by removing the encrypted password from /etc/passwd and storing it in the shadow password file, /etc/shadow, which can only be read by the system superuser (root). The /etc/passwd and /etc/shadow files provide the authentication information for the system. The authorization on the UNIX and Linux systems using local files is provided at the individual file level, with permissions being set on files, directories, and programs. Group information is held in the /etc/group file and is referenced in the passwd file by the GID field. Groups are defined by a line in this file, with fields separated by colons as follows: Groupname:Password:GID:User list These fields are explained in Table 2.3. In UNIX and Linux it is not possible to make a group a member of another group. Table 2.3: Description of Fields in UNIX group File Field Groupname Password GID User list Description The name for the group This field is no longer in common use. It is usually left empty or set to a common value such as "X" indicating that there is no group password. The numeric identification for the group A list of users who are members of the group in addition to the users that specify the group as their default group in /etc/passwd. The list of users consists of user names separated by commas. Each file and program has a user owner and a group owner. The permissions on the file or directory define who is authorized to carry out the three types of operation: read, write, or execute, as Table 2.4 shows. Table 2.4: UNIX File Operations Representation Operation Description r Read Permission to view the file or list the contents of a directory w Write Permission to modify the file or the contents of a directory x Execute Permission to run the file or to access a directory 48

49 These permissions are assigned to each of three groups of potential users of the file the user owner of the file, members of the group that is the group owner of the file, and all other users. Displaying the current permissions of a file is possible by using the ls command with the l switch, which produces a long form of the list of files. -rw-rw-r-- 1 mike devel 6581 Oct 5 20:43 project.tar drwx mike devel 4096 Aug 15 12:22 project drwxr-xr-x 7 mike devel 4096 Jul 28 18:06 www This example shows one file and two directories owned by the user mike and the group devel. The directories are distinguishable by the leading d in the permissions string. The permissions are detailed in Table 2.5. Table 2.5: File Permission Example File Directory User Group Other project.tar - r w - r w - r - - project d r w x www d r w x r x r - x The project.tar file has permissions set so that the user owner (mike) can read and write to it, members of the group owner (devel) can read and write to it and everyone else is able to read the file. The project directory has permissions set so that only the user owner is able to list the contents of the directory, create a new file in the directory, delete a file in the directory, or change (move) from the current working directory to the project directory. In contrast, the www directory is set so that everyone can read and change into the directory, but only the user owner can create or delete files in it. These file permissions define the authorization within the file system. Because of the way that UNIX handles devices as files, users can easily be restricted from using a certain device by ensuring that the permissions are set correctly. Pluggable Authentication Modules The previous section showed how the /etc/passwd and /etc/shadow files can be used for authentication and authorization on some versions of UNIX, such as Solaris, and Linux systems. In order for UNIX and Linux systems to use other methods of authentication, the pluggable authentication module (PAM) service was developed. PAM provides a standard method for configuring authentication systems on UNIX and Linux operating systems. Different PAM modules can be used to provide different methods of authenticating a user and obtaining account information from the standard local account files. The PAM architecture discussed in this section is detailed in Figure

50 Figure 2.1 PAM system overview Conventional UNIX and Linux users log on by supplying a unique user name and a password. The user name and password are compared with those stored in the /etc/passwd and /etc/shadow files. PAM allows the user name and password information to be stored in many different places and ways. PAM also allows different methods of authentication that do not use user names and passwords, such as retina scans and smartcards. On systems that use PAM, the logon process and all utilities that require user authentication must be compiled to use PAM for authentication and authorization. PAM must then be configured to correctly handle the different authentication methods allowed on a particular system. PAM is configured either with the file /etc/pam.conf or with the files contained in the directory /etc/pam.d. In the /etc/pam.conf file, each line contains fields specifying the behavior of a specific service, and each service often has more than one line to allow for fine levels of control. In the directory /etc/pam.d, there are files defining the behavior of the service one file for each service with the file name specifying which service it relates to. One important feature of the PAM configuration files is that rules defining the behavior of the PAM modules may be stacked to combine the features of different PAM modules for a specific task. For example, several password entries can be stacked so that a valid password could be one that is found in /etc/passwd, /etc/shadow, or an LDAP server. There are four independent management groups within PAM. These are: Account This management group provides services for checking the validity of the account; for example, by checking if the password has expired and by confirming that the user is permitted access to the service. Authentication This management group authenticates the user using a chosen authentication mechanism. The mechanism can be a simple challenge-response mechanism, such as entering a password, or the mechanism can be based on authentication hardware, such as retina scans or smartcard readers. 50

51 Password This management group provides methods for keeping the authentication mechanism up-to-date. In the simplest case, this makes it possible for users to change their passwords. On UNIX and Linux, changing the password is implemented by using the passwd command. Session This management group provides the facility to define tasks that need to take place before a service being granted and after it is withdrawn. It can be used for auditing. PAM modules allow the use of many different authentication methods, including the ones discussed in the rest of this chapter. The Network Information System As the model of networking moved away from the centralized computer with directly connected terminals, the local file system methods of authentication and authorization became much harder to maintain. The maintenance of the local system files on all computers is required in order for a user to be able to log in on any of the computers in the network. On any more than a few computers, this practice soon becomes impractical. Sun Microsystems developed the solution of a centralized database that contains copies of files that are appended to the local files to extend them. The Network Information Service (NIS) simplifies the administration of a larger network by allowing the administrator to make a single change on the centralized server and to have the clients update automatically. Note NIS utilities are identifiable by their "yp" prefix. Sun Microsystems initially called NIS "Yellow Pages," but discovered that this name infringed on a trademark and it was renamed. However, the programs have retained their historical naming; for example, ypinit, ypbind, and ypcat. NIS is built on a client/server model, where servers provide a central repository of files and the clients request information when required. It is a common practice to use these centralized files, called maps, to replace any files that are identical between systems, such as passwd, group, hosts, ethers, and so on. NIS is not suitable for files that are system-dependent. The client/server model is extended by the use of slave servers. An NIS slave server can answer a client request with its own internal representation of the maps, but it is unable to make changes to any of the files. NIS can operate on local files in one of two ways, depending on the configuration of the Name Service Switch (NSS): Files can be replaced by the NIS copy. This can happen for ethers, hosts, netmasks, netgroups, networks, protocols, rpc, and services. Other key files can be augmented by NIS. These files retain all of their own contents, but during a search, where a match is not found in the local file, NIS will proceed to search the relevant NIS map for a match. For example, this can be used to extend the aliases, group, passwd, and shadow files. Which maps are used to augment and which are used to replace the local files is defined in the NSS configuration file /etc/nsswitch.conf. NSS allows the system to specify the source of data returned when requested using standard system calls. Note A full discussion of the working of NSS is found in Chapter 3, "Active Directory and LDAP as Identity Stores in UNIX and Windows Environments." 51

52 Under Linux, there is also a pluggable authentication module (PAM) that interfaces directly with NIS for authentication purposes. PAM is described in detail in the "Pluggable Authentication Modules" section earlier in this chapter. Despite the advantages of NIS, there are also many disadvantages. These disadvantages include: NIS has inherently weak security. NIS security mechanisms are not extensible. NIS data types are not object oriented. NIS is UNIX-specific, not platform-independent. NIS has a flat name space. NIS+ is the evolution of NIS by Sun Microsystems that attempts to address some of these issues. Although they share a common name, the commands and overall structure of NIS+ differs from NIS because of its complete redesign. NIS+ improves security by using additional authentication requirements for access to the maps. Additionally, it makes use of Data Encryption Standard (DES) encryption instead of the cleartext transmissions used by its predecessor. The name space of NIS+ has also changed; it is now hierarchical, allowing for the construction of domains and subdomains within NIS+. This makes NIS+ much more scalable to large environments. The number and scope of the maps handled by NIS has also been extended in NIS+ with the concept of tables. NIS and NIS+ are no longer in development, and their support from Sun is being phased out. Solaris 9 will be the last version of the operating system that supports NIS and NIS+ by default. Kerberos Security Support The Kerberos authentication mechanism is introduced in Chapter 1, "Overview of Network Security and Directory Services." Kerberos has strong security and a structure designed to be inherently scaleable. Kerberos, like NIS, is used in addition to the local authentication files, providing a centralized database that can be queried for user information. Kerberos provides only authentication and authorization information. It contains no other system configuration data. Lightweight Directory Access Protocol The origins of LDAP are discussed extensively in Chapter 1, "Overview of Network Security and Directory Services." LDAP is a directory service and, as such, is capable of holding information about users and groups for authentication and authorization purposes. Unlike Kerberos, the LDAP protocol is not intended as a generic authentication mechanism for applications or services other than LDAP. LDAP authentication exists for the purpose of authenticating LPAP transactions. Although it is possible to use LDAP authentication to authenticate users for purposes other than accessing the LDAP directory, LDAP servers are typically not designed for use in this manner and performance will be less than that achieved by using an authentication mechanism designed for more widespread use, such as Kerberos. In the case of LDAP, an entity is represented by a distinguished name (DN). The entity authenticates with the server using an LDAP bind operation. If the bind operation is successful, then the entity is authenticated; if it is unsuccessful, the entity is not authenticated. 52

53 An LDAP bind operation consists of sending an entity's credentials to the server. The server then uses the credentials to validate the entity before returning a response that indicates success or failure. The following methods can be used to bind to the server: Anonymous authentication With anonymous authentication, the client binds to the LDAP server using a null DN and password. Simple authentication In simple authentication, the client binds to the LDAP server using a DN and a cleartext password. The server compares the password with the entry in a password field (for example, userpassword), and if they match then the client is authenticated. The password can be stored in the password field as a hash. A hash is a unique code calculated from the password using an algorithm that cannot easily be reversed to obtain the original password. In this case, the server calculates the hash from the client's cleartext password and compares it with the hash in the password field. If they match, the client is authenticated. Simple authentication over SSL/TLS Sending passwords in cleartext over a network is inherently insecure. For this reason, LDAP servers can secure simple authentications using Secure Sockets Layer (SSL) or Transport Layer Security (TLS). SSL and TLS encrypt session traffic and make it very difficult for a hacker to gain access to entity or password information. With LDAPv3, SSL and TLS can be used in two ways: By connecting to a special port, ldaps (tcp/636), that connects using SSL or TLS. By using the STARTTLS mechanism on the standard ldap port (tcp/389) to negotiate using SSL or TLS after the connection has been initiated. Guidance for using SSL/TLS is beyond the scope of this guide. Simple Authentication and Security Layer Simple Authentication and Security Layer (SASL) is a standard that allows other protocols to use a wide range of extensible security mechanisms. SASL is security mechanism-independent. SASL-aware applications can use any security mechanism that is available on a specific platform and that has been complied into the SASL libraries. There are several standard authentication mechanisms available with SASL, including: Kerberos 4 (KERBEROS_V4) The Generic Security Service Application Programming Interface (GSSAPI), Version 2 The S/Key mechanism (SKEY) The external mechanism (EXTERNAL) Kerberos 5 is an option with the GSSAPI mechanism. During the bind phase, the client requests a specific security mechanism from SASL. The client and server then use the SASL protocol to carry out any additional steps required by the agreed upon security mechanism. On its own, LDAP has no capability to perform UNIX or Linux login and service authentication, but when coupled with PAM modules, it is capable of providing a centralized database of authentication information to augment the existing local files. Through the integration of LDAP with the NSS, LDAP is capable of providing all of the information that NIS can. LDAP, however, is platform-independent, and implementations are available for nearly all platforms. 53

54 Windows Authentication and Authorization Models The models used for authentication and authorization under Windows changed with the release of Microsoft Windows 2000, upon which Windows Server 2003 is based. The following sections describe the security components that were developed in Microsoft Windows NT Server, and that have now been modified to use Kerberos in Windows 2000 and Windows Server The Security Accounts Manager The Security Accounts Manager (SAM) is a protected subsystem that manages user and group account information. SAM and its role in authentication and authorization are discussed in detail in Chapter 3, "Active Directory and LDAP and Identity Stores in UNIX and Windows Environments." Domain Authentication Model in Windows NT Server 4.0 There are four recommended domain models for Windows NT Server: Single domain Master domain Multiple-master domain Complete trust These models are based on the concept of master domains and resource domains. There are no inherent differences between master and resource domains; rather, they are defined by their usage. Master domains typically hold user and group account information, and resource domains hold network resources such as file shares and printers. 54

55 Figure 2.2 Windows NT 4.0 domain models 55

56 The single-domain model contains all users and groups within a single domain. There is one primary domain controller (PDC) and one or more backup domain controllers (BDCs). This model allows for the centralized management of all users within an organization. There are limits to the size that this model can support, and other models are recommended for sites with more than 25,000 users. The single-master domain model has one master domain that is trusted by all other domains in the network. The master domain contains all of the user and group information and is centrally administered. The resource domains contain only resources such as printers and file shares, and through the use of a one-way trust, authenticate all of their users to the master domain. The multiple-master domain model contains two or more master domains. Like the single-master domain model, the master domains act as account domains, with the users and groups created and maintained on them. Other domains in the network are resource domains with a one-way trust set up to the master domains to allow the authentication of users. The master domains have a two-way trust set up between them. This means that user accounts held in either of the master domains can be used anywhere. The complete-trust model uses two-way trusts between all domains on the network, effectively allowing user accounts to be used on all computers. When a user logs on with a domain account (local accounts are resolved locally), the user name and password entered into the dialog box are checked against those held in the domain database. This is done using the Net Logon service. The Net Logon service starts when a member of the domain starts up. It attempts to find a local domain controller in its trusted domain. This domain controller is then used for all subsequent account authentications. Net Logon then creates a secure channel for authentication information to be sent through by verifying their valid computer accounts within the domain. When the user logs on, the account credentials are passed to the domain controller. If the domain controller is not the domain controller where the account is defined, then it passes the credentials on to the correct domain controller for authentication. This only occurs if the domain controllers have the correct trusts set up. Network authentication in the post-windows NT Server 4 domain is natively handled using Kerberos 5 authentication. This is used to provide a secure authentication method in the networked environment. The architecture and implementation of the Microsoft Kerberos solution are discussed in the following section. 56

57 Microsoft Windows Server 2003 Kerberos The Kerberos implementation present in Windows Server 2003 has been developed based upon the standard described in RFC 1510, which defines Kerberos 5. This section describes the architecture and implementation of this solution. Architecture Windows Server 2003 implements the Key Distribution Center (KDC) as a domain service. It uses the domain s Active Directory as its account database and gets some information about users from the global catalog. As in other implementations of the Kerberos protocol, the KDC is a single process that provides two services: Authentication Service (AS). This service issues Ticket Granting Tickets (TGTs) good for admission to the Ticket Granting Service (TGS) in its domain. Before network clients can get tickets for services, they must get an initial TGT from the authentication service in the user s account domain. Ticket Granting Service (TGS). This service issues tickets good for admission to other services in its domain or to the Ticket Granting Service of a trusted domain. When clients want access to a service, they must contact the TGS in the service s account domain, present a TGT, and ask for a ticket. If the client does not have a TGT valid for admission to that Ticket Granting Service, it must get one through a referral process that begins at the TGS in the user s account domain and ends at the TGS in the service s account domain. The KDC is located on every domain controller, as is the Active Directory service. Both services are started automatically by the domain controller s Local Security Authority (LSA) and run in the process space of the LSA. Neither service should be stopped, although the KDC service can be stopped using the command net stop kdc. Windows Server 2003 ensures availability of these services by allowing each domain to have several domain controllers, which are all peers. Any domain controller can accept authentication requests and ticket-granting requests addressed to the domain s KDC. The security principal name used by the KDC for a Windows Server 2003 domain is krbtgt, as specified by RFC An account for this security principal is created automatically when a new domain is created. The account cannot be deleted, and the name cannot be changed. A password is assigned to the account automatically. The password for the KDC account is used to derive a secret key for encrypting and decrypting the TGTs that it issues. The password for a domain trust account is used to derive an inter-realm key for encrypting referral tickets. All instances of the KDC within a domain use the domain account for the security principal krbtgt. Clients address messages to a domain s KDC by including both the service principal name, krbtgt, and the name of the domain. Both items of information are also used in tickets to identify the issuing authority. For information on name forms and addressing conventions, see RFC Account Database The account database that the KDC needs to obtain information about security principals is provided by the domain s Active Directory. Each principal is represented by an account object. The encryption key used in communicating with a user, computer, or service is stored as an attribute of that security principal s account object. 57

58 Only domain controllers are Active Directory servers. Each domain controller keeps a writeable copy of the directory, so accounts can be created, passwords reset, and group membership modified at any domain controller. Changes made to one replica of the directory are automatically propagated to all other replicas. Windows Server 2003 does not, however, implement the Kerberos replication protocol. Instead, it replicates the information store for Active Directory using a proprietary multi-master replication protocol over a secure channel between replication partners. Physical storage of account data is managed by the Directory System Agent (DSA), a protected process integrated with the LSA on the domain controller. Clients of the directory service are never given direct access to the data store. Any client wanting access to directory information must use one of the supported Active Directory Service Interfaces (ADSI) to connect to the DSA, or LDAP, and then search for, read, and write directory objects and their attributes. Requests to access an object or attribute in the directory are subject to validation by Windows Server 2003 access control mechanisms. Like file and folder objects in the Windows NT File System (NTFS), objects in Active Directory are protected by access control lists (ACLs) that specify who can access the object and in what way. Unlike files and folders, however, Active Directory objects have an ACL for each of their attributes. Thus, attributes for sensitive account information can be protected by more restrictive permissions than those granted for other attributes of the account. The most sensitive information about an account is, of course, its password. Although an account object s password attribute stores an encryption key derived from a password, not the password itself, this key is just as useful to an intruder. Warning There is an option to use Reversible Encryption, which is disabled by default in Windows Server If this is enabled, it reduces the security of the object's password attribute. More information on Reversible Encryption is available in the "Storing Passwords with Reversible Encryption" article available at wsserver2003/proddocs/standard/505.asp Therefore, access to an account object s password attribute is granted only to the account holder, never to anyone else, not even administrators. Only processes with Trusted Computer Base privilege processes running in the security context of the LSA are allowed to read or change password information. To hinder an offline attack by someone with access to a domain controller s backup tape, an account object s password attribute is further protected by a second encryption using a system key. This encryption key may be stored on removable media so that it can be safeguarded separately, or stored on the domain controller but protected by a dispersal mechanism. Administrators are given the option to choose where the system key is stored and which of several algorithms is used to encrypt password attributes. 58

59 Kerberos Policy In Windows Server 2003, Kerberos policy is defined in the Default Domain Group Policy object and implemented by the domain s KDC. By default, the policy settings can be modified only by members of the Domain Admins security group. The elements of Kerberos policy are: Enforce user logon restrictions This element determines whether the KDC validates every request for a session ticket against the user rights policy on the target computer. When this policy is enabled, the user requesting the session ticket must have the right either to Log on locally or to Access this computer from network. Validation of each request is optional because the extra step takes time and may slow network access to services. By default, this policy is enabled. Maximum lifetime for service ticket This element determines the maximum amount of time (in minutes) that a ticket granted for a service (that is, a session ticket) can be used to access the service. If the setting is 0 minutes, the ticket never expires. Otherwise, the setting must be greater than 10 minutes and less than the setting for Maximum lifetime for user ticket. By default, the setting is 600 minutes (10 hours). Maximum lifetime for user ticket This element determines the maximum amount of time (in hours) that a user s TGT can be used. When a user s TGT expires, a new one must be requested or the existing one must be renewed. By default, the setting is 10 hours. Maximum lifetime for user ticket renewal This element determines the longest period of time (in days) that a TGT can be used if it is repeatedly renewed. By default, the setting is seven days. Maximum tolerance for computer clock synchronization This element determines the maximum difference (in minutes) that Kerberos will tolerate between the time on a client s clock and the time on a server s clock while still considering the two clocks synchronous. By default, the setting is 5 minutes. These policy settings define many of the settings that will affect the overall security of your solution. Further guidance on the recommended values for the key settings previously mentioned and how to implement them is given in Chapter 7, "Developing Heterogeneous Kerberos Security Solutions." Delegation of Authentication In Windows NT, a service can impersonate clients when accessing resources on the computer where the service process is running. In Windows Server 2003, a service can use the Kerberos protocol s delegation feature to impersonate clients on other computers as well. The following two conditions must be met: The client s account must be enabled for delegation. The service s account must be enabled for delegation. 59

60 Constrained delegation allows for delegation within a restricted context. This allows a service to delegate client credentials, with domain controllers exercising control when issuing the credentials. Thus, when service A requests Kerberos tickets for service B using delegated client credentials, the domain will consult a list to see if service A is allowed to delegate credentials to service B. In other words, the network administrator can control the scope of delegation. The specifics of constrained delegation are described in detail in the "Exploring S4U Kerberos Extensions in Windows Server 2003" article available at This feature requires a Windows Server 2003 domain. The computer that initially receives the delegation request and the computer hosting the service must also be running Windows Server Preauthentication By default, the KDC requires all accounts to use preauthentication. This makes offline password-guessing attacks very difficult. Preauthentication can be disabled on an account to ensure compatibility with other Kerberos implementations. Kerberos Security Support Provider The Kerberos authentication protocol is implemented as a security support provider (SSP), a dynamic-link library supplied with the operating system. Windows Server 2003 includes an SSP for NTLM authentication as well. By default, both are loaded by the LSA on a Windows Server 2003 computer when the system boots. Either SSP may be used to authenticate network logons and client/server connections. Which one is used depends on the capabilities of the computer on the other side of the connection. Kerberos authentication is generally preferred by Windows Server 2003 over NTLM authentication, although there are situations where NTLM authentication is used for performance reasons. After the LSA establishes a security context for an interactive user, another instance of the Kerberos SSP may be loaded by a process running in the user s security context to support the cryptographic signing and sealing of messages. System services and transport-level applications access SSPs through the Microsoft Security Support Provider Interface (SSPI). This is a Microsoft Win32 interface with methods for enumerating the providers available on a system, selecting one, and using it to obtain an authenticated connection. The methods in the SSPI are generic, black-box routines that developers can use without knowing the details of a particular protocol. All distributed services in Windows Server 2003 use the SSPI to access the Kerberos SSP. A partial list of the ways in which the Kerberos protocol is used for authentication includes: Print spooler services CIFS/SMB remote file access LDAP queries to Active Directory Distributed file system management and referrals IPSec host-to-host security authority authentication 60

61 Reservation requests for network Quality of Service Intranet authentication to Internet Information Server Remote server or workstation management using authenticated Remote Procedure Calls (RPCs) Certificate requests to the Microsoft Certificate Server for domain users and computers Credentials Cache On computers running Windows Server 2003, tickets and keys obtained from the KDC are stored in a credentials cache, which is an area of volatile memory protected by the LSA. The credentials cache is never paged to disk. All objects stored there are deleted when a security principal logs off or the system is shut down. The credentials cache is managed by the Kerberos SSP, which runs in the LSA s security context. Whenever tickets and keys need to be obtained or renewed, the LSA calls the Kerberos SSP to accomplish the task. The LSA also keeps a copy of an interactive user s hashed password. If the user s TGT expires during a logon session, the Kerberos SSP uses the LSA s copy of the hashed password to obtain a new TGT silently, and without interrupting the user s logon session. The password is not stored permanently on the computer, and the local copy is deleted when the user s logon session is terminated. Hashed passwords for services and computers are handled differently. As in earlier versions of Windows NT, they are stored in a secure area of the computer s registry. The registry is also used to store hashed passwords for user accounts on the local system. DNS Name Resolution RFC 1510 specifies that Internet Protocol (IP) transport should be used for messages between clients and the KDC. When the Kerberos SSP on a client computer wants to send an initial authentication service request, it needs to find an address for the KDC in the user's account domain. To do that, it needs the Domain Name System (DNS) name of a server where the KDC service is running. If the DNS name can be resolved to an IP address, that is where the Kerberos SSP sends its message. Otherwise, the Kerberos SSP generates an error indicating that it can find no such domain. In Windows Server 2003 domains, the KDC service runs on every Windows Server based domain controller. In addition to being KDC servers, domain controllers are also LDAP servers. Both services are registered in DNS service locator records (SRV resource records). Clients can find a domain controller by querying DNS for SRV resource records with the name _ldap._tcp.dc._msdcs.example.com. The KDC service can be located by querying DNS for SRV resource records with the name _kerberos._udp.example.com. Clients that do not support the SRV record type in their DNS resolver can query for a host record (an A resource record) with the name of the domain. Computers running Windows Server 2003 can participate in Kerberos realms that are not Windows Server 2003 domains. In this case, the KDC will not be on a Windows Server 2003 domain controller, so the DNS names for KDC servers must be stored in the client computer's registry. The Kerberos SSP looks in the registry for the DNS domain name of the user's realm, and then it resolves the name to an IP address by querying a DNS server. 61

62 IP Transport According to RFC 1510, when a client contacts the KDC, it should send a User Datagram Protocol (UDP) datagram to port 88 at the KDC s IP address. The KDC should respond with a reply datagram to the sending port at the sender s IP address. UDP is a connectionless transport protocol, making it a logical choice when an exchange of messages must precede a connection. UDP is also well suited to applications with one message and one response, such as the exchanges between clients and the KDC, so long as each message fits into a single datagram. Using the UDP transport protocol works best when the higher level protocol data fits into a single UDP datagram. The capacity of a frame varies with the medium. The Maximum Transmission Unit (MTU) for an Ethernet frame is 1500 octets. The maximum size of the IP header is 60 octets and the UDP header is 16 octets long. If the physical network is Ethernet, then Kerberos messages sent as UDP datagrams can carry up to 1424 octets of data with an IP header of 60 octets. The UDP standard states that hosts must be capable of accepting UDP datagrams that are only 516 octets long. Windows Server 2003 authorization data can easily total more than 1424 octets. This is outside the capacity of the UDP packet size; therefore, the only solution is to make use of the Transport Control Protocol (TCP) for the transport of this authorization data. The use of TCP transport is consistent with recently proposed revisions to RFC 1510 in the Internet Draft with the file name draft-ietf-krb-wg-kerberos-clarifications-04.txt, and has been implemented in the latest release of the MIT Kerberos solution. Authorization Data Kerberos is a protocol designed primarily for authentication. It verifies that the identity of the Kerberos security principals is correct. It does not determine which files and other objects security principals may access or how they may access them. These decisions are left to whatever access control mechanism may be available on the system. The Kerberos protocol has extensions allowing it to assist authorization mechanisms by providing a field for authorization data in Kerberos tickets. Kerberos does not specify the form of the data or how servers should use it. Access Control in Windows Server 2003 On some operating systems, applications are required to implement their own mechanisms for determining the level of a user s authorization. Often, applications do this by maintaining private lists with the names of users who are authorized access. This kind of access control can be integrated with Kerberos authentication by ensuring that the authorization data field of a ticket carries some form of the security principal s name. This is sometimes called name-based authorization. Applications designed for Windows Server 2003 can implement name-based authorization mechanisms to control access to information internal to the application. Database applications, for example, often maintain private authorization tables to control which fields in a record a particular user can view or change. Unfortunately, private authorization mechanisms are just that private. A database application is powerless to prevent an unauthorized user from running another application and using it to edit the data file. 62

63 On Windows Server 2003, if a file or other resource can be shared by two processes, it is secured against unauthorized access by the operating system s own access control mechanism. The header of every object includes a security descriptor with an access control list (ACL) maintained by the object s owner who has the discretion to grant or deny access to any security principal and to define the level of authorization for a security principal who has been granted access. The operating system enforces the owner s decisions by performing an access check whenever an application requests access to a protected object. Before returning a handle, the operating system examines the object s ACL to see whether the security principal that is using the application has been granted access. If not, the application is denied access. Another important difference from other access control mechanisms is that security principals are not identified by name in Windows Server 2003, either by the operating system or by entries in ACLs. Instead, each security principal is assigned a unique Security Identifier (SID), an alphanumeric value with a structure similar to a telephone number. Like the country/region code used in international calling, the first part of a SID identifies the domain where the SID was issued. Like the number for a particular telephone within a country/region, the second part of a SID identifies an account within the issuing domain. The value for a domain is unique within an enterprise, and the value for an account is unique within a domain. Unlike telephone numbers, SIDs are never reused. There is no possibility that a user could be assigned a SID that once belonged to another user a problem not easily solved by name-based access control mechanisms. A third important difference with name-based access control is that authorization is determined not only by user s identity but also by the user s membership in one or more security groups. In fact, the preferred method of controlling resources is to grant access to groups instead of to individuals, adjusting the level of a group s authorization according to the needs of its members. This method makes it easier to keep ACLs up-to-date on networks with thousands of users and millions of objects. Group membership can be managed centrally by administrators, who can change a particular user s level of authorization for many resources by adding or removing a member from a group. Windows Server 2003 makes resource security still easier to manage by allowing groups to be nested. A group created in one domain can be included in the membership of a group created in another domain or in the membership of a universal group used throughout a tree of trusted domains. As a result, when employees change jobs, their level of authorization can be changed throughout the enterprise without touching the ACL on a single object. Like individual security principals, each Windows Server 2003 security group has an SID. A user s level of authorization is determined, then, by a list of SIDs one SID for the user and one SID for each security group to which the user belongs. How the Microsoft KDC Prepares Authorization Data When the Kerberos protocol is used for authentication, a list of SIDs identifying a security principal and the principal s group membership is transported to the local computer in the authorization data field of a session ticket. Authorization data is gathered in two separate steps. The first step takes place when the KDC in a Windows Server 2003 domain prepares a TGT. The second step is accomplished when the KDC prepares a session ticket for a server in the domain. 63

64 When a user requests a TGT, the KDC in the user s account domain queries the domain s Active Directory. The user s account record includes an attribute for the user s SID as well as an attribute with SIDs for any domain security groups to which the user belongs. The list of SIDs returned by the KDC s query is placed in the TGT s authorization data field. In a multiple-domain environment, the KDC also queries the global catalog for any universal groups that include the user or one of the user s domain security groups. If any are found, their SIDs are added to the list in the TGT s authorization data field. When the user requests a session ticket for a server, the KDC in the server s domain copies the contents of the TGT s authorization data field to the session ticket s authorization data field. If the server s domain is different from the user s account domain, the KDC queries Active Directory to find out whether any security groups in the local domain include the user or one of the user s security groups. If any are found, their SIDs are added to the list in the session ticket s authorization data field. This use of the authorization data field is consistent with revisions to RFC 1510 submitted to the IETF. The Windows Server 2003 authorization data is in Network Data Representation (NDR) format and is signed by the KDC. How Services Use Authorization Data In Windows Server 2003, services act in their own security contexts only when accessing resources on their own behalf. For the most part, this is just when they are doing their own housekeeping accessing configuration data stored in registry keys, binding to communications ports, and completing other tasks not related to work for a particular client. When a service does do something for a client, it impersonates the client, acting in the client s security context. This means that in addition to identifying clients, Windows Server 2003 services must also take on some of their characteristics specifically, the client s level of authorization on the system. When a service sets up housekeeping on a computer running Windows Server 2003, it calls the SSPI method AcquireCredentialsHandle to gain access to its own credentials the secret key for the account under which the service runs. The service then binds to a communications port, where it listens for messages from prospective clients. When a client requests a connection and presents a session ticket, the service asks the Kerberos SSP to verify the client s credentials by calling the SSPI method AcceptSecurityContext, passing the client s session ticket along with a handle to the service s secret key. The Kerberos SSP verifies the ticket s authenticity, opens it, and passes the contents of the authorization data field to its parent process, the LSA. If the data includes a list of SIDs, the LSA uses them to build an access token representing the user on the local system. In addition, the LSA queries its own database to determine if the user or one of the user s security groups is a member of a security group created on the local system. If any are found, the LSA adds those SIDs to the access token. The LSA then confirms to the calling service that the client s identity has been authenticated, enclosing a reference to the client s access token. On receiving confirmation, the service completes its connection with the client and attaches the client s access token to an impersonation thread by calling ImpersonateSecurityContext. When the impersonation thread needs access to an object, it presents the client s token. The operating system performs an access check by comparing SIDs in the token to SIDs in the object s ACL. If it finds a match, it checks to see that the entry in the ACL grants the level of access requested by the thread. If it does, the thread is allowed access. Otherwise, access is denied. 64

65 Why Authorization Data Is Signed Session tickets are encrypted with the secret key for the account under which the service starts. When a service acquires a handle to its own credentials on the system, it gains access to that key. A rogue service could be installed by an unscrupulous user with a legitimate network account but limited authorization on the local computer. The user could request a session ticket for the service, and then the service could decrypt the ticket, modify the authorization data by adding the SID for a privileged group, encrypt the altered ticket, and present it to the LSA in a call to AcceptSecurityContext. The result would be to elevate the user s level of authorization on the computer where the service is running. To prevent tampering with authorization data, it is signed by the KDC before it is stored in a session ticket. Any attempt to alter the data will invalidate the signature. The LSA on a Windows Server 2003 computer always checks the validity of this signature when session tickets are presented by untrusted services. The LSA can trust calls to AcceptSecurityContext from services running under the Local System account. This account is used by services installed with the operating system by the native Server service, for example. Other services can be configured to use the Local System account, but this must be done by a member of the Administrators group. It is assumed that the administrator who installs the service can vouch for its security. The LSA does not trust services running under any other account. If a session ticket is presented by an application that is not running as Local System, the LSA asks the KDC in its domain to verify the signature on the ticket s authorization data. The question is asked and answered by a Remote Procedure Call (RPC) over the Net Logon secure channel to the domain controller. Requests for verification do not need to travel beyond the local domain because session tickets are always issued and therefore authorization data is always signed by the KDC for the target computer s domain. Implementation When a user with an account in a Windows Server 2003 domain logs on at the keyboard of a computer running Windows Server 2003, the user s logon request is processed in three stages: 1. The user asks for admission to the Ticket Granting Service for the domain. This is accomplished by an AS Exchange between the Kerberos SSP on the computer and the KDC for the user s account domain. The result of a successful exchange is a TGT that the user can present in future transactions with the KDC. 2. The user asks for a ticket for the computer. This is accomplished by a TGS Exchange between the Kerberos SSP on the computer and the KDC for the computer s account domain. The result is a session ticket that the user can present when requesting access to system services on the computer. 3. The user asks for admission to Local System services on the computer. This is accomplished when the Kerberos SSP on the computer presents a session ticket to the LSA on the computer. 65

66 If the computer s domain is different from the user s domain, an extra step is involved. Before requesting a session ticket for the computer, the Kerberos SSP must first ask the KDC in the user s account domain for a TGT good for admission to the KDC in the computer s account domain. It can then present the TGT to that KDC and get a session ticket for the computer. Exactly how the logon process works will depend on how the computer is configured. With standard configurations of Windows Server 2003, interactive users log on with a password. The operating system also includes the option to log on with a smart card. The basic process is the same for both configurations. Their differences will be examined after first stepping through the process for a standard logon with a password. For example, suppose Alice has a network account in the domain example.com. The computer she normally uses, Machine01, also has an account in example.com. When Alice logs on to the network, she begins by pressing the key combination CTRL+ALT+DEL, the Secure Attention Sequence (SAS) on computers with a standard Windows configuration. In response to the SAS, the computer s Winlogon service switches to the logon desktop and dispatches to the Graphical Identification and Authentication (GINA) dynamic-link library, a component loaded in Winlogon s process. The GINA is responsible for collecting logon data from the user, packaging it in a data structure, and sending everything to the LSA for verification. Third parties can develop replacement GINAs, but in this case Winlogon has loaded the standard component supplied with the operating system, msgina.dll. Winlogon dispatches to it, and it displays the standard Logon Information Dialog. Alice types her user name and password. From the domains in a drop-down list, she selects example.com. When she clicks OK to dismiss the dialog box, msgina.dll returns her logon information to Winlogon. It sends the information to the LSA for validation by calling LsaLogonUser. On receiving a data structure with Alice s logon data, the LSA immediately converts her cleartext password to a secret key by passing it through a one-way hashing function. It saves the result in the credentials cache, where it can be retrieved when needed for TGT renewal or for NTLM authentication to servers that are not capable of Kerberos authentication. To validate Alice s logon information and set up her logon session on the computer, the LSA must obtain: A TGT good for admission to the Ticket Granting Service A session ticket good for admission to the computer The LSA gets these tickets by working through the Kerberos SSP, which exchanges messages directly with the KDC in example.com, as shown in Figure 2.3. KDC LSA Kerberos SSP TGT for Domain Ticket for Computer Authentication Service Ticket Granting Service Figure 2.3 Interactive Logon to a domain account 66

67 The messages follow this sequence: 1. The LSA sends the message KRB_AS_REQ to the KDC in example.com. The message includes: The user principal name: Alice The name of the account domain: example.com Preauthentication data encrypted with the secret key derived from Alice s password 2. If the client s preauthentication data is correct, the KDC replies with KRB_AS_REP. The message includes: A session key for Alice to share with the KDC, encrypted with the secret key derived from Alice s password A TGT for the KDC in example.com, encrypted with the KDC s secret key The TGT includes: A session key for the KDC to share with Alice Authorization data for Alice The authorization data includes: The SID for Alice s account SIDs for security groups in the domain example.com that include Alice SIDs for universal groups in the enterprise that include either Alice or one of her domain groups 3. The LSA sends the message KRB_TGS_REQ to the KDC in example.com. The message includes: The name of the target computer: Machine01 The name of the target computer s domain: example.com Alice s TGT An authenticator encrypted with the session key Alice shares with the KDC 4. The KDC replies with KRB_TGS_REP. The message includes: A session key for Alice to share with Machine01, encrypted with the session key Alice shares with the KDC Alice s session ticket to Machine01, encrypted with the secret key Machine01 shares with the KDC The session ticket includes: A session key for Machine01 to share with Alice Authorization data copied from Alice s TGT 67

68 Having received Alice s session ticket, the LSA decrypts it with the computer s secret key and extracts her authorization data. It then queries the local SAM database to discover whether Alice is a member of any security groups local to the computer and whether she has been given any special privileges on the local computer. It adds any SIDs returned by this query to the list taken from the ticket s authorization data. The entire list is then used to build an access token, and a handle to the token is returned to Winlogon, along with an identifier for Alice s logon session and confirmation that her logon information was valid. Winlogon creates a window station and several desktop objects for Alice, attaches her access token, and starts the shell process she will use to interact with the computer. Alice s access token is subsequently inherited by any application process that she starts during her logon session. This allows Alice to securely use Active Directory services on various Windows Server 2003 servers without having to reauthenticate. Summary In this chapter, the concepts of authentication and Kerberos have been expanded to build upon the initial foundations that were laid out in Chapter 1, "Network Security and Directory Services." The Kerberos 5 protocol is in common use across all platforms and provides a secure, encrypted authentication and authorization solution. The security services that are currently available on UNIX and Linux have been summarized. These summaries have included the features available from each of the operating systems, along with each of their strengths and weaknesses. With the advent of Windows 2000, Microsoft implemented the Kerberos 5 standard as a part of Active Directory. Windows Server 2003 has built upon the standards based implementation of Kerberos found in Windows Active Directory is fully Kerberos 5-compliant, and the concepts presented in this chapter will be expanded upon in later chapters. These chapters will also show how the technologies present in Windows Server 2003 Active Directory can be used to create a heterogeneous security solution. 68

69 3 Active Directory and LDAP as Identity Stores in UNIX and Windows Environments Introduction Enterprise operating systems such as UNIX, Linux, and Windows Server 2003 make use of a wide range of configuration information. The most common information used by enterprise operating systems is the information relating to user accounts. Other information used by enterprise operating systems includes printer configurations, user groups, host names, organizational structure, and application information. All of this information must be stored in some form of directory, either on the local computer or on the network in a central repository. This chapter delineates the different techniques used to store the information used by UNIX, Linux, and Windows operating systems and the applications that run on them. In an ideal world, all organizational data, including that required by operating systems and the applications that run on them, would be stored and administered in one place. Duplication of data would be avoided, savings would be made in the storage and administration of the data, and benefits could be gained by improving user access to organizational information. This chapter describes how it is possible for you to achieve these benefits by utilizing the Lightweight Directory Access Protocol (LDAP) directory services in the UNIX, Linux, and Windows Server 2003 operating systems and then maximize these benefits by using Microsoft Windows Server 2003 Active Directory as a centralized LDAP directory service. Using Active Directory also allows for tight integration with Microsoft operating systems and applications, extensive management tools, and comprehensive security facilities. 69

70 UNIX and Linux Identity Management and Directory Services UNIX and Linux identity management and directory services have evolved over many years. When UNIX was first created, modern network management and directory standards did not exist. In the early days of UNIX, it was unusual for systems to be networked together. For these and other reasons, information used by UNIX systems and UNIX applications was traditionally held in simple text files. Over the years, new methods of storing system and application information were developed and added to UNIX systems. These methods also became a part of the Linux operating system. Some features of the evolution of UNIX and Linux identity management and directory services are covered in Chapter 1, "Overview of Network Security and Directory Services," and Chapter 2, "Authentication and Authorization in UNIX and Windows Environments." This section looks in more detail at the different methods of storing system and application data on the UNIX and Linux platforms. The technologies covered in this chapter are summarized and compared in Table 3.1. Table 3.1: UNIX and Linux System and Application Data Stores Naming Structure Local Files DNS NIS NIS+ LDAP Flat Hierarchical Flat Hierarchical Hierarchical Data Store Files Various, but typically in zone files Server Types Security Network Protocol Scope Platform Extensible data types NA File permissions Master, slave TSIG or DNSSEC Two-column maps Master, slave NA TCP/IP TCP/IP Local LAN Local computer Primarily UNIX/Linux Typically not implemented or enforced Multicolumn tables Root master, master, replica Various indexed databases Master, replica, or multi-master replica None DES Various and extensible: plain, SSL/TLS, SASL methods TCP/IP Global Local LAN Has issues with global operation UNIX/Linux UNIX and Linux support incomplete TCP/IP Global Limited No No Yes Platformindependent Platformindependent 70

71 Note If you are unfamiliar with some of the terminology, the acronyms and terms in Table 3.1 are spelled out and explained later in this chapter. Note The Vintela Authentication Service (VAS) uses LDAP to connect to the Active Directory directory service. VAS is covered in more detail in Chapter 11, "The Vintela Authentication Service." Note Guidance for using LDAP SSL/TLS is beyond the scope of this guide. There are some similarities between this section and the "UNIX and Linux Authentication and Authorization Services" section in Chapter 2, "Authentication and Authorization in UNIX and Windows Environments." These similarities are a result of UNIX and Linux using directory stores to hold authentication data required by the authentication and authorization mechanisms described in Chapter 2. It is important to differentiate between the authentication mechanism and where the authentication data is stored because the first is an authentication mechanism and the second is a directory service. Local, File-based Systems The UNIX and Linux operating systems have a tradition of using text files for storing configuration settings and other system information. This approach means that UNIX and Linux can be configured from the command line using standard text editors such as vi or emacs. In addition to manual configuration of UNIX and Linux systems, text files lend themselves to automatic configuration using one or more of the many scripting languages available to UNIX and Linux administrators. Many UNIX and Linux configuration files are stored in the /etc directory. Key examples of the configuration information stored there are user account and group account information. User configuration details are typically stored in two files, /etc/passwd and /etc/shadow. Each line represents a user account in a format that is common across UNIX and Linux platforms. Group information is stored in /etc/group and is also stored as one group entry per line. Each of these files is formatted so that entries (one per line) are stored in colon separated fields. The standard fields for the /etc/passwd file are: account:password:uid:gid:gecos:directory:shell These fields are explained in Table 3.2. Table 3.2: Standard Fields for UNIX and Linux passwd Files Field Name account password UID GID Description The unique name of the user on the system. Lowercase only. The encrypted password of the user. On most UNIX and Linux implementations, this field contains an asterisk character (*) and the password is actually stored in the /etc/shadow file. The User Identification number. The UID is represented either by a 16 bit or 32 bit integer. Because of the historical use of 16 bit integers for representing UIDs the maximum UID number on some systems is The Group Identification number. The GID is represented either by a 16 bit or 32 bit integer. Because of the historical use of 16 bit integers for representing GIDs, the maximum GID number on some systems 71

72 Field Name GECOS directory shell Description is The General Electric Comprehensive Operating System field. The name of this field is historical. This field is usually used for the full name of the user or for a comment. The home directory for the user. This is the directory that the user process is placed at login. The login shell for the user. This is set to the path of the binary for the user's login shell. Defaults to /bin/sh the Bourne shell. Can be set to /bin/false to disable logins. In UNIX and Linux, the information stored in system configuration files is not accessed directly by a service or application. Instead, UNIX and Linux provide an application programming interface (API) in the form of functions that are available to programmers as a standard part of the C programming libraries. Among these APIs are functions for accessing, manipulating, and using the system configuration stored in UNIX and Linux configuration files. In the case of the /etc/passwd file, the functions are getpwnam(), getpwuid(), getpwent(), setpwent(), endpwent(), getpw(), and putpwent(). There are a number of disadvantages with storing system configuration information in files. The most prominent of these is that the files are usually local to a specific computer. The administration of each computer consists of editing every computer's own local files. For example, if a user was added to the network, then that user would have to be added to the passwd file on every UNIX or Linux system that the user might need to access. In large organizations with thousands of UNIX and Linux servers and thousands of users, this method of administration is onerous at best and impractical at worst. For this reason, methods of centralizing the administration of UNIX and Linux configuration information have been developed. 72

73 Name Service Switch To ease the use of different methods of providing UNIX and Linux configuration information, the Name Server Switch (NSS) architecture was developed. This modular architecture defines an interface between the standard C programming function calls and a service module that implements the storage of UNIX information in a particular file, database system, or directory. Figure 3.1 shows the basic structure of NSS. Figure 3.1 The name service switch architecture 73

74 The name service switch can be used to redefine where UNIX and Linux obtain a wide range of configuration information. The databases typically supported by NSS are shown in Table 3.3. Table 3.3: Name Server Switch Standard Supported Databases Database Description Example C function aliases Mail aliases used by sendmail. N/A Presently ignored. ethers Hard-coded Ethernet MAC-to-IP ether_ntohost() address translations. group User groups. getgrent() hosts netgroup Defines the relationships between IP addresses and host names. Network-wide list of hosts and users; used for access rules. gethostbyname() or getipnodebyaddr() getnetgrent() network Network names and numbers. getnetent() passwd The user account database. getpwent() protocols Network protocols. getprotoent() publickey Public and secret keys used by secure getpublickey() RPC. rpc Remote procedure call names and numbers. getrpcbyname() services Network services. getservent() shadow Stores user password and account parameters. getspnam() NSS is configured through the file /etc/nsswitch.conf. Like other UNIX and Linux configuration files, nsswitch.conf is a text file with a configuration entry on each line. Lines beginning with a number symbol (#) are comments. A configuration line begins with the name of the database suffixed with a colon, and it ends with a list of the methods used to resolve the database query or function. The methods listed for a specific entry are tried in turn from left to right. For example, the standard user and group entries read: passwd: shadow: files files group: files This example shows that the passwd, shadow, and group information are obtained from the standard files located in /etc. A more complex example is shown here: passwd: shadow: files nisplus nis files nisplus nis group: files nisplus nis For each of the databases in this case, the operations are made first against the standard system files in /etc, and then by using the latest incarnation of the Network Information System (NIS+), and finally using standard NIS. 74

75 The NSS service methods available depend on the installation of shared library objects for a specific service. The services typically found on a UNIX or Linux system are shown in Table 3.4. Table 3.4: Typical NSS services Service Name compat db dns files hesiod nis nisplus ldap Description Use with /etc/passwd, /etc/group, and /etc/shadow to support old style plus (+) and minus (-) notation Use local database files ending with the suffix.db Use the Domain Name System (DNS) Use local text configuration files, typically found under /etc Use hesiod for lookups Use the Network Information Service (NIS) for lookups Use NIS+ for lookups Use for LDAP lookups Note Not all services are available on all UNIX and Linux platforms. Also, not all services are capable of using all data source types. This is particularly true of the LDAP service. NSS enables UNIX and Linux systems to use some of the services shown in Table 3.4. The following sections look at four of these services, DNS, NIS, NIS+ and LDAP. The Domain Name System Internet domain names are a convenient way of referring to a host without using its Internet Protocol (IP) address. On the early Internet, host names and IP addresses for all hosts on the Internet were stored in a file which was called HOSTS.TXT. A copy of this file was available for file transfer to local computers from a central location. UNIX systems and Linux systems store this information in the /etc/hosts file. This file is equivalent to the Windows file %SYSROOT%\system32\drivers\etc\hosts. In these files, each line begins with an IP address and is followed by a list of space-separated names that the host is known by, as shown here: localhost localhost.localdomain win2003ent win2003ent.example.com. In this example, win2003ent.example.com is the domain name of your server and is used in examples throughout this guide. Managing a centralized host file for the Internet quickly became impractical. The Domain Name System (DNS) was developed to provide a scalable, distributed, hierarchical naming system specifically for information related to network addresses. DNS is an essential service on the modern Internet. It is used by practically every other service and application operating on the Internet and other Transmission Control Protocol/Internet Protocol (TCP/IP)-based networks. On UNIX and Linux, NSS can be configured to use DNS for network name and address lookups. The following line in /etc/nssswitch.conf on a UNIX or Linux system configures NSS to use the local host file and DNS for network name and address lookups. hosts: files dns 75

76 DNS is a directory service that fulfils a very specific function: resolving network entities such as IP addresses or domain names. It is not intended as a generic directory for arbitrary information. For this reason, it is unlikely that a generic directory service such as LDAP would ever replace DNS. However, it is possible to store a DNS server's zone data in an LDAP directory. The Microsoft DNS Server can be configured to store its zone data in Active Directory. The Berkeley Internet Naming Domain (BIND) can be configured to store its zone data in an LDAP directory. For both servers, this has many advantages. The LDAP service (such as Active Directory) can use replication to create DNS servers configured in a multiple master configuration. A multiple master configuration has many benefits, the most important of which is that it allows updates to the DNS zone data to be made on any DNS server, and not just the primary. This is particularly useful when using Dynamic DNS (DDNS) because it facilitates load-balancing and improvements in resilience. The DNS data stored in LDAP can be used for other functions within an organization, such as asset management and printer management. The Network Information System NIS provides a method of centralizing all UNIX and Linux configuration files. It is often used to distribute the user and group databases on a network. It can also be used to distribute other system files such as /etc/services and /etc/protocols. NIS is described in detail in the "The Network Information System" section in Chapter 2, "Authentication and Authorization in UNIX and Windows Environments." The main points from that discussion that pertain to identity management are summarized in the following paragraphs. Centralized management of UNIX and Linux systems using NIS and NIS+ is a significant improvement over administration through the configuration of local files. Large scale implementation of NIS or NIS+ in homogeneous UNIX networks leads to many benefits beyond centralized administration. A consistent user database across all UNIX servers and UNIX workstations allows users to roam from one computer to another using the same user name and password. Despite the benefits, NIS and NIS+ have a number of disadvantages: NIS uses weak security techniques and is inherently insecure. NIS+ uses improved security based on the Data Encryption Standard (DES), but it is not extendable to be able to use the latest security algorithms and techniques. NIS presents data to the operating system as flat files, which are not as scalable as a directory service. NIS is not extensible. The NIS and NIS+ systems are specific to UNIX or UNIX-like operating systems. They are not platform-independent, although gateways to other operating systems do exist (for example, Microsoft Server for NIS). NIS has a flat name space. NIS stores UNIX system configuration information effectively, but this information cannot easily be consolidated with information required by other applications or services. NIS and NIS+ are becoming obsolete, with some UNIX vendors announcing migration from NIS and NIS+ to LDAP. NIS and NIS+ are useful when managing UNIX and Linux networks; however, the limitations make them inappropriate as a generic directory store for an organization's data. This is particularly true when an organization wants to consolidate data from across multiple platforms such as UNIX, Linux, and Windows. 76

77 LDAP as an Identity Store Each of the methods of storing system information on UNIX and Linux systems described in this chapter so far have limitations; for example: Local files do not allow you to implement network-wide centralized administration. DNS is not a generic service and it only supports network information. NIS and NIS+ are specific to UNIX and Linux and do not easily allow you to implement cross-platform integration. LDAP solves all of these problems (and others). Using LDAP as a naming service on UNIX and Linux systems provides the following advantages: LDAP allows you to consolidate information by replacing system and applicationspecific databases with one directory. LDAP makes efficient data synchronization between masters and replicas possible. LDAP is an open standard that is multi-platform and multi-vendor compatible. On UNIX and Linux, LDAP can be used to store configuration and system information after the LDAP NSS module (nss_ldap) is installed and configured. The detail of the configuration of the LDAP NSS module is covered in Chapter 8, "Developing the LDAP Security and Directory Infrastructure." The /etc/nsswitch.conf file is configured to use LDAP after the LDAP NSS module has been installed and configured by adding the ldap service to configuration lines. The three lines here show the user and group databases configured to use the NSS LDAP service: passwd: shadow: files ldap files ldap group: files ldap Because LDAP is a generic directory service, it is necessary to extend the standard schemas to store the objects and attributes required to hold UNIX and Linux system information. Typically, the schema used to hold UNIX and Linux system information will also be capable of holding information for the major system information databases, some of your organization's bespoke databases, and databases used by applications (including, for example, ). Some standard schemas provided with LDAP may already contain entities that UNIX and Linux servers need to be capable of accessing. However, these entities may not contain the attributes required by UNIX and Linux. For example, the object class person is used to store basic information about an individual, but it does not contain attributes required by UNIX or Linux, such as their UID number or their GID number. The object class organizationalperson is derived from the person object class. But organizationalperson does not contain many UNIX or Linux attributes. The inetorgperson object class is derived from the organizationalperson object class, but this does not contain attributes necessary for use with UNIX and Linux, either. 77

78 While the object classes person, organizationalperson, and inetorgperson do not contain all the user attributes required by UNIX or Linux, they do illustrate the fact that the LDAP schema can be extended by creating new object classes based upon existing ones. Because none of these three object classes contain the full set of UNIX or Linux attributes required to store the information stored in the /etc/passwd and /etc/shadow files, it is necessary to extend the schema. Because extending the schema builds on those attributes that already exist, any information about individual's already stored in the LDAP database and in use by other applications or operating systems will continue to be used as before, and this information is consolidated with the individual's UNIX or Linux attributes. Extending the LDAP schema is not restricted to object classes describing individuals; it can also be applied to all other system information. In some cases, new object classes are required that will only be used by UNIX or Linux systems and have no application elsewhere. In other cases, such as groups and printers, UNIX or Linux information about these objects could be consolidated with information from other platforms or applications. How you decide to extend the LDAP schema in Active Directory to store UNIX or Linux information is a key component of this guide. It is covered in detail in Chapter 5, "Planning Heterogeneous Security and Directory Solutions." This guide provides solutions based on the Active Directory schema and the Active Directory schema extended using Microsoft Services for UNIX. The tools and techniques covered in this guide enable you to use other schemas, including bespoke schemas and the schema described in RFC The RFC 2307 LDAP Schema The RFC 2307 schema is a relatively new schema that is currently at an experimental status. There is also an update to RFC 2307, called RFC 2307bis that is currently in development. Despite the current state of its development, it has been implemented in products from a variety of vendors, including PADL, Red Hat, Apple Computers, and most UNIX vendors. RFC 2307, "An Approach for Using LDAP as a Network Information Service," was authored by PADL to standardize a schema that contains the object classes and attributes necessary to replace NIS with LDAP. The RFC 2307 schema is intended for use in two common scenarios: As a direct replacement for NIS. UNIX and Linux clients access LDAP directly. This is the scenario implemented in PADL's LDAP modules. In NIS-to-LDAP gateways. UNIX and Linux clients still use the NIS protocol, but the NIS server stores its data in an LDAP directory. This scenario is implemented in NIS gateways from various vendors, including PADL. The same functionality is provided by Microsoft using Microsoft Server for NIS. The PADL modules covered in this guide can be configured to use most schemas even though the PADL modules use RFC 2307 internally. Therefore, the PADL modules can use both the default schemas provided with Active Directory and the extended schemas provided as a part of Microsoft Services for UNIX (SFU). The RFC 2307 schema is not covered by this guide because it remains experimental at the time of writing. 78

79 Microsoft Windows Directory Services The Windows Server 2003 operating system is comparatively new. Although based on the technologies found in Windows NT, significant changes and additions were introduced in Windows The most prominent of these additions is Microsoft Active Directory. Active Directory has been extended and improved in Windows Server Active Directory is an enterprise directory service based on open standards. Active Directory makes it possible for administrators to centralize all of an organization's information, including user, group, computer, printer, application, and file information. The directory can be structured to reflect the organization's structure, easing administration and allowing users to search efficiently for the information that they require. In Windows Server 2003, Active Directory is tightly integrated with the operating system and, in particular, the security subsystem. The tight integration of the directory service and security subsystem services is key to the implementation of Windows Server 2003 distributed systems. How Active Directory relates to the security subsystem is explained in the following sections, beginning with the Security Accounts Manager (SAM). The Security Accounts Manager The SAM is a protected subsystem that manages user and group account information. In Windows Server 2003, security accounts are stored by SAM in the local computer registry, and domain controller security accounts are stored in Active Directory. SAM provides functionality similar to that provided by the combination of PAM and NSS in UNIX and Linux systems. Using SAM in Mixed Mode and Native Mode Windows Server 2003 supports Win32 security APIs in both mixed mode and native mode. In mixed-mode domains, where Microsoft Windows NT 4.0-based backup domain controllers are still in use, SAM clients that run Microsoft Windows NT 4.0 communicate with the SAM server through SAM APIs, which are required for replication and for authentication against the SAM database. In native-mode domains, there are no Windows NT 4.0 domain controllers, but there can be clients that run Microsoft Windows 95, Microsoft Windows 98, Windows NT 3.x, or Windows NT 4.0. These clients continue to authenticate by using the same SAM APIs. SAM Client and Server Operations Most SAM operations are structured as reads and writes of properties. For workstation accounts, operations read from and write to the registry. Domain account operations are performed on Active Directory objects and their corresponding properties, which are stored as column values in the directory database. The SAM client calls public SAM routines that, in turn, call internal routines that encapsulate the RPC. On the server side, the internal SAM routines do the bulk of the work. 79

80 In Windows NT 4.0, all access to account information is accomplished through internal SAM routine calls to the accounts database that is stored in the registry. In Windows Server 2003, the SAM server effectively splits off the domain controller account information from the workstation account information and places it in Active Directory instead of in the registry. The SAM is implemented in the dynamic-link library (DLL) samsrv.dll. The logic in samsrv.dll manages the security principal database differently, depending on the role of the computer. On a domain controller, samsrv.dll uses Active Directory for security principal storage. On all other Windows Server 2003 computers, samsrv.dll uses the SAM database in the registry for storage. Gaining access to Windows Server 2003 domain controller account information is accomplished by routines that are implemented as part of the Directory System Agent (DSA) process on the server. These routines are called in-process on the server and offer the ability to search for, read, and write directory service objects. Figure 3.2 illustrates the interactions between the SAM client and server processes and the storage of domain and local accounts. Figure 3.2 depicts the logic applied by samsrv.dll to the domain controller case (Directory API), where the accounts are domain accounts, and to all other cases (Registry API), where the accounts are local to the computer. Figure 3.2 SAM client and server interactions and account storage Microsoft Active Directory A directory service consists of both a directory storage system (called the directory store) and a mechanism that is used to locate and retrieve information from the system. Active Directory stores objects that provide information about the things that exist in an organization's network and that are associated with one or more domains, such as users, specific groups of users, computers, applications, services, files, and distribution lists. It then makes this information available to users and applications throughout the organization. 80

81 Windows Server 2003 uses modules and modes that combine to provide operating system services to applications. Two processor access modes, kernel and user, divide the low-level, platform-specific processes from the upper-level processes, respectively, to shield applications from platform differences and to prevent direct access to system code and data by applications. Each application, including service applications, runs in a separate module in user mode, from which it requests system services through an API that gains limited access to system data. An application process begins in user mode and is transferred to kernel mode, where the actual service is provided in a protected environment. The process is then transferred back to user mode. The security subsystem in user mode is the module in which Active Directory runs. The security reference monitor, which runs in kernel mode, is the primary authority for enforcing the security rules of the security subsystem. Access to all directory objects first requires proof of identity (authentication), which is performed by components of the security subsystem, and then validation of access permissions (authorization), which is performed by the security subsystem in conjunction with the security reference monitor. The security reference monitor enforces the access control applied to Active Directory objects. Security Subsystem Architecture Windows Server 2003 includes a set of security components that make up the Windows security model. These components ensure that applications cannot gain access to resources without authentication and authorization. Components of the security subsystem run in the context of the Local Security Authority (LSA) lsass.exe process, and include the following: Local Security Authority Net Logon service Security Accounts Manager service LSA server service Secure Sockets Layer Kerberos 5 authentication protocol and Windows NT LAN-Manager (NTLM) authentication protocol The security subsystem keeps track of the security policies and the accounts that are in effect on the computer system. In the case of a domain controller, these policies and accounts are the ones that are in effect for the domain in which the domain controller is located. They are stored in Active Directory. The LSA is a protected subsystem that maintains the information about all aspects of local security on a system (collectively known as the local security policy) and provides various services for translation between names and identifiers. In general, the LSA performs the following functions: Manages local security policy. Provides interactive user authentication services. Generates tokens, which contain user and group information, as well as information about the security privileges for that user. After the initial logon process is complete, all users are identified by their Security Identifier (SID) and the associated access tokens. Manages the Audit policy and settings. When an audit alert is generated by the Security Reference Monitor, the LSA is charged with writing that alert to the appropriate system log. 81

82 The local security policy identifies the following: The domains that are trusted to authenticate logon attempts. Who can have access to the system and in what way (for example, interactively, over the network, or as a service). Who is assigned privileges. What security auditing is to be performed. Default memory quotas (paged and non-paged memory pool usage). Figure 3.3 shows a local perspective of Active Directory within the LSA security subsystem (lsass.exe). The LSA security subsystem provides services to both the kernel mode and the user mode for validating access to objects, checking user privileges, and generating audit messages. Figure 3.3 Active Directory within the Local Security Authority The LSA has the following components: netlogon.dll. This is the Net Logon service. Net Logon maintains the computer's secure channel to a domain controller. It passes the user's credentials through a secure channel to the domain controller and returns the domain security identifiers and user rights for the user. In Windows Server 2003, the Net Logon service uses DNS to resolve names to the IP addresses of domain controllers. Net Logon is the replication protocol for Windows NT Version 4.0 primary domain controllers and backup domain controllers. msv1_0.dll. This is the NTLM authentication protocol. This protocol authenticates clients that do not use Kerberos authentication. 82

83 schannel.dll. This is the Secure Sockets Layer (SSL) authentication protocol. This protocol provides authentication over an encrypted channel instead of a lesssecure clear channel. Note Guidance for using Active Directory schannel.dll is beyond the scope of this guide. kerberos.dll. This is the Kerberos 5 authentication protocol. kdcsvc.dll. This is the Kerberos Key Distribution Center (KDC) service, which is responsible for granting Ticket Granting Tickets (TGTs) to clients. lsasrv.dll. This is the LSA server service, which enforces security policies. samsrv.dll. This is SAM, which stores local security accounts, enforces locally stored policies, and supports APIs. ntdsa.dll. This is the directory service module, which supports the Windows Server 2003 replication protocol and LDAP and manages partitions of data. secur32.dll. This is the multiple authentication provider that holds all of the components together. Directory Service Architecture Active Directory functionality can be described as a layered architecture in which the layers represent the server processes that provide directory services to client applications. Active Directory consists of three service layers and several interfaces and protocols that work together to provide directory services. The three service layers accommodate the different types of information that are required to locate records in the directory database. Above the service layers in this architecture are the protocols and APIs (APIs are on the clients only) that enable communication between clients and directory services or, in the case of replication, between two directory services. Figure 3.4 shows the Active Directory service layers and their respective interfaces and protocols. The direction of the arrows indicates the manner in which the different clients gain access to Active Directory through the interfaces. LDAP and Messaging API (MAPI) clients gain access to the directory by calling functions, indicated by one-way arrows into the directory system agent. The SAM exists as separate dynamic-link library (samsrv.dll) and can call only entry points exported by the directory system agent DLL, ntdsa.dll. All other components except the extensible storage engine (esent.dll) are in ntdsa.dll itself and are linked to the functions that they want to call. Thus, a three-way interaction is required between the three DLLs. 83

84 Figure 3.4 Active Directory service layers and interface agents Clients obtain access to Active Directory by using one of the following mechanisms that are supported by Active Directory: LDAP/ADSI. Clients that support LDAP use LDAP to connect to the directory system agent. MAPI. Microsoft Outlook messaging and collaboration clients connect to the directory system agent by using the MAPI RPC Address Book provider interface. SAM. Windows clients that use Windows NT 4.0 or earlier use the SAM interface to connect to the directory system agent. Replication from backup domain controllers in a mixed-mode domain goes through the SAM interface as well. REPL. During directory replication (REPL), Active Directory directory system agents connect to each other by using a proprietary RPC interface. The key service components include the following: Directory system agent. This builds a hierarchy from the parent-child relationships stored in the directory, and it provides APIs for directory access calls. Database layer. This provides an abstraction layer between applications and the database. Calls from applications are never made directly to the database; they go through the database layer. Extensible storage engine. This communicates directly with individual records in the directory data store on the basis of the object's relative distinguished name attribute. Data store (the database file ntds.dit). This file is manipulated only by the extensible storage engine database engine. You can administer the file by using the ntdsutil command line tool. These service components are explained in more detail in the following sections. 84

85 Directory System Agent The DSA is the process that provides access to the store. The store is the physical store of directory information located on a hard disk. The DSA is the server-side process that creates an instance of a directory service. Clients use one of the supported interfaces to connect (bind) to the DSA and then search for, read, and write Active Directory objects and their attributes. The Active Directory namespace is partitioned so that individual domain controllers do not store the entire directory. Every DSA holds at least a single Windows Server 2003 directory partition that stores domain data for a domain (such as users, groups, and organizational units) plus two non-domain directory partitions that store forest-wide data, which includes the schema and configuration data. The DSA layer provides the following functionality: Object Identification. Every object in Active Directory has a permanent globally unique identifier (GUID) that is associated with several string forms of the object name (SAMAccountName, user principal name, distinguished name) as well as a security identifier. These object names and the security identifier are not permanent that is, they can be changed. All permanent references to the object are kept in terms of the GUID; the object name is used for hierarchy navigation and display purposes, and the security identifier is used for access control. The DSA maintains the GUID association with an object when the object's string name or security identifier changes. Schema Enforcement of Updates. In a multi-master system, a change to a schema object in one replica might conflict with existing objects in that replica and also with objects in other replicas. In Windows Server 2003, a schema change is a single-master operation, so if an update does not produce a conflict at the originating replica, the update is considered acceptable at all replicas. Thus, replicated updates do not perform any schema checks, and you do not have to wait until the schema replicates before creating instances of a new object or attribute. Access Control Enforcement. The DSA enforces security limitations in the directory. The DSA layer reads SIDs on the access token. Support for Replication. The DSA contains the hooks for replication notifications. All object updates ultimately must go through the appropriate function for the directory service to work properly. Referrals. The DSA manages the directory hierarchy information (referred to as "knowledge"), which it receives from the database layer. The DSA is responsible for cross-references of Active Directory domain objects up and down the hierarchy and also out to other domain hierarchies. Database Layer The database layer provides an object view of database information by applying schema semantics to database records, thereby isolating the upper layers of the directory service from the underlying database system. The database layer is an internal interface. No database access calls are made directly to the extensible storage engine; instead, all database access is routed through the database layer. The database layer in Active Directory uses the LDAP hierarchical naming model, referencing objects by their distinguished name or their relative distinguished name. Data is stored by the database layer in Active Directory using the standard LDAP information model. Details of the LDAP naming and information models can be found in Chapter 1, "Overview of Network Security and Directory Services." 85

86 Extensible Storage Engine Active Directory is implemented on top of an indexed sequential access method (ISAM) table manager. The Windows Server 2003 version of this database is esent.dll. Extensible Storage Engine (ESE) stores all Active Directory objects. It can support a database up to 16 terabytes in size, which can theoretically hold many millions of objects per domain. The following ESE characteristics make it well suited to the storage needs of Active Directory. The ESE: Is used by the information store in Exchange Server Supports indexing. Supports multivalue attributes. Supports update operations that are transacted for stability and integrity across system failures. Can be backed up while the domain controller is online. Handles sparse rows well that is, rows in which many of the properties do not have values. Active Directory comes with a default schema that defines all of the attributes that are required and allowed for a given object. ESE reserves storage only for the space that is used that is, only for the attributes that have values, not for all possible attributes. For example, if a user object already has 50 attributes defined in the schema and you create a user with values for only four attributes, storage space is allocated only for those four attributes. If more attributes are added later, more storage is allocated for them. esent.dll implements the search and retrieval functionality of the underlying database. Also, ESE is capable of storing attributes that can have multiple values. For example, the database can store multiple phone numbers for a single user without requiring a different phone number attribute for each phone number. Protocols and Interfaces to Active Directory The diagram of the Active Directory architecture (Figure 3.4) illustrates four avenues of entry to Active Directory: LDAP/ADSI, REPL, SAM, and MAPI. Each of these access routes uses a different set of protocols and APIs that enable communication with the directory service. Table 3.5 shows the APIs that Active Directory supports and that can be used by developers to integrate with Active Directory or use resources in Active Directory. 86

87 Table 3.5: Active Directory APIs API Name LDAP C API ADSI MAPI Windows NT 4.0 SAM Description As described in RFC 1823 for LDAPv3, LDAP API is a C language API to the LDAP network protocol. COM interface to Active Directory that abstracts the details of LDAP communications. ADSI provides services and Active Directory information to directory-aware applications. ADSI supports multiple programming languages, including Microsoft Visual Basic, C, and Microsoft Visual C++. ADSI also can be accessed by using Windows Script Host (WSH). Messaging API that is supported for compatibility with Microsoft Exchange Client and Outlook Address Book client applications. Windows NT 4.0 networking APIs (Net APIs) that are used by Windows NT 4.0 clients to gain access to Active Directory through SAM. APIs that communicate with the DSA APIs. These APIs communicate with Active Directory by using various access methods, as described in Table 3.6. Table 3.6: Active Directory Access Methods Access Method LDAP MAPI RPC Replication RPC Replication Simple Mail Transfer Protocol (SMTP) Description Core protocol that is supported by Active Directory, as described in RFC 2251 (LDAPv3) and RFC 1777 (LDAPv2). RPC interfaces used by MAPI Address Book provider. RPC interfaces used by Active Directory replication over IP transport for replication within sites and between sites. Replication protocol used by Active Directory replication over IP transport for message-based replication between sites only. The last two protocols in Table 3.6. are used for Active Directory replication, which is explained in the next section. Active Directory Replication Active Directory replication is performed over replication transport protocols, which are represented in the Active Directory architecture diagram (Figure 3.4) as REPL. For replication within a site, Active Directory replication uses RPC-over-IP transport protocols. For replication between sites, Active Directory replication uses two replication transport protocols: IP (RPC over IP) and SMTP (SMTP over IP). Note The user interface that is associated with connection properties in Active Directory Sites and Services displays RPC for all connections within a site, and it displays either IP (for RPC over IP) or SMTP (for SMTP over IP) for connections between sites. This convention is used to distinguish between RPC over IP for connections that are between sites and those that are within a site. 87

88 RPC replication between sites can be scheduled and is compressed. For replication within a site, RPC is always used. RPC replication within a site is not compressed. Thus, Windows Server 2003 directory replication recognizes three degrees of connectivity: Uniform, high-speed connectivity (RPC over IP for replication of all directory partitions within a site) Point-to-point, synchronous, low-speed connectivity (RPC over IP for replication of all directory partitions between sites) Mail-only, asynchronous connectivity (SMTP over IP for replication of only nondomain directory partitions between sites) On each DSA, replication uses a single thread to receive changes from other servers and applies them locally by using either RPC synchronous transport or asynchronous transport for messaging between sites. The choice of transport is determined by the corresponding connection object (class ntdsconnection). Connection objects are created automatically by the Knowledge Consistency Checker (KCC). You can also create connection objects manually by using Active Directory Sites and Services. Both synchronous and asynchronous transports operate on a request-response basis. Active Directory Data Storage Active Directory stores data for an entire forest. "Directory" and "forest" can be considered synonymous. Although there is a single directory, data storage is distributed among one or more domains, while consistent data is maintained throughout the forest that applies to all domains. Active Directory is partitioned and replicated. So that it can support tens of millions of objects, Active Directory is partitioned into logical segments. To provide support for hundreds of thousands of clients and to provide availability, each logical partition replicates its changes separately among those domain controllers in the forest that store copies (replicas) of the same directory partitions. Some directory partitions store forest-wide configuration information and schema information; other directory partitions store information that is specific to individual domains, such as users, groups, and organizational units. The directory partitions that store domain information are replicated to domain controllers in that domain only. The directory partitions that store configuration and schema information are replicated to domain controllers in all domains. In this way, Active Directory provides a data repository that is logically centralized but physically distributed. Because all domain controllers store forest-wide configuration and schema information, a domain controller in one domain can reference a domain controller in any other domain if the information that it is requesting is not stored locally. In addition, domain controllers that are global catalog servers store a full replica of one domain directory partition plus a partial replica of every other domain in the forest. Thus, a domain controller that is a global catalog server can be queried to find any object in the forest. Note There is a distinction between a directory partition and a database partition. The Active Directory database is not partitioned. Only the directory tree, which is the logical representation of the data held by a domain controller, is partitioned. 88

89 The distribution of Active Directory data in the directory tree can be summarized as follows: Domain-wide Data Domain-specific data is stored in a domain directory partition. A full, writable replica of the domain directory partition is replicated to every domain controller in the domain, including any global catalog servers in the domain. Forest-wide Data Forest-wide data is stored in two directory partitions the configuration directory partition and the schema directory partition. The Configuration container is the topmost object of the configuration directory partition; the Schema container is the topmost object of the schema directory partition. Full, writable replicas of the configuration directory partition and the schema directory partition are replicated to every domain controller in the forest. In addition to a full, writable replica of a single domain (the domain for which the domain controller is authoritative), partial, read-only replicas of every other domain directory partition in the forest are stored on domain controllers that are designated as global catalog servers. The read-only replicas in the global catalog are "partial" because they store only some of the attributes for each object. Note When Active Directory is first installed on a computer that is running Windows Server 2003, the entire full replicas or partial replicas are replicated to create the directory. Thereafter, only changes to directory objects (attribute changes and the creation and deletion of objects) are replicated. 89

90 Data Characteristics The key characteristics of the data that is stored by a directory service correspond to size and latency. Active Directory should store objects that are not so large that they hamper replication and not so unstable that they change before an update replicates to all replicas in the forest. In general, Active Directory is appropriate for the storage of data that has the following characteristics: The data is globally useful information in the domain that needs to be replicated to each Active Directory domain controller. The data has well-defined object attributes and semantics. The data has a useful life that is at least two times the maximum replication latency for the forest (to include replication of data that is marked to replicate to the global catalog). In general, if data can become outdated before the completion of a replication cycle or shortly thereafter, it should not be stored in Active Directory. Clients should be capable of tolerating the inability to update data for at least as long as it takes for the data to be replicated throughout the domain. The data-per-attribute value is not so large that it affects performance. An attribute value is replicated as a single block of data; therefore, an attribute that is x megabytes in size requires an equivalent amount of buffer space in the sending and in the receiving domain controllers. If the amount of required buffer space is large, the performance of the domain controller can be adversely affected. As a result of these characteristics, large, unstructured data sets and data values that change frequently are not appropriate for storage in Active Directory. 90

91 Windows Server 2003 LDAP Implementation The Windows Server 2003 implementation of LDAP is an essential component of Active Directory because it defines: Network connectivity Naming model Information model APIs In all of these, Active Directory adheres to the LDAP standard. This section looks at the specifics of the LDAP implementation within Active Directory. The LDAP implementation present within Active Directory is based on the standards described in RFC 2251 (which defines LDAPv3) and RFC 1777 (which defines LDAPv2). Windows 2000 clients, as well as Windows 98 and Windows 95 clients that have the Active Directory client components installed, use LDAPv3 to connect to the directory system agent. The LDAP Protocol in Active Directory LDAP is a directory service protocol that specifies directory communications. It runs directly over TCP/IP and can also run over User Datagram Protocol (UDP) connectionless transports. LDAP enables clients to query, create, update, and delete information stored in a directory service over a TCP connection through the TCP default port 389. In Active Directory, LDAP is the only network protocol used to access the directory. Note Windows Server 2003 Active Directory does not implement the X.500 protocols (which include Directory Access Protocol [DAP], Directory System Protocol [DSP], Directory Information Shadowing Protocol [DISP], and Directory Operational Binding Management Protocol [DOP]). LDAP provides the most important functions offered by DAP, and it is designed to work over TCP/IP without the overhead of "enveloping" OSI protocols over TCP/IP. The LDAP Directory Service and Information Model in Active Directory The Active Directory LDAP directory service is based on a client/server model. One or more LDAP servers contain the data making up the directory tree. An LDAP client connects to an LDAP server and requests information or performs an operation. The server performs the operation or provides the information, or it refers the client to another LDAP server that might be capable of doing so. When connecting to a specific LDAP directory tree, it does not matter what LDAP server a client connects to; a name presented to one LDAP server references the same object (referred to as an entry in LDAP) that it would reference at another LDAP server. This is an important feature of a global directory service. The LDAP information model is based on the entry, which contains information about some object (for example, a person or computer). In Active Directory, an LDAP entry is referred to as an object. Entries are composed of attributes, which have a type and one or more values. Each attribute has a syntax that determines what kinds of values are allowed in the attribute. 91

92 For more information about LDAP, see the sections "Pertinent RFCs" and "The Lightweight Directory Access Protocol" in Chapter 1, "Overview of Network Security and Directory Services." The Active Directory Schema The Active Directory schema contains formal definitions of every object class that can be created in an Active Directory forest. The schema also contains formal definitions of every attribute that can exist in an Active Directory object. In addition to the default schemas provided with Windows Server 2003, Active Directory also allows you to extend the schema, either using standard-based schemas not included in Active Directory or your own bespoke schemas. This guide mainly concentrates on using Active Directory to store user account data and user authentication data; therefore, it is important to consider the schemas that are used to store user account data in Active Directory. In the "LDAP as an Identity Store" section of this chapter, object classes used to store user account information are introduced. These classes include inetorgperson, which is derived from organizationalperson, which is itself derived from person. Active Directory differs from this structure because user account information is stored in objects of the class user, which is derived from the object class organizationalperson. Microsoft created the user class to enable them to store the attributes required by a user in a Active Directory domain. The user class extends the organizationalperson class with many additional attributes; these attributes are defined in two auxiliary classes: securityprincipal and mailrecipient. The auxiliary class securityprincipal contains security information about the user, such as the user's SID. The auxiliary class mailrecipient contains information relating to the user's account; these attributes are most commonly used by Microsoft Exchange Server. The inetorgperson Class in Windows Server 2003 Active Directory In Windows Server 2003, the inetorgperson object class was added to the schema used in Windows 2000 Active Directory. The inetorgperson class is defined by RFC It is used to store information in the directory that is relevant to user accounts; this is similar to the user class in Active Directory. The inetorgperson class is important because it is widely used by other vendors. For example, many companies that use iplanet or edirectory as an e-commerce or enterprise directory have built or purchased applications that depend on the existence of the inetorgperson class. The vendors that build these applications would like to integrate them with Active Directory with the smallest amount of modifications to their applications. Additionally, enterprises that have been using other directories and would like to migrate to Active Directory want to be able to move their current set of inetorgperson objects to Active Directory with the smallest amount of difficulty. The implementation of inetorgperson in Active Directory differs from RFC 2798 in the following ways: The inetorgperson class is derived from the user class instead of the organizationalperson class. Attributes that have already been defined in the base schema for Active Directory are not changed. There are two mandatory attributes that are inherited by the inetorgperson class. They are the cn and samaccountname attributes. The objectcategory for inetorgperson is set to person. 92

93 Microsoft took a number of important steps to ensure that inetorgperson attributes are integrated with user attributes. Of particular note is the integration of password management. There are two different fields to store passwords in the two schemas: unicodepwd and userpassword. The unicodepwd stores a one-way format of the password that makes it is extremely difficult to determine the original password. unicodepwd is the attribute used by Windows 2000 and Windows Server 2003 to store user passwords. The inetorgperson attribute used to store passwords is userpassword. In an attempt to ensure that the two password fields are kept synchronized, updating the userpassword attribute over a secure connection will also update the unicodepwd attribute. Storing User Attributes Using the Services for UNIX Schema in Active Directory The SFU schema also contains user attributes, but in this case the user attributes contain UNIX-style account information. The SFU schema extends the standard Active Directory user class to enable it to store UNIX account information. Additionally, SFU extends Active Directory management tools and integrates features, such as password management, to include UNIX attributes. Note Further information about the Active Directory schemas for Windows 2000, Windows Server 2003, and Active Directory Application Mode (ADAM) can be found at active_directory_schema_site.asp. The LDAP API in Active Directory Unlike most other Internet protocols, the LDAP protocol has an associated API that simplifies writing Internet directory service applications. The LDAP API is a C language API to the LDAP protocol. RFC 1823 specifies the LDAP APIs that are required for a client to gain access to a directory service that supports the LDAP protocol. This API set is relatively simple and supports both synchronous and asynchronous calls to the server. Microsoft implements the LDAP API in wldap32.dll also referred to as "LDAP C" or "C-binding LDAP." Applications that are written using the LDAP API are compatible only with LDAP directory services. ADSI, which provides a COM interface to Active Directory, is layered on top of LDAP and provides the easiest access to Active Directory through LDAP. However, Active Directory also fully supports the LDAP APIs for directory access. Note For more information about the LDAP API and about programming in LDAP, see the About LDAP, Using LDAP and LDAP Reference links on the Platform SDK, Lightweight Directory Access Protocol page at using_the_ldap_api_in_a_client_application.asp. Active Directory Service Interfaces The primary and recommended API for Active Directory is ADSI. ADSI enables access to Active Directory by exposing objects stored in the directory as COM objects. A directory object is manipulated using the methods on one or more COM interfaces. ADSI providers contain the implementation of ADSI objects for a particular namespace. By implementing the required interfaces, ADSI providers translate these interfaces to the API calls of a particular directory service. 93

94 ADSI LDAP Provider The ADSI LDAP provider operates on the ADSI client to provide access to Active Directory or to other LDAP directory services. The ADSI LDAP provider works with any LDAP server that supports at least LDAPv2. In addition to Windows Server 2003 Active Directory, directory services that are accessible through the LDAP provider include the following: Netscape Directory Server Microsoft Exchange Server 2000 Microsoft Commercial Internet System (MCIS) Address Book Server University of Michigan Stand-alone LDAP Directory (SLAPD) Server Other Internet directory servers (for example, ldap.yahoo.com) Note The WinNT ADSI provider enables access to Windows NT 4.0 directories, providing for communication with Windows NT 4.0 primary domain controllers and backup domain controllers. Other providers include NDS for access to Novell Directory Services directories, NWCOMPAT for access to Novell NetWare 3.x and Novell NetWare 4.x directories, and Microsoft Internet Information Services (IIS) for access to HTTP data directories used by IIS. 94

95 Common Uses of Directory Services Directory services can be used to store operating system information. This chapter has looked at using LDAP to store operating system information for UNIX, Linux, and Windows Server LDAP can also be used as a directory service for applications. This section looks at some common uses of LDAP as a directory service beyond its use in system management. Host Name Lookup In the section, "The Domain Name System," earlier in this chapter, the importance of host name lookup as a network service is emphasised. Almost all network services and applications require the resolution of network names to IP addresses and vice versa. The standard directory service for the resolution of network names is DNS and, as such, it is the most widely used network directory service. DNS is a specialized directory service, and it is particularly efficient and effective at providing that service. LDAP directories can be used to store and resolve host names instead of DNS, but because LDAP is a generic directory service, it is not as effective at this task as DNS. Additionally, it is unlikely that DNS will ever be replaced by LDAP for this task. However, the host and network address data stored within DNS has uses beyond those possible with DNS, and it would be helpful if it was stored in LDAP. One method of making the host information in DNS more widely available is to place the DNS Resource Records (RRs) within a LDAP directory. In this scenario, the DNS server uses LDAP as its data store. Because the data store is LDAP, it is possible to add attributes to the host information stored there and utilize this information for other purposes. One potential use of this data is for printer management. A printer host entity within an LDAP directory could have attributes to store the resource record data required by DNS, and attributes to store printer settings and capabilities. The Microsoft DNS server in Windows Server 2003 supports placing DNS resource records in Active Directory instead of in zone files. A significant benefit of placing RRs in Active Directory is that the zone data is automatically replicated over all Active Directory domain controllers. The Microsoft DNS server utilizes this for load-balancing and to enable each domain controller to act as part of a DNS multiple-master configuration. In standard DNS configurations, one DNS server acts as the master. The master DNS server is the only server where modifications to the zone data can take place, including modifications resulting from Dynamic DNS updates. Copies of changes to the master zone files are made to slave (or secondary) DNS servers using a process called a zone transfer (or through incremental zone transfers). In a multiple-master configuration, updates to the zone data can occur on any DNS server. This is a significant advantage gained by using Microsoft DNS, particularly as Dynamic DNS updates are an important part of Active Directory. Application Stores Many current applications are capable of using LDAP as a directory store. These applications include Web servers, ERP systems, and systems. systems are probably the single largest users of LDAP directories. LDAP directories are ideal for storing address books and configuring settings. Both clients, such as Message User Agents (MUAs), and servers, such as Message Transfer Agents (MTAs), can make use of LDAP. The majority of clients and servers include LDAP integration. 95

96 servers that support the use of LDAP for configuration include: Microsoft Exchange Server Sendmail Postfix Exim clients that support the use of LDAP include: Microsoft Exchange Client Microsoft Outlook Eudora Pine Evolution Mozzila Mail Netscape Communicator Many other LDAP-enabled applications could be cited. Those listed previously serve to illustrate the potential that exists for consolidating enterprise data into Active Directory, thereby enabling you to benefit from the comprehensive security and management features of Active Directory and from the significant benefits of a single repository for enterprise data. Note For more information about how Microsoft Exchange Server 2000 uses Active Directory as a directory for configuration and user information, see the Microsoft online book Understanding and Troubleshooting Directory Access at b7a6-9d8446ef6409&displaylang=en. 96

97 Summary In this chapter, the concepts of directory stores and Active Directory have been expanded to build upon the initial foundations that were laid out in Chapter 1, "Overview of Network Security and Directory Services." The summaries of the directory services that are currently available on UNIX and Linux include the features available from each of the solutions, along with each of their strengths and weaknesses. With the advent of Windows 2000, Microsoft entered into the directory services arena. Windows 2000 included Active Directory, which is a directory service based around the LDAP protocol. Active Directory has been discussed in depth, showing much of its internal workings and its relationship to the LDAP protocol that it is derived from. Active Directory is fully LDAP-compliant. The concepts presented in this chapter are expanded upon in later chapters. These chapters also show how the technologies present in Active Directory can be used to create a heterogeneous directory solution. 97

98

99 Part 1: Plan 99

100

101 4 Envisioning Heterogeneous Security and Directory Solutions Introduction and Goals This chapter provides the background and technical information required to complete the first phase of a heterogeneous security and directory solution project. The approach used in this chapter (and subsequent chapters) is based on Microsoft Solutions Framework (MSF) and on the MSF Process Model. The MSF Process Model contains specific phases and milestones that produce fast, high-quality results through a proven project life cycle using a key set of project activities and deliverables. Accordingly, this chapter and subsequent chapters show the specific deliverables that the project team must create and the activities it needs to undertake according to the phase at hand. Milestones pertaining to each sequential phase are also presented, which serve as review and synchronization points for determining whether the objectives of the phase have been met. Projects are formally launched in the Envisioning Phase, which represents an early form of planning. During this phase, the overarching goal is to create and agree upon a highlevel view of the project's goals, constraints, and solution. The parties who must reach this agreement are the project team, the customer, and key stakeholders. The work of achieving this goal can be divided into the following list of discrete tasks that are discussed in this chapter: Set up a team Define the project structure Define the business goals Assess the current situation Create the vision and define the scope for the project Define high-level requirements and user profiles Develop the solution concept Assess risk 101

102 Although IT projects can originate from either the IT organization or the business it serves, the impetus for a heterogeneous security and directory services project is likely to come from the business. Business needs such as productivity improvements, cost cutting, or risk management are frequently the drivers. The work of the Envisioning Phase is heavily focused on understanding business needs and ensuring that the solution will meet them. Regardless of origin, the project begins when management appoints a Program Manager (PM) to manage the project. One of the PM's primary responsibilities during this phase is to create and organize a core project team. The phase may be well under way before all members are fully engaged because the early planning activities that occur in Envisioning require heavier involvement from some roles than others. The PM also defines how the team will work together by establishing standards for administrative procedures, such as communication, documentation, and version control, in a project structure document during this phase. The Program Manager and members of the team who have been assigned begin the work of creating a solution by defining the business opportunity or problem that it must address. They also assess the current state of the business with respect to the problem to determine what is feasible and how much work will be required to solve the problem. The team then crafts a vision statement, which describes the desired future state of the customer's environment. Alternatively, the vision statement may be handed down by the business and, in this case, it is negotiated as needed. The team then documents it, along with project constraints, in a vision/scope document. Note The "customer" is the individual or individuals who expect to gain business value from the solution, and is also known as the business sponsor. The Chief Finance Officer, representing the corporation, might be the customer for a solution to be implemented by a project team within the IT organization. The next logical step is to interpret the vision statement in more concrete terms by gathering the high-level business requirements and user requirements (which are determined by the various roles within the organization that will use the solution) that the solution must satisfy. The team is then ready to build a solution concept that describes at a high level how the solution will solve the business problem in terms of the approaches it will take to build and deliver the solution. It documents business and design goals, functionality, assumptions, and constraints. It also defines the success criteria for the project, which helps the team establish the scope the parts of the vision that will be accomplished in the current effort. Both the solution concept and the scope are incorporated into the vision/scope document. A final task of this phase, driven by Program Management but participated in by the entire team, is to make an initial assessment of project risks and document them in a risk assessment document, which identifies and qualifies the various risks that the project faces. 102

103 The Envisioning Phase ends with a milestone, Vision/Scope Approved. To meet the milestone, the customer (business sponsor), the major stakeholders, and the project team members must accept the vision/scope document (usually in a formal meeting) as a statement of the proposed solution and how it will address the business problems. Meeting the milestone also signifies that a project team has been established and risks have been assessed. At the end of this phase, the business decision makers and IT department should have a clear idea of the goals for the project and the project team can begin to make specific plans for how to achieve the goals. It should be understood that the decisions that are made during this phase may need to be revised as a result of the much more extensive investigation and analysis that will be done during Planning. However, any changes in the decisions will need to be approved by the approvers of the initial vision/scope. Table 4.1 summarizes the progression of the Envisioning Phase and its key tasks. The owners of each task are defined according to the MSF team roles. The table also includes further details of these roles in relation to a distributed security or directory solution. Table 4.1: Major Tasks and Owners During the Envisioning Stage Major Tasks Setting up a team Senior management determines that a project is viable and selects a program manager whose first task is to assemble a project team that represents all six MSF team roles. Defining the project structure The team creates the project structure, which describes the administrative structure for the project team going into the Planning Phase. It includes standards the team will use to manage and support the project. Defining the business goals The team identifies the business problems or opportunities to determine the objectives for the solution. Assessing the current situation The team assesses the current state of the business and performs a gap analysis to help identify a path toward the desired state of the business. Creating the vision and defining the scope for the project The team creates a shared and clearly articulated vision statement that guides a team toward its business goals. The team also identifies the scope of the project by defining what will and will not be included. Defining high-level requirements and user profiles The team determines the needs of each key stakeholder, sponsor, and end user to provide input to forming the solution concept, provide criteria for evaluating the vision/scope, and evolve into more detailed requirements in the Planning Phase. Developing the solution concept The team transforms the high-level requirements into an initial concept of how the solution will solve the business problem. The solution concept serves as a baseline and sets the stage Owners Product Management Program Management Program Management Product Management Program Management Product Management Program Management Product Management User Experience Program Management 103

104 Major Tasks for the more formal design of the solution. Assessing risk The team proactively identifies project risks and creates plans to deal with them. It continues this recurring process throughout the project. Closing the Envisioning Phase The team completes the approval process for the Vision/Scope Approved Milestone by formalizing the documentation that records the results of its tasks and presenting it to management for approval. Owners Program Management Project team Prerequisites Before creating the vision/scope document and other deliverables of the Envisioning Phase, you should ideally read this entire guide. At a minimum, you should have an understanding of the security and directory technologies used in this guide before undertaking the Envisioning Phase. For less technical roles such as the Program Management Role, User Experience Role, and Product Management Role, reviewing the material on Kerberos and LDAP in the preceding chapters will provide you with the minimum knowledge necessary: Chapter 2, "Authentication and Authorization in UNIX and Windows Environments" Chapter 3, "Active Directory and LDAP as Identity Stores in UNIX and Windows Environments" For more technical roles, such as the Development Role and the Test Role, reviewing the highly technical information contained in Chapters 6 through 9 in addition to Chapters 2 and 3 will provide you with information that will help you better understand the implications of the decisions you help make during the Envisioning Phase. 104

105 Set Up a Team The team you create should include the six team roles you are familiar with from the MSF Team Model, which emphasizes the importance of aligning roles to areas of responsibility that are defined in terms of meeting the major success criteria for an IT project as well as functionally. Remember that each role does not necessarily match to a single person: for a small project, one person may take two or more roles; a large project will include several people cooperating on a single role. Review the UNIX Migration Project Guide for further information on the goals, functional areas, and responsibilities associated with each role. The team structure should be documented in the project structure document. Expertise in UNIX, Linux, and Windows are clearly essential for this project, and this applies not only to the technical roles, such as Development, but also to the User Experience Role, which must collect insights from end users into everyday problems and feedback on potential solutions. If you are proposing, for example, an integrated directory system to replace separate Windows and Linux LDAP systems, the User Experience Role must learn from the users the difficulties they face with the existing systems. You may, with this information, be able to avoid the same difficulties on the new system, and thus improve productivity. Often, an expert in Windows knows little about UNIX or Linux, and vice versa. Therefore, your team may necessarily be larger than usual so that both perspectives are represented. Without this combined knowledge, the team might suggest a solution that misses the opportunity to correct an important business problem, or they might approach the solution in a way that is technically unfeasible. The following sections discuss each MSF role, identifying the principal goal around which it is organized and the skills required for it in a distributed security or directory solution project. Product Management Role This role's responsibilities include developing the business case for the solution, marketing it to the customer and end users, acting as an advocate for them to the rest of the project team, and enforcing the project structure. The principal goal for this role is to satisfy the customer. Many of the skills required for this role are general to any project; for example, the ability to communicate clearly and in non-technical language. However, to develop the business case and to manage customer expectations accurately, the role requires a high-level knowledge of UNIX, Linux, and Windows and of the technical problems associated with the current situation. It will not be necessary for the Product Management Role to possess highly technical skills in Windows, UNIX, or Linux, but a familiarity with using each system, particularly the problems associated with using them, is needed. The difficulties of using two or more independent user accounts, for example, with passwords that may diverge, can best be appreciated by experience. The Product Management Role should also consider the difficulties in the administration of UNIX, Linux, and Windows when they are not well integrated. The Product Management Role will need to communicate with administrators closely to gain insight into the problems of administering such a network. This knowledge of user and administrative problems, and how they can be solved by the proposed project, will enable the Product Management Role to accurately advocate the customer's needs to the rest of the project team. The role will also be able to market the solution to the customer by clearly communicating the improvements that will be made. 105

106 Program Management Role The goal of the Program Management Role is to deliver the solution within project constraints. Clearly, time is a major constraint on any project, and so this role ensures that delivery times are estimated accurately and work proceeds as quickly as possible to meet those times. However, another constraint is quality; it is the responsibility of the Program Management Role to balance the conflicting pressures of delivering a highquality solution in as short a time as possible. Also included in this role are the management of the project specification, which describes exactly what issues this project addresses and how they are corrected; and the project structure, which describes standards for communication, documentation, and version control. The Program Management Role has four functional areas within the Team Model. These are described in the following list in relation to an integrated security and directory migration project: Project management This involves moving the project forward as fast as possible. First, a project schedule should be created, setting out the project milestones and realistic times for delivery. Program Management should track progress closely throughout the project to ensure these are met. A key aspect to project management is the avoidance of bottlenecks. Suppose, for example, that Windows developers are creating an Active Directory LDAP server for Linux clients to use in lookups. The Linux developers may be unable to begin their development or configuration tasks until the LDAP servers are in place, resulting in efficient project management. See Figure 4.1 for an illustration of this. Figure 4.1 An example of inefficient project management 106

107 Such bottlenecks must be identified and discussed in the Planning Phase of the project. If they are identified early, Program Management can direct extra resources to their resolution and minimize delays. Solution architecture The Program Management Role takes charge of the overall design of the project. This includes the selection of appropriate technologies and products, the description of their configuration, and the specifications of any custom code that must be developed. The identification of dependencies is important. For example, the Kerberos solutions described in this guide assume adherence to the Kerberos 5 standards. If one of your components implements only Kerberos 4, it will need to be upgraded before proceeding. Process assurance The quality of the finished solution will be assured if all team members adhere to the agreed project structure document. It is the responsibility of the Program Management Role to monitor the progress of work and ensure that divergences from this structure are corrected. Frequently, for example, the Development Role team members are separated into those with Windows backgrounds and those with UNIX and Linux. It is easy for communication to fail between these two groups and to diverge from the standards laid out in the project structure. Program Management should spot this if it arises and ensure that the Development team is acting as a single team, regardless of background. Administrative services It is the task of the Program Management Role to report on the project's progress to team members, particularly Product Management, who can communicate it to the customer. Project administration also includes the maintenance of the project schedule. This will change frequently as targets are delivered early or late. Time estimates are also revised in the light of knowledge gained in the early stages of the project. The Program Management Role clearly requires a deeper knowledge of UNIX, Linux, and Windows than Product Management but, again, detailed expertise, such as the syntax of UNIX commands, is unnecessary. Development Role The Development Role builds the solution to the project specifications. This is where the deepest technical knowledge of UNIX, Linux, and Windows resides in the project team. In addition, the Development Role provides technical consultancy services to the rest of the team, for example, by ruling out solution architectures that are impossible to build or accurately estimating the time required to complete a task. The Development Role is commonly filled by more than one person for two principal reasons: it is unlikely that a single individual will possess the depth of technical knowledge that is required in disparate areas, and the sheer volume of work is likely to be too much for one person. The role is thus frequently referred to as the Development team in this guide. 107

108 The functional areas of the Development Role are as follows: Technology consulting Because the Development Role possesses the most detailed technical knowledge, all other roles approach these team members for information when their own knowledge is insufficient. In an integration project such as this, members of the Development Role will also provide consultation skills to each other. For example, when comparing LDAP directory implementations, Windows developers will help UNIX and Linux developers to understand the features of the implementation and schema that are specific to Active Directory. Implementation architecture and design The Development Role designs the solution at the most detailed level, providing the specifications of individual features and components and specifying their configuration. Application development This includes developing the documentation that describes how a chosen technology should be installed and configured. How, for example, should Active Directory servers be configured to support Kerberos authentication from a Linux workstation? Many projects involve the development of custom code, such as UNIX shell or Windows Script Host (WSH) scripts, as well as compiled code, such as C++ or Microsoft Visual Basic. The project may also involve the modification of directory schema, either within Active Directory, OpenLDAP, or another directory system. Infrastructure development The Development Role is also responsible for the design and implementation of a supporting infrastructure. The most pertinent in this case is DNS because Kerberos and LDAP clients rely on it to locate servers. Test Role The Test Role's primary goal is to approve the solution for release only after all quality issues are identified and addressed. These team members are responsible for verifying that the solution works. It is worth remembering that although, in a small project team, two MSF roles can be taken by a single person; you should never combine the Development and Test Roles. This is because the Test Role must provide a clear statement of the success of each component, unbiased by the effort that Development may have expended on it. 108

109 The following functional areas define the Test Role: Test planning After all components and functions of the solution have been defined, a comprehensive test plan must be devised. If the solution is to provide two-way authorization between UNIX and Windows, then it is insufficient to test access to UNIX file resources from Windows. You should test access to Windows resources as well. Test engineering This includes the creation of a realistic test environment and conducting the tests themselves. There will be several rounds of testing; after each, improvements and bug fixes must themselves be tested. Test reporting After each testing cycle, a detailed report of successes and failures must be circulated to every member of the project team. A good level of technical knowledge, roughly equivalent to that of the Development Role, is required for testing. If, by way of example, the Test Role has little expertise in UNIX security, a solution may appear successful to them even though it allows Windows users to impersonate other UNIX accounts and thus gain access to sensitive information. User Experience Role The goal of this role is to enhance user effectiveness. Advocating the interests of the end users tends to result in a solution that is convenient, requires less training, and is focused on productivity. Although deep technical knowledge is not required for this role, the persons who fill it must be able to understand and articulate the needs of users from each of the UNIX, Linux, and Windows environments. Of particular importance to this role in this project is minimizing the difficulties users may experience when working in a heterogeneous environment. For example, the UNIX, Linux, and Windows graphical user interfaces contrast strongly indeed some UNIX systems do not include them and use command line shells. Also, subtle differences exist between command line tools for managing Kerberos tickets on Windows, Linux, and UNIX clients. Early in the project, the User Experience Role is responsible for gathering, analyzing, and prioritizing user requirements and developing usage scenarios. In later phases, this role is responsible for evaluating the need for training in the project, and for ensuring that relevant, targeted training is provided so that all users have the necessary experience in both environments. 109

110 Release Management Role The members of the Release Management Role aim to achieve smooth deployment and to provide transition to successful ongoing operations. During the Envisioning and Planning stages the Release Management Role serves as an advocate for operations and support services, such as the help desk and technical support. While development and testing of the solution are occurring, this role ensures that the solution includes efficient deployment mechanisms. Release Management is in charge of deploying the solution in the final stages of the project. If your integrated directory and security solution involves users in UNIX, Linux, and Windows environments, your help desk staff must be skilled in all three, so Release Management must ensure that the project includes sufficient training to guarantee these skills. Interim Milestone: Core Team Organized At this milestone, you have initiated the project and taken the first steps by organizing the team. All the team members are now clear about their roles and can take responsibility for decision making within their expertise. The team now proceeds to investigate the project to gain a thorough understanding of its aims and scope. 110

111 Define the Project Structure Envisioning the project includes the creation of the project structure document, which defines standards for communication, documentation, and version control. This document has been fully described in the UNIX Migration Project Guide (UMPG), and it is not discussed in detail in this guide. The standards you have used in previous projects may be suitable for this project, but they should still be documented again as part of the Envisioning Phase. Define the Business Goals A project's business goals are of two types: those that address a problem and those that take advantage of an opportunity. To focus the team's energy and clarify the project scope, these goals must be clearly defined as part of envisioning the project. If you are interested in creating a heterogeneous security solution for UNIX, Linux, and Windows, the problems you want to address might include: The proliferation of user accounts for each user in your organization. In a mixed UNIX, Linux, and Windows environment, users frequently require a separate account to access each operating system. This makes it harder for users to remember their credentials, and they may lose track of their passwords for each system. The authentication of users across the boundaries of the two environments. How, for example, can a Windows user be successfully and securely identified should he or she attempt to access a UNIX or Linux file server? The authorization of users across the boundaries of the two environments. Assuming that the user in the previous example has been identified, how is the UNIX or Linux system to determine the file resources that user should be allowed to access? If you are interested in creating a heterogeneous directory solution for UNIX, Linux, and Windows, the problems you want to address may include: The proliferation of data about users. Your organization may, for example, store postal addresses for employees in systems, human resources databases, contact management systems, and other locations within UNIX, Linux, and Windows environments. Should a user change his or her address, these systems must all be updated. Access to data about users. A human resources database may only be accessible with proprietary client software installed. If this client runs only on Windows, UNIX and Linux users are denied access. The preceding lists are not exhaustive and you may find other issues within your organization that could be solved by integrating security or directory systems across operating systems. You must investigate and understand your own organization thoroughly to make such an assessment. 111

112 Some common business goals that can be addressed with an integrated security and directory solution are described in the following list, each with examples showing how the business need is addressed: Increasing the productivity of users In a business with a mixed Windows, UNIX, and Linux IT environment, a major barrier to the productivity of users is the proliferation of user accounts. Each user may need two, three, or more accounts to gain access to the full range of services because they are spread across the operating systems. Suppose, when the Windows password expires, a user replaces it, but does not log on to Linux or UNIX workstations for several days. The user may neglect to make the same password change there. As this situation continues, the user might frequently lose track of several passwords. If the user has forgotten the UNIX password, he or she may be discouraged from performing UNIX tasks and put them off, even though they are business-critical. When the user finally resolves to access UNIX, the account may become locked out or the user may have to wait for an administrator to reset the password. The creation of an integrated security solution, as described in this guide, allows the "single sign on" principle to be achieved. Here, a single account is sufficient to gain access to UNIX, Linux, and Windows. There is, consequently, only one password for the user to remember, and changes to this are rapidly applied to authentication requests from all the operating systems. Users will waste less time and productivity increases. Reducing the cost of administration The discussion up to this point implies that the help desk and administration staff will spend less time resetting forgotten passwords after a single sign on system has been implemented. By integrating two systems into one, you have halved the number of administrative tasks. For example, where tasks used to include "Creating a Windows account" and "Creating a Linux account," there will be only "Creating an integrated account." Of course, the new system is larger than either of the previous two, so the volume of work will not necessarily be halved, but a significant reduction in administrative load should be evident. To continue the example, the integrated system will include both accounts for Windows and those for Linux users, and therefore be larger than either of the two original systems. However, where a user used to need two accounts, one for Windows and one for Linux, only one will be required after this project. The cost of the training necessary for new administrators should also be reduced as a consequence of such a project. Previously, administrators needed to be skilled in both systems, or else the organization had to maintain two sets of administrators. Reducing the cost of hardware Because the number of users and the overall load will not be changed by the integration of security and directory systems, you may expect that the number of servers necessary will not be changed. Suppose, however, that you have a small office with only ten Windows and ten Linux workstations that are linked to the rest of the organization through a low bandwidth or unreliable connection. Without the integrated security solution, a Linux and a Windows server will be required to ensure that all users in this office can log on at any time, despite the fact that the servers are likely to be under-utilized. If the Linux workstations can authenticate against the Windows server, one of these servers becomes redundant. 112

113 Elimination of obsolete technologies An old technology is not necessarily a bad one. However, it can frequently be incompatible with many of the diverse components making up your systems. These incompatibilities create barriers to the sharing of information and user productivity. They also add to the complexity and cost of administration. In the field of security, there is a further issue: old technologies are likely to have vulnerabilities that are well known to attackers. The adoption of new technologies based on open standards, such as LDAP and Kerberos, brings significant advantages. Their interoperability with systems from diverse manufacturers is guaranteed, and you will not lose support should a single manufacturer abandon the technology. LDAPv3 and Kerberos 5 are the latest versions of open standards, they are widely supported by diverse manufacturers, and they include resilience against the latest security attacks. Increasing the availability of information The purpose of a directory is to store information and make it widely available to users and applications within your organization. applications, for example, can use a directory to find address information from a name typed by a user, or the membership of a distribution list the user has selected from an address list. Users can locate a staff member with a specific set of skills, or find a telephone number. If there are two or more unsynchronized directories within your organization, users and applications will need to search twice for each piece of information. Metadirectory services and other technologies can be used to ensure that the two directories are synchronized so that all information appears in both directories. Users can then find what they need with a single search. However, in this case, data is duplicated in two or more places and the synchronization system must be maintained. If you have a single, integrated directory service that all client computers and applications can access, information published once is immediately available to the whole organization without the necessity for further synchronization or duplication of data. Reducing the risk of service unavailability When security and directory systems are operating system-specific, each client must find a server of its own type for success. If the Linux authentication server has failed, for example, a Linux user may be prevented from logging on, even though a Windows authentication server (that is, a domain controller) is available on the network. If the Windows domain controllers can authenticate Linux clients as well, the risk of service unavailability is removed. Of course, this improvement is dependent on a high-quality system design; it must include sufficient redundancy, or a failure in a server may result in Windows, Linux, and UNIX clients being unable to authenticate. When evaluating the project's business goals, you should include the broader goals of the organization itself. Is the business planning to expand, for example, and if so, by how much? If your project design cannot cope with such an expansion, it will have a short lifetime and will not justify the investment. 113

114 Assess the Current Security and Directory Systems Achieving a full understanding of your current situation is a vital early step in any project. Just as defining your business goals clarifies where you want to get to, assessing your current systems establishes your starting point. Your present systems may define the feasibility of the possible project solutions, and they may lead you toward the easiest one. A basic criterion measuring the success of any migration project is that its functionality should improve upon the functionality of the replaced environment. If you do not know the capabilities of the old systems, you cannot assess this improvement and may end up worse off. Goals for improvement will be used to develop the vision/scope document. Aspects of the existing situation that should be assessed are discussed in the following sections. Profiling the User Community You should document the size of the user community with respect to the platforms that will be employed in the solution. It is particularly important to identify user community statistics that will enable you to quantify the benefits that can result from implementing a heterogeneous security and directory solution based on Windows Server For example, quantifying the number of duplicate accounts will provide an indication of the efficiency improvements that can be made by moving to a single, unified account database and authentication system. Examples of the statistics to quantify and evaluate include: The number of UNIX and Linux users The number of Windows users The number of cross-platform users The user population growth rates The user transfer rates between platforms (for example, the number of UNIX users becoming Windows users) Evaluating the Current Solution This is a process in which all aspects, both strengths and weaknesses, of existing directories and security systems are evaluated. They should be measured against each business goal that you have defined for this project. This should take the form of a gap analysis that shows the gap between the organization's requirements and the current solution's features. 114

115 You should specifically consider the following: User and identity management infrastructure You should document the scale and range of the user and identity management infrastructure currently employed within the organization. Identify and describe all user databases and identity stores regardless of their purpose or location. A human resources database, for example, may be overlooked because it is not, strictly speaking, a directory and is used by an individual department at a single site. Include this in the evaluation because it may be possible to incorporate in the integrated solution you are creating. Another duplication of user data is thus avoided. For each infrastructure component, you should record the technology that each employs and its current version. In addition, you should determine which technologies support the Kerberos or LDAP protocols. Those that do will require little or no modification to take part in your integrated solution. Network topology Obtain network diagrams from network managers. These should include segment bandwidth capacities and the bandwidth capacity of the interfaces to servers affected by this project. If possible, obtain current figures on network utilization. This is important because a significant proportion of network traffic is related to authentication, authorization, and directory lookups, so the current project may result in a big increase or decrease in network traffic. Some changes made by such a project tend to decrease the network load. For example, a single integrated directory does not require clients to query twice to search all information, unlike a directory split between UNIX, Linux, and Windows. If you are using a Meta-Directory service to keep two directories in agreement, the synchronization traffic may be significant, and it is removed by creating an integrated system. Other changes may increase network traffic. For example, Kerberos 5 is more complex than older, less secure authentication systems, and thus generates more network packets. It will not be possible to accurately estimate how traffic will change in response to your solution until the Stabilizing Phase. However, good knowledge of the network will influence your design. Access control mechanisms The access control mechanisms within your organization determine which resources a given user can access, and what actions they are permitted to perform. Review Chapter 2, "Authentication and Authorization in UNIX and Windows Environments," for a detailed description of access control mechanisms. Your evaluation of these mechanisms must describe how they appear in Windows and your versions of UNIX and Linux. In particular, document support, if it is included, for the Kerberos and LDAP protocols and the versions of these protocols. For example, if you have a RADIUS service, then you should investigate and then document whether RADIUS user accounts can be held in a remote LDAP directory such as Active Directory. 115

116 Management procedures List the administration and management procedures that are in place pertaining to authentication, authorization, and identity management. These procedures guarantee quality and consistency. Many of them can be carried over into the new solution, albeit with revisions because of the new features, user interfaces, and administrative tools. Others can be discarded. For example, if you have dispensed with a Meta-Directory service because you now have only one, integrated directory, you no longer need the procedures for maintaining that service. The following management actions will include procedures that are relevant to this project: Management of user accounts Changes to access controls on resources such as files, printers, and the directory Publishing information in the directories Modification of the directory schemas Changes to the Kerberos configuration values Changes to the configuration of other authentication mechanisms 116

117 Create the Vision and Define the Scope for the Project Now that you have a thorough understanding of the existing systems and of problems and opportunities you want to address, your team can create the vision/scope document. This expresses the vision of the solution in a brief and clear statement describing the future state of the customer's environment at project completion. The vision presented in this document is a statement describing how the project addresses the business goals you have identified. The scope defines the boundaries of the project, indicating which issues must be addressed and which are for other projects. The Project Vision The vision is a short statement, usually only a sentence or two, and it contains a minimal amount of technical information. It is intended to provide direction and a context for all later decision making. All members of the team should refer to it throughout the project. The following three statements constitute three sample visions: Users can access any system in the organization using the same authentication credentials. Consolidate our organization s directories. One user name, one password, one place for user information. The Solution and Project Scopes These two scopes define what is included in, and what is excluded from, the solution and project. The solution scope places a boundary around the technologies that will be implemented. It lists the included features and functions, the excluded features and functions (particularly those which are similar to or associated with the included ones), and discusses the criteria by which the solution can be measured so that the customer and users can accept it. For an integrated security solution, single sign on is an example of a feature that will be included, but you must define it so that less technical team members and the customer can fully appreciate its importance. As an example of a feature that is out of scope, the prevention of virus infection may not be included (but the customer may expect some improvement in this area regardless because it is associated with security). As an example of an acceptance criterion for the single sign on feature, the customer and end users can demonstrate that single sign on is working when they observe that a password change made on a Windows computer rapidly affects Linux and UNIX workstations, as well. Other features that may be in scope for an integrated security solution include: Kerberos 5 client software installed on all workstations regardless of operating system. UNIX and Linux clients configured to authenticate against Windows Key Distribution Centers (KDCs). The organization's DNS system reconfigured to allow any Kerberos client to locate a KDC. 117

118 Time synchronization; UNIX and Linux clients are configured to synchronize with Windows domain controllers, and Windows computers are configured to do this by default. Ticket lifetime configuration values optimized to balance the needs of security against the network traffic generated by very frequent reissues. Features that may be in scope for an integrated directory solution include: LDAPv3 client software installed on all workstations regardless of operating system. UNIX and Linux clients configured to query against Windows directory servers. All clients configured to authenticate against the Windows directory servers using LDAP binds. The organization's DNS system reconfigured to allow any LDAP client to locate a directory server. The Active Directory schema updated to include classes and attributes required by UNIX and Linux clients. The project scope limits the work that the team will do, and it rules out work that will not be done as part of this project. Time, the number of people needed to do the work, how much access is needed for authorities or subject matter experts, budget requirements, and other constraints all limit what can be achieved, and the project scope describes these boundaries. Tasks that may be included in your project scope for this project are: Time service configuration Configuring DNS resolution Configuring KDCs Configuring UNIX and Linux Kerberos hosts Configuring group and security policy Designing the placement of KDCs Securing KDCs physically and logically Configuring UNIX and Linux Kerberos clients Standardizing the authorization strategy Configuring the Microsoft Windows Server 2003 LDAP service Extending the Active Directory LDAP schema Securing the LDAP service Configuring UNIX and Linux LDAP clients Account migration Training users and administrators Remember to use the MSF trade-off triangle and trade-off matrix when making decisions about scope. See the UNIX Migration Project Guide for guidance in using these decisionmaking tools. 118

119 Define High-Level Requirements and User Profiles This stage of the envisioning of your project ensures that the vision and scope you have created is translated into a solution that is business-driven, which means it improves the effectiveness, competitiveness, or productivity of your organization and justifies the investment. The team must determine the needs of each stakeholder in the project, including the customer, system administrators who will operate the solution, and end users who will benefit from it. High-Level Requirements The team defines a broad list of high-level functional requirements and features that should be considered for inclusion in the project. These should all address the business goals identified earlier. The team then narrows the list to a number considered essential. In the current project, you should consider the following high-level requirements: To eliminate the difficulties associated with multiple user accounts This is a barrier to user productivity that will be removed when a single sign-on authentication system is in place. To remove the necessity to query multiple directories and identity stores If a single query is sufficient, the time taken for a user to find information has been halved or better, depending on how many identity stores there were in the first place. Again, this addresses user productivity. To remove the necessity to synchronize multiple directories and identity stores When a single directory serves the whole organization, no synchronization or Meta-Directory system is required. There is, therefore, less to administer. To increase the security of the organization's systems This can be achieved after an integrated security system is set up by removing old authentication systems that are no longer used. Old systems tend to have more loopholes that an attacker can target. To lower expenditure on hardware From creating a single directory or a single, integrated authentication system, opportunities will arise to reduce the number of servers in the system because clients of any operating system can authenticate against Windows servers, and so Linux and UNIX servers will become unnecessary for providing security and directory services. To increase the system's resilience to failures If you do not make this a high-level requirement, you may create a system in which failures have a greater effect than before. For example, the failure of an Active Directory server may affect not only Windows users, but also Linux and UNIX users. Redundancy should be built in, which allows alternate authentication and directory servers to be located and used. User Profiles To evaluate the requirements of users, the solution team must first identify and describe all the different types of users who will be accessing the solution. For each user type, investigate what they will use the system for, which of its features will be relevant to them, and how this will improve on the existing systems. 119

120 The following is an example user profile for an integrated security solution: UNIX workstation users These users log in to UNIX workstations and are authenticated by the local PAM module. They require access to the integrated Kerberos KDCs, to be hosted by Windows servers, so that they can authenticate and gain tickets to network services. Their productivity will be curtailed should this access fail, so they need a resilient system in which an alternate server can be found should the most appropriate server fail. User profiles that may exist in your organization and need consideration for this project also include: Linux workstation users Cross-platform Windows, UNIX, and Linux workstation users UNIX and Linux server administrators Windows server administrators UNIX and Linux client administrators Windows client administrators Help desk users Note that the user profiles include those of system administrators, operators, and help desk staff. Their experience of the system is just as important as business users, such as sales staff, accountants, and so on. 120

121 Develop the Solution Concept The solution concept provides the essential link between the business goals and requirements on the one hand, and the proposed solution on the other. It describes how the solution addresses the problem or opportunity (the starting point) and takes into account any constraints that have been identified. The result is the first summary of the system that you are proposing. It presents a high-level overview of the components necessary to satisfy the requirements that you have identified and should not go into great detail the details will be added in the Planning Phase of the project. In conceptualizing a solution that provides security and directory services, the team must make two basic choices: what to do about authentication and what to do about authorization. Regarding authentication, the options are: Nothing (no change) Synchronization (separate authentication systems but synchronizing passwords) Integration (consolidation to one authn system) If integration is chosen, there is an additional sub-choice: Kerberos authentication LDAP authentication Regarding authorization, the options are: Nothing (no change) Synchronization (multiple directories with authz data using something like MIIS to synchronize them) Integration (consolidation to a single directory) Suppose your vision is Users can access any system in the organization using the same authentication credentials. Fulfilling this vision clearly requires a change to the existing authentication mechanisms in your enterprise. There are two major ways to achieve the goal: either synchronize your existing authentication mechanisms or replace them with a single common mechanism that can be used by all systems. A single mechanism will typically be less expensive to manage in the long run, but it may be more costly to implement. Your analysis of business requirements related to project expenses and operational costs will factor into this choice. It may be that there is no single mechanism supported by all the systems in your enterprise; you can either choose to synchronize multiple mechanisms, or you can constrain the scope of the project so you need not consider the systems that cannot use a common mechanism. If you decide to implement a single integrated authentication solution, the two likeliest candidate technologies are Kerberos and LDAP authentication. Other requirements will affect this choice. For example, LDAP authentication becomes more expensive to manage and more difficult to implement as the number of users increases or as the topology of the network infrastructure becomes more complex; some software systems can support LDAP authentication but cannot easily support Kerberos. 121

122 Instead, suppose your vision is One user name, one password, one place for user information. Fulfilling this vision requires not only a change to system authentication mechanisms but will also require a change to the way user information, including authorization data, is stored and accessed. And those choices must be made so that the new authentication and authorization solutions work together. In developing the solution concept, you should examine each of the identified business and technical requirements to determine how they constrain or focus the set of possible solutions. Some requirements are "binary" in nature; that is, a solution either satisfies the requirement or it does not. Other requirements are less absolute and can be fulfilled to a greater or lesser degree by any given solution. You may find it helpful to assign weights to such requirements and then score each potential solution along those dimensions to produce a rank ordering. Requirements frequently conflict with each other; a set of "must have" requirements might eliminate all possible solutions, or an otherwise-ideal solution might be ruled out by a single requirement. In those cases, it may be possible to adjust the scope of the project to eliminate the conflict. For example, you might determine that using Kerberos to provide a single authentication mechanism is the best solution to a problem, but then discover that Kerberos authentication is not supported by a small number of systems in your environment. Instead of choosing a less suitable authentication solution, you could instead change the project scope to omit coverage of that small set of systems. If your unique requirements result in there being no viable solutions even after you have adjusted the project scope to the maximum possible degree, then you have a choice: either explicitly drop requirements until the conflict is resolved and at least one solution becomes possible, or cancel the project. Do not regard cancellation as "failure"; it is the best possible choice when the alternative is to spend a great deal of money pursuing an unobtainable solution. Because the solution concept will be presented to the customer, it should be written in non-technical language. However, the solution concept should include enough information to inform feasibility studies, risk analysis, usability studies, and performance analysis. The solutions presented in this guide are aimed at the "integrate and consolidate to a single mechanism" choices for both authentication and authorization. Moreover, the solutions covered by the guide were selected to be complementary, allowing them to be applied simultaneously to fulfill a vision such as One user name, one password, one place for user information. Other solutions to problems related to authentication and authorization are possible. For example, Windows and UNIX authentication mechanisms can be synchronized through the use of features in the Microsoft Services for Unix product. User information stored in the Active Directory can be synchronized with the contents of some other directories through the use of the Microsoft Identity Integration Server product. While the development information contained in this guide is not directly relevant to those solutions, you may find the guidance on planning, stabilization, and deployment helpful in a general way. 122

123 Interim Milestone: Vision/Scope Document Drafted The project team and customer now have a broad view of the project, the problems and opportunities it addresses, the user community that will benefit, how this specific user community will benefit, and the approach that will be taken to provide a solution. The scope of the project and solution have been defined both in terms of features included and those excluded. The team also has a clear and shared vision that defines the purpose of the project and provides direction. 123

124 Assess Project Risks The team assesses risks because, in any project, things are likely to go wrong. You may feel in this case, for example, that integrating the separate UNIX, Linux, and Windows directory systems might increase the impact of failures. A failure that previously affected only Windows users may, after the integration is complete, affect UNIX and Linux users as well. This probability is alleviated by the distributed nature of Active Directory, which allows the load of halted servers to be automatically switched to functional ones. However, having identified this risk, your later planning and implementation will ensure that UNIX and Linux clients can make use of such automatic failover along with Windows clients. The team's risk assessment activities result in a risk assessment document. In this document, each risk should be described along with the impact that it will have on the project should it occur, the chance of it occurring, and action plans for how the team will address the risk. A particular risk may be very likely to occur, or very unlikely. When it occurs, the impact on the success of your project or user productivity may be small or very extensive. Those risks which have a large impact and are likely to happen are the most important. Note The UNIX Migration Project Guide includes further discussion of risk assessment, and MSF has some tools that help to measure your exposure to each risk. These tools are available at The importance of risk assessment means that it must be done throughout the project by all team members and it should follow the procedures identified in the MSF Risk Management Discipline. This ongoing evaluation may make the difference between the project succeeding and failing. This stage of the project is, however, the first opportunity you have to consider risks because you have a conceptual understanding of what the project does and how it does it. In the case of an integrated security and directory system, the following risks are likely to be present and your particular exposure to them must be assessed and reduced by good planning and design: Service unavailability If there is no authentication service available to a client, a user will be prevented from logging on or accessing a resource. If there is no directory server available, a user may be unable to obtain information. Fortunately, both Kerberos and LDAP systems can be designed in such a way that clients can find other servers if their preferred one is down. However, your placement of servers, DNS design, network topology (particularly WAN links), and replication system must all be right to allow this. Time synchronization problems This does not significantly affect directory access, but Kerberos is sensitive to differences in the system time of clients and servers. If a client is unsynchronized with the server, no user will be able to log on to that computer. If two servers have time differences, trust relationships may break down and access to resources might be disrupted. 124

125 Replication interruptions A distributed LDAP directory system, such as Active Directory, must replicate changes from one server to another so that each user is presented with the most up-to-date information. If this fails, users may be misled by data that should have been replaced. Identity spoofing Any security system must concern itself with identity spoofing, in which an attacker impersonates a legitimate user. Kerberos 5 has a good reputation, but it is not invulnerable. If, for example, your users have chosen insecure passwords, such as dictionary words with no numbers or other characters, attackers will be able to crack them with relatively little effort. Close the Envisioning Phase Reaching the Vision/Scope Approved Milestone concludes the Envisioning Phase. At this point, the project team and the customer have agreed on the overall direction for the project, including which features the solution will and will not include and a general timetable for delivery. Key Deliverables from the Envisioning Phase A deliverables checklist for the Envisioning Phase includes: Project structure document Assessment of the current security and directory systems with the organization A profile of the user community Evaluation of the current solution Vision/scope document The project vision The solution and project scopes The solution concept High-level requirements for the project Risk assessment document You should refer to the UMPG for any of these deliverables that have not been covered in this chapter. Key Milestone: Vision/Scope Approved At this milestone, the key documents listed in the previous section will be finalized and agreed upon. Project teams usually mark the completion of a milestone with a formal sign-off. Key stakeholders, typically including representatives of each team role and any important customer representatives who are not on the project team, signal their approval of the milestone by signing or initialing a document stating that the milestone is complete. The sign-off document becomes a project deliverable and is archived for future reference. The Planning Phase of the project can now begin. 125

126 Summary This chapter has provided guidance on how to envision your security and directory solutions. At this point, the high-level key decisions have been made, a vision/scope has been created and it is now possible to progress to the planning of the solution. 126

127 5 Planning Heterogeneous Security and Directory Solutions Introduction and Goals This chapter provides the background and technical information required to complete the Planning Phase of a heterogeneous security and directory solution project. It builds on the documents created and agreed to in the Envisioning Phase. The primary goals for the Planning Phase are to create the solution architecture and design, the project plan, and the project schedule. The solution design and architecture is articulated as a concept, as a logical system, and as physical components (the conceptual design, logical design, and physical design), and will become part of the functional specification. This is the phase of a project when the initial vision is translated into practical plans for how to achieve it. Team members draw upon their expertise to create individual plans in all areas of the project, ranging from security to budget to deployment, and the role of Program Management rolls up these plans into the master project plan. Likewise, individual schedules are combined to become the master project schedule. The phase concludes when the project team agrees that the plans are sufficiently welldefined to proceed with development, and the team, business sponsor, and key stakeholders approve the master project plan and schedule and the functional specification, usually at a milestone meeting. The formal conclusion is marked by the major milestone, Project Plans Approved. The following list identifies the tasks that must be completed to meet the milestone. Like most planning activities, they are likely to involve much communication. Keep in mind that deliverables may undergo numerous iterations before agreement can be reached between the project team and the customer and stakeholders. The tasks are: Develop the solution design and architecture Validate the technology Create the functional specification Develop the project plans Create the project schedules Set up the development and test environments 127

128 The technical information provided in this chapter will guide you in the considerations to keep in mind as you make decisions related to this phase. For example, designing the physical architecture is partially determined by the performance that is needed, as well as other production and operational requirements. Requirements for the development and test environments are discussed, and guidance is also provided on validating the technology that will be used. Readers should consult the UNIX Migration Project Guide (UMPG) for guidance on organizing the team and processes to accomplish the work. Table 5.1 summarizes the progress of the Planning Phase and its key tasks. The owners of each task are defined according to the MSF team roles. The table also includes details of these roles in relation to a distributed security or directory solution. Table 5.1: Major Planning Phase Tasks and Owners Major Tasks Developing the solution design and architecture The team begins the design process with the solution design and architecture and culminates it with a design document that becomes part of the functional specification. Validating the technology The team creates a small scale pilot that is used to evaluate the different solution technologies and options. Creating the functional specification The team creates a functional specification that describes the solution requirements, the architecture, and the detailed design for all the features. Developing the project plans The team develops a collection of plans that address how the six MSF team roles will perform their tasks. These plans are consolidated into the master project plan. The master project plan is considered a roll-up of all of the plans and, thus, also includes strategic items such as the approach, dependencies, and assumptions for the solution. Creating the project schedules The team creates the master project schedule, which consists of milestone-driven schedules developed by each of the individual team roles when planning their respective activities. Setting up the development and test environments The team creates development and testing environments that are independent of the production environment to develop and test the solution. Closing the Planning Phase The team completes the approval process for the Project Plans Approved Milestone and documents the results of completing the tasks performed in this phase. Owners Development Development Program Management Program Management Program Management Development and Test Project team 128

129 Deliverables The deliverables for the Planning Phase are: Functional specification A summary of the vision/scope document Additional user and customer requirements beyond those in the vision/scope document The solution design and architecture Specification of components that are part of the solution Master project plan Security plan Budget plan Resource plan Development plan Test plan Deployment plan Pilot plan Operations plan A development and test environment Project schedule 129

130 Develop the Solution Design and Architecture Developing the solution design and architecture begins with a design process, the results of which become the functional specification. The design process prepares the team members for their responsibilities during the Developing Phase by building upon the vision the team developed and business requirements gathered during the Envisioning Phase. The design process gives the team a systematic way to work from abstract concepts down to specific technical detail by developing a conceptual, logical, and physical design for the solution. These are not three separate design processes, but are more properly thought of as three overlapping stages of a design continuum. Note As the team moves from gathering requirements to designing the solution to creating detailed functional specifications, it is important to maintain traceability between requirements and solution features. Traceability does not have to be on a one-to-one basis; in fact, it often is not. There may be features that satisfy more than one requirement, and it may take many features to satisfy a single requirement. But every requirement must be traceable to its solution counterpart. Maintaining traceability serves as one way to check the correctness of design and to ensure that the design meets the goals and requirements of the solution. Conceptual Design of the Security and Directory Services The conceptual design depicts the functionality present for each major feature of the solution. For migration projects, the conceptual design is generally identical to that developed for the current version of the infrastructure component. It is nonetheless important to articulate that design in the functional specification for the migration project; the actual concept for the current component may have drifted from its initial conception. Even if that conceptual design has remained constant, it serves as a touchstone for subsequent designs. For example, conceptual designs illustrate each of the user interface elements that must be included in the solution. The conceptual design captures how the solution will work for both users and administrators. The team considers the needs of all the user profile groups when designing. To do this, they must first develop a strong understanding of the requirements. This is done by reviewing a series of documents that were developed during the Envisioning Phase: Business goals User community profile Current solution evaluation High-level requirements User profiles The designers incorporate these requirements in terms of descriptions that eventually become part of the functional specification. 130

131 Figure 5.1 summarizes the conceptual designs for the solutions presented by this guide. Although other designs are possible, this guide does not present solutions that embody them. In the diagram in Figure 5.1, the left side illustrates the different conceptual designs for security solutions, and the right side illustrates the different conceptual designs for directory solutions. It is important to note that the solutions presented in this guide can be combined to create an integrated security and directory solution shown in the figure as the Combined Solutions oval. Note This guide covers security solutions before covering directory solutions in each section and chapter where they are both relevant. 131

132 132 Figure 5.1 Overview of the conceptual designs for security and directory services

133 In each solution case presented in this guide, the assumption is that each solution will be implemented in environments that have existing legacy systems, legacy security services, and legacy directory services. The capability to integrate as well as migrate legacy systems with any new systems is an important aspect of each solution. The different security and directory solution designs are described in more detail in the following sections. Conceptual Design of the Security Services The conceptual designs of the security services shown in Figure 5.1 are primarily intended to deliver single sign on security across all platforms and applications. Security management is centralized in one place. The usability of systems and applications is improved because users and administrators have to deal with only the same user account or user accounts across all platforms. The main option presented is between single-realm or cross-realm. The single-realm solution is adequate where only one authentication realm is required. The cross-realm solution is necessary when more than one realm is required within the organization. In the case of the cross-realm solution, it is probable that the cross-realm authentication will take place across authentication systems residing on different operating systems. In this case, interoperability is an essential part of the solution. The directory authentication solution is present as an option that is useful in two circumstances: When it is not possible to use a standard security service for authentication For authentication during directory operations as part of a directory service solution All solutions must be capable of integrating with legacy systems that may continue to be required with the organization to support specific business functions. Conceptual Design of the Directory Services The conceptual designs of the directory services as shown in Figure 5.1 are primarily intended to deliver a centralized account directory for all operating systems within the organization. Additionally, the directory service should also be capable of storing other operating system information, user account information, and organizational information that is used by the organization's systems and applications. The directory store holds all the accounts for the organization's employees, simplifying account management and making possible improvements in users' experiences. As with the security service solution, two main options are presented in Figure 5.1. These are single-domain and multiple-domain. These represent the scenarios where an organization has a requirement to split the directory into two different domains, either for political or technical reasons. In either case, the multiple-domain solution is where crossplatform directory services operate in a multiple domain environment. In the majority of cases, the directory solution will require directory authentication to ensure that directory service operations can be secured. Logical Design of the Security and Directory Services Logical design takes each piece of conceptual design and assigns it to a specific logical role within an architecture. For projects based on the security and directory solutions in this guide, the architecture is a series of block diagrams showing networks, service components, and network connection elements. 133

134 Because this is a migration project, the team should document the existing logical design as well as the logical design of the migrated infrastructure component, emphasizing the areas of change. It may be necessary to show how other components outside the scope of the project interact with the subject of the migration. This section of the guide is split into subsections that cover the different security and directory solutions presented by this guide and the infrastructure that they require. The logical design of each individual solution includes these minimum requirements: It is standards-based. The solution platform is Windows Server The solution is cross-platform and allows for the integration of Windows Server 2003 Active Directory with legacy UNIX and Linux-based systems. Where possible, the solutions should make best use of any security features available in each of the solution components. The solution will be primarily managed through the use of Windows Server 2003 management tools. In the following sections, the components and logical designs of solutions are based upon standard components available as a part of the target operating systems, and where required, upgrades to the MIT Kerberos distribution and the PADL LDAP modules. If your conceptual design specifies a fully integrated security and directory solution, you can partially achieve this using the UNIX and Linux components described in these sections, but certain aspects of the solution cannot be fully integrated using these standard components. If you require full integration, you should consider the commercially available Vintela Authentication Services (VAS) product. VAS is covered in Chapter 11, "Vintela Authentication Services." Table 5.2 compares the features of the security and directory components that you can use in your logical design. Table 5.2: Comparison of the Features of Solution Components Feature Automatic support of complex Active Directory forests MIT Kerberos PADL Modules VAS No No Yes Automatic keytab file updates No No Yes Centralized authentication with Active Directory Yes Yes Yes Centralized identity management with Active Directory No Yes Yes Maintainability Complex Complex Simple Login access controls: per user/group/domain No Yes Yes Local cache for disconnected mode operation No No Yes User migration tools No Yes Yes Does not require third-party tool that may intrude into Windows security services Yes Yes Yes Supported commercial product No No Yes Provides automatic time synchronization No No Yes Compatible with Microsoft Services for UNIX N/A Yes Yes 134

135 Feature schema extensions MIT Kerberos PADL Modules Compatible with RFC 2307 schema extensions N/A Yes Yes Simple to install and configure No No Yes Supports Dynamic DNS No No Yes Supports DNS SRV records for service discovery VAS Yes Partially Yes Supports dynamic key versioning No No Yes Supports the use of global catalog for distributed scalability UNIX and Linux systems require no complex non-standard tools UNIX and Linux systems appear as computer objects in Active Directory Does not require the overhead of SSL/TLS for LDAP security LDAP security through GSSAPI using Kerberos session keys Does not require special account or anonymous access to LDAP Active Directory service No No Yes Yes Yes Yes No No Yes N/A N/A N/A nss_ldap only nss_ldap only nss_ldap only Yes Yes Yes Note Although the PADL modules are not commercial software, some companies, including PADL, do provide commercial support for them. Note Guidance for using LDAP SSL/TLS is beyond the scope of this guide. The following sections look at the functionality and features of the different security and directory solutions in more detail. Choosing the Authentication Mechanism Two types of cross-platform authentication solutions are provided in this guide Kerberos 5 and the Lightweight Directory Access Protocol 3 (LDAPv3). It is also possible to use both types of authentication in a solution. 135

136 Kerberos and LDAP authentication services are built into Active Directory. Kerberos is the standard authentication method used by applications, services, and users within Active Directory. The LDAP authentication solution presented in this guide is for use when the Kerberos solution cannot be used for some reason. While LDAP authentication is required for the directory solutions presented in this guide, its use as a user authentication mechanism in a cross-platform environment is not recommended except in special circumstances. Using LDAP authentication for user authentication has the following disadvantages: It is not scalable to large numbers of users. It has performance problems. Not all applications within Active Directory can use LDAP authentication as well as Kerberos authentication. Logical Design of the Kerberos Security Services Kerberos is the default authentication service for Windows Server 2003 and is an open standards-based solution. This section covers the logical design decisions that you need to make when planning a Kerberos security solution based on Windows Server The requirements for the Kerberos security solutions are: A standards-based security solution must be used (Kerberos 5). User credentials should be stored in Windows Server 2003 Active Directory. A cross-platform authentication service (Kerberos 5) supported by Windows Server 2003 Active Directory. An implementation of Kerberos 5 for UNIX and Linux platforms that supports the Kerberos 5 implementation found in Windows Server 2000, UNIX, and Linux. This requirement is met by the MIT Kerberos implementation. The solution must be capable of supporting cross-realm authentication with UNIX and Linux Key Distribution Centers (KDCs). A time synchronization infrastructure that is capable of guaranteeing the synchronization of time across all Windows, UNIX, and Linux platforms to the accuracy required by the Kerberos configuration. This is covered in the "Logical Design of the Time Synchronization Infrastructure" section later in this chapter. A DNS infrastructure that supports the features required by Windows Server 2003 Active Directory, UNIX clients, Linux clients, and Kerberos. This is covered in the "Logical Design of the Domain Name System Infrastructure" section later in this chapter. 136

137 Figure 5.2 shows the two most common scenarios when implementing a Kerberos security solution using Windows Server They are briefly described in the following list: Single-Realm In this scenario, the Kerberos Key Distribution Centers (KDCs) serve only one Kerberos realm. If the single realm existed before the implementation of one of the Windows Server 2003-based security solutions from this guide, then after the solution has been implemented, all of the KDCs will be Windows Server 2003 KDCs. The Kerberos authentication data is held in Active Directory, and all UNIX, Linux, and Windows clients authenticate to Active Directory. This configuration provides a centralized point of management and a single set of tools for controlling authentication across all platforms. Cross-Realm In this scenario, a number of realms exist, and these are served by different sets of KDCs. To gain all the benefits of centralized and unified management using Windows Server 2003 Active Directory, it is necessary to migrate all realms and their KDCs to Windows Server Windows Server 2003 Active Directory automatically creates cross-realm trusts between Kerberos realms in an Active Directory forest. An Active Directory Kerberos realm is equivalent in scope to an Active Directory domain, and an Active Directory forest is a collection of domains. However, in many migrations it is not possible to migrate all realms to Windows Server 2003 at once, and sometimes there are business and technical reasons why some realms may continue using UNIX or Linux based KDCs. In these cases, some realms are served by Windows Server 2003 KDCs and others by UNIX or Linux KDCs. In these heterogeneous scenarios, cross-realm trusts between Windows Server 2003 KDCs and UNIX or Linux KDCs are required to gain some of the benefits of single sign on and cross-platform authentication. This configuration has none of the benefits of centralized management or the single set of tools, and it has higher maintenance overhead than the Windows-only scenario, but it allows for users in either realm to authenticate to either set of Kerberos servers. Thus, it is a realistic midpoint in an overall migration strategy that allows for the mitigation of risks that can arise from a complete transfer from UNIX to Windows Server

138 138 Figure 5.2 Logical designs for the security service

139 When you are creating your logical design, you must consider if there is any requirement for a heterogeneous KDC solution using cross-realm authentication. In general, it should be feasible for a homogenous Windows Server 2003 KDC solution to be deployed as the end result for the authentication of UNIX or Linux clients. During the migration process, it may be necessary to stage the migration to retain UNIX or Linux KDCs to allow for a phased transition and to provide a potential recovery option should any problems be experienced. Logical Design of the Kerberos Realms and KDCs The planning considerations that are required in the planning of a Kerberos security solution using Windows Server 2003 include determining the following: Kerberos realm name or names Although a Kerberos realm name can technically be any ASCII string, it is recommended that you follow the conventions described in RFC This format for the realm name is similar to a domain name where the name is made up of components separated by periods, except that the realm name is in uppercase characters. Also, this format cannot contain either colons (:) or slashes (/). For example, the example.com domain becomes the EXAMPLE.COM Kerberos realm. If there is a need for multiple realms, then you should use descriptive names that end with your domain name; for example, LONDON.EXAMPLE.COM and WASHINGTON.EXAMPLE.COM. Internet Protocol (IP) ports to use for Kerberos services The default Kerberos Transmission Control Protocol (TCP) ports are 88 for the KDC and 749 for the administration server. Unless there is good reason within your organization to modify these, it is recommended that they are left at the default settings to ease administration and troubleshooting. Host names of primary and secondary KDCs Regardless of the true names of your KDC servers, it is recommended that in DNS you create CNAME (alias) records for the primary and secondary Kerberos KDCs. Use kerberos for the primary KDC and kerberos-1, kerberos-2, and so on for the secondary KDCs. Microsoft recommends using this convention, which is in line with the advice in the Kerberos V5 System Administration's Guide (MIT, 2000). Following this convention means that should you require to swap computers, you only have to modify the DNS entry for the KDC. More information about locating KDCs using DNS can be found in the "Logical Design of the Domain Name System Infrastructure" section on DNS later in this chapter. Kerberos Database propagation Windows Server 2003 makes use of the Active Directory to store Kerberos authentication data. This means that the Kerberos authentication data is automatically replicated, along with all other data in the Active Directory, to all domain controllers. There is no way to replicate the Kerberos data held in the Active Directory to a KDC not running Windows Server Kerberos realms hosted on UNIX or Linux KDCs will need to have database replication explicitly defined for primary and secondary KDCs. Kerberos 4 compatibility Microsoft recommends that Kerberos 4 compatibility is not attempted in any of the Kerberos-based solutions presented in this guide. The use of Kerberos 4 with Kerberos 5 services is a complex problem that can result in significant difficulties. Additionally, the combination of Kerberos 4 and Kerberos 5 in a solution using Windows Server 2003 Active Directory is particularly difficult. 139

140 Many of these decisions will already have been made if you have an existing Kerberos realm. It is recommended that you retain any of the decisions that you have made previously in your realm design unless there is a good reason so that you can minimize the potential problem areas during the migration. Kerberos Ticket Life Cycle Management The lifetime of a Kerberos ticket is usually between 8 and 10 hours, depending upon the Kerberos implementation. It may be that your environment requires more frequent authentication to reduce the chances of a user's ticket being stolen and misused, or longer to reduce the number of times that a given user has to reauthenticate. It is recommended that, unless you have specific reason to change the ticket lifetime, you use the default lifetime as supplied with your implementation. The renewable lifetime of a ticket is the period of time that a Kerberos ticket can be automatically renewed without user intervention. This is usually set to a maximum of seven days. The exact length of the renewable ticket is specified by the user when it is requested, but it cannot exceed the maximum. Unless there is a specific reason within your environment to modify this setting, it is recommended that the default be used. Design Issues for Coexistence in Heterogeneous Kerberos Environments In a large environment of UNIX or Linux hosts, a migration will take place over a period of time and is not an instantaneous change. It must therefore be determined how the old and new environments can coexist over the period of the migration. This will allow for UNIX or Linux clients to be reconfigured so that they can obtain their authentication information from the Windows KDCs. There are three possible coexistence scenarios: Single Kerberos realm and single Active Directory domain Multiple Kerberos realms and Active Directory domain tree Multiple Kerberos realms and Active Directory forest In the first of these scenarios, there is a single Kerberos domain and a single Active Directory domain. This single realm can be recreated within the single Active Directory domain. There is no need for the creation of cross-realm trusts. Users can be created within the Active Directory, and then the UNIX or Linux clients can be reconfigured to reference the Windows Server 2003, and the UNIX or Linux KDC can be retired. This is illustrated in Figure

141 Figure 5.3 Single Kerberos realm and single Active Directory domain In the second of these scenarios, there are multiple Kerberos realms and an Active Directory domain tree. This is illustrated in Figure

142 Figure 5.4 Multiple Kerberos realms and an Active Directory domain tree Within an Active Directory tree, implicit trusts exist between the domains. This means that any Kerberos data entered into the Active Directory will be available to all domains. Users can therefore all be created within the Active Directory, and as UNIX or Linux clients are reconfigured to reference the Windows Server 2003, the UNIX or Linux KDCs can be retired. In the third scenario, there are multiple Kerberos realms and there are multiple domain trees within a forest. This scenario is similar to scenario two, with the exception that there is no implicit trust between domain trees in a forest this needs to be defined explicitly before the UNIX or Linux client reconfiguration begins. Each domain tree can be treated as in the second scenario, with the retirement of UNIX or Linux KDCs when all of the UNIX or Linux clients have been reconfigured to reference the Windows Server This scenario is illustrated in Figure

143 Figure 5.5 Multiple Kerberos Realms and an Active Directory Forest Any real-world situation can be described as some variation of these three scenarios. There are cases where your UNIX or Linux KDCs must be retained; in these cases, a cross-realm trust should be established, as in the third scenario, without the immediate retirement of the UNIX or Linux KDCs. 143

144 Active Directory Integration Design Issues You must decide how to integrate the UNIX or Linux user accounts and applications into the existing Active Directory structure in the organization. The following list enumerates the design decisions that you must make: Organizational Unit hierarchy Are the users that are being migrated from the UNIX or Linux Kerberos realm being absorbed into an existing Organizational Unit (OU), or are they being created into a new OU created specifically for them? Using a specific OU for the migrated users makes administration during the migration more straightforward. Microsoft recommends that you create a new OU for this purpose. When the migration is complete, the migrated users should be integrated into your standard OU structure. Applications Are you migrating UNIX or Linux applications? Applications under UNIX or Linux that perform authentication require an application-specific user with a fully qualified realm name to be added to Active Directory. This user is used by the application to authenticate to Active Directory. Naming constructs Do your existing Kerberos principal names meet the required naming standards? The naming standards used for UNIX or Linux accounts will need to meet the existing naming standards for integration into Active Directory or will need to be modified to be acceptable. Your organization may have naming standards for UNIX or Linux accounts. Some historical applications and systems limited names, for example, to lowercase and less than eight characters. Although these limits generally no longer apply, if your organization has applications that must adhere to these limits, then your Kerberos principal names must be within these limits, too. Although it is not a requirement for the use of Kerberos to authenticate UNIX or Linux clients to Windows Server 2003, there are benefits in extending the Active Directory schema to allow for a representation of UNIX or Linux user account attributes in Active Directory user accounts. Extending the schema and its advantages are discussed in more detail later in this chapter in the "Choosing the Schema for LDAP Directory Services" section. Logical Design of the Time Synchronization Infrastructure Kerberos requires the rough synchronization of all systems clocks to within a tolerance of less than five minutes to function correctly. Your Kerberos security solution must include a time synchronization infrastructure. This section describes the choices you must make when creating a logical design for such an infrastructure. The requirements for the time synchronization solutions are: All systems within the security solution, including UNIX, Linux, and Windows servers and clients must have system clocks that are roughly synchronized to within less than the maximum clock skew allowed by the solution's Kerberos configuration. If the organization has other applications that require time synchronization of a higher degree of accuracy than that required by Kerberos, then the time synchronization solution must provide time synchronization to at least that level. The solution must use standards-based time services and protocols, such as the Network Time Protocol (NTP) and the Simple Network Time Protocol (SNTP). 144

145 If possible, the Windows clients will use SNTP to synchronize their clocks because this is a less complex solution than using NTP and it allows the use of the built-in security of the Windows time service. The solution must include a single time source for all servers and clients in the solution. Internal or external time sources are acceptable options. Multiple time sources are acceptable when they are known to be synchronized. The UNIX and Linux clients use the NTP protocol to synchronize with the solution's chosen time source (the NTP protocol is implemented as part of the ntpd UNIX and Linux daemon). On Windows clients, the system clock is synchronized using either the domain time synchronization features built into Microsoft domains or the NTP protocol to synchronize with the solution's chosen time source. For solutions that must encompass multiple Active Directory forests, the solution must guarantee acceptable time synchronization across all forests and the UNIX or Linux clients and realms. The solution must be secure, using the available security features of SNTP and NTP where possible. When designing your time synchronization service, it is recommended that you review the Microsoft paper The Windows Time Service, which is available at Design of the Time Synchronization Topological Hierarchy There are three main time synchronization options: Use the hierarchical time synchronization service built into the Active Directory domain system to synchronize all Windows platforms within each forest and synchronize each forest's time service and all UNIX and Linux system clocks to a NTP time source. Synchronize all Windows, UNIX, and Linux system clocks to a NTP time source. Use a third-party time synchronization solution. This option is not covered in this guide. The first two options are explained in more detail here. Figure 5.6 shows the structure of the built-in time hierarchy in Windows Server 2003 Active Directory domains and domain trees. Note that time services of Active Directory forests are not synchronized unless each is synchronized to a common time source. 145

146 Figure 5.6 Hierarchy of authoritative servers Microsoft recommends that the built-in time service provided with Windows Server 2003 Active Directory is used to synchronize the time in Active Directory domains and domain trees and that each forest is synchronized to a common time source. Each UNIX and Linux system should then be synchronized to the same common time source as the Active Directory domains are synchronized to. This is shown in Figure

147 Figure 5.7 Time synchronization using Active Directory and NTP time services The approach in Figure 5.7 synchronizes all computers that are not a part of the Active Directory domain directly to an external time source. The computers that are a part of the Active Directory hierarchy have their clock times synchronized automatically with the Windows Server 2003 domain controllers. The Windows Server 2003 domain controllers synchronize their clock times to the external time source. If greater time accuracy is required, then Microsoft recommends that all Windows, UNIX, and Linux systems synchronize with a common time source using the NTP protocol. 147

148 The two approaches to time synchronization are compared in Table 5.3. Table 5.3: Approaches to Time Synchronization Feature Accuracy Security Ease of configuration Time source Active Directory and NTP Solution Windows hosts are loosely synchronized. Both systems (SNTP and NTP) use their own security features internally. Synchronization between Active Directory and common time source cannot use NTP security features. Relatively easy to configure. Automatically configured within Active Directory. Can use internal or external time sources. NTP-only Solution Potential for high degree of time accuracy. UNIX and Linux clients can use security features of NTP. Windows clients cannot use security features of NTP. Difficult to configure. Requires configuring on all Windows, UNIX, and Linux clients. Can use internal or external time sources. Selecting a Time Source Each of the time synchronization systems presented here requires a time source. There are two main possible time sources: External NTP server or servers on the Internet. These are typically public services. Internal NTP server or servers. The internal time servers will themselves need to synchronize their clocks, either manually or using some other method, such as an external time server. A complete list of publicly accessible time servers is available from the official NTP site at When choosing the server that you will use for time synchronization, it is important to consider the following: Geographical location of the server Ideally, you should choose a server which is close to you geographically. This will reduce the number of intermediate steps that the data has to pass through and improve the overall accuracy of the system. Reliability Public access servers often have no guarantees of uptime. If your timekeeping requirements need to guarantee uptime, you should consider a hardware time source solution such as Global Positioning System (GPS). Access requirements imposed by the servers Free servers may still implement some restrictions on access, such as requiring registration or allowing only academic sites. You should ensure that you fulfill any requirements that the site you choose to synchronize from imposes. 148

149 Note An alternative to synchronizing an internal authoritative server to external Internet sources would be running a self-maintained time source, such as a GPS receiver. A list of hardware-based time sources that are on the Microsoft Hardware Compatibility List and, therefore, are supported by Windows Server 2003, can be found at Logical Design of the LDAP Security Services Using the LDAP service to provide authentication for UNIX and Linux clients is not a recommended solution. It is, however, covered in this guide because there are some situations where a Kerberos authentication solution may not be possible. For example, there can be occasions when a client application does not include Kerberos authentication code, but it does include LDAP authentication code. In this case, providing LDAP authentication allows this application to authenticate to Active Directory, which would not have been possible with a solution that provided only Kerberos authentication. LDAP authentication does not require a schema extension, although it is usual for the schema to be extended as a part of an LDAP directory solution. Apart from this rare exception, the requirements for LDAP authentication are the same as for LDAP directory services as covered in the following section. Logical Design of the LDAP Directory Services This section covers the logical design decisions that you need to make when planning an LDAP directory service solution based on Windows Server 2003 Active Directory. The requirements for the directory solutions include the following: Standards-based directory services must be used (based on LDAPv3). User accounts should be stored in single LDAPv3-compliant directory (Windows Server 2003 Active Directory). The LDAP schema used must support both Windows Server 2003 Active Directory and UNIX or Linux user account attributes. The SFU schemas meet this requirement. The UNIX and Linux clients must be capable of obtaining user account details from the LDAPv3 directory. The PADL LDAP Name Service Switch (NSS) module meets this requirement. Optionally, the solution should allow UNIX and Linux clients to use the LDAPv3 directory service for authentication. The PADL LDAP Pluggable Authentication Module (PAM) meets this requirement. This option is presented in the "Logical Design of the LDAP Security Services" section earlier in this chapter. The PAM LDAP module pam_ldap must be capable of processing Active Directory user passwords, enabling the password to be changed. The PADL PAM LDAP module supports Active Directory passwords; PAM LDAP modules shipped with many versions of UNIX do not. An implementation of LDAPv3 for UNIX and Linux platforms that supports the LDAPv3 features found in Windows Server This requirement is met by recent versions of OpenLDAP, as covered in this guide. A DNS infrastructure that supports the features required by Windows Server 2003 Active Directory, UNIX clients, Linux clients, and Kerberos. This is covered in the "Logical Design of the Domain Name System Infrastructure" section later in this chapter. 149

150 Figure 5.8 shows an overview of the directory service and the components that you should include in your logical design. The following sections describe these components and the decisions that you should make when creating the logical design. Figure 5.8 Overview of the logical design of a directory service Choosing the Schema for LDAP Directory Services To use Active Directory as a directory service that stores UNIX and Linux user account information, it is necessary to extend the schema. The attributes available within the default schemas supplied with Active Directory do not include all of the attributes necessary for UNIX or Linux account management. The following options for extending the Active Directory schema are available to you: Create your own bespoke schema. A proprietary schema may limit interoperability with other systems and applications and will not be easily managed by the standard Active Directory management tools. Use the RFC 2307 schema for storing Network Information Service (NIS) information in LDAP. The RFC 2307 schema is not integrated into Active Directory. So while it is possible to use this schema, the lack of integration means that: Some parameters will not be automatically synchronized with Active Directory attributes: for example, the different password attributes. The Active Directory management tools cannot be used with this schema because these tools do not use RFC 2307 object classes or attributes. 150

151 Use the schema provided with SFU. This is a schema supported by Microsoft and is fully integrated with Active Directory and Microsoft Services for NIS. It also allows you to make use of UNIX extensions to the Active Directory Users and Computers Microsoft Management Console (MMC). It is recommended that you use the latest schema extensions available with Microsoft Services for UNIX (SFU) 3.5. The SFU 3.0 schema is identical to the SFU 3.5 schema and can be used with this guide. Other SFU schemas can be used but they are not recommended. You should only consider using another SFU schema when you have an existing installation of SFU within the organization. Directory Object Security and Access Control In order for the LDAP solution to function, UNIX and Linux LDAP clients must be capable of authenticating themselves to the Active Directory LDAP service. In LDAP, this is referred to as binding to the directory. You can bind to Active Directory in one of two ways: Anonymously with Null credentials. Null credentials are where the user name and password are not set. Anonymous binding is not permitted by default with Active Directory. By using a special user to authenticate to the LDAP service from UNIX and Linux clients; the user must be authorized to browse the Active Directory. Microsoft recommends the use of a special user for binding to Active Directory because it allows for the implementation of better security measures than are possible with anonymous binding. Active Directory Integration Strategy The planning considerations that are required include determining how you are going to integrate the UNIX or Linux user accounts and applications into the existing Active Directory structure in the organization. The following list enumerates the planning considerations that are going to be needed: Organizational Unit (OU) hierarchy Will the UNIX and Linux user accounts in Active Directory: Exist in your current OU structure for users? Be placed in a new OU that you use to contain users with UNIX or Linux attributes? Microsoft recommends placing the users into your standard OUs used to store your Active Directory users; there should be no need to differentiate between the two types of users. This recommendation differs slightly from the recommendation in the "Logical Design of the Kerberos Security Services" section earlier in this chapter. If you are implementing a security and a directory services solution, then you can either: Follow both sets of guidance and use two OUs, one for migrated users, and the other for storing Active Directory users in a standard OU. Create an extra OU for UNIX and Linux users for use during the migration period. 151

152 Naming constructs The naming standards required by the UNIX or Linux accounts will need to meet the existing standards, or changes to existing standards will be required for integration into the Active Directory. For example: Historically, UNIX and Linux account names could not contain uppercase letters. You should determine if this restriction applies in your environment. For historical compatibility, UNIX and Linux account names may need to be kept to a maximum length of eight characters. You should determine the length of user names that can be supported in your environment. Logical Design of the Domain Name System Infrastructure The security and directory solutions presented in this guide all require a working DNS infrastructure. Windows Server 2003 includes a standards-compliant DNS server that is fully integrated with Windows Server 2003 Active Directory. The DNS server commonly used on UNIX and Linux servers is the Berkeley Internet Naming Domain (BIND). The main features of these two DNS servers are compared in Table 5.4. Table 5.4: Feature Support in Different Implementations of DNS Feature Supports RFC 2782: A DNS RR for specifying the location of services (DNS SRV) Windows Server 2003 Dynamic update Yes Yes Secure dynamic update based on the GSS- Transaction Signature (TSIG) algorithm Secure dynamic update based on fixed key Transaction signatures (TSIG) WINS and WINS-R records Yes No Incremental zone transfers Yes Yes UTF-8 character encoding Yes No Integrated DNS management into Windows Server 2003 MMC Active Directory integrated zones Yes No Stub zones Yes Yes Conditional forwarding Yes Yes Yes Yes No Yes BIND 9.2 Yes No Yes No Note More information on the Windows Server 2003 DNS server can be found at More information on the BIND DNS server can be found at The requirements for the DNS infrastructure include the following: The solution must be standards-based. This requirement can be met either by Windows Server 2003 DNS or by the BIND DNS server. Zone transfers, dynamic updates, and other key features of the DNS service must be secured with appropriate standards-based security mechanisms. 152

153 Service locator records (SRV) must be supported (RFC 2782). Support for SRV records is required for Windows Server 2003 Active Directory and is used to locate the Kerberos and LDAP services. Ideally, Dynamic DNS (DDNS) updates will be supported (RFC 2136). DDNS can reduce the administrative workload required to maintain the DNS database. While DDNS is not a mandatory requirement, it is desirable. If you do not use DDNS, you must update records manually. The most important issue for deciding whether to use DDNS with BIND is security. This is discussed later in this section. For efficiency, it is desirable that the solution supports incremental zone transfers (IXFR). These are supported by Windows Server 2003 DNS and by BIND versions from 8.2 onwards. With IXFR, a DNS server can transfer only those portions of a zone that have changed since the last time the secondary server was updated. This reduces network traffic related to maintaining up-to-date zone information. You must make a number of important decisions as part of the planning process. These decisions affect not only the version of BIND that you use, but also the domain structure or namespace that your network will use and the deployment options that are available to you. The solutions that you must consider when designing your DNS infrastructure are summarized in the following list: Use only Windows Server 2003 DNS servers In this scenario, Domain Name System (DNS) services are provided exclusively by Windows Server 2003 DNS servers. Active Directory, all Windows, and all UNIX computers use the Windows Server 2003 DNS servers for name resolution. Existing DNS servers are migrated to Windows Server 2003 DNS. Microsoft recommends this solution because it has the following advantages: Excellent integration with the Active Directory management tools. Benefits from multiple master operations as a result of replication within Active Directory. Fully integrated security mechanisms based on Kerberos 5. Backward compatibility with other DNS servers where required. Use only BIND DNS servers In this scenario, DNS services are provided exclusively by UNIX BIND servers. Active Directory, all Windows computers, and all UNIX computers use the BIND DNS servers for name resolution. While this is not the recommended solution, it may be necessary because of the historical use of BIND DNS servers within your organization. You have two options when using BIND DNS servers: Use BIND DNS servers with DDNS enabled. Dynamic DNS (DDNS) is permitted for a restricted set of computers, including the Windows Server 2003 Dynamic Host Configuration Protocol (DHCP) server and domain controllers. Use BIND DNS servers without DDNS enabled. In this model, the DNS resource records that typically would have been created automatically by computers that are members of the Active Directory domain are entered manually into a static name server. The most important issue when deciding whether to use DDNS with BIND is security. This is covered in detail in the "Dynamic DNS Updates" section later in this chapter. 153

154 Use a combination of Windows Server 2003 DNS servers and BIND DNS servers In this scenario, the DNS infrastructure is provided by both Windows Server 2003 DNS and BIND. There are two main ways of implementing this scenario: Mixed Windows Server 2003 DNS and BIND DNS serving the same domain In this scenario, Windows Server 2003 DNS servers are installed into the same domain as the existing UNIX BIND DNS servers. Active Directory is set up to use the same root domain name as the organization's domain name. The BIND DNS servers retain primary control of the organization's domain name and reverse lookup zones. The Windows Server 2003 DNS server acts as a secondary server. Windows Server 2003 DNS implemented in a subdomain In this scenario, all Windows computers are placed into a subdomain under the organization's domain name. The organization's domain name's zone data is held on BIND DNS servers There are several DNS server capabilities that you should consider when deciding which version of the BIND DNS server to use. The two most important considerations are support for service locator records and dynamic updates. The following two sections describe these capabilities in more detail. Service Locator Records When choosing a version of the BIND DNS server, the first issue to consider is whether the version of BIND you intend to use supports service locator records (SRV). This is a mandatory requirement for interoperability with Active Directory. SRV records enable clients to locate a number of Active Directory entities, including: Domain controllers Lightweight Directory Access Protocol (LDAP) services Global catalog servers Kerberos Key Distribution Centers A typical resource SRV record looks like this example: _ldap._tcp.example.com 600 SRV dc.example.com This record would be used to find the LDAP server for the example.com domain. In this record, the parameters have the following meanings: _ldap is the service advertised. _tcp is the transport protocol. The services are being supplied to the example.com domain. 600 represents the Time-to-Live (TTL) for the record. 0 is the priority, and 100 is the weight. Priority and weight are automatically adjusted, so these parameters are only useful in non-ddns environments. 389 is the port. dc.example.com is the domain controller that hosts the service. 154

155 When Windows Server 2003 Active Directory clients initialize, they attempt to contact a DNS server to obtain the address of a domain controller. This information is stored in an SRV record in the DNS database. Without these records, Windows Server 2003 Active Directory clients cannot log on. Active Directory also requires that the DNS server support SRV records. You cannot install Active Directory without a suitable DNS server. Dynamic DNS Updates When choosing the version of BIND DNS server to use, you must also decide whether it will support dynamic DNS (DDNS) updates. Although this is not a required service for Windows Server 2003 Active Directory, it has several benefits that make it desirable. Most importantly, it reduces the need for administrators to edit and maintain DNS configuration files manually. BIND P5 and later versions support DNS Security (DNSSEC) and Transaction Signatures (TSIG)-authenticated dynamic updates. Because the IETF standards were not in place when Windows 2000 was being designed, Microsoft implemented a different secure dynamic update mechanism using Generic Security Service-Transaction Signatures (GSS-TSIG) and based upon IETF draft documents. These two secure dynamic update mechanisms are incompatible. Thus, at present, secure DDNS cannot be enabled on the BIND server if it supports Windows clients. If you configure your BIND server to accept unsecured updates, it will accept changes from any client without requiring authentication. As a result, BIND servers supporting unsecured DDNS are vulnerable to IP spoofing attacks. Furthermore, Windows Server 2003 provides secure updates only when the DNS zones are configured as Active Directory integrated zones, and this, in turn, requires the use of a Windows Server 2003-based DNS server on a domain controller. If you configure the Windows Server 2003 DNS zones as standard primary zones, no security is provided. Again, this exposes the DNS server to IP spoofing attacks. There are three methods to minimize the exposure: Do not permit dynamic DNS updates. Restrict updates to trusted IP addresses. Delegate specific zones to Windows 2000 DNS servers and allow Windows 2000 clients to use the secure DDNS provided by Windows Additional DNS Infrastructure Design Considerations When designing your DNS infrastructure, you should consider a number of additional issues. The following list describes these issues and provides you with the information that you need to make informed design decisions: Incremental zone transfers Versions of BIND earlier than 8.2 do not support incremental zone transfer (IXFR), which is based on RFC Windows Server 2003 DNS supports servers that cannot use IXFR. If a secondary server does not support IXFR, Windows Server 2003 DNS uses asynchronous full zone transfer (AXFR). Negative caching Negative caching (RFC 2308) is a feature that stores names and records sets that are known not to exist. It is used to prevent unnecessary lookups for these names and, hence, it can reduce DNS network traffic. BIND Version 8.2 supports this feature. 155

156 DNS change notification DNS change notification (RFC 1996) is a mechanism that allows primary DNS servers to notify secondary servers when a zone has changed. The secondary server can then request an incremental zone transfer to obtain the information it needs. BIND Version 8.2 supports this mechanism. Non-standard resource record types Windows Server 2003 uses additional record types, such as the WINS and WINS- R records. Third-party servers may drop these records or be unable to process a zone transfer. Make sure your DNS servers will handle these records gracefully. You can also prevent Windows Server 2003 DNS from attempting to replicate these records. When the Windows 2000 DNS server encounters a record it does not recognize, it drops the record and continues. It also drops circular CNAME records. Optional services that require Windows Server 2003 DNS A number of Windows Server 2003 services require an Active Directory-compatible DNS server to function, including Microsoft Remote Installation Services (RIS). Load balancing of services For non-windows Server 2003-based DNS servers, you must also consider how you will load balance services. For instance, Windows Server 2003 uses a Kerberos KDC service as part of the authentication mechanism. You must ensure your BIND database is configured to distribute the load among the Windows Server 2003 KDCs instead of sending all client requests to a single KDC. Note For more information on these and other issues, refer to the Windows Server 2003 Server Resource Kit at Physical Design of the Security and Directory Services The physical design of the network is important because it ensures that the services are both efficient and secure. Because of the nature of this guide and the wide variations in physical hardware that are likely to be in place in various organizations, it is not possible to give detailed guidance for the physical design. However, you should consider the following issues and how they relate to your organization. Network Topology Your network topology is already likely to have been decided at this point, although it is worth reviewing because you may be able to improve the performance of the network. You should choose a topology that best reflects the requirements of your organization, bearing in mind that there is an associated cost both financially and in terms of management with the more complicated topologies. Providing your Windows, UNIX, and Linux computers with good bandwidth and low latency on the network links to the servers providing Kerberos and LDAP services is important. Specifics will vary from organization to organization. 156

157 Security Considerations for Server Placement Servers containing authentication and authorization data should be kept as secure as possible. These servers should not be placed in any location where they are accessible to the public or unauthorized people. There should be sufficient network protection to block access to all TCP/IP ports that are not required for authentication or authorization services, and the computer should be positioned so as to restrict physical access to only trusted personnel. Ideally, a slave server should be located at a separate location to the master, bearing in mind that the slave server has the same security requirements as the master. Performance Considerations For large-scale infrastructures, there is a need to ensure that the server is capable of processing the maximum number of user connections at a peak time, such as the start of a business day. The computer should have sufficient memory, processor capability, and bandwidth available to answer all requests. Should your organization be on a scale which is not easily handled by a single server, then you should consider implementing one or more slaves or splitting your organization into two or more realms. 157

158 Validate the Technology Often in parallel to the design process, the team validates the technologies being used in the solution. During technology validation, the team evaluates the products or technologies to ensure that they work according to specifications provided by their vendor and that they will meet the business needs for the specific solution scenario. Technical Proof of Concept After validating the technologies, the team then makes an initial pass at creating a model of the technology to be implemented. This is the initial iteration of an effort that later produces a proof of concept (in the Developing Phase), and ultimately the development of the solution itself. This initial proof of concept model often produces both answers and additional questions for the team. This information helps in the risk management process and identifies changes needed to the overall designs that must be incorporated into the specifications. You can use the procedures and guidance in Chapter 7, Developing Heterogeneous Kerberos Security Solutions, and Chapter 8, Developing the LADP Security and Directory Infrastructure, to create your proof of concept. Baselining the Environment During this time, the team must also conduct an audit, sometimes known as discovery, of the current-state of the production environment in which the solution will operate. Information is collected on server configurations, the physical network, desktop software, and all relevant hardware. This baseline allows for the team to account for any changes required or design issues that may cause the solution to be at risk. This baselining step is critical to the success of a migration project. You must thoroughly understand where your organization is today before you can effectively plan how to move forward. Interim Milestone: Technology Validation Complete At this point, the team has confirmed the high-level features and functionality of the technologies planned for use and has sufficiently documented the current environment. The team is comfortable that all issues have been addressed or tracked sufficiently to move forward with creating the functional specification. 158

159 Create the Functional Specification The functional specification is the technical description of the solution and represents the contract between the customer and the project team. It is the basis for building project plans and schedules. The Program Management Role takes the lead in creating it, with input from the role leads regarding their areas of responsibility. During the Planning Phase, the functional specification is baselined and placed under change control. Because it includes all requirements documents and design specifications, the functional specification contains the information required to design the solution. It serves as formal documentation of the design process, and it incorporates the conceptual, logical, and physical designs. Accordingly, high-level design decisions such as server placement and network configuration should be included in the functional specification. A basic functional specification should include the following: A summary of the vision/scope document as agreed upon and refined, including background information to place the solution in a business context Any additional user and customer requirements beyond those already identified in the vision/scope document The solution design as developed in the "Develop the Solution Design and Architecture" section in this chapter Specifications of the components that will be part of the solution The functional specification must describe, without ambiguity, the complete functionality of the solution under development. Quantitative measurements should be included in the functional specification whenever possible. Quantifying performance or business metrics in a functional specification is significant because the information can be used to drive justifications (in development and operations, for example) for a project. These metrics are as much a part of the specification as any other functional details. The following items are examples of information that should be included in a functional specification when planning heterogeneous security and directory solutions: Features. The functional specification should document the complete set of planned features for the solution. The features of the solution should be expressed using both words and diagrams, if possible. Quantitative specifications for the solution, such as the number of user accounts, concurrent user capacity, authentication and directory performance metrics, and so on should be clearly stated. Security requirements. A functional specification should specify the strength of security to be used for LDAP binds, Kerberos authentication, and so on, including a description of any encryption standards to be used. A description of the type and location of security systems such as the KDCs and the LDAP servers should be included. Legal requirements. Legal requirements must be clearly understood and stated in a functional specification, including what needs to be done to adhere to these requirements (for example, custom code to meet a custom user scenario, governmental requirements, or business policy). Risk analysis documents. Risk analysis documents should include descriptions of potential impact to the project and mitigation strategies. For example, the risk analysis documents should state what the risk of failing to obtain necessary hardware would be and provide a mitigation strategy for dealing with this risk. 159

160 The following are examples of information that should not be included in a functional specification when planning heterogeneous security and directory solutions: Details of software architecture. Too much detail in a functional specification can overburden a project team with extraneous facts. Detailed directory schema. A high-level description of directory details is sufficient to include in a functional specification. These details should be determined and finalized during the Developing Phase. The Developing Phase is covered in the following chapters of this guide: Chapter 6, "Developing the Infrastructure for Heterogeneous Security and Directory Solutions" Chapter 7, "Developing Heterogeneous Kerberos Security Solutions" Chapter 8, "Developing the LDAP Security and Directory Infrastructure" Interim Milestone: Functional Specification Baselined At this interim milestone, the functional specification is complete enough for customer and stakeholder review. At this point, the team baselines the specification and begins formally tracking changes. The functional specification is maintained as a detailed description of the various solution components and how the solution will look and operate. It can be changed only with customer approval. The functional specification is the basis for building the master project plan and schedule. 160

161 Develop the Project Plans The UMPG describes a number of different project plans that may be required by a migration project. Nearly every project will require a development plan and a test plan, and this is no different for this project. Additionally, your security and directory project will also require other plans. You should create project plans that you require for your specific solution based on the guidance in this guide. Your first step should be to determine which plans are necessary for your project. This section helps you to do that effectively. You must then develop your plans using this guide to formulate the steps necessary in each plan. You will require at lest the following plans: Security plan Budget plan Resource plan Development plan Test plan Deployment plan Pilot plan Operations plan A project team should review the various plans in the UMPG and determine which apply to their situation and that should become a part of the master project plan. Project sizes vary and not all master project plans require each subplan. Guidance on when you require each of these plans is provided in the following sections. Develop the Security Plan The security and directory solutions presented in this guide are closely linked to your organization's security. Therefore, it is important that you develop a security plan. When developing this plan, you may need to perform all of the following: Validate that the solution meets the organization's security policy. Ensure that any necessary changes are made to the organization's security policy arising from this solution. Ensure continuity of security during solution deployment. Provide security guidance to the users. Provide security guidance to the solution administrators. Develop the Budget Plan The budget plan is important to ensure that the project adheres to the project's budget and that it meets any cost-benefit goals. The budget plan should include the costs of each part of the master project plan. You should factor into the budget plan equipment, software, training, and resource costs. In the solutions presented in this guide, one key cost differentiator is the fact that the PADL software is free and the VAS software is a commercial product. 161

162 Develop the Resource Plan The resource plan is closely linked to the budget plan. It is focused on the resources required to deliver the project according to the master project plan. As has been previously mentioned, it will be necessary to include technical resources with UNIX, Linux, and Windows skills. Develop the Development Plan The development plan is a crucial plan; it must take into account all of the development stages relevant to your organization and chosen solution. The steps necessary for developing the security and directory solutions covered by this guide are found in Chapters 6 through 8. Develop the Test Plan The test plan is a crucial plan, too; it must take into account all of the appropriate testing for your organization's chosen solution. Of particular importance with the security solutions presented in this guide is the testing of the security settings to ensure that they conform to the organization's security policies. Another critical area is that of performance. The security and directory solutions presented in this guide are both critical to the performance of the client operating systems and applications. It is important that testing confirm the scalability of your solution to the number of users in your organization. The test plan should be based on the steps found in Chapter 9, "Testing Windows-based Security and Directory Services." Develop the Deployment Plan Another crucial plan is the deployment plan. The deployment plan is different for each organization and for each of the solutions in this guide. Chapter 10, "Deploy a Windowsbased Security and Directory Solution," covers the steps that must be included in your deployment plan. Develop the Pilot Plan Many organizations should plan to undertake a pilot deployment of the solution. The pilot plan will be based on the deployment plan, but it must take into account the fact that a pilot must be capable of operating alongside legacy systems with minimal impact. Develop the Operations Plan The operations plan should include preparing the operations team and infrastructure for the operation of the solution after it has been successfully deployed. It should include the following: Training for the operations team The updating of operations procedures The writing of operations procedures to cover new functions not required by the legacy environment Skills transfer from the development team to the operations team The skills and procedures necessary to operate the solutions in this guide are covered in Chapter 6 through Chapter

163 Interim Milestone: Master Project Plan Baselined At this point, the team has rolled-up all initial drafts of the plans to create the master project plan. The master project plan is required to create estimates for the time required to fulfill these project plans. This then becomes the basis of the master project schedule. Adjustments to these documents may be necessary as the project moves forward. It is important, however, to ensure that enough of a base exists to provide clarity for schedule estimation before the transition into the Developing Phase. 163

164 Set Up the Development and Test Environments The development, testing, and staging environments must be properly set up before moving into the Developing Phase to maximize development team productivity and to mitigate risks. To avoid delay, the development and testing environments should be set up even as plans are being finalized and reviewed. The MSF Release Management Role is typically responsible for performing these tasks for the project team. Establishing a development environment entails setting up hardware and other infrastructure resources, as well as any project structure or policy elements that will guide solution development activities. The team should install the hardware and infrastructure according to the configurations established in the development plans. Policies include those that ensure all members of the development team are using compatible versions of software and tracking all bugs. The process of creating the testing environment is centered on setting up the architecture (hardware) according to the configurations established in the test plan and obtaining approval from the development team in this decision process. Similar to the development environment, the testing environment should be designed to emulate the production environment as closely as possible, but the team must balance the level of representation with the associated costs. Other necessary choices to make for the testing environment include deciding on a common bug-tracking utility and other tools. This is the point in the project where all solution software is installed. The staging environment is where the team tests content and software being changed or deployed to ensure that they function as expected. The content and software are moved from the development environment to the staging environment before they are published to the production environment. Solution components successfully tested in the development environment may not necessarily work after all elements are in place and have been integrated. The staging environment provides a place for all solution elements to make sure they work before being put into production. Hardware and software installed in the staging environment should mimic the production environment as closely as possible. Depending upon the availability of hardware resources, an individual server can perform several different server roles in the staging environment. However, it should be recognized that all deviations from the production environment detract from the representative value of testing, and should therefore be clearly known, understood, agreed upon, and tracked. Ideally, the staging servers are built according to the documented server build procedures that are developed. This ensures that testing accurately portrays what will be seen in production. The guidance in Chapters 6 through 8 of this guide should be used as a basis for the procedures used to configure the development and test environments. Interim Milestone: Development and Test Environment Set Up At this point, the team has the necessary settings in place to enable the work of building and stabilizing the solution. With the environment setup completed, the team can now begin shifting its focus entirely to development work involved in migrating. 164

165 Close the Planning Phase Closing the Planning Phase requires completing a milestone-approval process, culminating in the Project Plans Approved Milestone. The team must document the results of all of the tasks it has performed during this phase before submitting the project to key stakeholders and customers for approval. Key Deliverables from the Planning Phase A deliverables checklist for the Planning Phase includes: Functional specification Master project plan Master project schedule Updated risk management documents You should refer to the UMPG for any of these deliverables that have not been covered in this chapter. Key Milestone: Project Plans Approved At the Project Plans Approved Milestone, the project team and key project stakeholders agree that interim milestones have been met, due dates are realistic, project roles and responsibilities are defined, and mechanisms are in place for addressing areas of project risk. The team approves the functional specification, the master project plan, and master project schedule, which then become the project baseline and provide the basis for making future trade-off decisions. The baseline takes into account the various decisions that are reached by consensus by applying the three project planning variables: resources, schedule, and features. After the baseline is completed and approved, it is placed under change control. This does not mean that all decisions reached in the Planning Phase are final. But it does mean that as work progresses in the Developing Phase, the team should formally review and approve any suggested changes to the baseline by using a change control process. Project teams usually mark the completion of a milestone with a formal sign-off. Key stakeholders, typically including representatives of each team role and any important customer representatives who are not on the project team, signal their approval of the milestone by signing or initialing a document stating that the milestone is complete. The sign-off document becomes a project deliverable and is archived for future reference. Summary This chapter has provided guidance on how to plan your security and directory solutions based on Windows Server 2003 Active Directory. At this point, key decisions have been made, and it is now possible to progress to the development of the solution. 165

166

167 Part 2: Build 167

168

169 6 Developing the Infrastructure for Heterogeneous Security and Directory Solutions Introduction This chapter provides guidance on how to develop the infrastructure that is required to implement heterogeneous security and directory services using Microsoft Windows Server 2003 Active Directory. This guidance covers infrastructure configuration in heterogeneous environments consisting of the Windows Server 2003, UNIX, and Linux platforms. Specifically, the infrastructure required before implementing heterogeneous security and directory services includes the Domain Name System (DNS), Active Directory, and a time service. Although the development work is the focus of this phase, and the Development Role is thus the primary driver for the phase, all team roles are active in building and testing deliverables. For instance, the User Experience Role will be creating training materials. See Chapter 4, "Developing Phase," in the UMPG for more guidance about team roles during this phase. Some development work may continue into the Stabilizing Phase in response to testing. The phase formally ends with the Scope Complete Milestone. At this major milestone, the team gains formal approval from the customer and key stakeholders that all solution elements are built and the solution features and functionality are complete according to the functional specifications agreed upon during Planning. The following list represents a breakdown of the tasks involved in developing your solution: Develop the solution components Build or migrate system tests to be used during the Stabilizing Phase Build a proof of concept Build the solution in a series of daily builds Test the solution (for example, perform security testing and validate system tests) 169

170 See the UMPG for process guidance about completing the tasks. Chapters 6 through 8 provide technical information instead of process guidance. This chapter is a prerequisite for the later chapters in this guide. You should read and implement the guidance here before proceeding to implementing the solutions covered in Chapters 7 and 8. Building the Solution When planning your heterogeneous security and directory solution, you chose a specific scenario from the range of solutions presented by this guide; only specific sections of this chapter are relevant to that scenario. Therefore, you should implement only the sections from this chapter necessary for your scenario as described in Chapter 5, "Planning Heterogeneous Security and Directory Solutions." All solutions require you to follow the guidance in the following sections in this chapter: "Configuring the Domain Name System" "Configuring the Windows Server 2003 Active Directory Domain Controllers" Kerberos solutions also require you to follow the guidance in the "Configuring Time Services" section in this chapter. Configuring the Domain Name System Before you can proceed with implementing your security and directory solutions using Windows Server 2003 and Active Directory, you must first have a functional DNS. DNS is required for the following reasons: DNS is a prerequisite for Active Directory. Active Directory cannot be installed or configured without DNS. Domain names are used to reference the root of each Active Directory domain tree. DNS is also used by computers in the domain to find key services, such as the domain controllers, Kerberos services, Lightweight Directory Access Protocol (LDAP) services, and global catalog servers. Kerberos 5 uses DNS to locate Kerberos domain controllers. In a Windows Server 2003 Kerberos environment, Windows clients use DNS to locate the Kerberos domain controllers. Some UNIX and Linux clients are also capable of locating the Kerberos domain controllers using DNS. LDAP requires DNS to find the rootdsc. LDAP clients and servers use DNS to find the root of the LDAP directory (rootdsc). They can also use DNS SRV records to locate LDAP services for a domain. The following section addresses the most common DNS scenarios found in a heterogeneous UNIX, Linux, and Windows environment. Note Before designing and implementing your DNS infrastructure, Microsoft recommends that you read the "Deploying DNS" section from the Windows Server 2003 Deployment Kit at wsserver2003/proddocs/deployguide/dnsbd_dns_overview.asp. 170

171 DNS Scenarios in a Heterogeneous Environment A range of possible scenarios exist for providing a DNS service in a heterogeneous environment. These scenarios include: Use only Windows Server 2003 DNS servers. In this scenario, DNS services are provided exclusively by Windows Server 2003 DNS servers. Active Directory, all Windows computers, all UNIX computers, and all Linux computers use the Windows Server 2003 DNS servers for name resolution. Existing DNS servers are migrated to Windows Server 2003 DNS. Use only BIND DNS servers. In this scenario, DNS services are provided exclusively by UNIX or Linux BIND servers. Active Directory, all Windows computers, all UNIX computers, and all Linux computers use the BIND DNS servers for name resolution. When using UNIX BIND servers for DNS, you can choose to enable or disable Dynamic DNS (DDNS). These two options are described here: Use BIND DNS servers with DDNS enabled. DDNS is permitted for a restricted set of computers, including the Windows Server 2003 Dynamic Host Configuration Protocol (DHCP) server and domain controllers. Use BIND DNS servers without DDNS enabled. In this model, the DNS resource records that normally would have been created automatically by computers that are members of the Active Directory domain are entered manually into a static name server. Use a combination of Windows Server 2003 DNS servers and BIND DNS servers. Mixed Windows Server 2003 DNS and BIND DNS serving the same domain. In this scenario, Windows Server 2003 DNS servers are installed into the same domain as the existing UNIX or Linux BIND DNS servers. Active Directory is set up to use the same root domain name as the organization's domain name. The BIND DNS servers retain primary control of the organization's domain name and reverse lookup zones. The Windows Server 2003 DNS server acts as a secondary server. Windows Server 2003 DNS implemented in a subdomain. In this scenario, all Windows computers are placed into a subdomain under the organization's domain name. The organization's domain name's zone data is held on BIND DNS servers. 171

172 The details of configuring DNS in each of these scenarios are beyond the scope of this guide. However, DNS configuration for each of these scenarios is extensively covered in other documents. Table 6.1 directs you toward the documents you should read when configuring your DNS infrastructure. Table 6.1: DNS Resources and References DNS Scenario General background reading Use only Windows Server 2003 DNS servers Use only BIND DNS servers Use a combination of Windows Server 2003 DNS servers and BIND DNS servers References "Deploying DNS" section from the Windows Server 2003 Deployment Kit at p?url=/technet/prodtechnol/windowsserver2003/prod docs/deployguide/dnsbd_dns_overview.asp BIND 9 Administrator Reference Manual at DNS and BIND (Albitz and Liu, 2001) DNS on Windows 2000 (Larson and Liu, 2001) Domain Name System (DNS) Center Knowledge Base Articles at /communications/dns/dnskbs.asp HOW TO: Migrate an Existing DNS Infrastructure from a BIND-Based Server to a Windows Server 2003-Based DNS at -us; Using BIND DNS Servers with Windows 2000 at bind.doc Using BIND DNS Servers with Windows 2000 at bind.doc DNS Configuration Issues for Windows Server 2003-based Security and Directory Solutions This section highlights the specific configuration issues that are important when configuring DNS for the purpose of providing security and directory services using Windows Server These issues involve: The use of SRV resource records The DNS scenario that you choose must support SRV resource records. This is a mandatory requirement of Active Directory. The use of SRV resource records also simplifies the configuration of Kerberos clients. Securing DNS servers You must ensure that your DNS servers are physically and logically secure. Security issues with the DNS service will compromise your security and directory services. Configuring secure Dynamic DNS updates If you are using Dynamic DNS updates, you must secure them; otherwise, your security and directory services will be compromised. 172

173 Limiting zone transfers to authorized systems If you have configured DNS zone transfers, then you must ensure that the transfers are secured; otherwise, your security and directory services will be compromised. Dynamic DNS When choosing a DNS scenario, you should consider the benefits of choosing one that allows you to use Dynamic DNS securely. Dynamic DNS reduces the need for administrators to edit and maintain DNS configuration files manually. To maximize the effectiveness of your directory and security solution, it is wise to make use of the load balancing facilities that are present in the Windows Server 2003 implementation of DNS. This is described in depth in the following section. Configuring Windows Server 2003 DNS to Use Round Robin for Load Balancing Round robin is a load balancing mechanism used by DNS servers to share and distribute network resource loads. You can use it to rotate all Resource Record (RR) types contained in a query answer if multiple RRs are found. By default, DNS uses round robin to rotate the order of RR data returned in query answers where multiple RRs of the same type exist for a queried DNS domain name. This feature provides a simple method for load balancing client use of Web servers and other frequently queried computers with multiple IP addresses (multihomed computers). If round robin is disabled for a DNS server, the order of the response for these queries is based on a static ordering of RRs in the answer list as they are stored in the zone (either its zone file or Active Directory). Example: Round-Robin Rotation A forward lookup-type query (for all record type A RRs that match a DNS domain name) is made for a multihomed computer (multihomed.example.microsoft.com) that has three IP addresses. Separate A RRs are used to map the host's name to each of these IP addresses in the zone. In the stored example.microsoft.com zone, the RRs appear in this fixed order: multihomed IN A multihomed IN A multihomed IN A The first DNS client that queries the server to resolve this host's name receives the list in default order. When a second client sends a subsequent query to resolve this name, the list is rotated as follows: multihomed IN A multihomed IN A multihomed IN A

174 Restricting Round-Robin Rotation for Selected RR Types By default, DNS will perform round-robin rotation for all RR types. You can specify that certain RR types should not be included in the round-robin rotation in the registry. A registry entry called DoNotRoundRobinTypes (REG_SZ) has a string value containing a list of RR types. By modifying this entry, you turn off round-robin rotation for specific RR types. For example, to prevent round-robin rotation for A, PTR, SRV, and NS record types, you would enter the following value for the registry entry: a ptr srv ns Restricting Round-Robin Rotation for All RR Types The default setting for round-robin rotation is contained in the registry entry RoundRobin (REG_DWORD). By default, this entry's value is 1, which rotates all RR types except those listed in the DoNotRoundRobinTypes registry entry. If the value of RoundRobin is set to 0, then no RR types will be round-robin rotated. Warning Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. You can also use the Last Known Good Configuration startup option if you encounter problems after manual changes have been applied. Note The string value for the DoNotRoundRobinTypes registry entry may contain types in numeric (as shown earlier) or mnemonic formats. Both of the round-robin registry entries must be created and stored in the following registry subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters Local subnet priority supersedes the use of round-robin rotation for multihomed names. When enabled, round robin continues to be a secondary method used to sort multiple RRs returned in a listed answer. More information about configuring round-robin operation on Windows Server 2003 DNS can be found at server2003/proddocs/entserver/sag_dns_imp_roundrobin.asp. 174

175 Configuring the Windows Server 2003 Active Directory Domain Controllers You must implement Active Directory before implementing a heterogeneous security and directory infrastructure based on Windows Server 2003 Active Directory. The implementation of Active Directory and all that it entails is beyond the scope of this guide. It is covered extensively in other Microsoft guides, support material, and training courses. This section serves as a high-level reminder of the tasks that you must complete before implementing the guidance in this guide. Installation and Configuration of Active Directory You need to implement Windows Server 2003 Active Directory. Depending on the size of your organization, the implementation of Active Directory can vary significantly in size. The following guides, documentation, and training will assist you in implementing Active Directory. You can find information about deploying Windows Server 2003 Active Directory at /windowsserver2003/default.asp. The book, Active Directory, 2nd Edition (Allen and Lowe-Norris, 2003) provides guidance on installing and configuring Active Directory. The Microsoft training course, 2279: Planning, Implementing, and Maintaining a Microsoft Windows Server 2003 Active Directory Infrastructure provides the skills necessary to plan, implement, and troubleshoot the key components of a Microsoft Windows Server 2003 directory service environment. Network Configuration for Active Directory The design and implementation of the network infrastructure used by Active Directory is crucial to its operation. It is also essential for security and directory services based on Active Directory. Before implementing the solutions covered in this guide, you must have an operational network. For useful resources when configuring your network to support the solutions in this guide, see the Windows Server 2003 Networking and Communications How-to Articles at 3%20Networking%20and%20Communications%20Howto%20Articles&LL=kbwinserv2003search&Sz=kbnetwork%20and%20(kbhowtomaster%2 0or%20kbhowto)&product=winsvr2003. Securing Active Directory The security of Active Directory is extremely important when your Windows, UNIX, or Linux infrastructure will use Active Directory for security and directory services. Before proceeding with implementing the solutions covered in this guide, you should implement the guidance contained in the Windows Server 2003 Security Guide at /w2003hg/sgch01.asp. 175

176 Configuring Time Services Kerberos 5 authentication is dependent upon the synchronization of the internal clocks within the Kerberos domain. Before proceeding with building a security solution using Kerberos, it is necessary to set up a time service to ensure this required accuracy. Windows Server 2003 time services are based upon the Simple Network Time Protocol (SNTP); this is a simplified version of the UNIX Network Time Protocol (NTP). The packet formats of both protocols are identical, and the servers and clients for each can be used interchangeably. More information about the time service protocols can be found in the RFCs for each protocol. These are as follows: RFC 2030: "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6, and OSI" RFC 1305: "Network Time Protocol (Version 3) Specification, Implementation, and Analysis" Version 4 of NTP is currently in development and has yet to be released as a RFC. More information on the specifics of implementing time services in the Active Directory environment can be found in The Windows Time Service (Brandolini and Green) at The following sections address the most common configuration scenarios for setting up time servers and clients in a heterogeneous environment. Time Services Scenarios in a Heterogeneous Environment A range of possible scenarios exist for providing a time service in a heterogeneous environment. These scenarios include: A Windows Server 2003 primary domain controller (PDC) emulator synchronized to an Internet time source A Windows Server 2003 PDC emulator providing the synchronization time A Windows Server 2003 PDC synchronizing to the domain source A UNIX or Linux server synchronized to an Internet time source A UNIX or Linux server providing the synchronization time UNIX, Linux, and Windows clients in these scenarios need to be configured to synchronize their clocks with the server regularly and efficiently. Because SNTP and NTP protocols are interchangeable, the configuration of clients is the same regardless of the type of server being accessed. Note This section will only cover the client/server time service architecture. Broadcast and multicast time services are beyond the scope of this document, as is the configuration of GPS systems as the ultimate source of time. 176

177 Before you begin to configure your time service, you must consider the following issues: The choice of Internet time server There are two tiers of time servers available on the Internet. Tier One servers are the ultimate sources of time. They are usually linked to atomic clocks and are heavily loaded. Tier Two servers are those that synchronize to the Tier One servers. These are still very accurate, but are many more in number and have much less load. You should choose the server or servers that you are synchronizing with after considering the servers' geographical location, reliability, and any access requirements imposed. To this end you, should research any time server to ensure that it can meet your requirements, as described in Chapter 5, "Planning Heterogeneous Security and Directory Solutions." A list of publicly accessible time servers is available from The configuration of firewalls and routers NTP and SNTP run on port 123. This port needs to be opened on all firewalls and routers both internal and perimeter to ensure that the synchronization network traffic is available. It is also vital to consider the security of the time service because a malicious attacker could attempt to gain access through a poorly secured service. Details on securing your Windows and UNIX or Linux Kerberos domain controllers are covered in Chapter 7, "Developing Heterogeneous Kerberos Security Solutions." The layout of your time service SNTP and NTP are hierarchical protocols, with a single time source synchronizing many lower servers, and then these lower level servers finally synchronizing clients. You should choose your primary and secondary servers so as to maximize availability and to minimize cross-network traffic. In particular, the following recommendations are made by the authors of NTP: Do not use another peer in the same stratum to synchronize to unless it is receiving time from another, lower stratum server that the synchronizing server has no direct connection to. Do not synchronize more than one time server within a domain to a single source outside of that domain. This creates both a single point of failure and a potential source of misuse. Configuring Time Services on Windows Servers Warning The following instructions contain details about modifying the registry. Before you do this, make sure you know how to back up, restore, and edit the registry. For more information, see the "Description of the Microsoft Windows Registry" Knowledge Base article at As the preceding section shows, there are three scenarios for the configuration of the Windows Server 2003 time service. The recommended method is to synchronize with a GPS device; the configuration of this is beyond the scope of this document. The second best solution is to use synchronization with an Internet time server. The alternative of using the local server as the source of time should only be used where Internet connectivity is unavailable. 177

178 SNTP and NTP use coordinated universal time (UTC). UTC is based on an atomic time scale and is independent of time zone. Therefore, it is essential that you have the correct time zone set on your clients so that the correct time for your time zone can be calculated. The Windows Server 2003 time service (W32Time) is administered through the use of the w32tm tool. This tool provides configuration and debugging facilities for all aspects of the functioning of the time service. It is a command line tool and the options available are listed in Table 6.2. Table 6.2: w32tm Command Line Tool Options Option /register /unregister /monitor [/domain:<domain name>] [/computers:<name>,[<name> ]] [/threads:<num>] /ntte /ntpte /resync [/computer:<name>][/nowait] [/rediscover][/soft] /stripchart /computer:<name>[/period:<refresh>] [/dataonly][/samples:<count>] /config [/computer:<name>][/update] [/manualpeerlist::<peers>] [/syncfromflags:<source>] [/LocalClockDispersion:<seconds>] [/reliable:(yes NO)] Description Register to run as a service and add the default configuration to the registry. Unregister as a service and remove all configuration information from the registry. Returns monitoring data on the specified domain or list of computers. threads specifies how many computers may be analyzed simultaneously the default value is 3; the allowed range is 1 to 50. Converts a Windows NT system time to a human-readable format. Converts an NTP time to a humanreadable format. Tells a computer to resynchronize its clock as soon as possible. computer specifies the computer that should be resynchronized. nowait exits the utility immediately instead of waiting for the resynchronization to complete. rediscover reanalyzes the network and rediscovers sources and then resynchronizes. soft resynchronizes using the existing error statistics this is only provided for compatibility. Displays a stripchart showing the offset between this and another computer. The period is the time between samples; it defaults to 2 seconds. Dataonly does not draw a graph; it just reports the data. Samples specifies how many samples to collect before stopping if not defined, the utility will continue until Ctrl-C is pressed. Configures the time service on the specified computer. Update forces the changes to take place. Manualpeerlist specifies the NTP peers for the computer. Syncfromflags specifies the NTP server 178

179 Option [/largephaseoffset::<milliseconds>] /tz /dumpreg [/subkey:<key>][/computer:<name>] Description that the computer should query for authoritative time. LocalClockDispersion sets the accuracy that will be assumed if the local clock should time not be available from the other configured sources. reliable sets if this computer is to be considered a reliable source of time for others. Largephaseoffset sets the threshold value that the local computer will consider differences in time to be a spike. Displays the current time zone settings. Displays the values associated with a given key. The default key shown is HKLM\System\CurrentControlSet\Services\ W32Time. subkey specifies which subkey to display. computer specifies which computer to query. The following procedures show how you should use w32tm to configure time services on Windows Server 2003 for each of the time services scenarios depicted earlier in this section. To configure Windows Server 2003 PDC emulator with an external time source, follow these steps: 1. Open a command prompt. Click Start, Click Run, enter cmd, and click OK. 2. At the command prompt, enter the following command: w32tm /config /syncfromflags:manual /manualpeerlist:peerlist Where PeerList is a comma-separated list of DNS names or IP addresses of the desired time sources. 3. At the command prompt, enter the following command: w32tm /config /reliable:yes This command configures the Windows time service to announce itself as a reliable source of time so that other computers can synchronize to it. 4. At the command prompt, enter the following command: w32tm /config /update This command notifies the time service of the changes to the configuration, causing the changes to take effect. To configure Windows Server 2003 PDC emulator to provide synchronization time, follow these steps: 1. Start the Registry Editor. Click Start, click Run, enter regedt32.exe, and click OK. 2. Locate the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimePr oviders\ntpclient 3. Set the value of the Enabled variable of type REG_DWORD to

180 4. Open a command prompt. Click Start, click Run, enter cmd, and click OK. 5. At the command prompt, type the following command: w32tm /config /reliable:yes This command configures the Windows time service to announce itself as a reliable source of time so that other computers can synchronize to it. 6. At the command prompt, type the following command: net stop w32time && net start w32time This command restarts the Windows time service as a server only. Note The Windows time service must not point to itself. If it is configured to do so, the following entries will be visible in the System Event Log: The time provider NtpClient cannot reach or is currently receiving invalid time data from (ntp.m 0x :123-> :123) No response has been received from Manual peer after 8 attempts to contact it. This peer will be discarded as a time source and NtpClient will attempt to discover a new peer from which to synchronize. The time provider NtpClient is configured to acquire time from one or more time sources, however none of the sources are currently accessible. No attempt to contact a source will be made for 960 minutes. NtpClient has no source of accurate time. To configure Windows Server 2003 domain controller to synchronize to the domain source, follow these steps: 1. Open a command prompt. Click Start, click Run, enter cmd, and click OK. 2. At the command prompt, type the following command: w32tm /config /syncfromflags:domhier This command sets the source of time to be a domain controller in the domain hierarchy. 3. At the command prompt, type the following command: w32tm /config /reliable:yes This command configures the Windows time service to announce itself as a reliable source of time so that other computers can synchronize to it. 4. At the command prompt, type the following command: w32tm /config /update This command notifies the time service of the changes to the configuration, causing the changes to take effect. 180

181 Configuring Time Services on UNIX and Linux Servers On UNIX and Linux, the time services are provided by the NTP daemon. This daemon (ntpd on Red Hat Linux 9 and xntpd on Solaris 9) constantly updates the system clock in comparison with the clock on the NTP server. Configuring Time Services on Red Hat Linux 9 The configuration information of the NTP daemon is contained within the ntp.conf file, which is read when the daemon is started. The typical location of the ntp.conf file on Red Hat Linux 9 is in the /etc directory. To verify the running of the NTP daemon, follow this step: You can check that an NTP daemon is running by entering the following at a shell prompt: ps ef grep ntpd The following shows what you would see if the daemon is running; if the daemon is not running, you would not see this process line: root :46? 00:00:00 ntpd Configure Red Hat Linux 9 to Synchronize to an Internet Time Source The permissions on the ntp.conf file should be set so as to prevent unauthorized changes being made to the configuration. This means that the following operations should be carried out by a user who has write permission to the ntp.conf file or root. The following lines are required in a server configuration. # ntp.conf ntpd configuration file server time.nist.gov server time-a.nist.gov server time-b.nist.gov driftfile /etc/ntp.drift Note As with most UNIX and Linux configuration files, lines preceded by the number symbol ("#") in ntp.conf are comments. This is the simplest form that the ntp.conf file can take. The server lines specify which higher-level NTP servers are queried for the accurate time. These can be specified as dotted IP addresses, but the use of DNS names is good practice because they are less prone to change. The driftfile declaration allows the NTP daemon to record information regarding the accuracy of the local clock in the file specified. This reduces the problem of keeping the clock correct should the servers become unavailable. This file contains details of the normal rate of change of the local clock from the accurate time. The value is calculated during the first day of operation of the daemon and is constantly updated. After any changes have been made to the configuration files, the NTP daemon needs to be restarted to reread them. 181

182 To restart the NTP daemon on Red Hat Linux 9, follow this step: To restart the NTP daemon, ntpd, enter the following command: /etc/init.d/ntpd restart Configuring Time Services on Solaris 9 The configuration information of the NTP daemon is contained within the ntp.conf file, which is read when the daemon is started. The typical location of the ntp.conf file on Solaris 9 is in the /etc/inet/ directory. To verify the running of the NTP daemon, follow this step: You can check that an NTP daemon is running by entering the following command at a shell prompt: ps ef grep xntpd The following shows what you would see if the daemon is running; if the daemon is not running, you would not see this process line: root :51:01? 0:00 /usr/lib/inet/xntpd Configure Solaris 9 to Synchronize to an Internet Time Source The permissions on the ntp.conf file should be set so as to prevent unauthorized changes being made to the configuration. This means that the following operations should be carried out by a user who has write permission to the ntp.conf file or root. The following lines are required in a server configuration. # ntp.conf ntpd configuration file server time.nist.gov server time-a.nist.gov server time-b.nist.gov driftfile /etc/ntp.drift Note As with most UNIX and Linux configuration files, lines preceded by a number symbol ("#") in ntp.conf are comments. This is the simplest form that the ntp.conf file can take. The server lines specify which higher-level NTP servers are queried for the accurate time. These can be specified as dotted IP addresses, but the use of DNS names is good practice because they are less prone to change. The driftfile declaration allows the NTP daemon to record information regarding the accuracy of the local clock in the file specified. This reduces the problem of keeping the clock correct should the servers become unavailable. This file contains details of the normal rate of change of the local clock from the accurate time. The value is calculated during the first day of operation of the daemon and is constantly updated. After any changes have been made to the configuration files, the NTP daemon needs to be restarted to reread them. To restart the NTP daemon on Solaris 9, follow these steps: To restart the NTP daemon, xntpd, enter the following commands: /etc/init.d/xntpd stop /etc/init.d/xntpd start 182

183 Configuring Windows Clients to Synchronize with Time Service Windows clients that are members of a domain automatically start w32time when they start up. The Net Logon service looks for a domain controller that can authenticate and synchronize with a client. When such a domain controller is found, the client sends a request for the time and waits for a reply from the domain controller. There follows an exchange of SNTP packets that synchronize the client and calculate the roundtrip delay between the client and the server. For these domain member computers, the only task that needs to be done to complete the configuration is to set the correct time zone. To configure Windows clients to synchronize with the time service, follow these steps: 1. Open a command prompt. Click Start, click Run, type cmd, and click OK. 2. At the command prompt, enter the following command: w32tm /tz This will print the current time zone information. For example: Time zone: Current:TIME_ZONE_ID_DAYLIGHT Bias: 360min (UTC=LocalTime+Bias) [Standard Name:"Central Standard Time" Bias:0min Date:(M:10 D:5 DoW:0)] [Dayliht Name:"Central Daylight Time" Bias:-60min Date:(M:4 D:1 DoW:0)] 3. Should the time zone need adjustment, open the Control Panel and select Date and Time. 4. From the Date and Time window, select the Time Zone tab. 5. From the drop-down menu, select the required time zone. For example: (GMT) Greenwich Mean Time: Dublin, Edinburgh, Lisbon, London The map in the window will realign so that your selected time zone is centered within the window. 6. Click OK to accept the changes. 7. To confirm the changes, at the command prompt enter the following command: w32tm /tz You should see the correct time zone: Time zone: Current:TIME_ZONE_ID_DAYLIGHT Bias: 0min (UTC=LocalTime+Bias) [Standard Name:"GMT Standard Time" Bias:0min Date:(M:10 D:5 DoW:0)] [Daylight Name:"GMT Daylight Time" Bias:-60min Date:(M:3 D:5 DoW:0)] If the main time server within your organization is a UNIX or Linux server, it is recommended that you synchronize your domain controller with this server as described in the procedure "To configure Windows Server 2003 PDC emulator with an external time source," but using the Domain Name or IP Address of your server in place of the Internet time server. If you have decided to synchronize Windows clients directly to a UNIX server, then perform the following procedure: 183

184 To configure Windows clients to synchronize with a UNIX or Linux based time service, follow these steps: 1. Open a command prompt. Click Start, click Run, type cmd, and click OK. 2. At the prompt, enter the following command: net time /setsntp:servername Where ServerName is the domain name or IP address of your UNIX or Linux time server. 3. To test that the change has been made correctly, at the command prompt enter the following command: net time /querysntp The following line is returned: The current SNTP value is: time.nist.gov,0x1 To revert back to a domain hierarchy-based time server, at a command prompt type the following command without a specified server name: net time /setsntp This will clear any specified SNTP server names and determine the time source from the domain hierarchy. Configuring UNIX and Linux Clients to Synchronize with Time Service The configuration of UNIX and Linux clients is identical to that of servers; the ntp.conf file needs to contain the name of the server that the computer is synchronizing to. The NTP daemon on both Red Hat and Solaris will automatically respond to client requests. Note If there is not a local time service for your UNIX or Linux hosts, it is recommended that you create one. This local computer should synchronize to the external time source, and all the other local computers should synchronize to it. This is both more efficient and more respectful of the higher tier providers who will not be inundated with synchronization requests. If you are building multiple new computers, then it is recommended that you include NTP configuration information as part of the automated build process. Both Red Hat and Sun provide tools for the easy configuration of multiple computers, and more information about these tools is available from the manufacturers. 184

185 Summary This chapter has covered the steps that are the prerequisites to building a heterogeneous security and directory solution. All of the solutions presented in this guide require the full implementation of the Windows Server 2003 Active Directory. Because configuration guidance for Active Directory is beyond the scope of this document, references that describe the design, installation, and configuration of Active Directory are provided. There are also references on how best to secure your Active Directory implementation. All of the solutions are also dependant on a correctly functioning DNS service. The Kerberos security solution is particularly dependant on the correct configuration of a time service. Your options and the solution requirements have been presented in this chapter. After the development of the infrastructure in this chapter, you will be ready to develop the security and directory solutions that are presented in the next two chapters. 185

186

187 7 Developing Heterogeneous Kerberos Security Solutions Introduction This chapter provides guidance for implementing a security infrastructure for UNIX and Linux clients using the Windows Server 2003 Kerberos service. Guidance is also provided for configuring the Windows Server 2003 domain controller and UNIX and Linux Key Distribution Centers (KDCs) and clients. The guidance is specifically for Red Hat Linux 9 and Solaris 9, although the setup should be similar on other UNIX platforms. Organizations can use this guidance to create a unified security solution based around the Windows Server 2003 platform. This unified security solution provides for centralized administration of users and passwords, and it allows for a single sign on for users across all platforms. This simplifies the authentication procedures for users by requiring them to remember only one user name and password across Windows, UNIX, and Linux clients. The guidance in this chapter covers two main solution scenarios: The use of Windows Server 2003 as the sole source of Kerberos authentication services The use of Windows Server 2003 in conjunction with UNIX or Linux Kerberos services The chapter is structured into five sections: "Configuring the Windows KDC" "Configuring the UNIX or Linux KDC" "Creating Cross-Realm Trusts" "Migrating Users" "Configuring Clients, Applications, and Services" The diagram in Figure 7.1 is a high-level overview of the solution presented in this chapter. The key components of these solutions that are shown in Figure 7.1 are the Kerberos pluggable authentication module (PAM) pam_krb5 and Kerberized applications such as telnet and ssh. Also shown is the creation of the cross-realm trust between the Windows Server 2003 Kerberos realm and the UNIX or Linux Kerberos realm. The configuration of these and their respective infrastructure requirements are covered in this chapter. A reference to the details of the PAM can be found in the "Prerequisites" section. 187

188 188 Figure 7.1 Overview of Kerberos security solution infrastructure

189 Prerequisites Complete the Envisioning and Planning phases before implementing the Kerberos security infrastructure using Windows Server Before continuing to implement the solution in this chapter, you should: Make the design decisions outlined in Chapter 5, "Planning Heterogeneous Security and Directory Solutions," and produce an implementation plan. Read and implement the sections from Chapter 6, "Developing the Infrastructure for Heterogeneous Security and Directory Solutions," that apply to the Kerberos solution. Review the descriptions of Kerberos and Pluggable Authentication Modules (PAM) found in Chapter 2, "Authentication and Authorization in UNIX and Windows Environments." Configuring the Windows KDC Kerberos 5 is the default authentication method for authentication in Windows Server 2003 Active Directory. This means that no specific Kerberos configuration steps are required for setting up a Windows Server 2003 domain controller. There are, however, a number of configuration changes that can be made to fine-tune the behavior of the default solution. These are detailed in the following subsections. Note The Kerberos realm name is derived from the Active Directory domain name. The realm name is the domain name converted to uppercase. In the case of the example.com domain name, the realm name is EXAMPLE.COM. Setting up Windows Server 2003 and Active Directory is covered extensively and comprehensively in other documents. It is recommended that you follow the guidance given in these documents in the creation of your domain controllers. There is detailed information about all aspects of installing and configuring Windows Server 2003 in the Windows Server 2003 Product Documentation, available at server2003/proddocs/entserver/default.asp. Configuring Active Directory There are no changes that need to be made to the Active Directory Lightweight Directory Access Protocol (LDAP) schema to use it as a Kerberos KDC that can provide security services for UNIX and Linux clients. If, however, you are going to implement Kerberos alongside an LDAP directory service, it is recommended that you implement any schema changes required by the directory service before proceeding with your Kerberos solution. Modifications to the schema are described in detail in Chapter 8, "Developing the LDAP Security and Directory Infrastructure." Installing Tools and Utilities There are a number of useful tools for administering Kerberos tickets available from Microsoft in the Windows Server 2003 Resource Kit. 189

190 Installing the Windows Server 2003 Resource Kit Tools The Windows Server 2003 Resource Kit includes utilities for examining and deleting Kerberos tickets. You should install the Windows Server 2003 Resource Kit before proceeding with developing the Kerberos solution. Note If you have already installed the Beta version of the Resource Kit Tools, it must be removed before performing this procedure. 1. See the Windows Server 2003 Resource Kit Tools at 2. Click the Download link to start the download. Do one of the following: To start the installation immediately, click Open or Run this program from its current location. To copy the download to your computer for installation at a later time, click Save or Save this program to disk. 3. To install the Resource Kit tools, run the rktools.exe package. Using Windows Explorer, browse to the location where you downloaded rktools.exe and double-click the file. This starts the Windows Resource Kit Tools Setup Wizard. 4. Click Next. 5. In the End User License Agreement dialog box, select I agree, and then click Next. 6. In the User Information dialog box, enter your name and organization, and then click Next. 7. Click Install Now, and then click Finish. 8. All necessary files are installed to the %Program Files%\Windows Resource Kits\Tools folder. 9. Before starting and using the Resource Kit tools, please be sure to read the Readme.htm file, which is located in the %Program Files%\Windows Resource Kits\Tools folder. Readme.htm can also be accessed by clicking Start, selecting All Programs, selecting Windows Resource Kit Tools, and then selecting Windows Resource Kit Tools Readme. Security Options There are a number of measures that you should take to increase the security of your KDC. These measures can be classified into two categories: Measures that improve the security of Kerberos Measures that improve the security of Windows Server 2003 itself The following sections provide some guidelines and suggestions for configuration changes that can be made to enhance your organization's security. Network Security If your organization's network is connected to any other networks, either directly or indirectly over the Internet, you should be using some form of perimeter protection to prevent unauthorized access to your network. An example layout of an organization's network is shown in Figure

191 Figure 7.2 Example scenario for network security configuration. In the scenario presented in Figure 7.2, the organization has two Kerberos realms at different sites that have a cross-realm trust between them that is connected over the Internet. There are Kerberos clients at both sites and Kerberos clients external to the sites that authenticate to the Kerberos KDC. The KDCs synchronize time and obtain DNS information from sources external to the organization. This scenario contains all of the basic network security concepts required for any Kerberos-based security solution. Table 7.1 lists the ports that are required to be opened for the correct operation of Kerberos 5 across both Windows and UNIX or Linux platforms. Table 7.1: Required TCP/UDP Ports for the Correct Operation of Kerberos 5 Port 53/UDP 53/TCP 88/TCP 88/UDP 123/UDP 749/TCP Description The DNS Service. The internal Active Directory DNS server needs to be accessible to all clients for the location of KDC computers. The Active Directory domain controllers need to be capable of accessing external DNS servers for resolving external domain name requests. The Kerberos Ticket Granting Service. All clients need to be capable of connecting to this port on the KDC Servers. The SNTP and NTP Service. All clients need to be capable of connecting to this port for time synchronization, either to an internal time server or to an external time source. The internal time server will need to connect to an external time source to synchronize. The Kerberos 5 password changing service. This port is also used by the MIT implementation of Kerberos to provide administrative services. This should be accessible to all clients. 191

192 The only port required for authentication to work is port 88; the others are peripheral to authentication, but are required for the infrastructure to function optimally. Specific firewall configuration is beyond the scope of this guide, and you should refer to your vendor documentation for more information. Windows Server 2003 has the capability to use IPSec Filters to block and allow specific ports on the domain controller itself. IPSec can perform host-based packet filtering to provide limited firewall capabilities for end systems. You can configure IPSec to permit or block specific types of unicast IP traffic based on source and destination address combinations and specific protocols and specific ports. Note For more information on IPSec and its use within Windows Server 2003, refer to the IPSec Technical Reference available at 2k3tr_ipsec_intro.asp Table 7.2 lists all of the filters that can be created on a Windows Server 2003 Active Directory Domain controller to maximize security. Table 7.2: Domain Controller IPSec Filter Network Traffic Map Service Protocol Source Port CIFS/SMB Server TCP UDP ANY ANY Destination Port Source Address ANY ANY Destination Address ME ME Action ALLOW ALLOW Mirror YES YES RPC Server TCP UDP ANY ANY ANY ANY ME ME ALLOW ALLOW YES YES NetBIOS Server TCP UDP UDP TCP ANY ANY ANY ANY ANY ANY ANY ANY ME ME ME ME ALLOW ALLOW ALLOW ALLOW YES YES YES YES Monitoring Client Terminal Services Global catalog Server DNS Server Kerberos Server LDAP Server ANY ANY ANY ME MOM Server ALLOW YES TCP ANY 3389 ANY ME ALLOW YES TCP TCP TCP UDP TCP UDP TCP UDP TCP UDP ANY ANY ANY ANY ANY ANY ANY ANY ANY ANY ANY ANY ANY ANY ANY ANY ANY ANY ANY ANY ME ME ME ME ME ME ME ME ME ME ALLOW ALLOW ALLOW ALLOW ALLOW ALLOW ALLOW ALLOW ALLOW ALLOW YES YES YES YES YES YES YES YES YES YES NTP Server TCP UDP ANY ANY ANY ANY ME ME ALLOW ALLOW YES YES Static AD TCP ANY ANY ME ALLOW YES 192

193 Service Protocol Source Port Destination Port Source Address Destination Address Replication Server DC Comms ANY ANY ANY ME Domain controller DC Comms ANY ANY ANY ME Domain controller 2 Action ALLOW ALLOW ICMP ICMP ANY ANY ME ANY ALLOW YES All Inbound Traffic Mirror YES YES ANY ANY ANY ANY ME BLOCK YES The following procedure shows you how to add an IPSec Filter to allow port 88 for Kerberos authentication. There are two aspects to IPSec filtering: there is an IPSec Filter List that contains details of the port and the source of packets that are required to be filtered, and then there is an IPSec Filter Action that performs an action on an item in the filter list. To create filters for other ports, you will need to modify the procedure details to reflect the port and the actions that you want to take. 193

194 To create an IPSec Filter List, follow these steps: 1. Click Start, click All Programs, click Administrative Tools, and then click Active Directory Users and Computers. 2. In the Active Directory Users and Computers window, right-click your domain name and select Properties from the menu. 3. In your Domain Properties dialog box, select the Group Policy tab. 4. Select the Default Domain Policy group policy object and click Edit. 5. Expand the Default Domain Policy tree through Computer Configuration, and then through Windows Settings, and then through Security Settings. Right-click IP Security Policies and select Manage IP filter lists and filter actions. 6. In the Manage IP Filter Lists dialog box, select the Manage IP Filter Lists tab, and then click Add. This action is shown in Figure 7.3. Figure 7.3 Manage IP filter lists and filter actions dialog box 194

195 7. Enter a name and description into the Name and Description fields. In this example, you can use "Kerberos Filter" for the name and "Allow traffic to TCP and UDP port 88" for the description. This is shown in Figure 7.4. Figure 7.4 IP Filter List dialog box 8. Clear the Use Add Wizard check box and click Add. 195

196 9. In the IP Filter Properties dialog box, select the Addresses tab, change the Source address to Any IP Address and change the Destination address to My IP Address. Ensure that the Mirrored check box is selected to allow all return traffic to pass unrestricted. This is shown in Figure 7.5. Figure 7.5 IP Filter Properties Addresses tab 196

197 10. Click the Protocol tab and change the Select a protocol type to TCP, select the From any port radio button and the To this port radio button, enter 88 into the text field, and click OK. This is shown in Figure 7.6. Figure 7.6 IP Filter Properties Protocol tab 11. Repeat steps 8 through 10, replacing TCP with UDP in the protocol type. This procedure creates an IP Filter List that details packets from any address to the Windows Server 2003 computer on TCP and UDP port 88, and it also includes all responses from the Windows Server 2003 computer to the requesting computer. An "action" needs to be created to define the steps that are to be carried out on any network traffic that meets the criteria specified in Table 7.3. This is done by carrying out the following procedure. To create an IPSec Policy for the IPSec Filter List, follow these steps: 1. Click Start, click All Programs, click Administrative Tools, and then click Active Directory Users and Computers. 2. In the Active Directory Users and Computers window, right-click your domain name and select Properties from the menu. 3. In your Domain Properties dialog box, select the Group Policy tab. 4. Select the Default Domain Policy group policy object and click Edit. 197

198 5. Expand the Default Domain Policy tree through Computer Configuration, then through Windows Settings, and then through Security Settings. Right-click IP Security Policies and select Create IP Security Policy. 6. In the Welcome to the IP Security Policy Wizard, click Next. 7. In the IP Security Policy Name dialog box, enter a relevant value into the Name and Description fields and click Next. In this example, type Kerberos TGS Policy in the Name field and type Allow access to the Kerberos Ticket Granting Service on Port 88 in the Description field. This is shown in Figure 7.7. Figure 7.7 IP Security Policy Name and Description 8. Clear the Activate the default response rule check box and click Next. 9. Select the Edit properties check box and click Finish. 198

199 10. In the Kerberos TGS Properties dialog box, click the Rules tab, clear the Use Add Wizard check box, and then click Add. This is shown in Figure 7.8. Figure 7.8 New IP Security Policy Properties dialog box 199

200 11. In the New Rule Properties dialog box, click the IP Filter List tab and select the radio button next to Kerberos Filter in the IP Filter Lists: area. This is shown in Figure 7.9. Figure 7.9 New Rule Properties selecting IP Filter 200

201 12. In the New Rule Properties dialog box, click the Filter Action tab, select the radio button next to the Permit action in the Filter Actions: area, and then click OK. This is shown in Figure Figure 7.10 New Rule Properties selecting Filter Action 13. Click OK to create the new security policy. Warning Do not assign rules until you have created a rule that denies all traffic. This rule will restrict traffic to only the rules that have been specifically selected from the preceding list. Failing to do this will permit all traffic. To do this, create a rule which has All IP Traffic as its filter, and Block as its action. 14. To activate the rule, you need to right-click the rule name and select Assign from the menu. You should create filters and assign actions to them for all of the ports listed in Table 7.3 to maximize the security of your Windows Server 2003 solution. 201

202 In the scenario that is presented in Figure 7.2, there is a Kerberos client that is external to the firewall that is connecting using Network Address Translation (NAT). NAT occurs when one IP address is mapped to another; in this case, the IP is being mapped to an address in the range. This potentially causes problems for Kerberos because each Kerberos ticket contains an IP address. The solution is to use address-less tickets; from a UNIX or Linux computer, this is done by using the -a option after kinit. The following procedure creates the same effect for a Windows XP client computer. To request address-less tickets using Windows XP, follow these steps: 1. Start the Registry Editor. Click Start, click Run, enter regedt32.exe, and click OK. 2. Locate the registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Para meters. If the Parameters key does not exist, it should be created. You can do this by right-clicking the Kerberos key and selecting New, and then Key, from the menu. 3. If the ClientIpAddresses variable does not exist, you will need to create it. You can do this by carrying out the following steps: a. Right-click the Parameters key and select New, and then DWORD Value, from the menu. b. Change the name of the variable to ClientIpAdresses. 4. Set the value of the ClientIpAddresses variable of type REG_DWORD to 0x0. You do this by carrying out the following steps: a. Right click the ClientIpAddresses variable and choose Modify from the menu. b. Enter 0 into the Value data box, with the Hexadecimal radio button selected. This is shown in Figure Figure 7.11 Registry Editor changing the value of the ClientIpAddresses variable. c. Click OK to set the value 5. Exit the Registry Editor. On the File menu, select Exit 202

203 Event Log Settings Windows Server 2003 records all successful authentication requests by default. To enable the logging of all requests, it is necessary to change the auditing settings for the domain. As there are likely to be a large number of entries in the log files, it is recommended that you increase the maximum size of the Windows Server 2003 security log from the default 512 KB to retain a relevant level of detail. To increase the size of the Security Log, follow these steps: 1. Click Start, click All Programs, click Administrative Tools, and then click Active Directory Users and Computers. 2. In the Active Directory Users and Computers window, right-click your domain name and select Properties from the menu. 3. In the Domain Properties dialog box, select the Group Policy tab. 4. Select the Default Domain Policy group policy object and click Edit. 5. Expand the Default Domain Policy tree through Computer Configuration, then through Windows Settings, and then through Security Settings. Click Event Log. This is shown in Figure Figure 7.12 The Group Policy Object Editor Window showing the Event Log settings 203

204 6. Double-click Maximum security log size. In the Maximum security log size Properties dialog box, select the Define this policy setting check box, enter into the kilobytes text field, and then click OK. This should log approximately 30,000 authentication requests. The dialog box is shown in Figure Figure 7.13 Maximum security log size Properties dialog box When the maximum log size has been increased, the logging of all authentication requests can be enabled. In Windows Server 2003, there are two types of auditing authentication requests. These are summarized here: Logon Auditing This policy setting enables the auditing of all Windows local login events. This includes all login methods and is not restricted just to Kerberos authentication. The audit log contains both the start and end time of the login. This setting is only for local logins, so it does not contain any details of Kerberos authentication requests for login on remote computers. Account Logon Auditing This policy setting enables the auditing of all Kerberos authentication requests. As there is no knowledge of the logout time given by remotely requested Kerberos authentication, there is only a record of the time that the authentication was successfully accepted or denied. These settings are not enabled by default, and it is necessary to manually enable them. This process is described in the following procedure. To enable logging of all Kerberos Authentication Requests, follow these steps: 1. Click Start, click All Programs, click Administrative Tools, and then click Active Directory Users and Computers. 2. In the Active Directory Users and Computers window, right-click your domain name and select Properties from the menu. 3. In the Domain Properties dialog box, select the Group Policy tab. 4. Select the Default Domain Policy group policy object and click Edit. 204

205 5. Expand the Default Domain Policy tree through Computer Configuration, then through Windows Settings, then through Security Settings, and then through Local Policies. Click Audit Policy. This is shown in Figure Figure 7.14 The Group Policy Editor Window showing the Audit Policy settings 205

206 6. Double-click Audit account logon events. In the Audit account logon events Properties dialog box, select the Define these policy settings check box, select both the Success and the Failure check boxes, and then click OK. The dialog box is shown in Figure Figure 7.15 Audit account logon events Properties dialog box 7. Double-click Audit logon events. In the Audit logon events Properties dialog box, select the Define these policy settings check box, select both the Success and Failure check boxes, and then click OK. The dialog box is shown in Figure Figure 7.16 Audit logon events Properties dialog box 206

207 The Windows Server 2003 KDC is now logging all Kerberos authentication requests. Details on how to interpret the log files that are generated are given in Chapter 9, "Testing Windows-based Security and Directory Services." Securing the Windows KDC There are some steps that can be taken to enhance the default level of security of the Windows Server 2003 KDC. These steps are discussed in the following subsections. Note Windows Server 2003 is configured by default to require preauthentication for all principals. This feature (which has to be manually set on most other implementations of Kerberos) forces a client to prove their identity before any tickets are issued. Password Policies Any security solution is only as strong as the passwords that are used to secure it. Strong passwords should be used as a matter of course. Note Advice on creating strong passwords can be found at wsserver2003/proddocs/standard/windows_password_tips.asp. Windows Server 2003 has the capability to evaluate the security of a password against a list of criteria. These criteria are: The account name is not included wholly or partially in the password. The password length is greater than six characters. There is at least one character from three of the four following types of characters: numbers, lowercase letters, uppercase letters, and punctuation symbols. The password age is less than a specified number of days. The password has not been used previously. All of these checks are enabled by default on Windows Server The following procedure details how to modify any of the default settings for the Password Policy. 207

208 To modify the Password Policy for all accounts, follow these steps: 1. Click Start, click All Programs, click Administrative Tools, and then click Domain Security Policy. 2. Expand the Security Settings tree through Account Policies and click Password Policy. This is shown in Figure Figure 7.17 Domain Security Settings showing Password Policies 3. To change any of the Password Policy settings, right-click the policy name and select Properties from the menu. System Software Updates It is recommended that all of your Windows computers are kept up to date with the latest security software updates that are released. Details of all security software updates are available from the Microsoft security website at You should also follow the advice given on securing your server in the Windows Server 2003 Security Guide available at 3tr_ipsec_intro.asp. Backing Up the Windows KDC Backups of your Windows Server 2003 Active Directory should be made according to local policy. Details and best practices for how to back up Windows Server 2003 are included in the product documentation available at server2003/proddocs/entserver/default.asp. 208

209 Configuring the UNIX and Linux KDC Most of the major UNIX and Linux distributions ship with their own implementation of Kerberos 5 that are usually based on the MIT Kerberos implementation. However, there are known issues with versions of MIT Kerberos prior to that are the result of the limitations of the limited UDP packet size, this results in the truncation of group lists, this has been shown to be present on both Solaris and Linux platforms. Earlier versions of MIT Kerberos also have certain security issues. More information on all of these vulnerabilities can be found in the Security Advisories section of the MIT Kerberos website at As a result, it is essential to download and install the MIT Kerberos version to ensure the correct operation of the solution. This process is described in the "Obtaining and Installing MIT Kerberos 1.3.1" section. To install the prerequisites for building MIT Kerberos from source on Solaris 9, follow these steps: 1. The build of MIT Kerberos requires a set of GNU tools. These should be downloaded from and installed before proceeding. You should download and install the following packages: gcc sol9-intel-local.gz make-3.80-sol9-intel-local.gz autoconf sol9-intel-local.gz automake sol9-intel-local.gz m4-1.4-sol9-intel-local.gz The intel portion of the file name indicates that these files are for the Intel platform; you must download packages suitable for your platform. The local portion of the file name indicates that files from this package will be installed under the directory /usr/local. For each package, follow the steps listed here. These steps use the make-3.80-sol9-intel-local.gz package file as an example; you must change the file names to reflect the file names that you are using: a. Extract the Solaris package file by entering the following command at the shell prompt: gunzip make-3.80-sol9-intel-local.gz b. Install the Solaris make package by entering the following command: pkgadd -d make-3.80-sol9-intel-local c. At the Select package(s) you wish to process (or 'all' to process all packages). (default: all) [?,??,q] prompt, enter y. d. If the Do you want the directory creating /usr/local [?,y,n,q] prompt is shown, enter y. 2. Repeat this procedure for each of the required packages listed earlier. 209

210 On Solaris 9, you should then modify your $PATH variable in your shell to include both the /usr/local/bin/ directory where you just installed the GNU utilities and the /usr/ccs/bin/ directory, where there are additional utilities needed by the MIT Kerberos build. The following guidance is for the sh shell, details for changing the $PATH variable in other shells can be found in their respective manual pages. To modify the $PATH variable, follow this step: At the command prompt, type the following commands: PATH=$PATH:/usr/local/bin/:/usr/ccs/bin/ export PATH Obtaining and Installing MIT Kerberos The MIT Kerberos implementation is available directly from the MIT Kerberos website at This guidance covers the latest version available at the time of writing. Later versions are likely to be similar to MIT Kerberos 1.3.1; however, it is strongly recommended that you refer to the product documentation before attempting an installation of a later version. To install and configure MIT 1.3.1, follow these steps: 1. Download the latest version of the MIT Kerberos source package from 2. Extract the source files by entering the following commands: gunzip krb tar.gz tar xvf krb tar 3. Configure and compile the source code by entering the following commands: cd krb /src./configure make 4. Install the compiled MIT Kerberos packages by entering the following command: make install This procedure installs the package and all of the Kerberized services into their default locations. Please refer to the MIT Kerberos documentation for further details. You should ensure that your path contains the directory that the Kerberos utilities are contained in. Guidance on how to do this for the standard sh shell is given in the following procedure; for other shells, you should refer to the online manual pages. To modify the $PATH variable, follow this step: At the command prompt, add the Kerberos directory to the PATH variable by typing the following commands: PATH=$PATH:/usr/kerberos/sbin/ export PATH You should modify the directory in this procedure to reflect your environment and ensure that it is set correctly. Following procedures will assume that the utilities can be found through the $PATH shell variable. 210

211 Configuring MIT Kerberos as a KDC Kerberos configuration is based on two important configuration files. The krb5.conf file, which is typically found in the /etc directory, contains all of the realm information, including the locations of KDCs and admin servers for the realm, the default settings, and the host name mappings. This file is common to both KDCs and clients. The kdc.conf file, which is typically found in /var/kerberos/krb5kdc/ on Red Hat Linux 9 and /etc/krb5/kdc.conf on Solaris 9, contains the specific configuration options for the KDC. Both files have a similar syntax; they are divided into stanzas made up of key-value pairs. Configuring the krb5.conf file This section details the configuration of the krb5.conf file. This guidance applies equally to UNIX and Linux KDCs and UNIX and Linux clients. The krb5.conf file is typically in the /etc directory. The possible stanzas that can be used in the krb5.conf file are described in Table 7.3. The file can be made up of any or all of the stanzas. It is recommended that a configuration contain at least [logging], [libdefaults], [realms] and [domain_realm]. A simple (but complete) krb5.conf file would look similar to the following example: # krb5.conf Kerberos Configuration File for the EXAMPLE.COM realm [logging] [libdefaults] [realms] [domain_realm] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false EXAMPLE.COM = { kdc = kerberos.example.com:88 admin_server = kerberos.example.com:749 default_domain = example.com }.example.com = EXAMPLE.COM example.com = EXAMPLE.COM 211

212 Table 7.3: Stanza Headings Within the krb5.conf file Section Name [libdefaults] [login] [appdefaults] [realms] [domain_realm] [logging] [capaths] Description This contains the default values used by the Kerberos 5 Library. This contains the default values used by the Kerberos 5 login program. This contains the default values used by any Kerberos 5 applications. This contains subsections for each Kerberos realm describing realm specific information. This contains information regarding the mapping of domain and subdomain names to Kerberos realms. This contains details of the logging to be performed by Kerberos applications. This contains details of the cross-realm authentication paths for direct authentication. The details of the key-value pair of each of these stanzas are described in Tables 7.4, 7.5, 7.6, and 7.7, and the details of the [capaths] stanza are provided in the "Establishing Cross-realm Trusts" section in this chapter. Table 7.4: [logging] Stanza Key-value Pairs Key name Kdc admin_server Default Description These entries specify the methods for the logging of the KDC. These entries specify the methods for the logging on the administrative server. These entries specify the logging method to be used in the absence of any other specific instructions. The values that can be taken by the [logging] section key pairs are as follows: Table 7.5: Values for the [logging] Key Pairs Value FILE=<filename> FILE:<filename> STDERR CONSOLE DEVICE=<devicename> SYSLOG[:<severity>[:<facility>]] Description Logging messages are recorded in specified file. If the "=" is used, then the file is overwritten; ":" causes the file to be appended. Logging messages are recorded to the standard error stream. Logging messages go to the console. Logging messages go to the specified device. Logging messages go to the system log. The severity and facility arguments are those supported by syslog without the prefixing "LOG_", as defined in the syslog(3) manual page. 212

213 Table 7.6: [libdefaults] Stanza Key-Value Pairs Key name default_keytab_name default_realm default_tgs_enctypes default_tkt_enctypes permitted_enctypes Clockskew kdc_timesync kdc_req_checksum_type ap_req_checksum_type safe_checksum_type ccache_type krb4_svrtab krb4_config krb4_realms dns_lookup_kdc dns_lookup_realm dns_fallback extra_addresses udp_preference_limit verify_ap_req_nofail renew_lifetime Noaddresses Forwardable Proxiable Description The default keytab name to be used by application servers. The default Kerberos realm for the client. The list of supported encryption types on the KDC. The list of encryption types that should be requested by the client. Identifies all the encryption types allowed in session key encryption. The time in seconds that Kerberos will tolerate before declaring a ticket invalid. Determines if the client computer will use the time returned from a KDC in a ticket to correct an inaccurate system clock. An integer specifying the type of checksum to use. Specifies the type of cache to use on distributed computing environment (DCE) clients. The location of the Kerberos 4 srvtab file. The location of the Kerberos 4 configuration file. The location of the Kerberos 4 realm translation file. Indicates if DNS SRV records should be used to locate KDCs and other servers for a realm. Indicated if DNS TXT records should be used to determine the realm of a host. Flag controlling the use of DNS in Kerberos. Allows for a computer to use multiple IP addresses. This is necessary in a network that uses Network Address Translation (NAT). Sets the size of message where Transmission Control Protocol (TCP) is used instead of User Datagram Protocol (UDP) for transport to the KDC. Fails a request for initial credentials if client does not have a keytab. Default renewable lifetime for initial tickets. Sets the initial Kerberos ticket to be address-less. Sets the initial ticket to be forwardable. Sets the initial ticket to be proxiable. In the [realms] stanza, each tag is the name of a Kerberos realm, and the value of the tag defines the properties of the realm. Each realm tag can have the values described in Table

214 Table 7.7: [realms] Stanza Tag Values Tag Values Kdc admin_server default_domain v4_instance_convert v4_realm auth_to_local_names auth_to_local Description The name of a computer running a KDC for the realm; a port number may also be specified when separated by a colon. The name of a computer running an Administration Server. Provided for Kerberos 4 compatibility to produce a full domain name from partial principal names. Allows for exceptions to the earlier default_domain rule to be included. Provided to convert Kerberos 5 principal names to Kerberos 4 principal names. Allows setting of explicit mappings between principal names and local user names. Provides a general rule for principals not explicitly defined with the auth_to_local_names rule. Possible values are: DB:filename principal will be looked up in the database filename. RULE:exp the local name will be formulated from the principal name and the regular expression exp. DEFAULT the principal name will be used as the local user name. The [domain_realm] section provides for the translation of a domain or host name to a Kerberos realm. The tag is either a domain or host name, and the value is the Kerberos realm that the host or domain maps to. Configuring Kerberos Using the kdc.conf file The kdc.conf file, typically in /var/kerberos/krb5kdc/ for Red Hat 9 and /etc/krb5/ for Solaris 9, contains the configuration information for the KDC. The format is identical to that of the krb5.conf file, with stanzas and key-value pairs. There are three stanza sections and the file may contain any or all of them. These are shown in Table

215 A kdc.conf file for the KDC server kerberos.example.com in the EXAMPLE.COM realm would look like the following example: # kdc.conf KDC configuration file for the EXAMPLE.COM realm [kdcdefaults] [realms] [logging] kdc_tcp_ports = 88 EXAMPLE.COM = { kadmin_port = 749 max_life = 8h 0m 0s max_renewable_life = 5d 0h 0m 0s master_key_type = des3-hmac-sha1 supported_enctypes = des3-hmac-sha1:normal des-cbc-crc:normal } kdc = FILE:/var/log/kdc.log des-cbc-crc:v4 admin_server = FILE:/var/log/kadmin.log This is the minimum set of data that your kdc.conf file should consist of, and it contains the recommended settings for each of the key-value pairs. Table 7.8: Stanza Headings Within the kdc.conf File Section Name [kdcdefaults] [realms] [logging] Description Contains the default values for the overall behavior of the KDC. Contains realm-specific information. Contains information regarding the logging for Kerberos applications. The values assignable to the [logging] section are the same as those described in Table 7.9 for the krb5.conf file. The [kdcdefaults] section defines the following relations: Table 7.9: [kdcdefaults] Stanza Key-value Pairs Key Name kdc_ports kdc_tcp_ports v4_mode Description Lists which UDP ports that the KDC should listen to for connections. Lists which TCP ports that the KDC should listen to for connections. Specifies how the KDC should respond to Kerberos 4 packets. The [realms] stanza is similar in format to that of the [realms] stanza in the krb5.conf file, with each tag representing a Kerberos realm and the values assigned to that tag being the properties of the realm. Table 7.10 shows the values that can be assigned to a realm. 215

216 Table 7.10: [realms] Stanza Tag Values Tag Values acl_file admin_keytab database_name default_principal_expiration default_prinicipal_flags dict_file kadmin_port kpasswd_port key_stash_file kdc_ports kdc_tcp_ports master_key_name master_key_type max_life max_renewable_life supported_enctypes reject_bad_transit Description Location of the access control list (ACL) file used by kadmin. Location of the keytab file for legacy support of kadmin4 and v5passwd. Location of the principal database for this realm. Default expiration date of principles in this realm. Specifies the default attributes of principals created in this realm. Location of dictionary file containing words prohibited from use in passwords. Port on which kadmind is to listen for this realm. Port on which kpasswdd is to listen for this realm. Location where the master key has been stored. List of UDP ports that the KDC is to listen to for requests for this realm. List of TCP ports that the KDC is to listen to for requests for this realm. The name of the principal associated with the master key. The type of the master key. Maximum time for which a ticket is valid in the realm. Maximum time period for which a valid ticket may be renewed in the realm. List of key:salt strings that are the default for principals in this realm. Check that the transited path is valid for the [capaths] section of the krb5.conf file. There are a number of possible flags that you can assign to a new principal created in a realm. The default value is set in the default_principal_flags value, and if it is not explicitly specified, it defaults to set the following flags: postdateable, forwardable, tgt-based, renewable, proxiable, dup-skey, allow-tickets, and service. The description of all of the possible values appears in Table Table 7.11: Valid Flags for the default_principal_flags Value Flag postdateable forwardable tgt-based renewable proxiable dup-skey allow-tickets Description Allows the principal to obtain postdateable tickets. Allows the principal to obtain forwardable tickets. Allows the principal to obtain tickets based on a Ticket Granting Ticket (TGT) instead of repeating the authentication process. Allows the principal to obtain renewable tickets. Allows the principal to obtain proxy tickets. Allows the principal to obtain a session key for another user. Permits the KDC to issue tickets for this principal. 216

217 Flag preauth hwauth pwchange service pwservice Description For a client principal, this sets the requirement of preauthentication before receiving any tickets; for a service principal, this means that service tickets will only be issued if a client has a Ticket Granting Ticket (TGT) that has the preauthenticated ticket value set. Sets the requirement for preauthentication using a hardware device before receiving any tickets. Setting this forces a password change for the principal. Allows the KDC to issue service tickets for this principal. Marks the principal as a password change service. Having modified the configuration files to reflect the correct information for your domain, you must now initialize your Kerberos database. To initialize the Kerberos Database, follow these steps: 1. On the command line, enter the following command as root: kdb5_util create s You should see the following output: Initializing database '/var/kerberos/krb5kdc/principal' for realm 'EXAMPLE.COM', master key name 'K/M@EXAMPLE.COM' You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: If, instead, you see: Configuration file does not specify default realm while retrieving configuration parameters. there is a fault with your /etc/krb5.conf file. Correct the file and attempt the step again. Note The Kerberos Database is encrypted on disk using the password that you supply in this step. In order for the database to be unencrypted for use, this password needs to be supplied. It is then held in memory to continue to decrypt the database. Should the computer be restarted, the password would need to be reentered for the decryption to take place. Because this is not always practical, Kerberos is capable of making use of a stash file to hold the password on disk so it can boot without user intervention. This facility is specified by the -s command line switch to kdb5_util. 2. At this point, you should choose and enter the database Master Password. You will be prompted to confirm the password again. Note You should choose a strong password for your database Master Password. Advice on creating strong passwords can be found at ndowsserver2003/proddocs/standard/windows_password_tips.asp. 217

218 3. At the command line, enter the following command to start kadmin: kadmin.local This starts a local, failsafe version of kadmin (the Kerberos administration tool). From here, you can add, delete, and modify principals, policies, passwords, and most aspects of your Kerberos KDC behavior. The full syntax of kadmin is beyond the scope of this document, but is readily available from the online man page. 4. At the kadmin prompt, enter the following command: listprincs This command returns a list of all the principals on the system. You can see that the only default existing principals are the basic system principals. 5. To add a new administrative principal, enter the following command: addprinc user/admin where user is the user name of the new administrative principal. 6. Enter and confirm the password for the user. 7. At the kadmin prompt, confirm that the new user has been created by typing the following command: listprincs 8. Quit kadmin by typing quit at the kadmin prompt. 9. Start the Kerberos KDC by entering the following command: krb5kdc 10. To test the KDC, log in as the user you just created by entering the following command: kinit user/admin Assuming you see no errors here, your KDC is running successfully. So far, the setup has created a working KDC and an administrative user. This user's access rights are currently set as those defined in the default_principal_flags setting in kdc.conf. The ACL file (kadm5.acl), by default, is located in the same directory as the KDC databases unless explicitly defined with the acl_file key in kdc.conf. The file contains a list of principals, one per line, followed by the permissions that the principal has, and the other principals that the permissions are restricted to. A line from the file looks like this: mallen/admin@example.com admicl */admin@example.com The meaning of the permission identifiers admicl are provided in Table Table 7.12: Meaning of the Permission Identifiers from the ACL File Permission Identifier a / A d / D m / M c / C i / I l / L Description Addition of users or policies Deletion of users or policies Modification users or policies Changing principals' passwords Querying principal information Listing all principals in the database * All of the preceding permissions 218

219 In all cases, the lowercase letter allows the specified user the permission, and the uppercase letter denies the permission. The final section of the line defines which principals the permissions act on. If this is left blank, the default is to allow the behavior to all principals in the realm. To grant full permissions to the administrative user, follow this step: Edit the ACL so that the administrative user that you previously created has full permission. If the ACL does not exist, it should be created. Add the following line to the file (replacing EXAMPLE.COM with your realm name): * where user is the name of the administrative user. The final stage before Kerberos is fully installed on the network is to create a keytab file containing the kadmin principals that were created with the initialization of the realm. To create a keytab file, follow these steps: 1. Start kadmin locally by entering the following command: kadmin.local 2. At the kadmin prompt, enter the follwing command (all on one line): ktadd k /var/kerberos/krb5kdc/kadm5.keytab kadmin/admin kadmin/changepw This creates the keytab file in /var/kerberos/krb5kdc/, and it adds the principals to it. If you are using a different directory for your Kerberos installation, then this needs to be substituted at this point. 3. Exit kadmin by entering exit at the kadmin command prompt. It is now possible to start the Kerberos daemons to answer user authentication requests. The krb5kdc daemon has already been started in the "Initializing the Kerberos Database" procedure performed earlier; there is only one more daemon that needs to be started. To start the Kerberos Admin Daemon, follow this step: Start the kadmind daemon by entering the following command: kadmind The server is now capable of answering user authentication requests. Securing the UNIX or Linux KDC Securing a UNIX or Linux KDC is beyond the scope of this guide. However, there are many good sources for advice on this topic available. The following list provides a small selection: Linux Security Cookbook (Barrett, 2003) Practical UNIX and Internet Security (Garfinkel and Spafford, 2003) UNIX Installation Security and Integrity (Ferbrache and Shearer, 1993) Backing Up the UNIX or Linux KDC Regular backups should be made of a KDC according to local policy. The backups should exclude the krb5.keytab file. When backing up over a network, care should be taken so that the security of the system is not compromised. Use encryption whenever possible. 219

220 Establishing Cross-Realm Trusts Where it is required in the process of the development of a heterogeneous security solution using Windows Server 2003, you should set up a trust relationship between Windows Server 2003 domains and UNIX or Linux Kerberos realms. The following procedure sets up trust between the Windows Server 2003 domain EXAMPLE.COM and the UNIX or Linux Kerberos realm ADATUM.COM. By default, the trust will be nontransitive. This can be changed to transitive by using the netdom.exe tool from the Windows Server 2003 Resource Kit. The tool is located in the \support\reskit\netmgmt folder on the distribution media. See the tool's Help menu for details. Workstation computers that use services in an MIT Kerberos realm need to have a realm entry added. To set up a one way trust with an MIT Kerberos realm to access Kerberos resources in that realm: On each Windows computer that uses the MIT Kerberos realm for services, enter the following command at the command prompt: ksetup /addkdc ADATUM.COM kerberos.adatum.com Ksetup is part of both the Windows XP Resource Kit and the Windows Server 2003 Support Toolst. These mappings are stored in the registry under HKLM\System\CurrentControlSet\Control\LSA\Kerberos\Domains. You can use this key in conjunction with the Security Configuration Template mechanism to deploy realm configuration data to multiple computers instead of using Ksetup explicitly on individual computers. Guidance on how to do this is available from the Step-by-Step Guide to Using the Security Configuration Tool Set available at ndows2000serv/howto/seconfig.asp. To set up trust, follow these steps: 1. On the domain controller for the Windows Server 2003 domain, use the following command to set up the configuration for the foreign Kerberos realm: ksetup /addkdc ADATUM.COM kerberos.adatum.com 2. Start the Domain Tree Management tool. Click Start, click Programs, click Administrative tools, and then click Active Directory Domains and Trusts. 3. Right-click your domain and select Properties, select the Trusts tab, and then click New Trust. 4. Create a trusted domain relationship with the MIT Kerberos realm. Follow the steps through the New Trust Wizard. Click Next, enter the name of the realm you are creating a trust with, click Next, select Realm trust, click Next, select Transitive, click Next, select Two-way, click Next, enter a Trust password and confirm it, click Next, confirm your settings, and then click Next. Click Finish. Note The password used in steps 4 and 5 does not need to be entered again after the creation of the trust. The password can therefore be made as secure as is necessary, it is recommended that you use a completely random string made of lowercase and uppercase letters, numbers, and symbols. The string should be more than 8 characters long, and it is recommended that you increase this to

221 5. Use the following MIT Kerberos administration commands to create cross-realm principals in the foreign MIT Kerberos realm: kadmin -q ank -pw password kadmin -q ank -pw password where password is a valid password for the administrator. 6. Add the following lines to your krb5.conf file in the [realms] section: EXAMPLE.COM = { kdc = Kerberos.example.com:88 default_domain=example.com } Instead of using the Domain Tree Management user interface, you can use the Netdom tool to establish trust to an MIT Kerberos realm. See the tool's Help menu for details. Creating Account Mappings Account mappings are used to map a foreign Kerberos identity (in a trusted MIT Kerberos realm) to a local account identity in the domain. These account mappings are managed through the Active Directory Management tool. These account mappings allow the Kerberos realm to act as an account domain. Users with Kerberos principals that have mappings to domain accounts can log on to a workstation that is joined to a trusted domain using the Kerberos principal and password from the Kerberos realm. If you need to access earlier versions of Windows NT systems, the domain account that is used for mapping needs to have a password that is synchronized to the Kerberos principal password. This is because earlier versions of Windows NT systems will be using NTLM for authentication. Users can change their passwords in the Kerberos realm by selecting the Change Password feature from the Task Manager called up by pressing the <CTRL+ALT+DEL> sequence. 221

222 To create a mapping, follow these steps: 1. Click Start, click All Programs, click Administrative Tools, and then click Active Directory Users and Computers. 2. Start advanced features by clicking View, and then Advanced Features, as shown in Figure Figure 7.18 Active Directory Users and Computers dialog box 3. Locate the account to which you want to create mappings and right-click to view Name Mappings. This example uses the account michael_allen. 4. Click the Kerberos Names tab. 222

223 5. Add a principal from the foreign MIT Kerberos realm. The example shown in Figure 7.19 uses michael@adatum.com. Figure 7.19 Security Identity Mapping Kerberos Names tab Migrating Users Migrating users from a UNIX or Linux Kerberos realm can be done in one of two ways: Complete Migration All of the users that exist under the UNIX or Linux Kerberos realm are recreated under the Windows Server 2003 realm and the clients are all reconfigured to reference the Windows Server 2003 KDC for authentication information before the UNIX or Linux KDC is retired. Staged Migration A cross-realm trust is established between the UNIX or Linux Kerberos realm and the Windows Server 2003 realm, and the users are migrated over a period of time, with the client computers being reconfigured after all users are finally migrated to reference the Windows Server 2003 KDC. The Complete Migration scenario is the preferred solution, although it is more difficult to implement for larger organizations with many users. For administrative purposes, it is recommended that in the process of the migration you use a separate OU for the users that you are migrating so that they are easily separable from the remainder of your users. 223

224 Configuring Clients, Applications and Services The following sections detail how to configure UNIX or Linux clients and specific applications and services to use the Windows Server 2003 KDC. Creating Computer and User Accounts Use the Active Directory service management tool to create computer and user accounts for the host and user security principals logging on to the Windows Server 2003 Kerberos domain. To configure the UNIX and Linux hosts, follow these steps: 1. Use the Active Directory Management tool to create a new user account for the UNIX or Linux host: a. Select the Users folder, right-click and select New, and then choose user. b. Follow the New Object User Wizard and create a user with the logon name of the UNIX or Linux computer, and enter the name of the computer into the First name field to proceed to the next section. Click Next. c. Enter a password and clear the "User must change password at next logon" check box. Click Next. Click Finish. The account can be created in any container. It might be useful to create a new organizational unit (OU) and create the accounts there to easily identify them from Windows accounts. 2. Use ktpass to create the keytab file and set up the account for the UNIX or Linux host, and then copy the keytab file to the UNIX or Linux system and merge the keytab file into /etc/krb5.keytab, as follows: a. Use the following command to generate the UNIX or Linux host keytab file, map the principal to the account, and set the host principal password. This command should all be entered on one line: ktpass -princ host/hostname@example.com -mapuser account -pass password -out UNIXmachine.keytab where: hostname is the host DNS name, for example, kerberos.example.com. EXAMPLE.COM is the Kerberos realm name. account is the user account for the computer. password is a complex password for the account. Windows Server 2003 account names are not multipart as Kerberos principal names are. Because of this, it is not possible to directly create an account of the name host/hostname.dns.com. Such a principal instance is created through service principal name mappings. In this case, an account is created with a meaningful name and a service principal name mapping is added for host/hostname.dns.com. This is the purpose of using ktpass with the -princ and -mapuser switches. b. Securely transfer the keytab file (UNIXmachine.keytab from the earlier example) to the UNIX or Linux host. Then, merge the keytab file with any existing keytab file for the UNIX or Linux computer. In the directory that you have copied the keytab file to, start the ktutil utility by entering the following command: ktutil c. Then, at the kutil command prompt, enter the following command: 224

225 rkt UNIXmachine.keytab d. To ensure that the keytab has been merged properly, you should enter the following command at the ktutil command prompt: list The output should appear similar to the following example: slot KVNO Principal host/server.example.com@example.com f. To exit kutil, enter q at the kutil command prompt. g. Edit the file (/etc/krb5.conf) to refer to the Windows Server 2003 domain controller as the Kerberos KDC. The krb5.conf file entries should be similar to the following example: [libdefaults] default_realm = EXAMPLE.COM default_tkt_enctypes = des-cbc-md5 ; or des-cbc-crc default_tgs_enctypes = des-cbc-md5 ; or des-cbc-crc [realms] EXAMPLE.COM = { kdc = kerberos.example.com:88 } Note The default encryption type entries, default_txx_enctype, are optional. However, if the Kerberos client receives an encryption type error, set the default encryption type to either des-cbc-md5 or des-cbc-crc. Warning Be sure that your system clocks are synchronized (within two minutes) to the KDC system s clock. Otherwise, Kerberos authentication will fail because of clock skew errors. Instructions on the configuration of the NTP Service are provided in Chapter 6, "Developing the Infrastructure for Heterogeneous Security and Directory Solutions." 3. Finally, you need to create UNIX or Linux accounts on the client computers that correspond to the Windows Server 2003 domain accounts created in Step 1 so that the login process uses Kerberos authentication. You can do this by using the vipw command or other administration tools, depending on how you manage UNIX or Linux accounts. See the Kerberos Version 5 manual pages for more information on the use of computer accounts. Support for Kerberos Services Services running on UNIX or Linux systems can be configured with service instance accounts in the Active Directory. This allows full interoperability. Kerberos clients and servers on UNIX systems can authenticate using the Windows Server 2003 Kerberos server. And Windows 2000 Professional-based clients can authenticate to Kerberos services that support GSS API. Unlike Kerberos principal names, Windows Server 2003 account names are not multipart. Because of this, it is not possible to directly create an account of the name service/unix_srv.example.com. Such a principal instance is created through the service principal name mappings. 225

226 To create a service instance account in the Active Directory 1. Use the Active Directory Management tool to create a user account for the UNIX or Linux service; for example, create an account with the name sample. 2. Use the ktpass tool to set up an identity mapping for the user account. Use this command: ktpass princ service-instance@realm mapuser account-name -pass password -out UNIXmachine.keytab The format of the Kerberos service-instance name is: service/host.realm_name; for example: ktpass princ sample/unix_srv.example.com@example.com -mapuser sample pass password out UNIX_SRV.keytab In this case, an account is created with a the name sample, and a service principal name mapping is added for sample/unix_srv.example.com. This is the purpose of using Ktpass with the princ and mapuser switches. 3. Merge the keytab file with the /etc/krb5.keytab file on the UNIX or Linux host by copying the keytab file to the UNIX or Linux host and then entering the following command in the directory that it has been copied to: ktutil Then, at the ktutil command, prompt enter the following command: rkt UNIX_SRV.keytab Where UNIX-SRV.keytab is the name of the keytab file you created in Step 2. Exit kutil by entering q at the kutil prompt. Note You cannot map multiple service instances to the same user account Configuring MIT Kerberos as a Client The MIT Kerberos distribution contains both client and server applications. As a result, the installation and initial /etc/krb5.conf configuration of Kerberos as a client is identical to that of the KDC. Please follow the guidance provided earlier in this chapter for the following procedures: Obtaining and installing MIT Kerberos Configuring the /etc/krb5.conf file Configuring the Kerberos-aware PAM Pluggable Authentication Modules (PAMs) allow the standard authentication methods to be extended. The operation of PAM is explained in Chapter 2, "Authentication and Authorization in UNIX and Windows Environments." The following sections detail the installation and configuration of Kerberos PAM modules on Solaris 9 and Red Hat Linux 9. Configuring the Solaris PAM Module The standard Solaris installation for both Solaris 8 and Solaris 9 includes the PAM-KRB5 module. The krb5.conf file needs to be configured as described in the "Configuring the /etc/krb5.conf" section earlier in this chapter. 226

227 Modifying /etc/pam.conf for PAM-KRB5 The second file that needs to be modified is the /etc/pam.conf file. This contains the details of the modules used by each application for authentication. The following line needs to be included in the file. login auth optional pam_krb5.so.1 try_first_pass This enables the login program to authenticate against the Kerberos PAM module. Additional lines can be added for other applications. Note It is recommended that systems are configured to use the Kerberized telnet and ftp clients. These should not be included in the /etc/pam.conf file for authentication because they already are configured to do this. Configuring the Red Hat PAM Module The standard Red Hat Linux 9 installation includes the pam_krb5 module. To determine if it is installed, type the following: rpm -qa grep pam_krb5 This returns the version of the RPM installed. If it is not installed on your system, you should install it using the following procedure. To install the pam_krb5 RPM, follow these steps: 1. Insert the second of the three Red Hat Linux 9 Installation CDs into the CD-ROM drive. 2. Type the following commands: mount /mnt/cdrom cd /mnt/cdrom/redhat/rpms rpm ivh pam_krb rpm cd / umount /mnt/cdrom Editing the PAM configuration files In order for the PAM module to be used, you need to make changes to the relevant files in /etc/pam.d/. Each of the files in this directory represents a single program that uses the PAM authentication modules. Each of the example files is similar to the one in the following example. This particular one is for the ssh daemon (sshd). #%PAM-1.0 auth required pam_stack.so service=system-auth auth required pam_nologin.so account required pam_stack.so service=system-auth password required pam_stack.so service=system-auth session required pam_stack.so service=system-auth session required pam_limits.so session optional pam_console.so 227

228 Examples for the lines which need to be added for the pam_krb5 module are included in the RPM and are installed in /usr/share/doc/pam_krb5-1.60/pam.d/. Continuing with the example for sshd, the recommended modifications are as follows: #%PAM-1.0 auth required /lib/security/pam_nologin.so auth sufficient /lib/security/pam_unix.so shadow md5 nullok likeauth auth required /lib/security/pam_krb5.so use_first_pass account required /lib/security/pam_unix.so password required /lib/security/pam_cracklib.so password required /lib/security/pam_unix.so shadow md5 nullok use_authtok session required /lib/security/pam_unix.so session optional /lib/security/pam_krb5.so There are example configurations for all significant applications included in the /usr/share/doc/pam_krb5-1.60/pam.d/ directory. Configuring Kerberos-aware Applications and Services There are a number of Kerberos-aware applications available, including MIT Kerberos 1.3.1, open source, and commercial programs. The following sections detail the configuration and use of a small number of these applications. Using the Applications from MIT Kerberos The applications installed with the MIT Kerberos distribution are dependant upon the correct configuration of the /etc/krb5.conf file. Please follow the earlier guidance on the installation of MIT Kerberos to ensure that all the steps have been carried out before proceeding with the following section. Telnet The Kerberized telnet program is already configured for use. It is identical to the standard telnet command, with the addition of the following switches: -f Forwards a copy of your tickets to the remote host -F Forwards a forwardable copy of your tickets to the remote host -k realm Requests tickets for the remote host in realm instead of determining the realm -K Uses tickets to authenticate to the remote host, but does not log in -a Attempts to automatically log in using tickets. This will assume the same user name unless you explicitly specify another -x Turns on encryption. 228

229 To log in to the remote.example.com computer automatically using an encrypted Kerberos session, type the following: telnet a f x remote.example.com FTP The Kerberized ftp program is already configured for use. It is identical to the standard ftp command, with the addition of the following switches: -k realm Requests tickets for the remote hosts in realm instead of determining the realm -f Forward a copy of your tickets to the remote host It also adds the protect command at the ftp> prompt to the non-kerberized version. The protect command has three options: clear, safe, and private. clear has no protection. safe checks the data integrity by using a checksum. private encrypts the session. Configuring OpenSSH to Use Kerberos OpenSSH in an open implementation of the Secure Shell protocol developed by the OpenBSD group. It is available at and although it has Kerberos support, it is not enabled by default. Obtaining and Compiling OpenSSH There are two versions of OpenSSH available for download: the OpenBSD-specific version and the portable version. For all platforms other than OpenBSD, the portable version is required. It is also necessary to have a number of GNU utilities installed to build the OpenSSH packages. Note To compile on Solaris 9 and Red Hat Linux 9, the "portable" version is required. To install OpenSSH prerequisites on Solaris 9, follow these steps: The build of OpenSSH on Solaris 9 requires a set of GNU tools. These should be downloaded from and installed before proceeding. You should download and install the following packages: gcc sol9-intel-local.gz make-3.80-sol9-intel-local.gz autoconf sol9-intel-local.gz automake sol9-intel-local.gz m4-1.4-sol9-intel-local.gz openssl-0.9.7c-sol9-intel-local.gz The intel portion of the file name indicates that these files are for the Intel platform, you must download packages suitable for your platform. The local portion of the file name indicates that files from this package will be installed under the directory /usr/local. For each package, follow the steps listed here. These steps use the make-3.80-sol9-intellocal.gz package file as an example; you must change the file names to reflect the file names that you are using: 229

230 1. Extract the Solaris package file by entering the following command at the shell prompt: gunzip make-3.80-sol9-intel-local.gz 2. Install the Solaris make package by entering the following command: pkgadd -d make-3.80-sol9-intel-local 3. At the Select package(s) you wish to process (or 'all' to process all packages). (default: all) [?,??,q] prompt enter y. 4. If the Do you want the directory creating /usr/local [?,y,n,q] prompt is shown, enter y. Repeat this procedure for each of the required packages listed earlier. On Solaris 9, you should then modify your $PATH variable in your shell to include both the /usr/local/bin/ directory where you just installed the GNU utilities and the /usr/ccs/bin/ directory, where there are additional utilities needed by the OpenSSH build. The following guidance is for the sh shell. Details for changing the $PATH variable in other shells can be found in their respective manual pages. To modify the $PATH variable, follow this step: At the command prompt, type the following commands: PATH=$PATH:/usr/local/bin/:/usr/ccs/bin/ export PATH After the installation of the prerequisite utilities on Solaris 9, the steps required to install OpenSSH are the same for both Solaris 9 and Red Hat Linux 9. Patching and installing OpenSSH requires the following steps be taken: 1. Download the latest OpenSSH portable source from 2. Extract the source by entering the following commands: gunzip openssh-3.6.1p2.tar.gz tar xvf openssh-3.6.1p2.tar 3. Run the configuration utility with the Kerberos support specified by entering the command:./configure -with-kerberos5=/usr/local where /usr/local is your MIT Kerberos installation directory. 6. Build and install the SSH application by entering the following command: make && make install 230

231 Using OpenSSH You will need to ensure that the ssh_config file in /etc/ssh/ssh_config contain the options as listed in Table These additions allow SSH to use Kerberos for authentication. Table 7.13: Additional GSSAPI Options in ssh_config Option GssapiAuthentication GssapiDelegateCredentials Description Specifies if authentication based on GSSAPI may be used. This should be set to "yes." Specifies if SSH is to forward credentials to the server. This should be set to "yes." You will also need to ensure that the host has a host key in the system keytab and that a principal exists for the host. Provided that you have a forwardable ticket, SSH will automatically log you in and forward your ticket to the target server. To use OpenSSH, follow these steps: 1. To connect to a host running an ssh host daemon, enter the following command at the command line: ssh ssh-host.example.com where ssh-host.example.com is the name of the computer that you are trying to connect to. 2. If this is the first time that you are connecting to this computer, something similar to the following example will be returned: The authenticity of host 'ssh-host.example.com' can't be established. RSA Key fingerprint is fe:b6:80:5b:51:11:cb:16:80:a0:22:d8:2e:a6:e8:ba. Are you sure that you want to continue connecting (yes/no)? If you are aware of the RSA key of the computer that you are connecting to, you should ensure that the key matches with that displayed on the screen. Otherwise, accepting this by typing yes will add the host key to the list of known hosts. If the host key changes at any time, either through reconfiguration of the host or through a malicious attempt to use a man-in-the-middle attack, ssh will automatically warn you of the fact. After you accept the key, you will see the following: Warning: Permanently added 'ssh-host.example.com' (RSA) to the list of known hosts. You will then be presented with a shell prompt because the Kerberos ticket will be automatically forwarded to provide authentication. Configuring Kerberized Daemons A selection of Kerberized daemons are installed with MIT Kerberos These include versions of the standard Telnet, FTP, and Login server daemons. If you have followed the steps for downloading and installing OpenSSH with the Kerberos patches, the sshd on your system will be Kerberos-enabled already. These server daemons use the same configuration files as the other utilities detailed earlier, so the only changes that need to be made to your configuration are to ensure that inetd or xinetd call the correct Kerberized versions of the daemons. To enable Kerberized servers on Solaris 9, follow these steps: 231

232 1. You need to edit your /etc/inetd.conf file and comment out any lines which refer to telnet, ftp, or login. Then, insert the following lines at the end of the file: klogin stream tcp nowait root /usr/local/sbin/klogind => klogind -k -c ftp stream tcp nowait root /usr/local/sbin/ftpd => ftpd -a telnet stream tcp nowait root /usr/local/sbin/telnetd => telnetd -a valid ssh stream tcp nowait root /usr/local/sbin/sshd => sshd 2. Restart inetd. You can do this by entering the following command at the command prompt as root: kill HUP `ps e awk '/inetd/ {print $1}'` To enable Kerberized servers on Red Hat Linux 9, follow these steps: 1. You need to create an entry in the xinted.d directory to include the Kerberized ftpd. You can do this by entering the following command as root: cp /etc/xinted.d/gssftp /etc/xinetd.d/kftp 2. Now edit the /etc/xinetd.d/kftp file and change the server line to point to the installed location of the MIT Kerberized ftpd. On a default Red Hat Linux 9 installation, this line would read: server = /usr/local/sbin/ftpd You should also modify the klogin and krb5-telnet files in the /etc/xinetd.d/ directory to ensure that they are pointing to the klogind and the telnetd in the MIT Kerberos install directory. 3. At a command prompt, enter the following command as root: setup 4. This starts the setup utility. Scroll down the menu to System services, press Tab, and then press Enter to run the tool. 5. Scroll down the Services menu and press the space bar to select klogin, krb5- telnet, kftp, and sshd. You should clear any of the following non-kerberized services from the list : login, telnetd, gssftpd, rlogin, rsh, and tftpd. 6. Press Tab, and then press Enter to select Ok. Press Tab twice to select Quit, and then press Enter. 7. At the command prompt, type the following command to restart xinetd: /etc/init.d/xinetd restart Following this procedure establishes that your Telnet, FTP and Login daemons are automatically using the Kerberized versions. To operate a Kerberized Telnet or FTP daemon on Windows Server 2003, you will need to obtain and install a commercial package such as those available from Van Dyke. More information on Van Dyke can be found at If you have followed the steps for downloading and installing OpenSSH with the Kerberos patches, the sshd on your system will be Kerberos enabled already. 232

233 Summary In this chapter, you have been shown how to install and configure Kerberos as a heterogeneous security solution. The chapter has covered the creation of KDCs on UNIX, Linux, and Windows; cross-realm trusts between Windows and UNIX or Linux Kerberos realms; and the use of the Kerberized applications included with the MIT Kerberos distribution. You are now able to create a heterogeneous security solution using Windows Server

234

235 8 Developing the LDAP Security and Directory Infrastructure Introduction This chapter provides guidance for implementing a security and directory infrastructure for UNIX and Linux clients using the Windows Server 2003 Active Directory Lightweight Directory Access Protocol (LDAP) service. Guidance is also provided for configuring the Windows Server 2003 domain controller and the UNIX and Linux clients. Organizations can use this guidance to create a unified security and directory infrastructure based around the Windows Server 2003 platform. This solution improves the administration of users and passwords by centralizing user accounts into one place: Active Directory. This solution simplifies authentication procedures for users by requiring them to remember and use only one user name and password across Windows, UNIX, and Linux platforms. The guidance in this chapter covers two main solution scenarios: Using Active Directory for UNIX and Linux authentication and authorization Using Active Directory as an identity store for UNIX and Linux clients The chapter is structured into three sections. The first section is generic to both security and directory solutions using LDAP. The final two sections are specific to the security and directory solutions, respectively. The three sections are titled: "Configuring Active Directory, UNIX, and Linux to Support LDAP Security and Directory Services" "Building the LDAP Authentication and Authorization Infrastructure" "Building the Active Directory Identity Store" The diagram in Figure 8.1 is a high-level overview of the solution presented in this chapter. The key components shown in Figure 8.1 are the PADL LDAP Pluggable Authentication Modules (PAM), the Name Service Switch (NSS) module, and the extension to the Active Directory schema. The configuration of these and their respective infrastructure requirements are covered in this chapter. References to detailed information about PAM and NSS can be found in the "Prerequisites" section. 235

236 Figure 8.1 Overview of LDAP security and directory solution infrastructure Prerequisites Complete the Envisioning and Planning phases before implementing LDAP security and directory services using Windows Server Before implementing the solution in this chapter, you should: Make the design decisions outlined in Chapter 5, "Planning Heterogeneous Security and Directory Solutions," and produce a development plan. Read and implement the appropriate sections from Chapter 6, "Developing the Infrastructure for Heterogeneous Security and Directory Solutions." The guidance in this chapter requires a configured Windows Server 2003 Active Directory infrastructure and an appropriately configured Domain Name System (DNS) infrastructure. Review the descriptions of PAM and NSS in Chapter 2, "Authentication and Authorization in UNIX and Windows Environments," and Chapter 3, "Active Directory and LDAP as Identity Stores in UNIX and Windows Environments." 236

237 Configuring Active Directory, UNIX, and Linux to Support LDAP Security and Directory Services The standard installation of Windows Server 2003 Active Directory is tailored for a homogeneous Windows environment. It includes a comprehensive range of tools for this purpose. When Windows Server 2003 Active Directory is used to provide LDAP services in a heterogeneous environment, extra features and new tools are necessary. This section provides guidance on installing and configuring these tools with Active Directory to provide LDAP services to UNIX and Linux clients. This section also provides guidance on installing and configuring the LDAP tools required by the UNIX and Linux clients. Installing Tools and Utilities This section guides you through installing tools and utilities that are required when implementing an LDAP security and directory infrastructure based on Active Directory. The main Active Directory tools that you should install are shown in Table 8.1. Two of these are standard snap-ins for the Microsoft Management Console (MMC). Table 8.1: Active Directory Tools for Managing the LDAP service Tool/Utility Description Format Schema MMC Snap-in The easiest way to view and edit the MMC snap-in schema. Ldifde ADSI Edit MMC Snap-in Ldp The preferred tool to deploy Active Directory schema extensions in a production environment. Low-level Active Directory editor. Can be used to view all objects in the directory, including schema information. You can modify objects and set access control lists on objects using this tool. A GUI-based LDAP support tool. Allows you to carry out LDAP operations (connect, bind, search, modify, add, delete) against any LDAP-compatible directory. Command line tool MMC snap-in Windows GUI tool In addition to the Windows Server 2003-based tools, you will also need to install UNIX and Linux LDAP tools. Table 8.2 shows the main tools and utilities that you need to install. 237

238 Table 8.2: UNIX and Linux Tools for Managing the LDAP service Tool/Utility Description Format LDAP libraries ldapsearch, ldapadd, ldapmodify, ldapdelete pam_ldap nss_ldap Name Service Cache Daemon The shared libraries used by applications and modules on UNIX and Linux. Tools for searching and modifying an LDAP directory. PAM from PADL that provides LDAP authentication and authorization services for UNIX and Linux clients NSS modules from PADL that allow UNIX and Linux configuration data to be stored in LDAP directories. Caches NSS configuration data provided through nss_ldap to improve performance on UNIX and Linux clients. Installing the Active Directory Schema MMC Snap-in Binary package or source code. Programming interface. Command line tools PAM module NSS module Binary package or source code. UNIX or Linux system service (daemon) The Active Directory Schema MMC snap-in allows you to view and configure the Active Directory schema. It is not installed by default during the Windows Server 2003 installation. You require this feature when configuring your Windows Server 2003 Active Directory installation as an LDAP directory store. The Active Directory Schema MMC Snap-in should be installed on your Windows 2003 Server domain controllers. To install the Active Directory Schema MMC snap-in, follow these steps: 1. Open a command prompt, click Start, click Run, enter cmd, and click OK. 2. At the command prompt, type: regsvr32 schmmgmt.dll This command will register schmmgmt.dll on your computer. For more information about using regsvr32, see the Windows Server 2003 documentation. 3. Click Start, click Run, type mmc /a, and then click OK. 4. On the File menu, click Add/Remove Snap-in, and then click Add. 5. Under Snap-in, double-click Active Directory Schema, click Close, and then click OK. 6. To save this console, on the File menu, click Save. 7. In Save in, point to the %SystemRoot%\system32 directory. 8. In File name, type schmmgmt.msc, and then click Save. 238

239 To create a shortcut to the Active Directory Schema MMC snap-in on your Start menu, follow these steps: 1. Right-click Start, click Open all Users, double-click the Programs folder, and then double-click the Administrative Tools folder. 2. On the File menu, point to New, and then click Shortcut. 3. In the Create Shortcut Wizard, in Type the location of the item, type schmmgmt.msc, and then click Next. 4. In the Select a Title for the Program dialog box, in Type a name for this shortcut, type Active Directory Schema, and then click Finish. You will now find Active Directory Schema under your Start menu in Administrative Tools. Warning Modifying the schema is an advanced operation best performed by experienced programmers and system administrators. For detailed information about modifying the schema, see the Active Directory Programmer's Guide at To open the Active Directory Schema MMC snap-in, follow this step: To open the Active Directory Schema snap-in, click Start, click Control Panel, double-click Administrative Tools, and then double-click Active Directory Schema. Notes You can also run the Active Directory Schema snap-in from a computer running Windows XP Professional; install the Windows Server 2003 Administration Tools Pack on the computer. The Windows Server 2003 Administration Tools Pack cannot be installed on computers running Windows 2000 Professional or Windows 2000 Server. Installing the Windows Server 2003 Support Tools In addition to the tools built into the Windows Server 2003 operating system, a collection of additional support tools is included on the Windows Server 2003 operating system CD. You must install them separately by using the Support Tools setup program. These tools should be installed on your Windows Server 2003 domain controllers. The support tools are intended to assist Microsoft support personnel and network administrators in diagnosing and resolving computer problems. The support tools include utilities that enable you to extend and manage the Active Directory schema. These tools are necessary for some of the tasks in this chapter. Two Windows Server 2003 support tools are particularly useful for this guide: the ADSI Edit MMC snap-in and the Ldp tool. Important The Support Tools and Support Tools Help (Suptools.chm) are in the English language only. If you install them on a non-english operating system or on an operating system with a Multilingual User Interface (MUI) Pack, you will see English Support Tools content mixed with non-english content in the Help and Support Center. This behavior should be expected if you browse through tools documentation in the Tools By Category listing in the Tools Center in Help and Support Center, or if you search anywhere in Help and Support Center by a tool name. 239

240 You must be logged on as an administrator or a member of the Administrators group to install the Support Tools from the Windows Server 2003 operating system CD. The Support Tools setup program installs all the Support Tools files and documentation onto the Windows 2003 Server's hard disk. The setup program creates a Windows Support Tools folder within the Programs folder on the Start menu. For information about individual tools, click Tools Help. To install the Windows Server 2003 Support Tools, follow these steps: 1. Insert the Windows Server 2003 CD into your CD-ROM drive. 2. Click No if you are prompted to reinstall Windows. 3. When the Welcome screen appears, click Perform Additional Tasks, and then click Browse this CD. 4. Go to the \Support\Tools folder. For complete setup information, refer to the Readme.htm file in this folder. 5. Double-click Suptools.msi. 6. Follow the instructions that appear on your screen. Warning Certain support tools, if used improperly, may cause your computer to stop functioning. It is recommended that only experienced users install and use these tools. Installing the Windows Server 2003 Resource Kit The Windows Server 2003 Resource Kit includes utilities for managing the Active Directory LDAP database. You should install the Windows Server 2003 Resource Kit on each Windows Server 2003 domain controller before proceeding with extending and working with the Active Directory schema. To install the Windows Server 2003 Resource Kit Tools, follow these steps: Note If the Beta version of Resource Kit Tools is installed, it must be removed first. 1. Using Internet Explorer, browse to the Windows Server 2003 Resource Kit Tools at 2. Click the Download link to start the download. Do one of the following: To start the installation immediately, click Open or Run this program from its current location. To copy the download to your Windows 2003 Server domain controller for installation at a later time, click Save or Save this program to disk. 3. To install the Resource Kit tools, run the rktools.exe package. Using Windows Explorer, browse to the location where you downloaded rktools.exe and doubleclick the file. This starts the Windows Resource Kit Tools Setup Wizard. 4. Click Next. 5. In the End User License Agreement dialog box, select I agree and click Next. 6. In the User Information dialog box, enter your name and organization and click Next. 240

241 7. Click Install Now, and then click Finish. 8. All necessary files are installed to the %Program Files%\Windows Resource Kits\Tools folder. 9. Before starting and using the Resource Kit tools, be sure to read the readme.htm file, which is located in the %Program Files%\Windows Resource Kits\Tools folder. The readme.htm can also be accessed from the Start menu. Installing and Configuring the UNIX and Linux LDAP Client Libraries and Tools You need to install the LDAP client libraries and tools on the UNIX and Linux hosts before they can connect to and use the Active Directory LDAP service. The LDAP libraries provide the LDAP application programming interface (API) used by the LDAP tools and the PADL nss_ldap and pam_ldap modules. The LDAP tools include command line utilities for managing LDAP, debugging LDAP, and carrying out search and bind operations on an LDAP directory. The procedures in this guide use the OpenLDAP libraries on Red Hat Linux 9 and the native Solaris 9 LDAP libraries; these are the recommended libraries for implementing the PADL LDAP modules. Important Current versions of OpenLDAP do not implement some LDAP controls that are necessary when working with large numbers of entries in Active Directory; for example, large numbers of users or groups. These LDAP controls are the Paged Results control and the Ranged Results control. Active Directory sets limits on the results that can be returned to a client, and these two controls allow a client to retrieve results sets that are larger than those limits. For more information on changing the limits set by Active Directory, see the Knowledge Base article HOW TO: View and Set Lightweight Directory Access Protocol Policies by Using Ntdsutil.exe in Windows 2000 at Changing these parameters is not covered in this guide. Install and Configure the LDAP Client Libraries and Tools on Red Hat Linux 9 The standard installation of Red Hat Linux 9 includes the following LDAP-related Red Hat Package Manager (RPM) packages: php-ldap openldap nss_ldap openldap-devel This list can be verified by typing the following command: rpm qa grep ldap The standard installation of Red Hat Linux 9 does not include the LDAP client tools. Note You do not need to install the OpenLDAP server RPM when using UNIX and Linux as a client of Active Directory. 241

242 To Install and configure the OpenLDAP LDAP client tools on Red Hat 9, follow these steps: 1. Place the second of the three Red Hat Linux 9 installation CDs in the CDROM drive. 2. Type the following commands: mount /mnt/cdrom cd /mnt/cdrom/redhat/rpms rpm ivh openldap-clients i386.rpm cd / umount /mnt/cdrom 3. Edit the /etc/openldap/ldap.conf file and add two lines (shown in bold in the reprinted configuration file that follows). Important On Red Hat 9, there are two ldap.conf files: The /etc/openldap/ldap.conf file configures the client libraries and tools. The /etc/ldap.conf file configures pam_ldap and nss_ldap only. Always ensure that you update the correct ldap.conf file. Change the HOST line to contain the domain name of your Active Directory domain controller. # $OpenLDAP: pkg/ldap/libraries/libldap/ldap.conf,v /09/05 17:54:38 kurt Exp $ # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE #URI dc=example, dc=com ldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never HOST win2003ent.example.com BASE cn=users,dc=example,dc=com Note These lines can be added automatically using the Red Hat authconfig tool. 242

243 4. Test the configuration of your LDAP client tools by determining the Active Directory LDAP capabilities using the ldapsearch tool. Enter the following command: ldapsearch -x -s base -b "" "(objectclass=*)" The output from the command should be similar to that shown here: version: 2 # # filter: (objectclass=*) # requesting: ALL # # dn: currenttime: Z subschemasubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=example,DC=com dsservicename: CN=NTDS Settings,CN=WIN2003ENT,CN=Servers,CN=Default-First- Site,CN=Sites,CN=Configuration,DC=example,DC=com namingcontexts: DC=example,DC=com namingcontexts: CN=Configuration,DC=example,DC=com namingcontexts: CN=Schema,CN=Configuration,DC=example,DC=com namingcontexts: DC=DomainDnsZones,DC=example,DC=com namingcontexts: DC=ForestDnsZones,DC=example,DC=com namingcontexts: DC=TAPI3Directory,DC=example,DC=com defaultnamingcontext: DC=example,DC=com schemanamingcontext: CN=Schema,CN=Configuration,DC=example,DC=com configurationnamingcontext: CN=Configuration,DC=example,DC=com rootdomainnamingcontext: DC=example,DC=com supportedcontrol: supportedcontrol: supportedcontrol: supportedcontrol: supportedcontrol: supportedcontrol: supportedcontrol: supportedcontrol: supportedcontrol: supportedcontrol: supportedcontrol: supportedcontrol: supportedcontrol: supportedcontrol: supportedcontrol: supportedcontrol: supportedcontrol: supportedcontrol: supportedcontrol: supportedcontrol: supportedcontrol: supportedldapversion: 3 243

244 (continued) supportedldapversion: 2 supportedldappolicies: MaxPoolThreads supportedldappolicies: MaxDatagramRecv supportedldappolicies: MaxReceiveBuffer supportedldappolicies: InitRecvTimeout supportedldappolicies: MaxConnections supportedldappolicies: MaxConnIdleTime supportedldappolicies: MaxPageSize supportedldappolicies: MaxQueryDuration supportedldappolicies: MaxTempTableSize supportedldappolicies: MaxResultSetSize supportedldappolicies: MaxNotificationPerConn supportedldappolicies: MaxValRange highestcommittedusn: supportedsaslmechanisms: GSSAPI supportedsaslmechanisms: GSS-SPNEGO supportedsaslmechanisms: EXTERNAL supportedsaslmechanisms: DIGEST-MD5 dnshostname: win2003ent.example.com ldapservicename: example.com:win2003ent$@example.com servername: CN=WIN2003ENT,CN=Servers,CN=Default-First- Site,CN=Sites,CN=Configu ration,dc=example,dc=com supportedcapabilities: supportedcapabilities: supportedcapabilities: issynchronized: TRUE isglobalcatalogready: TRUE domainfunctionality: 0 forestfunctionality: 0 domaincontrollerfunctionality: 2 # search result search: 2 result: 0 Success # numresponses: 2 # numentries: 1 The main differences that you will see in your output relate to your server's DNS name and the distinguished name of your domain (for example, dc=example,dc=com). If you do not see all of the preceding sections, then it is probable that either your LDAP or your network configurations are at fault. To determine the exact problem, see the guidance on testing in Chapter 9, "Testing Windows-based Security and Directory Solutions." Note By default, the Windows Server 2003 Active Directory does not allow anonymous operations on the LDAP directory. However, the ldapsearch x s base b "" "(objectclass=*)" command searches the rootdse, and this anonymous operation is permitted. 244

245 Configure LDAP Client Libraries and Tools on Solaris 9 Solaris 9 includes the LDAP libraries. These libraries should be used when building the PADL pam_ldap and nss_ldap modules. Before building the PADL modules, you must configure and test the Solaris 9 LDAP libraries. The steps that you need to take are summarized here: Ensure that networking is correctly configured. Configure the DNS resolver. Configure the LDAP client libraries. The following procedure details how you should carry out these steps. To install and configure the LDAP client libraries and tools on Solaris 9, follow these steps: 1. Test the network connection from the Solaris 9 computer to the Active Directory domain controller by entering the following command at a shell prompt on the Solaris 9 computer: ping You should replace with the IP address of your Active Directory domain controller. 2. Configure the DNS resolver by editing the file /etc/resolv.conf using a text editor such as vi or emacs. You should update the following two lines with the IP address of your DNS servers or servers and your domain name: nameserver domainname example.com. 3. Check that the Solaris 9 LDAP libraries are installed by entering the following command: pkginfo grep ldap You should see the SUNWlldap package listed. a. If the SUNWlldap package is not listed, then install it from the Solaris 9 installation disk containing this package by entering the following command: pkgadd d /cdrom/cdrom0/s2/solaris_9/product SUNWlldap Note The path name may differ depending on the installation disks that you are using. c. At the following prompt: Do you want to continue with the installation of <SUNWlldap> [y,n,?] type y and press enter. 245

246 4. Test that the Solaris computer is capable of resolving the domain name of your Active Directory domain controller (for example, win2003ent.example.com). Do this by entering the following command at the shell prompt: nslookup win2003ent.example.com The output from this command should include the IP address of your Active Directory domain controller. The output should look similar to the following example: Server: Address: #53 Name: win2003ent.example.com Address: Configure the LDAP client tools and libraries using the Solaris ldapclient command by entering the following multi-line command. ldapclient -v manual \ -a objectclassmap=passwd:posixaccount=user \ -a attributemap=passwd:uid=samaccountname \ -a attributemap=passwd:uidnumber=mssfu30uidnumber \ -a attributemap=passwd:gidnumber=mssfu30gidnumber \ -a attributemap=passwd:uniquemember=member \ -a attributemap=passwd:homedirectory=mssfu30homedirectory \ -a attributemap=passwd:loginshell=mssfu30loginshell \ -a attributemap=passwd:gecos=mssfu30gecos \ -a attributemap=passwd:posixgroup=group \ -a defaultsearchbase=cn=users,dc=example,dc=com \ -a servicesearchdescriptor=passwd:cn=users,dc=example,dc=com \ -a defaultserverlist= \ -a domainname=example.com. \ -a credentiallevel=anonymous \ -a authenticationmethod=none Note The previous attributemap parameters in the ldapclient command are not used by the PADL NSS and PAM modules. They are only used by the Solaris pam_ldap and nss_ldap modules. The example maps the schema attributes expected by the Solaris pam_ldap and nss_ldap modules to the Microsoft Services for UNIX (SFU) 3.5 schema attributes used in this guide. These parameters are included here for completeness and are not strictly necessary. You must change the IP address to be that of your Active Directory domain controller or controllers, and the defaultsearchbase and servicesearchdescriptor parameters to reflect your domain name and the organizational unit where your Active Directory user accounts are stored, respectively. The other parameters configure the Solaris 9 pam_ldap and nss_ldap modules. These modules are not fully compatible with Windows Server 2003 Active Directory. Note The backslash character (\) is used by UNIX and Linux shells to indicate that a command line is being extended to the next line. It must be the last character on the line. 246

247 6. The ldapclient command modifies /etc/nsswitch.conf to only use LDAP and files for host name information. You must modify the file to add DNS lookups back in. Using a text editor such as vi or emacs, edit /etc/nsswitch.conf and modify the hosts: line to be: hosts: dns files 7. Test the configuration of your LDAP client tools by determining the Active Directory LDAP capabilities using the OpenLDAP ldapsearch tool. Enter the following command: ldapsearch -h win2003ent.example.com. \ -s base -b "" "(objectclass=*)" where win2003ent.example.com. is the domain name of your Active Directory domain controller. The output from the command should be similar to that shown here: currenttime= z subschemasubentry=cn=aggregate,cn=schema,cn=configuration,dc=example,dc=com dsservicename=cn=ntds Settings,CN=WIN2003ENT,CN=Servers,CN=Default-First- Site,CN=Sites,CN=Configuration,DC=example,DC=com namingcontexts=dc=example,dc=com namingcontexts=cn=configuration,dc=example,dc=com namingcontexts=cn=schema,cn=configuration,dc=example,dc=com namingcontexts=dc=domaindnszones,dc=example,dc=com namingcontexts=dc=forestdnszones,dc=example,dc=com namingcontexts=dc=tapi3directory,dc=example,dc=com defaultnamingcontext=dc=example,dc=com schemanamingcontext=cn=schema,cn=configuration,dc=example,dc=com configurationnamingcontext=cn=configuration,dc=example,dc=com rootdomainnamingcontext=dc=example,dc=com supportedcontrol= supportedcontrol= supportedcontrol= supportedcontrol= supportedcontrol= supportedcontrol= supportedcontrol= supportedcontrol= supportedcontrol= supportedcontrol= supportedcontrol= supportedcontrol= supportedcontrol= supportedcontrol= supportedcontrol= supportedcontrol= supportedcontrol= supportedcontrol= supportedcontrol= supportedcontrol= supportedcontrol= supportedldapversion=3 supportedldapversion=2 247

248 (continued) supportedldappolicies=maxpoolthreads supportedldappolicies=maxdatagramrecv supportedldappolicies=maxreceivebuffer supportedldappolicies=initrecvtimeout supportedldappolicies=maxconnections supportedldappolicies=maxconnidletime supportedldappolicies=maxpagesize supportedldappolicies=maxqueryduration supportedldappolicies=maxtemptablesize supportedldappolicies=maxresultsetsize supportedldappolicies=maxnotificationperconn supportedldappolicies=maxvalrange highestcommittedusn=94227 supportedsaslmechanisms=gssapi supportedsaslmechanisms=gss-spnego supportedsaslmechanisms=external supportedsaslmechanisms=digest-md5 dnshostname=win2003ent.example.com servername=cn=win2003ent,cn=servers,cn=default-first- Site,CN=Sites,CN=Configuration,DC=example,DC=com supportedcapabilities= supportedcapabilities= supportedcapabilities= issynchronized=true isglobalcatalogready=true domainfunctionality=0 forestfunctionality=0 domaincontrollerfunctionality=2 The main differences that you will see in your output relate to your server's DNS name and the distinguished name of your domain (for example dc=example,dc=com). If you do not see all of the preceding sections, then it is probable that either your LDAP or your network configurations are at fault. To determine the exact problem, see the guidance on testing in Chapter 9, "Testing Windows-based Security and Directory Solutions." Note By default, the Windows Server 2003 Active Directory does not allow anonymous operations on the LDAP directory. However, the ldapsearch -x -s base -b "" "(objectclass=*)" command searches the rootdse, and this anonymous operation is permitted. Install and Configure the Name Service Cache Daemon The Name Service Cache Daemon (NSCD) sits between the applications using name services and the mechanisms providing those name services. It caches name service data and improves response times. 248

249 Without NSCD, an application makes a call to one of the standard libc function calls: getxxnam(), getxxuid(), getxxent(), and getxbyy(). NSS then dynamically loads the correct module for the name service mechanism specified in /etc/nsswitch.conf. With NSCD, the application still makes the same call, but now the corresponding libc function actually calls NSCD through an Inter-Process Communication (IPC) call. If NSCD has cached the data required by the application, it returns it; otherwise, it calls the NSS module in the usual way. Three important things you should keep in mind when using NSCD are: NSCD does not play a direct role in authentication on PAM-enabled systems. PAM authentication occurs completely separate from NSS requests. Therefore, NSCD (in any configuration) will not provide scalability or disconnected-mode authentication features. NSCD uses time-based cache ageing. NSCD only caches information that comes in and out of the NSS function interfaces on the modules themselves. What this means is that NSCD uses a timebased caching algorithm that may require full cache refreshes even when they are not necessary. Consider the following example: suppose that someone decided to use the PADL nss_ldap module against an LDAP server with 10,000 user objects. The first time an application calls getpwent() to enumerate users, all 10,000 user objects are pulled over the network in response to the nss_ldap module's handling of the nss_getpwent() call. NSCD caches this information so that subsequent calls to getpwent() are resolved from cache and the nss_ldap module is never actually called at all. The problem arises as NSCD ages the cache. At a certain time interval (5 minutes) from the when the entries were first cached, all entries are flushed from the cache and the next call to getpwent() generates 10,000 user objects worth of LDAP traffic. NSCD caches failures. NSCD caches failed requests to reduce liability in the situation where continued calls to the NSS functions elicit failures. The reason for caching failures is to make it so that module-specific resources (such as the network) are not constantly used in common failure cases. Consider the following example: The id command calls the NSS interfaces (getpwnam() and others) to display information about a user. Suppose that a hacker decided to try to use the PADL nss_ldap module against an LDAP server with 10,000 user objects. A simple attack that would burden the LDAP server and saturate the network with LDAP traffic would be to call the id command in a shell script loop for a non-existent user. The solution in this case is to turn on negative caching so that until the cache aged, all failed calls (after the first failed call) to the NSS interfaces would be returned as failures without calling the nss_ldap NSS module. The problem with caching failures is that it makes it difficult to quickly resolve legitimate failures. For example, if you attempt to change the ownership of a file to a new employee's user name, you would execute the following command: chown newusername filename but an error is returned because the Administrator has not yet created the new user's account. When the Administrator creates the new user's account, you attempt the chown command again, but it still fails. This time, chown fails because NSCD returns the failure response from its cache. 249

250 Install and Configure NSCD on Red Hat 9 The standard Red Hat 9 distribution includes the NSCD RPM (nscd i386.rpm). This includes a standard configuration file /etc/nscd.conf, which is preconfigured to cache passwd, group, and hosts information. By default, the NSCD daemon (nscd) is not activated in the run-level scripts; neither is it configured for management by the Red Hat chkconfig run-level configuration tool. You must enable nscd for management by using chkconfig and configure nscd to start automatically at system startup. If the nscd daemon is not currently running, you should also start it. To install and configure NSCD on Red Hat 9, follow these steps: 1. Check that the NSCD RPM is installed using the following command: rpm qa grep nscd If it is not installed, install it from the distribution media. 2. Add the nscd daemon to the run-level configuration using the following command: chkconfig --add nscd Note the two hyphens preceding the add option. 3. Enable the nscd daemon in the run-levels 2, 3, 4, and 5 by typing the following command: chkconfig --levels 2345 nscd on 4. Turn the nscd daemon on by typing the following command: service nscd start Install and Configure NSCD on Solaris 9 The NSCD daemon is installed and configured on Solaris 9 by default. You can check that it is activated by entering the following command: ps -fe grep nscd This returns the NSCD daemon process details. If you want to stop the NSCD daemon, do so by entering the following command: /etc/init.d/nscd stop If you want to start the NSCD daemon, enter the following command: /etc/init.d/nscd start Note On Solaris 9, to clear the cache you may find it necessary to stop and start the NSCD daemon after configuring the PADL nss_ldap. Extending the Schema This section shows how you extend the Active Directory schema to store UNIX and Linux attributes. If you only use Active Directory for authentication, then you do not necessarily need to extend the schema; however, this is an unusual configuration and is not covered in this guide. This guide covers the SFU 3.5 Schema. SFU 3.5 is the latest version of SFU, and the SFU 3.5 schema is the currently supported version of the SFU schema. Note The SFU 3.5 schema is identical to the SFU 3.0 schema. Therefore, this guide applies equally to the SFU 3.0 schema as well as to the SFU 3.5 schema. 250

251 SFU 3.5 attributes have LDAP display names that begin with mssfu30. Two methods that you can use to extend the schema are covered in this section: Extend the Active Directory schema using the SFU 3.5 installation. Manually extend the Active Directory schema. Note While the use of both the SFU 3.0 and the SFU 3.5 schemas are covered in this guide, only the installation of SFU 3.5 is covered. This guide can be used if you already have an installed base of SFU 3.0. If you are installing SFU for the first time, then Microsoft recommends that you install the latest version of SFU. For this reason, this guide only covers the installation of SFU 3.5. Before Windows Server 2003, it was necessary to modify the settings on Active Directory to allow updates to the schema. With Windows Server 2003, schema updates are permitted by default, and you do not need to take any action before updating the schema. Extend the Active Directory Schema Using the Services for UNIX Installation During the installation of any version of SFU, you can extend the Active Directory Schema to store UNIX or Linux information. The extended schema is intended for use by Server for NIS. Server for NIS stores Network Information Service (NIS) map data in Active Directory, extending the Active Directory schema to accommodate both standard and nonstandard NIS maps. Standard maps consist of aliases, bootparams, ethers, hosts, group, netgroup, netid, netmasks, networks, passwd, protocols, rpc, services, and shadow files; all other maps are non-standard. The SFU installation includes many components that you may want to use in your organization. Before installing SFU, you should familiarize yourself with the SFU documentation and determine which components, if any, you need to use. Note To learn more about these maps, see the appendix in Microsoft Services for UNIX 3.0: Schema Changes for Server for NIS at E-418A-4B93-97C0-9CF1A9A Note More information on installing SFU can be found at Install SFU (version 3.0 or 3.5) on the domain controller in accordance with the SFU installation documentation. The "Standard Installation" is sufficient. After installing SFU, you should validate that the schema has been updated successfully. You can check that the schema has been successfully extended using the Active Directory Schema MMC Snap-in. For instructions on how to use this snap-in, see the "Viewing the Extended Schema in Active Directory" section later in this chapter. Manually Extending the Active Directory Schema You can manually extend the Active Directory schema using command line tools available as a part of the Windows Server 2003 Resource Kit. To extend the schema, you will need a file containing the schema definition in LDAP Interchange Format (LDIF). This guide covers the schema definition from SFU 3.5. It is possible to extend the 251

252 Active Directory schema using other schema definitions, but this is beyond the scope of this guide. Warning Extending the schema cannot be reversed without restoring Active Directory from a backup. Microsoft recommends that you use a supported schema, such as the SFU 3.5 schema, and that you extend the schema using the SFU installation process. To extend the Active Directory schema manually, follow these steps: 1. Obtain an LDIF file containing the schema that you want to use. In the example in this procedure, this file is called example.ldif. 2. Using a text editor, modify the LDIF file to reference your domain. Specifically, change any domain controller entries to reflect your domain name; for example, dc=example,dc=com. 3. Open a command prompt window. Click Start, click Run, type cmd, and then click OK. 4. From the command prompt, import the schema by typing the command: ldifde I k f example.ldif where example.ldif is the name of your LDIF file. 5. Validate that the schema has been updated successfully. You can check that the schema has been successfully extended using the Active Directory Schema MMC Snap-in. For instructions on how to use this snap-in, see the "Viewing the Extended Schema in Active Directory" section later in this chapter. Viewing the Extended Schema in Active Directory You can view the extended schema using the Active Directory Schema MMC Snap-in. Assuming you have created a shortcut to the Active Directory Schema on your Start menu, you can view the extended schema by following this procedure. To view the Active Directory schema using the Active Directory Schema MMC snap-in, follow these steps: 1. Open the Active Directory Schema snap-in, click Start, click Control Panel, double-click Administrative Tools, and then double-click Active Directory Schema. 2. In the Explorer bar, open Active Directory Schema [win2003ent.example.com] (the name of your computer and domain will be displayed within the square brackets). 252

253 3. Click Attributes. In the right-hand pane, scroll-down until you can see the attributes beginning with mssfu30. You will see a similar display to that shown in Figure 8.2: Figure 8.2 Viewing the Extended Schema using the Active Directory Schema MMC Snap-in The attributes beginning with mssfu30 are created by the installation of SFU 3.0 or SFU 3.5 Configuring DNS Configuring Domain Name System (DNS) is largely covered in Chapter 6, "Developing the Infrastructure for Heterogeneous Security and Directory Solutions." In the context of this chapter where you use Active Directory as an LDAP authentication mechanism and a directory store there are two important DNS configuration issues: Ensure that the UNIX and Linux clients are configured as clients of DNS. Ensure that with multiple Active Directory domain controllers, DNS is configured to supply their IP addresses in a round-robin fashion for simple load-sharing. To configure the UNIX and Linux clients as clients of DNS, use the following procedure. 253

254 To configure UNIX and Linux platforms as clients of the DNS service, follow these steps: 1. Open the file /etc/resolv.conf using a text editor such as vi or emacs. 2. Add or modify the nameserver parameter to the IP address of your DNS server. For example, nameserver Close and save the file /etc/resolv.conf. To configure your DNS servers to supply IP addresses in a round-robin fashion, refer to the "Configuring Windows Server 2003 DNS to Use Round Robin for Load Balancing" section in Chapter 6. Note The pam_ldap module cannot use the DNS SRV resource records to locate the LDAP server, whereas the nss_ldap module can. It is recommended that you configure pam_ldap and nss_ldap DNS lookups as shown in Table 8.3. Table 8.3. Recommended DNS Configuration When Using the PADL LDAP Modules pam_ldap used for authentication nss_ldap used for UNIX/Linux maps DNS Configuration Yes No Configure LDAP server domain names manually. No Yes Do not configure LDAP server domain names, forcing nss_ldap to use SRV records to locate LDAP servers. Yes Yes Configure LDAP server domain names manually. How to configure the PADL modules to use SRV records is covered in the "Configuring the PADL pam_ldap Module" and "Configuring the PADL nss_ldap Module" sections later in this chapter. Security Configuration In this section, you will learn how to secure your systems when using Active Directory as an LDAP service. You should have already implemented the security steps covered in Chapter 6, "Developing the Infrastructure for Heterogeneous Security and Directory Solutions." In addition, you should read and implement the appropriate actions from the Windows Server 2003 Security Guide at You should also have secured the UNIX and Linux platforms according to their specific vendor's security recommendations. Note For more information about securing UNIX and Linux platforms, see the following books: Practical UNIX& Internet Security (Garfinkel and Spafford 1991) Linux System Security (Mann and Mitchell 1999) Real World Linux Security (Toxen 2002) 254

255 For the scenarios covered in this chapter, you must secure access to the Active Directory LDAP service. By default, network access to Active Directory from UNIX and Linux clients takes place by connecting to the ldap TCP/IP port. Note When this guide refers to the LDAP protocol, it is written in uppercase. When this guide refers to the ldap TCP/IP port, the convention is to write it in lowercase. When a client binds to the LDAP service, it sends the user name and password in cleartext over the network. On the majority of networks, sending user names and passwords in cleartext is inherently insecure. It is straightforward for non-authorized persons using a network monitor to capture the cleartext user names and passwords used for binds to Active Directory. Thus, Using LDAP to validate a user s credentials and retrieve personal information has certain intrinsic risks. LDAP requests and responses traverse the network and may be intercepted. Thus, only secure links should be allowed to carry such information. This can be accomplished in any of several ways. It is recommended that LDAP authentication and authorization data be restricted to switchbased networks (network links that utilize IPSec, or other secure tunneling protocols) or networks that are both physically and logically secure from surreptitious monitoring. Further, there are scenarios where a client connects to a server, and the server then requests resources on the client s behalf. The resource request occurs in one of three security contexts: The server, as a trusted entity. Access is based on a trust between the resource holder and the server. The server impersonating the client s identity. The server is given the necessary credentials to authenticate as the client. The server presenting a delegated identity. The server presents a token, control of which demonstrates a trust to authenticate on the client's behalf. This last scenario is the most desirable. LDAP-based authentication does not provide for secure delegation. Therefore, it is recommended that Kerberos be utilized for authentication, as Kerberos supports secure, cross-platform delegation, with fine-grained control and audit. Providing the server with client credentials is not recommended, even if the credentials are transported via a secure tunnel. Propagation of client credentials to allow impersonation exposes the credentials to theft through malicious code running at the server, and it does not limit the scope of where and when the server may impersonate the client. Note Guidance for using SSL/TLS and IPSec are beyond the scope of this guide. 255

256 Building the LDAP Authentication and Authorization Infrastructure Implementing the LDAP authentication and authorization solution requires configuring Active Directory to store UNIX and Linux account information and configuring UNIX and Linux clients to use Active Directory as an additional authentication and authorization method. To implement this solution, you must first store UNIX and Linux users in Active Directory as described in the earlier section "Extending the Schema." You must then configure the pam_ldap module on UNIX and Linux clients so that they use Active Directory for authentication and authorization. The PAM service provides a standard method for configuring authentication systems on UNIX and Linux operating systems. Different PAM modules can be used to provide different methods of authenticating a user and obtaining account information. The pam_ldap module used in this solution allows UNIX and Linux clients to use LDAP servers (such as Active Directory) for authentication and authorization as shown in Figure 8.3, which represents a subset of Figure 8.1. Figure 8.3 pam_ldap module Configuring Active Directory Before proceeding with the configuration of UNIX and Linux clients, you must first prepare Active Directory so that it can be used by the UNIX and Linux clients for authentication and authorization. Security Configuration By default, Active Directory on Windows Server 2003 does not permit anonymous operations on the LDAP directory other than rootdse searches. UNIX and Linux computers must be capable of browsing Active Directory to access UNIX Authentication and Authorization data. This data is required before a user logs in to the system. Therefore, the credentials of a domain user cannot be used to bind to Active Directory for searching. There are two main solutions to this problem: Configure Active Directory to allow anonymous browsing. Create a special Windows user account that is authorized to browse the Active Directory and then configure the UNIX and Linux operating systems to authenticate to Active Directory as this user. 256

257 Configuring these solutions is covered in the next two sections. Configuring Active Directory to Allow Anonymous Browsing of the LDAP Directory With Windows Server 2003 Active Directory, only authenticated users can initiate an LDAP request against Windows Server 2003-based domain controllers. You can override this default behavior by changing the seventh character of the dsheuristics attribute on the DN path: CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,Root domain in forest. The structure of the dsheuristics attribute is shown in Figure 8.4. Figure 8.4 The structure of the dsheuristics attribute The dsheuristics setting applies to all Windows Server 2003 domain controllers in the same forest. The value is realized by domain controllers upon Active Directory replication without restarting Windows. Warning Windows 2000 domain controllers do not support this setting and do not restrict anonymous operations if they are present in a Windows Server 2003-based forest. Valid values for the seventh character of the dsheuristic attribute are 0 and 2. By default, the dsheuristics attribute does not exist, but its internal default is 0. If you set the seventh character to 2, anonymous clients can perform any operation that is permitted by the access control list (ACL). If dsheuristics already contains a value other than 0, then you must treat the seventh character as an eight bit binary word and modify the current value by setting bit 7 to 1. For example, if the current value is 5, then this is in binary. Set the seventh bit to 1 and it becomes , which is 7 in decimal notation. 257

258 To configure Active Directory to allow anonymous browsing of the LDAP directory, follow these steps: 1. Create a MMC Console using the ADSI Edit MMC snap -in. Click Start, click Run, in the Open box, enter mmc, and then click OK. 2. On the File menu, click Add/Remove Snap-in, and then click Add. In the Available Standalone Snap-ins box, click ADSI Edit, click Add, click Close, and then click OK. 3. Now connect to Active Directory Service. Right-click ADSI Edit, and then click Connect to. 4. In the Select a well known Naming Context box, select Configuration, and then click OK. 5. Double-click ADSI Edit, double-click Configuration, open CN=Configuration,DC=example,DC=com, open CN=Services, open CN=Windows NT, right-click CD=Directory Services, and then click Properties. Note You will see your own domain name here instead of the example of DC=example,DC=com. 6. Ensure that Show optional attributes is selected as shown in Figure 8.5. Figure 8.5 Using ADSI Edit to view and edit the dsheuristics attribute 258

259 7. Scroll down the list of Attributes and click dsheuristics. Important If the value shown is not , then you must modify the seventh character by treating it as a binary number and setting the seventh bit to one (1). 8. Click Edit. In the Value box, type , and then click OK. 9. Click Start, click All Programs, click Administrative Tools, and then click Active Directory Users and Computers. 10. In the Active Directory Users and Computers dialog box, click View, and then click Advanced Features. This enables a number of advanced features, including the facility to change access permissions on Active Directory objects. 11. Expand the container for your domain. Click the Users container so that it is selected. Right-click the Users container and click Properties. 12. In the Users Properties dialog box, select the Security tab. 13. Click Add. In the Enter the object names to select (examples): box, type Everyone, and then click OK. 14. In the Permissions for Everyone box, ensure that the Read permission is set to Allow, and then click OK. 15. Click Add. In the Enter the object names to select (examples): box, type Anonymous, and then click OK. 16. In the Permissions for ANONYMOUS LOGON box, ensure that the Read permission is set to Allow, and then click OK. 17. Test that anonymous browsing is now enabled by using the ldp tool. Click Start, click Run. In the Open box, enter ldp, and then click OK. 18. On the Connection menu, click Connect. 19. In the Server: dialog box, enter the name of the domain controller to connect to; for example, win2003ent.example.com, as shown in Figure 8.6. Figure 8.6 Entering the domain controller to connect to in the Server dialog box 20. In the Port: dialog box, enter 389 as the port number, and then click OK. 22. On the Browse menu, click Search. 259

260 23. In the Base Dn: dialog box, enter the LDAP search base: for example, cn=users,dc=example,dc=com, as shown in Figure 8.7. Figure 8.7 Entering the Base Dn parameter 24. In the Filter: dialog box, enter the filter (objectclass=*) and click Run, and then click Close. Using the scroll bar, examine the contents of the right-hand pane. It should show a list of all Active Directory user accounts and their attributes. If it does not, you should check your configuration and try again. Creating a User for Accessing Active Directory from UNIX or Linux To create a user for browsing the Active Directory, you need first to create a standard user using the Active Directory Users and Computers MMC. For the purposes of this guide, an example user name of padl (after the name of the organization that developed the PAM and NSS LDAP modules) will be used. You should set the password to a password that conforms to your password security policy. Because the padl user will be used for all access to Active Directory through the PADL modules, it is important that the password does not need to be changed while the PADL modules are in use. Therefore, you should also set the following options: User cannot change password Password never expires After the user has been created, you need to set the UNIX attributes for the user. Table 8.4 shows the recommended values for each attribute: Table 8.4: Recommended UNIX User Attribute Vales SFU 3.0 dialog box name SFU 3.5 dialog box name Value Not applicable Not applicable padl UID UID 499 (if this UID is not already in use) Primary group name/gid Primary group name/gid Create a separate group named padl with a UID of 499 (if this GID has not been used by any other group) Not applicable Not applicable Special user for browsing Active Directory Home Directory Home Directory /dev/null Login Shell Login Shell /bin/false 260

261 Adding UNIX and Linux Attributes to Active Directory Users In order for Active Directory to be used by UNIX and Linux clients for user authentication and authorization, UNIX and Linux attributes must be configured for each user. You can add these attributes manually or by using a script. The UNIX Attributes tab created by SFU allows you to add UNIX and Linux attributes to existing users. This tab is shown in Figure 8.8. Figure 8.8 The UNIX Attributes tab added to Active Directory Users and Computers MMC by Services for UNIX Adding user attributes can be automated using simple scripts. The scripts can be Windows, UNIX, or Linux-based. Adding UNIX and Linux Users to Active Directory New UNIX and Linux users can be added to Active Directory in the same manner as any other Active Directory user. The Active Directory Users and Computers MMC should be used to add new users. The only difference between standard Active Directory users and those with UNIX attributes is that the details in the SFU UNIX Attributes tab also need to be completed. 261

262 When large numbers of users need to be added to Active Directory, adding the users manually can be onerous. It is possible to add large numbers of users automatically using scripts. There are many options available for adding new users through scripts; for example: Windows script using ldp.exe Windows script using ADSI procedures UNIX or Linux script using the LDAP client tools Perl script using the CPAN LDAP Perl module (Net::LDAP) on any platform Perl script using the CPAN ADSI Perl module for Win32 platforms Migrating UNIX and Linux Users to Active Directory UNIX and Linux account details can be migrated to Active Directory after Active Directory and the UNIX and Linux clients are fully configured. Users can be migrated manually from UNIX and Linux to Active Directory using the Active Directory Users and Computers MMC UNIX Attributes tab created by SFU. However, for large numbers of users, this becomes impractical. Migrating large numbers of UNIX and Linux users to Active Directory is best achieved using scripts. It is possible to write your own scripts using: A Windows script that uses ldp.exe A Windows script that uses ADSI procedures A UNIX or Linux script that uses the LDAP client tools A Perl script that uses the CPAN LDAP Perl module (Net::LDAP) on any platform A Perl script that uses the CPAN ADSI Perl module for Win32 platforms PADL has provided a set of Perl scripts for migrating UNIX and Linux user accounts to an LDAP database. These scripts can be obtained from the PADL website ( The scripts are designed to be used with an LDAP directory containing the RFC 2307 schema. To use these scripts with an Active Directory schema that has been extended using the SFU3.5 schema, you must modify the scripts by changing the RFC 2307 attributes and object classes to the relevant attributes and object classes in SFU3.5. In addition to migrating user account information, the PADL LDAP migration tools can also migrate other UNIX and Linux information, including the information stored in the following configuration files: aliases, hosts, fstab, networks, services, protocols, rpc, and netgroup. These files are a subset of the files supported by the SFU schemas (see the Appendix "The Services for UNIX LDAP Schema"). As with the user account information, the attributes and object classes used by the PADL migration scripts are RFC compliant. If you want to use these scripts, you must modify them to use the attributes and object classes from the SFU 3.5 schema. To use the PADL scripts, you must have Perl installed. You must also have installed and configured the UNIX and Linux LDAP libraries and tools. See the earlier section in this chapter, "Installing and Configuring the UNIX and Linux LDAP Client Libraries and Tools," for information about how to do this. 262

263 Configuring the UNIX and Linux Clients You configure your UNIX and Linux clients to use the Active Directory LDAP service for authentication and authorization when you install pam_ldap and make changes to: The configuration file for pam_ldap The PAM configuration Installing the pam_ldap PAM Module You can use Active Directory for just authentication, or you can use it for authorization and account information as well. When Active Directory is only used for authentication, the UNIX and Linux clients use a successful bind to Active Directory to authenticate a user. To implement this scenario, you must: Install pam_ldap (if it is not already installed) Configure the pam_ldap module The following section shows you how to install and configure pam_ldap from source code or using a binary package. Installing the PADL pam_ldap Module on Red Hat 9 The standard Red Hat 9 installation includes the PADL pam_ldap module. If it is not installed on your system, you should install it using the following procedure: To install the PADL pam_ldap module on Red Hat 9, follow these steps: 1. Place the second of the three Red Hat Linux 9 installation CDs in the CD-ROM drive. 2. Install the pam_ldap RPM by entering the following commands at the shell prompt: mount /mnt/cdrom cd /mnt/cdrom/redhat/rpms rpm -ivh nss_ldap i386.rpm cd / umount /mnt/cdrom Note These commands also install the nss_ldap module. Red Hat releases updates to the RPMs for each version of their operating system on a regular basis. These can be downloaded from the ftp site: ftp.redhat.com. You can either install the updates manually, by using the Red Hat up2date tool, or by using the graphical version of this tool that appears on the desktop as a flashing red exclamation mark when updates are available. You should execute the commands in the following procedures while logged on as the Linux superuser account (root), or an equivalent account. 263

264 To build and install the PADL pam_ldap module from source code on Solaris 9, follow these steps: Before carrying out the following steps, you must configure the Solaris LDAP client libraries as described in the "Installing and configuring the UNIX and Linux LDAP Client Libraries and Tools" section earlier in this chapter. 1. Make a backup copy of the Solaris 9 pam_ldap module by entering the following command at a shell prompt: cp /usr/lib/security/pam_ldap.so.1 /usr/lib/security/pam_ldap.so.1.backup 2. The build of the PADL pam_ldap module requires a set of GNU tools. These should be downloaded from and installed before proceeding. You should download and install the following packages: gcc sol9-intel-local.gz make-3.80-sol9-intel-local.gz autoconf sol9-intel-local.gz automake sol9-intel-local.gz m4-1.4-sol9-intel-local.gz The intel portion of the file name indicates that these files are for the Intel platform; you must download packages suitable for your platform. The local portion of the file name indicates that files from this package will be installed under the directory /usr/local. For each package, follow the steps listed here. These steps use the make-3.80-sol9-intel-local.gz package file as an example; you must change the file names to reflect the file names that you are using: a. Extract the Solaris package file by entering the following command at the shell prompt: gunzip make-3.80-sol9-intel-local.gz b. Install the Solaris make package by entering the following command: pkgadd -d make-3.80-sol9-intel-local c. At the Select package(s) you wish to process (or 'all' to process all packages). (default: all) [?,??,q] prompt, enter y. d. If the Do you want the directory creating /usr/local [?,y,n,q] prompt is shown, enter y. Repeat this procedure for each of the required packages listed previously. 3. These utilities require Perl to be installed under /usr/local/bin. Perl is not installed in this directory on Solaris 9. To enable these utilities to execute, enter the following command: ln -s /usr/bin/perl /usr/local/bin/perl 4. Download the file containing the PADL pam_ldap source code (for example, pam_ldap.tgz) from 264

265 5. Extract the PADL pam_ldap files by entering the following commands: gunzip pam_ldap.tgz tar -xvf pam_ldap.tar This creates a directory named pam_ldap-164, where 164 is the version of the pam_ldap module used in this guide. 6. Compile and install pam_ldap by entering the following commands: cd pam_ldap-164 PATH=/usr/local/bin:$PATH LD_LIBRARY_PATH=/usr/local/lib export LD_LIBRARY_PATH./configure make make install cp pam_ldap.so /usr/lib/security/pam_ldap.so.1 You should now configure pam_ldap as described in the following section. Configuring the PADL pam_ldap Module The pam_ldap module is configured through a text configuration file. The configuration file is used by both pam_ldap and nss_ldap. You should take care when modifying the configuration file so as not to affect the operation of nss_ldap. The file name and its location vary depending on the platform and where the pam_ldap module was obtained. It is crucial that the correct file is modified when configuring pam_ldap because on some platforms the file has the same name (although a different location) as the OpenLDAP configuration file. The configuration file names and their locations for pam_ldap are shown in Table 8.5. Table 8.5: Vendor-specific pam_ldap Configuration File Names Operating System Installation Type pam_ldap configuration file name Red Hat 9 Standard /etc/ldap.conf Solaris 9 Standard N/A Red Hat 9 Source Install /etc/ldap.conf Solaris 9 Source Install /etc/ldap.conf The ldap.conf file consists of three sets of configuration parameters: generic parameters common to pam_ldap and nss_ldap, parameters specific to pam_ldap, and parameters specific to nss_ldap. The parameters specific to pam_ldap have names that begin with a prefix of pam_. Table 8.6 shows the parameters that are common to the configuration of the pam_ldap and nss_ldap modules. These parameters relate to the configuration of the PADL modules as LDAP client applications. Note The parameters in Table 8.6 beginning with tls_ are used for configuring the STARTTLS protocol. STARTTLS allows an LDAP client to connect to the standard ldap port and later issue a STARTTLS command to initiate SSL/TLS authentication and encryption. 265

266 Important The parameters regarding SSL and TLS that appear in Table 8.6 are presented for completeness only. Guidance for using SSL and TLS is beyond the scope of this guide. Table 8.6: ldap.conf Generic Parameters Required for pam_ldap and nss_ldap Parameter Name host base uri Description The DNS host name or IP address of the LDAP server. The host name must be resolvable without using LDAP. Multiple hosts may be specified, each separated by a space. How long the nss_ldap module takes to fall over depends on whether your LDAP client library supports configurable network or connect timeouts (see bind_timelimit). The distinguished name of the search base A uri is another method of referencing the LDAP server. For example: uri ldap:// / uri ldaps:// / uri ldapi://%2fvar%2frun%2fldapi_sock/ Note that %2f encodes the '/' used as directory separator ldap_version The version of the LDAP protocol. The default value is 3. binddn The distinguished name to bind to the server with. The default is to bind anonymously. bindpw The credentials to bind with. The default is no credential. rootbinddn The distinguished name to bind to the server with if the effective user ID is root. The password is stored in /etc/ldap.secret (mode 600) port The LDAP TCP/UDP port. The default is 389. scope The scope to use when searching the LDAP tree. This can be base, sub, or one. timelimit The search time limit in seconds. bind_timelimit The bind time limit in seconds. bind_policy The LDAP reconnect policy. The following two parameters are used: hard (the default) which will retry connecting to the server with exponential back-off when a reconnect is required. soft which will fail. ssl sslpath tls_checkpeer tls_cacertfile This option has two parameters: The on option configures SSL/TLS through the ldaps port (636) The start_tls option configures STARTTLS, which allows connections to the standard ldap port to switch to SSL/TLS operation. Do not use this option with Windows Server 2003 Active Directory. Netscape SDK SSL options. OpenLDAP SSL options. Require and verify server certificate (yes/no). Default is "no." File containing the certificates of Certificate Authorities. This 266

267 Parameter Name tls_cacertdir tls_randfile tls_ciphers tls_cert tls_key Description makes server certificate verification possible. Note that this option or tls_cacertdir is required if the parameter tls_checkpeer is yes. Directory containing the certificates of Certificate Authorities. This makes server certificate verification possible. Note that this option or tls_cacertdir is required if the parameter tls_checkpeer is yes. Seed for the Pseudo-Random Number Generator (PRNG) if the special device /dev/urandom is not available. The SSL cipher suite to be used. See the UNIX or Linux manual page (by using the command man ciphers) for syntax. The file containing the client certificate. You use this parameter and the tls_key parameter if your server requires client authentication. The file containing the client key. You use this parameter and the tls_cert parameter if your server requires client authentication. Table 8.7 contains the ldap.conf configuration file parameters that are used specifically to configure the pam_ldap module. Table 8.7: ldap.conf pam_ldap Parameters Parameter Name Description pam_filter The filter used to find user account objects. This filter is combined with uid=%s in a Boolean logical AND operation (the LDAP & operator). pam_login_attribute The user's login name attribute (defaults to uid) pam_lookup_policy Search the rootdse for the password policy (works with Netscape Directory Server). This parameter has two options: yes and no. pam_check_host_attr Use the LDAP host attribute for access control. Default is no; if set to yes and the user has no value for the host attribute, and pam_ldap is configured for account management (authorization), then the user will not be allowed to log in. pam_groupdn Force the user to be a member of the group specified by the DN assigned to this parameter. pam_member_attribute Specifies the LDAP attributes used to define the group membership of the user. pam_min_uid Specify a minimum UID number allowed. pam_max_uid Specify a maximum UID number allowed. pam_login_attribute Specifies the LDAP attribute that contains the user's user name. pam_password This defines how passwords are processed by the pam_ldap module. The aim of this parameter is to address the problem of 267

268 Parameter Name pam_password_prohibit_message Description password being stored in different attributes in different formats for the user objects used by different schemas. This parameter has the following options. clear Do not hash the password at all; presume the directory server will do it, if necessary. This is the default. crypt Hash password locally; required for University of Michigan LDAP server, and works with Netscape Directory Server if you are using the UNIX-Crypt hash mechanism and not using the NT Synchronization service. nds Remove old password first, then update in cleartext. Necessary for use with Novell Directory Services (NDS) ad Update Active Directory password, by creating Unicode password and updating the unicodepwd attribute. exop Use the OpenLDAP password change extended operation to update the password. Redirect users to a URL or some other mechanism when they want to change their passwords. You must define the LDAP service that the pam_ldap module will connect to. You should set the uri parameter to the name of your Active Directory server, preceded by the protocol ldap://. Note At present, pam_ldap cannot resolve the location of the LDAP service using DNS SRV records of the form _ldap._tcp.example.com. If you have more than one Active Directory domain controller, you can configure round-robin load sharing on your DNS server. For more information, see the "Configuring DNS" section earlier in this chapter. The default TCP and UDP port for connections to LDAP servers is the ldap port (389). This port is adequate for testing purposes. However, when using LDAP servers in a live environment, it is strongly recommended that you use a mechanism to encrypt network traffic. In addition to this, the Windows Server 2003 Active Directory LDAP service will not allow a user to update their password unless they do so over a connection that employs encryption. The default version of the LDAP protocol used by pam_ldap is version 3. You should not change this for connecting to Active Directory. You must configure the search parameters that tell pam_ldap how to find authentication data in the Active Directory tree. First, you need to define the search base, which is equivalent to the name of your domain. In the following example, the name of the domain is dc=example,dc=com. Set the search to a subtree search and also set a reasonable time limit to wait for search results (in this example, 30 seconds). The additional configuration lines are: 268

269 base scope dc=example,dc=com sub timelimit 30 If you have not configured your Active Directory server to accept anonymous binds and searches, then you must configure user details in /etc/ldap.conf for binding to Active Directory. In this example, the user padl is used. You should change the user name and password in your ldap.conf file to match the user details that you are using. binddn cn=padl,cn=users,dc=example,dc=com bindpw Now set the pam_login_attribute to the attribute that contains the user name that will be used during authentication. There are different attributes that store different forms of the user's user name, Microsoft recommends that, to ensure consistency with Active Directory and Services for UNIX, you use the samaccountname attribute. This line should read: pam_login_attribute samaccountname You should also set the pam_filter parameter: pam_filter objectclass=user Now you need to specify how pam_ldap handles passwords. The pam_ldap module includes a parameter that configures the pam_ldap module to operate so that standard Active Directory passwords stored in the attribute unicodepwd can be used. To turn this option on, include the line: pam_password ad The following procedure summarizes the configuration of pam_ldap. To configure PADL pam_ldap on Red Hat 9 and Solaris 9, follow these steps: 1. Open the pam_ldap configuration file with a text editor such as vi or emacs. The location and name of the configuration file for pam_ldap can be set at compile time. Different UNIX and Linux vendors place this file in different locations and call it different names. The file name that you should use is shown in Table 8.5. It is important that this file is not confused with the configuration file for OpenLDAP or other LDAP software. 2. Set the uri parameter to the DNS name of your Windows Server 2003 LDAP server. If the Active Directory server has a DNS name of win2003ent.example.com, the configuration line should read: uri ldap://win2003ent.example.com 3. Configure the pam_ldap LDAP search parameters: base cn=users,dc=example,dc=com scope sub timelimit When connecting to an installation of Active Directory that is not configured for anonymous binds, enter a user name and password for binds to Active Directory: binddn cn=padl,cn=users,dc=example,dc=com bindpw p"dl Configure the attribute to be matched against the logon user name: pam_login_attribute samaccountname 269

270 6. Set the filter to be used to search for users in Active Directory: pam_filter objectclass=user 7. Set the password handling within pam_ldap to interoperate with Active Directory passwords using the correct Active Directory attribute and password encoding format. pam_password ad 8. Save the file and exit your editor. Configuring PAM to Use the PADL pam_ldap Module The PAM service provides a standard method for configuring authentication systems on UNIX and Linux operating systems. Different PAM modules can be used to provide different methods of authenticating a user and obtaining account information. Conventional UNIX and Linux users log on by supplying a unique user name and a password. The user name and password are compared with those stored in the /etc/passwd and /etc/shadow files. PAM allows the user name and password information to be stored in many different places and ways. PAM also allows different methods of authentication that do not use user names and passwords, such as retina scans and smartcards. On systems that use PAM, the login process and all utilities that require user authentication must be compiled to rely on PAM for authentication and authorization. PAM must then be configured to correctly handle the different authentication methods allowed on a particular system. The pam_ldap module allows UNIX and Linux systems to use an LDAP directory for authentication and account information. When pam_ldap is configured, pam_ldap uses the user name and password credentials to attempt to bind to the LDAP server. If the bind succeeds, then the user is authenticated; if it fails, the user is denied access. PAM is configured either through the file /etc/pam.conf or files contained in the directory /etc/pam.d. In the /etc/pam.conf file, the first field contains the name of the service whose authentication is being configured. In the directory /etc/pam.d, each service has its own file with a file name that is identical to the service name, and because the file name identifies the service, the service field in each file is omitted. One important feature of the PAM configuration files is that rules defining behavior can be stacked to combine the features of different PAM modules for a specific task. For example, several password entries can be stacked so that a valid password could be one that is found in /etc/passwd, /etc/shadow, or an LDAP server. Warning It is crucial that care is taken when configuring PAM. A mistake could make it impossible to log on to the system. You should make backup copies of the PAM configuration files before making any changes. You should also keep a session open in another terminal or window to ensure that it is possible to correct any mistakes that you make. There are four independent management groups within PAM. These are: Account This management group provides services for checking the validity of the account; for example, by checking if the password has expired, and by confirming that the user is permitted access to the service. 270

271 Authentication This management group authenticates the user using a chosen authentication mechanism. The mechanism can be a simple challenge-response mechanism such as entering a password, or the mechanism can be based on authentication hardware such as retina scans or smartcard readers. Password This management group provides methods for keeping the authentication mechanism up to date. In the simplest case, this makes it possible for a user to change their password. On UNIX and Linux, changing the password is implemented using the passwd command. Session This management group provides a hook before a service being granted and after it is withdrawn. It can be used for auditing. The pam_ldap module has been written so that it can be used in each of the preceding groups. It contains methods for the account, authentication, password, and session groups. A complete solution would use all of these methods, but it is also possible to only use pam_ldap for specific functionality such as authentication. To use pam_ldap for authentication only, you should configure two lines in the PAM configuration files: an authentication line and a password line. The authentication line configures authentication through LDAP, and the password line allows the user to update the password stored on the LDAP server. Two example lines follow this paragraph. Note that these lines are in the format necessary for configuration files found in /etc/pam.d. To use these lines in /etc/pam.conf, an extra field containing the service name would need to be added to the beginning of each line. auth sufficient /lib/security/$isa/pam_ldap.so use_first_pass password sufficient /lib/security/$isa/pam_ldap.so use_authtok Note These lines were taken from a Red Hat 9 configuration file. The path to the pam_ldap library file pam_ldap.so is specific to Red Hat Linux, and so is different on other platforms. 271

272 The order of lines in PAM configuration files is significant. These two lines must appear along with the other lines in their group (either auth or password), and before the lines containing pam_deny.so. An example Red Hat 9 configuration is: auth required /lib/security/$isa/pam_env.so auth sufficient /lib/security/$isa/pam_unix.so likeauth nullok auth sufficient /lib/security/$isa/pam_ldap.so use_first_pass auth required /lib/security/$isa/pam_deny.so account required /lib/security/$isa/pam_unix.so #account [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore] /lib/security/$isa/pam_ldap.so password required /lib/security/$isa/pam_cracklib.so retry=3 type= password sufficient /lib/security/$isa/pam_unix.so nullok use_authtok md5 shadow password sufficient /lib/security/$isa/pam_ldap.so use_authtok password required /lib/security/$isa/pam_deny.so session required /lib/security/$isa/pam_limits.so session required /lib/security/$isa/pam_unix.so #session optional /lib/security/$isa/pam_ldap.so Note The last field on each line specifies the path name to a shared library object that implements the service functionality. In the example, the path names are relative to /lib/security/$isa/, which is the default directory path. The $ISA token is replaced by an implementation-defined directory name defining a path relative to the calling program's instruction set architecture. Where pam_ldap is only used for authentication, other account details, such as home directory and login shell, need to be stored elsewhere. By default, this information is stored in /etc/passwd, /etc/shadow, and /etc/group. Usually, pam_ldap is configured for authentication and authorization, and account details such as user name are also obtained from the LDAP server. To configure PADL pam_ldap on Red Hat 9 using the Red Hat authconfig tool, follow these steps: 1. From a terminal console or window, enter the following command: authconfig 2. On the User Information Configuration page, use the TAB key to move the cursor until the Next button is highlighted, and then press the ENTER key. 272

273 3. On the Authentication Configuration page, use the TAB key to move the cursor to the Use LDAP Authentication field. See Figure 8.9. Figure 8.9 Red Hat 9 authconfig tool authentication configuration 4. Ensure that the Use LDAP Authentication field is checked (contains an asterix (*)) by using the SPACE bar to toggle it off and on. 5. Press the TAB key to move the cursor to the Server field and enter the name of the Active Directory LDAP server; for example, win2003ent.example.com. 6. Press the TAB key to move the cursor to the Base DN field and enter the base for user objects in Active Directory, for example, cn=users,dc=example,dc=com. 7. Press the TAB key to move the cursor to the OK button and press the ENTER key. The authconfig tool Authentication Configuration page modifies the following files: /etc/ldap.conf Changes the generic configuration for pam_ldap.conf /etc/pam.d/system-auth Adds pam_ldap as a method for the groups account, auth, password, and session 8. Test the pam_ldap configuration by entering the following command at a shell prompt: su - michaelallen where michaelallen is a user account in Active Directory. The user must also be defined in the UNIX or Linux user account database that is either in /etc/passwd, NIS, or LDAP. The command should log you into the system as the user michaelallen. Return to your original shell by entering the command: exit 273

274 To configure PADL pam_ldap on Solaris 9, follow these steps: 1. Make a backup of your /etc/pam.conf file before proceeding by entering the following command at a shell prompt: cp /etc/pam.conf /etc/pam.conf.backup Warning You should ensure that you have another terminal session logged on as root just in case a mistake is made in the configuration of /etc/pam.conf. Mistakes in /etc/pam.conf can make it impossible to log in to your system. 2. To use LDAP for login authentication, you must edit /etc/pam.conf and add the two lines in bold in the following example; the position of the lines in the file is critical: # #ident "@(#)pam.conf /01/23 SMI" # # Copyright Sun Microsystems, Inc. All rights reserved. # Use is subject to license terms. # # PAM configuration # # Unless explicitly defined, all services use the modules # defined in the "other" section. # # Modules are defined with relative pathnames, i.e., they are # relative to /usr/lib/security/$isa. Absolute path names, as # present in this file in previous releases are still acceptable. # # Authentication management # # login service (explicit because of pam_dial_auth) # login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_auth.so.1 login auth required pam_dial_auth.so.1 login auth sufficient pam_ldap.so.1 use_first_pass # # rlogin service (explicit because of pam_rhost_auth) # rlogin auth sufficient pam_rhosts_auth.so.1 rlogin auth requisite pam_authtok_get.so.1 rlogin auth required pam_dhkeys.so.1 rlogin auth required pam_unix_auth.so.1 # # rsh service (explicit because of pam_rhost_auth, # and pam_unix_auth for meaningful pam_setcred) # rsh auth sufficient pam_rhosts_auth.so.1 rsh auth required pam_unix_auth.so.1 # 274

275 (continued) # PPP service (explicit because of pam_dial_auth) # ppp auth requisite pam_authtok_get.so.1 ppp auth required pam_dhkeys.so.1 ppp auth required pam_unix_auth.so.1 ppp auth required pam_dial_auth.so.1 # # Default definitions for Authentication management # Used when service name is not explicitly mentioned for authenctication # other auth requisite pam_authtok_get.so.1 other auth required pam_dhkeys.so.1 other auth required pam_unix_auth.so.1 # # passwd command (explicit because of a different authentication module) # passwd auth required pam_passwd_auth.so.1 # # cron service (explicit because of non-usage of pam_roles.so.1) # cron account required pam_projects.so.1 cron account required pam_unix_account.so.1 # # Default definition for Account management # Used when service name is not explicitly mentioned for account management # other account requisite pam_roles.so.1 other account required pam_projects.so.1 other account required pam_unix_account.so.1 # # Default definition for Session management # Used when service name is not explicitly mentioned for session management # other session required pam_unix_session.so.1 # # Default definition for Password management # Used when service name is not explicitly mentioned for password management # other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password required pam_authtok_store.so.1 other password sufficient pam_ldap.so.1 use_authtok # # Support for Kerberos V5 authentication (uncomment to use Kerberos) # #rlogin auth optional pam_krb5.so.1 try_first_pass #login auth optional pam_krb5.so.1 try_first_pass 275

276 (continued) #other auth optional pam_krb5.so.1 try_first_pass #cron account optional pam_krb5.so.1 #other account optional pam_krb5.so.1 #other session optional pam_krb5.so.1 #other password optional pam_krb5.so.1 try_first_pass Note If for any reason you find pam_ldap.so.1 lines already in this file, you must remove them before proceeding with adding the new lines. 3. Test the pam_ldap configuration by entering the following command: su - michaelallen where michaelallen is a user account in Active Directory. The user must also be defined in the UNIX or Linux user account database that is either in /etc/passwd, NIS, or LDAP. The command should log you in to the system as the user michaelallen. Return to your original shell by entering the command: exit 276

277 Building the Active Directory Identity Store Implementing the Identity Store solution requires configuring Active Directory to store UNIX and Linux account information and configuring UNIX and Linux clients to use Active Directory in addition to their local account database for account information. To implement a solution, you must first store UNIX and Linux users in Active Directory using the process described in the "Extending the Schema" section earlier in this chapter. Then you must configure the nss_ldap module on UNIX and Linux clients so that they use the account information stored in the Active Directory in the same manner in which they use the account information stored in the traditional passwd and shadow files. The NSS provides a flexible means of configuring where the UNIX and Linux operating systems look for specific system information. The /etc/nsswitch.conf configuration file consists of a series of lines that specify the information that UNIX or Linux requires and where it can be found. A brief excerpt from an nsswitch.conf file is shown here: passwd: shadow: files nisplus nis files nisplus nis group: files nisplus nis These three lines define where the UNIX or Linux system will obtain user and account information (passwd and shadow) and group information (group). In each case, this system is configured to look first in the standard local configuration files (files), to then use the most recent incarnation of NIS+ (nisplus), and, finally, to use the older version of NIS (nis). By adding new NSS libraries to the system, new methods of obtaining information can be configured. The nss_ldap NSS module provides a method of obtaining information from a LDAP directory, as shown in Figure 8.10, which represents a subset of Figure 8.1. Figure 8.10 Overview of LDAP directory infrastructure using nss_ldap Installing the PADL nss_ldap NSS Module Active Directory can be used for storing user account information. To implement this scenario, you must: Install the PADL LDAP Name Service Switch (nss_ldap) module (if it is not already installed). Configure the PADL nss_ldap module. 277

278 The following procedures show you how to install and configure nss_ldap from source code or by using a binary package. To install the PADL nss_ldap module on Red Hat 9, follow these steps: The nss_ldap module is installed by default on Red Hat 9. If for any reason it is not installed on your system, then follow these instructions to install it. 1. Place the second of the three Red Hat Linux 9 installation CDs in the CD-ROM drive. 2. Install the RPM by entering the following commands: mount /mnt/cdrom cd /mnt/cdrom/redhat/rpms rpm ivh nss_ldap i386.rpm cd / umount /mnt/cdrom Note These commands also install the pam_ldap module. To install and build the PADL nss_ldap module on Solaris 9, follow these steps: Before carrying out the following steps, you must configure the Solaris LDAP client libraries as described in the "Installing and configuring the UNIX and Linux LDAP Client Libraries and Tools" section earlier in this chapter. 1. Make a backup copy of the Solaris 9 nss_ldap module by entering the following command at a shell prompt: cp /usr/lib/nss_ldap.so.1 /usr/lib/nss_ldap.so.1.backup 2. The build of the PADL nss_ldap module requires a set of GNU tools. These should be downloaded from and installed before proceeding. You should download and install the following packages: gcc sol9-intel-local.gz make-3.80-sol9-intel-local.gz autoconf sol9-intel-local.gz automake sol9-intel-local.gz m4-1.4-sol9-intel-local.gz You should also download the following package from berkeleydb i386-csw.pkg.gz The intel portion of the file name indicates that these files are for the Intel platform. You must download packages suitable for your platform. The local portion of the file name indicates that files from this package will be installed under the directory /usr/local. For each package file, follow the steps listed here. The following steps use the make-3.80-sol9-intel-local.gz package file as an example; you must change the file names to reflect the file names that you are using: a. Extract the Solaris package file by entering the following command at the shell prompt: gunzip make-3.80-sol9-intel-local.gz b. Install the Solaris make package by entering the following command: pkgadd -d make-3.80-sol9-intel-local 278

279 c. At the Select package(s) you wish to process (or 'all' to process all packages). (default: all) [?,??,q] prompt, enter y. d. If the Do you want the directory creating /usr/local [?,y,n,q] prompt is shown, enter y. Repeat this procedure for each of the required packages previously listed. 3. The Berkeley DB package (berkeleydb i386-csw.pkg.gz) places its binaries in /opt/csw/bin, includes in /opt/csw/include, and libraries in /opt/csw/lib. Move these files into the main file system tree by entering the following commands at the command prompt: cd /opt/csw for d in `ls` do cd $d for i in `ls` do cp $i /usr/$d/$i done done 4. These utilities require Perl to be installed under /usr/local/bin. Perl is not installed in this directory on Solaris 9. To enable these utilities to execute, enter the following command: ln -s /usr/bin/perl /usr/local/bin/perl 5. Download the file containing the PADL nss_ldap source code from (for example, nss_ldap.tgz). 6. Extract the PADL pam_ldap files by entering the following commands: gunzip nss_ldap.tgz tar -xvf nss_ldap.tar This creates a directory called nss_ldap-212, where 212 is the version of the nss_ldap module used in this guide. 7. Compile and install nss_ldap by entering the following commands: cd nss_ldap-212 PATH=/usr/local/bin:$PATH./configure --enable-schema-mapping make cp nss_ldap.so /usr/lib /nss_ldap.so.1 You should now configure nss_ldap as described in the following section. Configuring the PADL nss_ldap Module The nss_ldap module from PADL allows NSS to obtain UNIX and Linux system information from an LDAP directory. The configuration file used by nss_ldap is usually the same as is used by pam_ldap. The generic parameters for both pam_ldap and nss_ldap are shown in Table 8.8. These are identical to the generic parameters described in the earlier section on pam_ldap and repeated here for completeness. Table 8.8 shows the parameters that are common to the configuration of the pam_ldap and nss_ldap modules. These parameters relate to the configuration of the PADL modules as LDAP client applications. 279

280 Note The parameters in Table 8.8 beginning with tls_ are used for configuring the STARTTLS protocol. STARTTLS allows an LDAP client to connect to the standard ldap port and later issue a STARTTLS command to initiate SSL/TLS authentication and encryption. Important The parameters regarding SSL and TLS that appear in Table 8.8 are presented for completeness only. Guidance for using SSL and TLS is beyond the scope of this guide. Table 8.8: ldap.conf Generic Parameters Required for pam_ldap and nss_ldap Parameter Name Description host The DNS host name or IP address of the LDAP server. The host name must be resolvable without using LDAP. Multiple hosts may be specified, each separated by a space. How long the nss_ldap module takes to fall over depends on whether your LDAP client library supports configurable network or connect timeouts (see bind_timelimit). base The distinguished name of the search base uri A uri is another method of referencing the LDAP server. For example: uri ldap:// / uri ldaps:// / uri ldapi://%2fvar%2frun%2fldapi_sock/ Note that %2f encodes the '/' used as directory separator ldap_version The version of the LDAP protocol. The default value is 3. binddn The distinguished name to bind to the server with. The default is to bind anonymously. bindpw The credentials to bind with. The default is no credential. rootbinddn The distinguished name to bind to the server with if the effective user ID is root. The password is stored in /etc/ldap.secret (mode 600) port The LDAP TCP/UDP port. The default is 389. scope The scope to use when searching the LDAP tree. This can be base, sub, or one. timelimit The search time limit in seconds. bind_timelimit The bind time limit in seconds. bind_policy The LDAP reconnect policy. The following two parameters are used: hard (the default) which will retry connecting to the server with exponential back-off when a reconnect is required. soft which will fail. ssl This option has two parameters: The on option configures SSL/TLS through the ldaps port (636) The start_tls option configures STARTTLS, which allows connections to the standard ldap port to switch to SSL/TLS operation. Do not use this option with Windows Server

281 Parameter Name sslpath tls_checkpeer tls_cacertfile tls_cacertdir tls_randfile tls_ciphers tls_cert tls_key Description Active Directory. Netscape SDK SSL options. OpenLDAP SSL options. Require and verify server certificate (yes/no). Default is no. File containing the certificates of Certificate Authorities. This makes server certificate verification possible. Note that this option or tls_cacertdir is required if the parameter tls_checkpeer is yes. Directory containing the certificates of Certificate Authorities. This makes server certificate verification possible. Note that this option or tls_cacertdir is required if the parameter tls_checkpeer is yes. Seed for the Pseudo-Random Number Generator (PRNG) if the special device /dev/urandom is not available. The SSL cipher suite to be used. See the UNIX or Linux manual page (by using the command man ciphers) for syntax. The file containing the client certificate. You use this parameter and the tls_key parameter if your server requires client authentication. The file containing the client key. You use this parameter and the tls_cert parameter if your server requires client authentication. As with pam_ldap, the nss_ldap parameters in this file begin with a prefix of nss_. The nss_ldap parameters are shown in Table 8.9. Table 8.9: ldap.conf nss_ldap Parameters Parameter Name Description nss_base_xxx nss_map_attribute nss_map_objectclass RFC2307 naming contexts. Where XXX is the name of one of the following maps: passwd, shadow, group, hosts, services, rpc, ethers, netmasks, aliases, and netgroup. The argument to the parameter is written as the tuple (three argument parameter) base?scope?filter where: - scope is either base, one, or sub. - filter is a filter to be ANDed with the default filter - base is the search base. You can omit the domain suffix (for example, dc=example,dc=com) from the search base to give: nss_base_passwd cn=users and the default base DN will be appended. This may incur a small performance impact. Examples: nss_base_passwd cn=users,dc=example,dc=com?one nss_base_shadow cn=users,dc=example,dc=com?one The RFC2307attribute mapped_attribute The RFC2307objectclass mapped_objectclass 281

282 By default, the nss_ldap module uses the schema defined in RFC 2307 for storing UNIX and Linux information. The schema described in this guide is the Services for UNIX 3.5 schema. While this schema is not RFC 2307-compliant, it does store identical information but uses attributes with different names from RFC The nss_map_attribute and nss_map_objectclass parameters allow you to define which Active Directory attributes and object classes are used to represent the RFC 2703 attributes and object classes required internally by nss_ldap. Choosing how to map attributes and object classes is a crucial part of configuring nss_ldap. The recommended mappings you should use with SFU 3.0 and SFU 3.5 are shown in Table Table 8.10: Recommended Schema Mappings When Using SFU 3.0 or SFU 3.5 RFC2307 (PADL attributes) posixaccount shadowaccount uid uidnumber gidnumber cn uniquemember homedirectory loginshell gecos posixgroup Map to with SFU 3.0 or SFU 3.5 User User samaccountname mssfu30uidnumber mssfu30gidnumber samaccountname member mssfu30homedirectory mssfu30loginshell name Group Notice that not all the mapped attributes are mapped to SFU attributes. In some cases, it is more appropriate to use standard Active Directory attributes. A good example of this is the RFC 2307 uid attribute. The RFC 2307 uid attribute is not the same as the UNIX uid, which is a unique number identifying a user, but instead stores the user's user name. The uid attribute is mapped to the Active Directory user name, which is stored in the attribute samaccountname and is equivalent to the UNIX user name. 282

283 An example map using the SFU 3.5 schema is shown here: nss_map_objectclass posixaccount User nss_map_objectclass shadowaccount User nss_map_attribute uid samaccountname nss_map_attribute uidnumber mssfu30uidnumber nss_map_attribute gidnumber mssfu30gidnumber nss_map_attribute cn samaccountname nss_map_attribute uniquemember member #nss_map_attribute userpassword mssfu30password nss_map_attribute homedirectory mssfu30homedirectory nss_map_attribute loginshell mssfu30loginshell nss_map_attribute gecos name nss_map_objectclass posixgroup Group Note The userpassword line is preceded by a UNIX comment symbol (#). This line is not necessary when pam_password is set to ad. In this case, the pam_ldap module controls the management of password functions using the Active Directory password stored in the unicodepwd attribute. The performance of directory searches can be improved by specifying where to start the search for specific UNIX and Linux information. The nss_base_xxx parameters make this possible. To improve performance when searching for user information, you add the following two lines to the configuration file and modify the domain names to reflect your own: nss_base_passwd cn=users,dc=example,dc=com?sub nss_base_shadow cn=users,dc=example,dc=com?sub Notice that, by default, Active Directory stores user objects in the Users container. As with pam_ldap, you must define the LDAP service that the nss_ldap module will connect to. You can either: Set the uri parameter to the name of your Active Directory server, preceded by the protocol ldap:// Use DNS SRV records to locate the LDAP service by not including a uri or host parameter in the configuration file. You should use Table 8.3 in the earlier section "Configuring DNS" when deciding whether to use DNS SRV records to locate the LDAP service. The default TCP and UDP port for connections to LDAP servers is the ldap port (389). This port is adequate for testing purposes. However, when using LDAP servers in a live environment, it is strongly recommended that you use a mechanism to encrypt network traffic. In addition to this, the Windows Server 2003 Active Directory LDAP service will not allow a user to update their password unless they do so over a connection that employs encryption. The default version of the LDAP protocol used by nss_ldap is version 3. You should not change this for connecting to Active Directory. 283

284 You must configure the search parameters that tell nss_ldap how to find authentication data in the Active Directory tree. First, you need to define the search base, which is equivalent to the name of your domain. In the following example, the name of the domain is dc=example,dc=com. Set the search to a subtree search and also set a reasonable time limit to wait for search results (in this example, 30 seconds). The additional configuration lines are: base scope dc=example,dc=com sub timelimit 30 If you have not configured your Active Directory server to accept anonymous binds and searches, then you must configure user details in /etc/ldap.conf for binding to Active Directory. In this example, the user padl is used. You should change the user name and password in your ldap.conf file to match the user details that you are using. binddn cn=padl,cn=users,dc=example,dc=com bindpw p@dl123. The following procedure summarizes the configuration of nss_ldap. To configure PADL nss_ldap on Red Hat 9 and Solaris 9, follow these steps: 1. Open the nss_ldap configuration file with a text editor such as vi or emacs. The location and name of the configuration file for nss_ldap can be set at compile time. Different UNIX and Linux vendors place this file in different locations and call it different names. The file name that you should use is shown in Table 8.5. It is important that this file is not confused with the configuration file for OpenLDAP or other LDAP software. 2. Determine whether to include the uri parameter using Table 8.3. If the uri parameter is included then set it to the DNS name of your Windows Server 2003 LDAP server. If the Active Directory server has a DNS name of win2003ent.example.com, the configuration line should read: uri ldap://win2003ent.example.com 3. Configure the nss_ldap LDAP search parameters: base cn=users,dc=example,dc=com scope sub timelimit When connecting to an installation of Active Directory that is not configured for anonymous binds, enter a user name and password for binds to Active Directory: binddn cn=padl,cn=users,dc=example,dc=com bindpw p"dl Configure the attribute mappings you will use according to Table Set the base for searches for user information in Active Directory: nss_base_passwd cn=users,dc=example,dc=com?sub nss_base_shadow cn=users,dc=example,dc=com?sub 7. Save the file and exit your editor. 284

285 Configuring NSS to Use the PADL nss_ldap Module To configure NSS to use nss_ldap, you must modify the passwd, shadow, and group lines in /etc/nsswitch.conf. You add ldap to the end of each of the lines. Other NSS methods that are already configured on your system can generally be left unchanged, unless you are replacing them with Active Directory, in which case they can be deleted. The files method should not be removed, as some accounts will always appear in the standard UNIX or Linux account databases. These three lines in the /etc/nsswitch.conf file should now look like this: passwd: shadow: group: files ldap files ldap files ldap Note If you had other NSS modules configured before updating /etc/nsswitch.conf, they would appear between the files and ldap fields. You can test the configuration of nss_ldap using the getent passwd command. This command should return the user entries from the /etc/passwd file followed by any UNIX user accounts stored in Active Directory. 285

286 To configure PADL nss_ldap on Red Hat 9 using the Red Hat authconfig tool, follow these steps: 1. From a terminal console or window, enter the following command: authconfig 2. On the User Information Configuration page, use the TAB key to move the cursor to the Use LDAP field. See Figure Figure 8.11 Red Hat 9 authconfig too l user information configuration 3. Ensure that the Use LDAP field is checked by using the SPACE bar to toggle it off and on. 4. Press the TAB key to move the cursor to the Server field and enter the name of the Active Directory LDAP server; for example, win2003ent.example.com. 5. Press the TAB key to move the cursor to the Base DN field and enter the base for user objects in Active Directory; for example, cn=users,dc=example,dc=com. 6. Press the TAB key to move the cursor to highlight Next button and press the ENTER key. The authconfig tool User Information Configuration page modifies the following files: /etc/ldap.conf Changes the generic configuration for nss_ldap.conf /etc/nsswitch.conf Adds ldap as a method for the following system databases: passwd, shadow, group, protocols, services, netgroup, and automount. While this guide only uses Active Directory to store information from the passwd and shadow system databases, the Services for UNIX 3.5 schema includes attributes that can be used to store the information found in group, protocols, services, netgroup, and automount. 286

287 7. On the Authentication Configuration page, use the TAB key to move the cursor to the OK button and then press the ENTER key. 8. You must now configure nss_ldap to use the correct mappings for the schema on the Active Directory LDAP server and the correct search base. Open the /etc/ldap.conf file with a text editor. 9. Add the appropriate lines for your schema as shown in Table 8.9. The following lines show the configuration file when using SFU 3.5. nss_map_objectclass posixaccount User nss_map_objectclass shadowaccount User nss_map_attribute uid samaccountname nss_map_attribute uidnumber mssfu30uidnumber nss_map_attribute gidnumber mssfu30gidnumber nss_map_attribute cn samaccountname nss_map_attribute uniquemember member #nss_map_attribute userpassword mssfu30password nss_map_attribute homedirectory mssfu30homedirectory nss_map_attribute loginshell mssfu30loginshell nss_map_attribute gecos name nss_map_objectclass posixgroup Group 10. Modify the nss_base parameters to reference the container holding your Active Directory users; for example: nss_base_passwd cn=users,dc=example,dc=com?sub nss_base_shadow cn=users,dc=example,dc=com?sub 11. Test the configuration by entering the following command: getent passwd You should see a list of users from the local /etc/passwd file followed by all the UNIX users stored in Active Directory. To configure PADL nss_ldap on Solaris 9, follow these steps: 1. Using a text editor, edit the NSS configuration file /etc/nsswitch.conf and modify the three following lines to include ldap at the end of each line: passwd: files ldap shadow: group: files ldap files ldap Note If you had other NSS modules configured before updating /etc/nsswitch.conf, they would appear between the files and ldap parameters. 2. Using a text editor, open the PADL nss_ldap configuration file /etc/ldap.conf. Make the following generic changes: a. Set the host name of the Active Directory domain controller in the host parameter. For example, if the domain controller has a DNS name of win2003ent.example.com, then the host line is: host win2003ent.example.com b. Enter the distinguished name (DN) of the search base for user accounts. For example, set the base parameter to: base cn=users,dc=example,dc=com c. Set the search scope to either sub or one depending on if your OU has subcontainers. For example: scope one 287

288 3. You must now configure nss_ldap to use the correct mappings for the schema on the Active Directory LDAP server and the correct search base. Open the /etc/ldap.conf file with a text editor. 4. Add the appropriate lines for your schema as shown in Table 8.9. The following lines show the configuration file when using SFU 3.5. nss_map_objectclass posixaccount User nss_map_objectclass shadowaccount User nss_map_attribute uid samaccountname nss_map_attribute uidnumber mssfu30uidnumber nss_map_attribute gidnumber mssfu30gidnumber nss_map_attribute cn samaccountname nss_map_attribute uniquemember member #nss_map_attribute userpassword mssfu30password nss_map_attribute homedirectory mssfu30homedirectory nss_map_attribute loginshell mssfu30loginshell nss_map_attribute gecos name nss_map_objectclass posixgroup Group 5. Modify the nss_base parameters to reference the container holding your Active Directory users; for example: nss_base_passwd cn=users,dc=example,dc=com?sub nss_base_shadow cn=users,dc=example,dc=com?sub 6. Test the configuration by entering the following command: getent passwd You should see a list of users from the local /etc/passwd file followed by all the UNIX users stored in Active Directory. After the getent passwd test has completed successfully, you have proven that your UNIX and Linux clients are configured to obtain user account information from Active Directory. Summary In this chapter, guidance on developing security and directory solutions using LDAP has been provided. The configuration of Windows Server 2003 Active Directory, UNIX, and Linux clients has been covered in detail. Guidance on the building and installation of the PADL pam_ldap and nss_ldap modules has been provided for UNIX and Linux clients. Details of how to extend the Active Directory schema to support UNIX and Linux attributes has also been covered. Using this chapter, you will be able to develop both security and directory heterogeneous solutions built upon the Windows Server 2003 Active Directory LDAP service. 288

289 9 Testing Windows-based Security and Directory Services Introduction and Goals This chapter presents guidance on how to test your Windows Server 2003-based security and directory services solution. It includes a comprehensive overview of the Windows, UNIX, and Linux tools you use to test security and directory services and guidance on how to use these tools. Following the prescriptive guidance in this chapter will help you to meet the acceptance criteria for release to production. This chapter conducts testing on heterogeneous, Windows-based security and directory services solutions whose features are complete. During this phase, the team transitions the feature-complete build into a state where the quality level defined during the Planning Phase is reached and the solution is ready for full production deployment. Testing during this phase mainly emphasizes usage and operation under realistic environmental conditions. The team focuses on triaging and resolving bugs and preparing the solution for release. The guidance in this chapter covers the testing of the solution infrastructure and the solution itself, as summarized here: The Windows Server 2003 Active Directory infrastructure The Domain Name System (DNS) infrastructure The Time Service infrastructure required by Kerberos based solutions Security solutions based on the Active Directory Kerberos service Security and directory solutions based on the Active Directory LDAP service. Prerequisites Before testing the solution in this chapter, you should: Make the design decisions outlined in Chapter 5, "Planning Heterogeneous Security and Directory Solutions," and produce an implementation plan. Read about and implement the infrastructure required for your specific solution as covered in Chapter 6, "Developing the Infrastructure for Heterogeneous Security and Directory Solutions." 289

290 Review the descriptions in the sections titled "Pluggable Authentication Modules" found in Chapter 2, "Authentication and Authorization in UNIX and Windows Environments," and "Name Service Switch" found in Chapter 3, "Active Directory and LDAP as Identity Stores in UNIX and Windows Environments." Implement a solution from either or both of the following chapters, depending on the migration solution you are implementing: Chapter 7, "Developing Heterogeneous Kerberos Security Solutions," or Chapter 8, "Developing the LDAP Security and Directory Infrastructure." Testing the Solution This section introduces the tools that you can use to test all of the different parts of the solutions presented in this guide and concludes by showing how you can test individual components of the solution. The references and procedures presented here should be used to build and implement your testing plan. You should read the documentation provided with the Windows Server 2003 Resource Kit because it includes a wealth of information on troubleshooting and performance monitoring. Generic Tools and Utilities for Testing Security and Directory Solutions The generic tools and utilities for testing security and directory solutions are those tools that are not specific to the technologies used in the solutions, such as Kerberos and LDAP, but are used generally for testing Windows Server 2003, Linux, and UNIX-based solutions and services. This section looks at Windows Server 2003 monitoring and testing tools and, in particular, the Event Viewer and Network Monitor; it also briefly introduces UNIX and Linux monitoring and testing tools. Many of the monitoring and testing tools introduced here are sophisticated tools that are widely used for testing operating systems and network services. They are extensively documented by Microsoft and other manufacturers. For this reason, this section only introduces some of the tools that you could use, and it refers you to other documentation sources for more detail. Windows Server 2003 Monitoring and Testing Tools Windows Server 2003 includes a range of powerful tools for the monitoring of the operating system and its services, including Active Directory. These tools enable you to find and resolve problems, identity capacity, and performance issues and track potential problems. Covering the detail of each of these tools is beyond the scope of this guide because these tools are complex and require an understanding of performance monitoring and analysis that is not directly relevant to security and directory solutions. Also, these tools are all covered in detail on the Microsoft "Monitoring and Status Tools" website at server2003/proddocs/standard/tools_monitoring_status.asp. Your UNIX, Linux, and Windows system administrators are likely to be familiar with many of these tools. You should ensure that your project team has staff available that can use these tools effectively. 290

291 These tools include: Task Manager overview Network Diagnostics Web page System Information System Properties Services Event Viewer Network Monitor Monitoring performance Shutdown Event Tracker Simple Network Management Protocol (SNMP) Device Manager Windows Management Instrumentation Control Two of these tools Event Viewer and Network Monitor are discussed in detail in the following two sections. These two tools are particularly helpful when testing Kerberos and LDAP solutions. Using Event Viewer to View Kerberos and LDAP Event Messages The Event Viewer is the primary method of managing logged information from applications, services, and the operating system itself on Windows Server Each of the Windows Server 2003 services and applications used in this guide logs debugging information to Event Viewer. For example, account authentication errors can be configured to be logged to Event Viewer. This section explains how to use Event Viewer to access and manage logging information such as Kerberos and Active Directory LDAP messages. Note More information about Event Viewer can be found at wsserver2003/proddocs/entserver/event_overview.asp. To view an event log, follow these steps: 1. Click Start, click Control Panel, click Administrative Tools, and then double-click Event Viewer. 2. In the console tree, click the log you want to view. 3. In the details pane, view the list of individual events. 4. If you want to see more details about a specific event, in the details pane, doubleclick the event. To refresh the event log view, follow this step: To refresh the view, on the Action menu, click Refresh. When you open a log, the Event Viewer displays the current information for the log. While you view the log, the display is not updated unless you refresh the Event Viewer window. If you switch to another log and then return to the first log, the display for the first log is automatically refreshed. When you refresh the view of an event log, only the view is updated; no changes are made to the log. The Refresh command is not available for archived logs because those files can no longer be updated. 291

292 To search for specific events, follow these steps: 1. Click Start, click Control Panel, click Administrative Tools, and then double-click Event Viewer. 2. In the console tree, click the log you want to search. 3. On the View menu, click Find. 4. Under Event types, select the types of events you want to find. 5. In the Event source, Category, Event ID, User, Computer, or Description text entry fields, specify additional information about the event or events you want to find. Notes In the Description text entry field, you can type any text that matches a portion of an event record description. To restore the default search criteria, click Restore Defaults before clicking Find Next. 6. Click Find Next. Windows Server 2003 offers the capability of tracing detailed Kerberos events through the event log mechanism. You can use this information when you troubleshoot Kerberos. The following procedure shows you how to enable Kerberos event logging. To enable Kerberos event logging, follow these steps: Important This procedure contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. More information on backing up the registry is available from the "HOW TO : Back Up, Edit, and Restore the Registry in Windows XP and Windows Server 2003" Knowledge Base article at 1. Start the Registry Editor. Click Start, click Run, enter regedt32.exe, and click OK. 2. Locate the registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Para meters. If the Parameters key does not exist, it should be created. You can do this by right clicking the Kerberos key and selecting New, and then Key, from the menu. 3. If the LogLevel variable does not exist, you will need to create it. You can do this by carrying out the following steps: a. Right click the Parameters key, select New, and then DWORD Value, from the menu. b. Change the name of the variable to LogLevel. 292

293 4. Set the value of the LogLevel variable of type REG_DWORD to 0x1. You can do this by carrying out the following steps: a. Right-click the LogLevel variable and choose Modify from the menu. b. Enter 1 in the Value data box, with the Hexadecimal radio button selected. This is shown in Figure 9.1. Figure 9.1 Registry Editor changing the value of the LogLevel variable. c. Click OK to set the value. Note Remove this registry value when it is no longer needed so that performance is not degraded on the computer. Also, you can remove this registry value to disable Kerberos event logging on a specific computer. 5. Exit the Registry Editor. On the File menu, select Exit. 6. Restart the computer. You can now find any Kerberos-related events in the security log by using the guidance provided in the procedure "To search for specific events." Capturing Network Traces Many of the tests in this chapter can benefit from the use of a network monitor. A network monitor allows you to examine the actual data sent over the network. In the case of many tests, this can lead to greater insight into how well your configuration is working than can be gained from looking at the end results of the network transaction. For example, when using the PADL LDAP nss_ldap module, the UNIX or Linux client is either capable of obtaining user account information from Active Directory or it is not. Either way, by using Network Monitor, you are able to look at each of the stages in the process used by the nss_ldap module to obtain account information. You can see if the authentication data, search criteria, and results returned match those that you would expect from your configuration. The network monitor used in the procedures in this chapter is the Microsoft Windows Server 2003 Network Monitor. While the procedures are specific to this particular network monitor, the tests can be modified to be used with most modern network monitors. Network monitors that you may want to use include open source tools, such as tcpdump and ethereal, and commercial tools, such as Network Associates Sniffer and snoop. 293

294 Network Monitor Overview By using Network Monitor, you can gather information that helps prevent or solve problems with the security and directory services solutions covered in this guide. Network Monitor provides information about the network traffic that flows to and from the network adapter of the computer on which it is installed. By capturing and analyzing that information, you can diagnose and solve many types of network problems and prevent their recurrence. You can configure Network Monitor to provide specific types of information that are most relevant to you. For example, you can set up triggers so that Network Monitor starts or stops capturing information when a circumstance or set of circumstances arises. You can also set up filters to control what types of information Network Monitor captures or displays. To make analyzing the information easier, you can modify how information appears on the screen, and you can save or print the information for review at a later time. The Network Monitor component that ships with the Microsoft Windows Server 2003 family of operating systems can capture frames that are sent to or from the computer on which Network Monitor is installed. If you want to capture frames that are sent to or from a remote computer, you must use the Network Monitor component that ships with Microsoft Systems Management Server, which can capture frames sent to or from any computer on which the Network Monitor driver is installed. The information that Network Monitor provides comes from the network traffic itself, which is divided into frames. These frames contain information such as the address of the computer that sent the frame, the address of the computer to which the frame was sent, and the protocols that exist within the frame. Note To perform this procedure, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform this procedure. Installing and Using Windows Server 2003 Network Monitor To install Network Monitor, follow these steps: 1. Open the Windows Components Wizard. To do so, click Start, click Control Panel, click Add or Remove Programs, and then click Add/Remove Windows Components. 2. In the Windows Components Wizard, click Management and Monitoring Tools, and then click Details. 3. In Subcomponents of Management and Monitoring Tools, select the Network Monitor Tools check box, click OK, and then click Next. 4. If you are prompted for additional files, insert the installation CD for your operating system, or type a path to the location of the files on the network. Note This procedure automatically installs the Network Monitor driver on the computer you are performing the installation on. In the tests where you must capture network frames, you should use the following procedure. 294

295 To capture network frames, follow these steps: 1. Open Network Monitor. To start Network Monitor, click Start, click Control Panel, click Performance and Maintenance, click Administrative Tools, and double-click Network Monitor. 2. If prompted, select the local network from which you want to capture data by default. 3. On the Capture menu, click Buffer Settings, and then set the buffer and frame size as appropriate. 4. On the Capture menu, click Start. 5. To pause, stop, or display the data capture, on the Capture menu, click Pause, Stop, or Display Captured Data. You can also stop and display the capture by clicking Stop and View. Note If you want to capture data from multiple local networks at the same time, install an adapter and start an instance of Network Monitor for each network. In each instance, specify the network from which you want to capture data by clicking the Capture menu, clicking Networks, and selecting a network. When using the Microsoft Network Monitor in this chapter, you should adhere to the following best practices: Run Network Monitor during low-usage times Run Network Monitor at low-usage times or for short periods of time. This decreases the effect that Network Monitor might have on the performance of your computer. Capture minimum amount of network statistics Use capture filters and capture only as many statistics as you need for evaluation. This prevents you from capturing too much information to make a reasonably quick diagnosis of the problem. View Network Monitor captures Use display filters when viewing captured frames to omit extraneous captured frames. Capture frames on token ring networks Token ring adapters reject frames larger than a size specified in their configuration settings. If you capture frames on token ring networks, set your network adapter to accept the largest possible token ring frame size, which is 17 KB. For more information, see the documentation for your network adapter. Displaying Network Frames Using Network Monitor This section covers different methods of displaying network frames using Network Monitor. When using Network Monitor on a network, there can be very large numbers of network frames passing through your server's network interface. You need to capture and filter these frames to focus in on those which are specific to the test you are carrying out. Note More information on displaying network frames using Network Monitor can be found at wsserver2003/proddocs/entserver/sag_netmndisplaydata_node.asp. 295

296 To perform the following procedures using Network Monitor, you must be a member of the Administrators group on the local computer, or you must have been delegated the appropriate authority. If the computer is joined to a domain, members of the Domain Admins group might be able to perform these procedures. First, you need to display the captured data; the following procedure shows you how to do this. To specify the protocol header to display, follow these steps: 1. Open Network Monitor. To start Network Monitor, click Start, click Control Panel, click Performance and Maintenance, click Administrative Tools, and doubleclick Network Monitor. 2. If prompted, select the local network from which you want to capture data by default. 3. Do one of the following: To open a previously captured session, on the File menu, click Open, and then double-click a saved capture file to open it. To capture a new session, on the Capture menu, click Start, and then click Display Captured Data when you are done capturing frames. 4. On the Display menu, click Options. 5. In the Display Options dialog box, click Auto, and then click OK. When examining Kerberos and LDAP network traffic, you will find it useful to assign each protocol a different color scheme. This will enable you to easily differentiate the LDAP and Kerberos frames from all other network traffic. You will also find it useful to assign a color to any other protocol that is relevant to your tests, such as the DNS protocol. The following procedure describes how to do this. To select a protocol color scheme, follow these steps: 1. Open Network Monitor. To start Network Monitor, click Start, click Control Panel, click Performance and Maintenance, click Administrative Tools, and doubleclick Network Monitor. 2. If prompted, select the local network from which you want to capture data by default. 3. Do one of the following: To open a previously captured session, on the File menu, click Open, and then double-click a saved capture file to open it. To capture a new session, on the Capture menu, click Start, and then click Stop and View when you are done capturing frames. 4. On the Display menu, click Colors. 5. In the Protocol Colors dialog box, click the protocol names and the color combination you want, and then click OK. Diagnosis of Network Problems The Tracert diagnostic utility determines the route taken to a destination by sending Internet Control Message Protocol (ICMP) echo packets with varying IP Time-To-Live (TTL) values to the destination. Each router along the path is required to decrement the TTL on a packet by at least 1 before forwarding it, so the TTL is effectively a hop count. When the TTL on a packet reaches 0, the router should send an ICMP Time Exceeded message back to the source computer. 296

297 Tracert determines the route by sending the first echo packet with a TTL of 1, and then incrementing the TTL by 1 on each subsequent transmission until the target responds or the maximum TTL is reached. The route is determined by examining the ICMP Time Exceeded messages sent back by intermediate routers. Note that some routers silently drop packets with expired TTLs and are invisible to Tracert. Tracert prints out an ordered list of the routers in the path that returned the ICMP Time Exceeded message. If the -d switch is used (telling Tracert not to perform a DNS lookup on each IP address), the IP address of the near-side interface of the routers is reported. In the following example, the packet must travel through two routers ( and ) to get to host In this example, the default gateway is and the IP address of the router on the network is at C:\>tracert Tracing route to over a maximum of 30 hops 1 2 ms 3 ms 2 ms ms 83 ms 88 ms ms 79 ms 93 ms Trace complete. The Tracert command can be used to determine where a packet stopped on the network. In the following example, the default gateway has determined that there is not a valid path for the host on There is probably a router configuration problem or the network does not exist (a bad IP address). C:\>tracert Tracing route to over a maximum of 30 hops reports: Destination net unreachable. Trace complete. Tracert is useful for troubleshooting large networks where several paths can be taken to arrive at the same point, or where many intermediate systems (routers or bridges) are involved. There are several command-line switches (shown in Table 9.1) that can be used with Tracert, but they are usually not needed for standard troubleshooting. The syntax is as follows: tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_name Table 9.1: Tracert Switches Switch Description -d Do not resolve addresses to domain names. -h maximum_hops The maximum number of hops to search for the target. -j host_list Specifies loose source route along the host-list. -w timeout Specify the timeout in milliseconds for each reply. target_name Name or IP address of the target host. 297

298 Using Tracert allows you to determine the intermediate hosts on the route between your client and the server. You can identify possible sources of firewall or routing restrictions in place preventing any network connections from forming properly. UNIX and Linux Monitoring and Testing Tools The UNIX and Linux operating systems include tools for the monitoring of the operating system and its services. These tools enable you to find and resolve problems, identity capacity, performance issues, and track potential problems. Covering the detail of each of these tools is beyond the scope of this guide. You should refer to the manufacturer's documentation, the manufacturer's website, and the system manual pages (man pages). The following list summarizes some of the UNIX and Linux tools available to you: Process Monitoring This is typically done using tools such as ps, top, vmstat, pacct and sar. These tools can be used to check the operation of the processes related to Kerberos and LDAP services and the amount of system resources, such as memory and CPU, that they require. Network Diagnostics This is typically done using tools such as, ifconfig, netstat, route, and ping. These tools can be used to confirm that network connectivity is available between the different computers in the solution. System Information This is determined by using tools such as sar, uname, and hostname. These tools provide information about your system that is useful in the planning and configuration of the solutions. Services When operating as daemons, UNIX and Linux services appear as normal processes. Relevant commands include cron, crontab, inet, xinet and init. UNIX and Linux services can be scheduled and controlled using these tools. Automated tasks, such as the running of a script to provide Kerberos database replication to slave servers, can be configured using cron. System Logs The standard method of system logging on UNIX and Linux systems is carried out by syslogd. The configuration of system log files varies from system to system; see the configuration file /etc/syslog.conf for more information. Network Monitor UNIX and Linux systems often include network monitoring tools, such as snoop, tcpdump, and ethereal. These are not covered in this guide because you will typically find it more useful to monitor network traffic on the Windows Server 2003 Active Directory domain controllers. Monitoring performance UNIX and Linux systems provide performance monitoring tools such as sar, iostat, vmstat, and pacct. Because most UNIX and Linux systems in the solutions presented in this guide are either client systems or servers that are being migrated to Windows, it is unlikely that performance monitoring on these systems will be critical. 298

299 The most useful generic UNIX and Linux tools used for testing the solutions presented in this guide are syslogd and ps. The ps command allows you to interrogate the system process table to determine if the correct system processes are running for your solution, and the SysLog service will log events, warnings, and error messages to the standard system log files for later analysis. Kerberos Testing and Optimization Tools This section provides guidance on using the various tools available for testing and optimizing solutions based on the Windows Server 2003 Kerberos service. Many of these tools have been mentioned earlier in the guide during the development of the solution in Chapter 7,"Developing Heterogeneous Kerberos Security Solutions." Table 9.2 summarizes the main tools used for managing the Kerberos security service on Windows Server Table 9.2: Windows Tools for Managing Kerberos Tool/Utility Description Format Kerbtray Displays and manages ticket information for the computer. GUI utility Klist Displays and manages ticket information for the computer. Command line utility The MIT distribution of Kerberos includes tools for managing the Kerberos service. These are summarized in Table 9.3. Table 9.3: MIT Tools for managing Kerberos Tool/Utility Description Format kinit Requests Kerberos tickets. Command line utility klist Displays Kerberos tickets. Command line utility kdestroy Destroys Kerberos tickets. Command line utility telnet Kerberized Telnet program Command line utility Microsoft also provides a cross-platform testing suite for Windows and UNIX or Linux. The tools provided in this suite are summarized in Table 9.4. Table 9.4: GSS Monger Tools for Testing Kerberos Tool/Utility Description Format gssmaster Master controlling utility for Windows command line managing test scenarios. utility gssmaggot Subordinate processes controlled by gssmaster for testing. Windows, UNIX, or Linux command line utility 299

300 All of these tools are examined in detail in the following sections. The Windows Server 2003 Kerbtray Kerberos Utility Kerbtray is a utility which displays the ticket information for a computer running the Microsoft implementation of the Kerberos V5 protocol. It is available as part of the Windows Server 2003 Resource Kit, which is downloadable from the Microsoft website. Kerbtray allows you to view and purge the cache of tickets on your computer. Note A copy of Kerbtray is available for individual download; however,. Microsoft recommends that the Resource Kit version be used instead of the individual version of Kerbtray. You should install the Windows Server 2003 Resource Kit as described in the procedure "To Install the Windows Server 2003 Resource Kit" in Chapter 8, "Developing the LDAP Security and Directory Infrastructure." To start Kerbtray, follow these steps: 1. Click Start, click Run, type cmd, and then click OK. 2. At the command prompt, enter the following command Kerbtray 3. Double-click the Kerbtray icon in the system tray to display the Kerbtray dialog box. Right-clicking the icon shown in Figure 9.2 displays a menu with two options: List Tickets and Purge Tickets. Select List Tickets to display the Kerbtray dialog box. Warning Selecting the Purge Tickets option will destroy all cached tickets. This will prevent you from authenticating to Kerberos resources. To regain tickets if you do select this option, log off, and then log on again. New tickets will be issued. Figure 9.2 Kerbtray icon in the system tray; it is the green shaded rectangle on the left. 300

301 As well as providing access to the Kerbtray dialog box shown in Figure 9.3, the system tray icon allows you to discover the time left on the initial TGT by moving the cursor over the icon. The icon will also change color in the last hour before renewal. Figure 9.3 Kerbtray dialog box The Kerbtray dialog box has four sections: Client Principal This section lists the name of the Kerberos client principal associated with the account. Domain and Tickets This section lists the domains and tickets for services that have been used since logon. Selecting an item from this section displays the properties of the item in the other sections of the dialog box. Service Principal This section lists the service principal for the selected ticket from the Domain and Tickets list. Properties This section details the properties of the ticket selected from the Domain and Tickets list. The Properties section is split into four tabs: Names, Times, Flags and Encryption types. 301