Microsoft Solution Guide for Windows Security and Directory Services for UNIX: Developing

Microsoft Solution Guide for Windows Security and Directory Services for UNIX: Developing the LDAP Security and Directory Infrastructure

Table of Contents (links per line)

Microsoft Solution Guide for Windows Security and Directory Services for UNIX: Developing the LDAP Security and Directory Infrastructure

Introduction

Prerequisites: DNS and Time sync

Configuring the Domain Name System

Microsoft: Configuring the WindowsServer2003 ActiveDirectory Domain Controllers

Configuring Time Services

Time Services Scenarios in a Heterogeneous Environment

Microsoft: Configuring Time Services on Windows Servers

Linux: Configuring Time Services on UNIX and Linux Servers

Microsoft: Configuring Windows Clients to Synchronize with Time Service

Linux: Configuring UNIX and Linux Clients to Synchronize with Time Service

Configuring ActiveDirectory, UNIX, and Linux to Support LDAP Security and Directory Services

Microsoft and Linux: Installing Tools and Utilities

Microsoft: Installing the ActiveDirectory Schema MMC Snap-in

Microsoft: Installing the WindowsServer2003 Support Tools

Microsoft: Installing the WindowsServer2003 Resource Kit

Linux: Installing and Configuring the UNIX and Linux LDAP Client Libraries and Tools

Linux: Install and Configure the Name Service Cache Daemon

Microsoft: Extending the Schema

Microsoft: Configuring DNS

Microsoft: Security Configuration

Building the LDAP Authentication and Authorization Infrastructure

Microsoft: Configuring ActiveDirectory to allow Linux Clients Access

Microsoft: Adding UNIX and Linux Attributes to ActiveDirectory Users

Microsoft: Adding UNIX and Linux Users to ActiveDirectory

Microsoft: Migrating UNIX and Linux Users to ActiveDirectory

Linux: Configuring the UNIX and Linux Clients

Linux: Installing the pam_ldap PAM Module

Linux: Configuring the PADL pam_ldap Module

Linux: Configuring PAM to Use the PADL pam_ldap Module

Building the ActiveDirectory Identity Store

Linux: Installing the PADL nss_ldap NSS Module

Linux: Configuring the PADL nss_ldap Module

Linux: Configuring NSS to Use the PADL nss_ldap Module

Summary

Introduction

This chapter provides guidance for implementing a security and directory infrastructure for UNIX and Linux clients using the WindowsServer2003 ActiveDirectory Lightweight Directory Access Protocol (LDAP) service. Guidance is also provided for configuring the WindowsServer2003 domain controller and the UNIX and Linux clients.

Organizations can use this guidance to create a unified security and directory infrastructure based around the WindowsServer2003 platform. This solution improves the administration of users and passwords by centralizing user accounts into one place: ActiveDirectory. 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 ActiveDirectory for UNIX and Linux authentication and authorization
• / Using ActiveDirectory 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 ActiveDirectory, UNIX, and Linux to Support LDAP Security and Directory Services"
• / "Building the LDAP Authentication and Authorization Infrastructure"
• / "Building the ActiveDirectory 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 ActiveDirectory 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.

Figure 8.1 Overview of LDAP security and directory solution infrastructure

Prerequisites: DNS and Time sync

Complete the Envisioning and Planning phases before implementing LDAP security and directory services using WindowsServer2003. 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 WindowsServer2003 ActiveDirectory 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, "ActiveDirectory and LDAP as Identity Stores in UNIX and Windows Environments."

Top of page

This section provides guidance on how to develop the infrastructure that is required to implement heterogeneous security and directory services using Microsoft WindowsServer2003 ActiveDirectory. This guidance covers infrastructure configuration in heterogeneous environments consisting of the WindowsServer2003, UNIX, and Linux platforms.

Specifically, the infrastructure required before implementing heterogeneous security and directory services includes the Domain Name System (DNS), ActiveDirectory, 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)

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.

Top of page

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 WindowsServer2003 ActiveDirectory Domain Controllers"

Kerberos solutions also require you to follow the guidance in the "Configuring Time Services" section in this chapter.

Top of page

Configuring the Domain Name System

Before you can proceed with implementing your security and directory solutions using WindowsServer2003 and ActiveDirectory, you must first have a functional DNS. DNS is required for the following reasons:

• / DNS is a prerequisite for ActiveDirectory.
ActiveDirectory cannot be installed or configured without DNS. Domain names are used to reference the root of each ActiveDirectory 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 WindowsServer2003 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.

NoteBefore designing and implementing your DNS infrastructure, Microsoft recommends that you read the "Deploying DNS" section from the WindowsServer2003 Deployment Kit at

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 WindowsServer2003 DNS servers.
In this scenario, DNS services are provided exclusively by WindowsServer2003 DNS servers. ActiveDirectory, all Windows computers, all UNIX computers, and all Linux computers use the WindowsServer2003 DNS servers for name resolution. Existing DNS servers are migrated to WindowsServer2003 DNS.
• / Use only BIND DNS servers.
In this scenario, DNS services are provided exclusively by UNIX or Linux BIND servers. ActiveDirectory, 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 WindowsServer2003 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 ActiveDirectory domain are entered manually into a static name server.
• / Use a combination of WindowsServer2003 DNS servers and BIND DNS servers.
• / Mixed WindowsServer2003 DNS and BIND DNS serving the same domain.
In this scenario, WindowsServer2003 DNS servers are installed into the same domain as the existing UNIX or Linux BIND DNS servers. ActiveDirectory 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 WindowsServer2003 DNS server acts as a secondary server.
• / WindowsServer2003 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.

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 / References
General background reading / "Deploying DNS" section from the Windows Server 2003 Deployment Kit at
BIND 9 Administrator Reference Manual at
DNS and BIND (Albitz and Liu, 2001)
DNS on Windows 2000 (Larson and Liu, 2001)
Use only WindowsServer2003 DNS servers / Domain Name System (DNS) Center Knowledge Base Articles at
/technologies/communications/dns/dnskbs.asp
HOW TO: Migrate an Existing DNS Infrastructure from a BIND-Based Server to a Windows Server 2003-Based DNS at 9
Use only BIND DNS servers / Using BIND DNS Servers with Windows 2000 at
Use a combination of WindowsServer2003 DNS servers and BIND DNS servers / Using BIND DNS Servers with Windows 2000 at

DNS Configuration Issues for WindowsServer2003-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 WindowsServer2003. 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 ActiveDirectory. 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.
• / 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 WindowsServer2003 implementation of DNS. This is described in depth in the following section.

Microsoft: Configuring the WindowsServer2003 ActiveDirectory Domain Controllers

You must implement ActiveDirectory before implementing a heterogeneous security and directory infrastructure based on WindowsServer2003 ActiveDirectory. The implementation of ActiveDirectory 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.

Microsoft: Installation and Configuration of ActiveDirectory

You need to implement WindowsServer2003 ActiveDirectory. Depending on the size of your organization, the implementation of ActiveDirectory can vary significantly in size. The following guides, documentation, and training will assist you in implementing ActiveDirectory.

• / You can find information about deploying WindowsServer2003 ActiveDirectory at
• / The book, Active Directory, 2nd Edition (Allen and Lowe-Norris, 2003) provides guidance on installing and configuring ActiveDirectory.
• / The Microsoft training course, 2279: Planning, Implementing, and Maintaining a Microsoft WindowsServer2003 ActiveDirectory Infrastructure provides the skills necessary to plan, implement, and troubleshoot the key components of a Microsoft WindowsServer2003 directory service environment.

Network Configuration for ActiveDirectory

The design and implementation of the network infrastructure used by ActiveDirectory is crucial to its operation. It is also essential for security and directory services based on ActiveDirectory. 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 WindowsServer2003 Networking and Communications How-to Articles at
Windows%20Server%202003%20Networking%20and%20Communications%20How-to%20Articles&LL=
kbwinserv2003search&Sz=kbnetwork%20and%20(kbhowtomaster%20or%20kbhowto)&product=winsvr2003.

Securing ActiveDirectory

The security of ActiveDirectory is extremely important when your Windows, UNIX, or Linux infrastructure will use ActiveDirectory for security and directory services. Before proceeding with implementing the solutions covered in this guide, you should implement the guidance contained in the WindowsServer2003 Security Guide at

Top of page

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.

WindowsServer2003 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 ActiveDirectory 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 WindowsServer2003 primary domain controller (PDC) emulator synchronized to an Internet time source
• / A WindowsServer2003 PDC emulator providing the synchronization time
• / A WindowsServer2003 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.

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

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.

Microsoft: Configuring Time Services on Windows Servers

WarningThe 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