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

Introduction .......................................................................................................................................................... 1 Prerequisites: DNS and Time sync ..................................................................................................................... 2

Configuring the Domain Name System ........................................................................................................... 3 Microsoft: Configuring the Windows Server 2003 Active Directory Domain Controllers ........................... 5 Configuring Time Services .............................................................................................................................. 6 Time Services Scenarios in a Heterogeneous Environment ............................................................................ 6 Microsoft: Configuring Time Services on Windows Servers ......................................................................... 7 Linux: Configuring Time Services on UNIX and Linux Servers ................................................................. 10 Microsoft: Configuring Windows Clients to Synchronize with Time Service ............................................. 11 Linux: Configuring UNIX and Linux Clients to Synchronize with Time Service ....................................... 12

Configuring Active Directory, UNIX, and Linux to Support LDAP Security and Directory Services ............ 12 Microsoft and Linux: Installing Tools and Utilities ..................................................................................... 12 Microsoft: Installing the Active Directory Schema MMC Snap-in .............................................................. 13 Microsoft: Installing the Windows Server 2003 Support Tools ................................................................... 14 Microsoft: Installing the Windows Server 2003 Resource Kit ..................................................................... 14 Linux: Installing and Configuring the UNIX and Linux LDAP Client Libraries and Tools ....................... 15 Linux: Install and Configure the Name Service Cache Daemon .................................................................. 18 Microsoft: Extending the Schema ................................................................................................................ 19 Microsoft: Configuring DNS ........................................................................................................................ 21 Microsoft: Security Configuration ................................................................................................................ 22

Building the LDAP Authentication and Authorization Infrastructure .............................................................. 23 Microsoft: Configuring Active Directory to allow Linux Clients Access .................................................... 23 Microsoft: Adding UNIX and Linux Attributes to Active Directory Users ................................................. 27 Microsoft: Adding UNIX and Linux Users to Active Directory .................................................................. 27 Microsoft: Migrating UNIX and Linux Users to Active Directory .............................................................. 28 Linux: Configuring the UNIX and Linux Clients ......................................................................................... 28 Linux: Installing the pam_ldap PAM Module .............................................................................................. 28 Linux: Configuring the PADL pam_ldap Module ........................................................................................ 29 Linux: Configuring PAM to Use the PADL pam_ldap Module ................................................................... 33

Building the Active Directory Identity Store ..................................................................................................... 36 Linux: Installing the PADL nss_ldap NSS Module ..................................................................................... 36 Linux: Configuring the PADL nss_ldap Module ......................................................................................... 37 Linux: Configuring NSS to Use the PADL nss_ldap Module ...................................................................... 41

Summary ............................................................................................................................................................ 43

IntroductionThis 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 clientsThe 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.

Figure 8.1 Overview of LDAP security and directory solution infrastructure

Prerequisites: DNS and Time syncComplete the Envisioning and Planning phases before implementing LDAP security and directory services using Windows Server 2003. 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."

Top of pageThis section 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)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 SolutionWhen 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.

Top of page

Configuring the Domain Name SystemBefore 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 http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/depkit/7F6DF44C-06C3-4B92-BA32-63D895A7924B.mspx.DNS Scenarios in a Heterogeneous EnvironmentA 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.

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 http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/depkit/7F6DF44C-06C3-4B92-BA32-63D895A7924B.mspxBIND 9 Administrator Reference Manual at http://www.isc.org/products/BIND/DNS and BIND (Albitz and Liu, 2001)DNS on Windows 2000 (Larson and Liu, 2001)

Use only Windows Server 2003 DNS servers

Domain Name System (DNS) Center Knowledge Base Articles at http://www.microsoft.com/windows2000/technologies/communications/dns/dnskbs.aspHOW TO: Migrate an Existing DNS Infrastructure from a BIND-Based Server to a Windows Server 2003-Based DNS at http://support.microsoft.com/default.aspx?scid=kb;en-us;32341 9

DNS Scenario References

Use only BIND DNS servers Using BIND DNS Servers with Windows 2000 at http://research.microsoft.com/programs/up_content/bind.doc

Use a combination of Windows Server 2003 DNS servers and BIND DNS servers

Using BIND DNS Servers with Windows 2000 at http://research.microsoft.com/programs/up_content/bind.doc

DNS Configuration Issues for Windows Server 2003-based Security and Directory SolutionsThis section highlights the specific configuration issues that are important when configuring DNS for the purpose of providing security and directory services using Windows Server 2003. These issues involve:

• The use of SRV resource recordsThe 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 serversYou 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 updatesIf you are using Dynamic DNS updates, you must secure them; otherwise, your security and directory services will be compromised.

• Limiting zone transfers to authorized systemsIf 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 DNSWhen 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.

Microsoft: Configuring the Windows Server 2003 Active Directory Domain ControllersYou 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.Microsoft: Installation and Configuration of Active DirectoryYou 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 http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/directory/activedirectory/default.mspx.

• 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 DirectoryThe 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 http://support.microsoft.com/common/canned.aspx?R=d&H=Windows%20Server%202003%20Networking%20and%20Communications%20How-to%20Articles&LL=kbwinserv2003search&Sz=kbnetwork%20and%20(kbhowtomaster%20or%20kbhowto)&product=winsvr2003.Securing Active DirectoryThe 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 http://www.microsoft.com/technet/security/prodtech/win2003/w2003hg/sgch01.mspx.

Top of page

Configuring Time ServicesKerberos 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 http://www.microsoft.com/windows2000/techinfo/howitworks/security/wintimeserv.asp.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 EnvironmentA 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 timeUNIX, 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.Before you begin to configure your time service, you must consider the following issues:

• The choice of Internet time serverThere 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 http://www.ntp.org/.

• The configuration of firewalls and routersNTP 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 serviceSNTP 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 ServersWarning  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 http://support.microsoft.com/default.aspx?scid=kb;en-us;256986.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.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 Description

/register Register to run as a service and add the default configuration to the registry.

/unregister Unregister as a service and remove all configuration information from the registry.

/monitor [/domain:<domain name>][/computers:<name>,[<name>...]][/threads:<num>]

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.

/ntte Converts a Windows NT system time to a human-readable

Option Description

format.

/ntpte Converts an NTP time to a human-readable format.

/resync [/computer:<name>][/nowait][/rediscover][/soft]

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.

/stripchart /computer:<name>[/period:<refresh>][/dataonly][/samples:<count>]

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.

/config [/computer:<name>][/update][/manualpeerlist::<peers>][/syncfromflags:<source>][/LocalClockDispersion:<seconds>][/reliable:(YES|NO)][/largephaseoffset::<milliseconds>]

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

/tz Displays the current time zone settings.

/dumpreg [/subkey:<key>][/computer:<name>] 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:PeerListWhere 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 /updateThis 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\TimeProviders\NtpClient3. Set the value of the Enabledvariable of type REG_DWORD to 0.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:YESThis 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 w32timeThis 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 192.168.1.1     (ntp.m|0x0|192.168.1.1:123->192.168.1.1:123)    No response has been received from Manual peer 192.168.1.1 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:DOMHIERThis 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:YESThis 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 /updateThis command notifies the time service of the changes to the configuration, causing the changes to take effect.

Linux: Configuring Time Services on UNIX and Linux ServersOn 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 9The 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 ntpdThe 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     3647    1  0  17:46 ?    00:00:00 ntpd

Configure Red Hat Linux 9 to Synchronize to an Internet Time SourceThe 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 fileserver time.nist.govserver time-a.nist.govserver time-b.nist.govdriftfile /etc/ntp.driftNote  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.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

Microsoft: Configuring Windows Clients to Synchronize with Time ServiceWindows 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 /tzThis 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, LondonThe 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 /tzYou 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:    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:ServerNameWhere 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 /querysntpThe 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 /setsntpThis will clear any specified SNTP server names and determine the time source from the domain hierarchy.

Linux: Configuring UNIX and Linux Clients to Synchronize with Time ServiceThe 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.

Top of page

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

Configuring Active Directory, UNIX, and Linux to Support LDAP Security and Directory ServicesThe 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.

Microsoft and Linux: Installing Tools and UtilitiesThis 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 schema. MMC snap-in

Ldifde The preferred tool to deploy Active Directory schema extensions in a production environment.

Command line tool

ADSI Edit MMC Snap-in 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.

MMC snap-in

Ldp A GUI-based LDAP support tool. Allows you to carry out LDAP operations (connect, bind, search, modify, add, delete) against any LDAP-compatible directory.

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.Table 8.2: UNIX and Linux Tools for Managing the LDAP service

Tool/Utility Description Format

LDAP libraries The shared libraries used by applications and modules on UNIX and Linux.

Binary package or source code.Programming interface.

ldapsearch, ldapadd, ldapmodify, ldapdelete

Tools for searching and modifying an LDAP directory. Command line tools

pam_ldap PAM from PADL that provides LDAP authentication and authorization services for UNIX and Linux clients

PAM module

nss_ldap NSS modules from PADL that allow UNIX and Linux NSS module

Tool/Utility Description Format

configuration data to be stored in LDAP directories.

Name Service Cache Daemon Caches NSS configuration data provided through nss_ldap to improve performance on UNIX and Linux clients.

Binary package or source code.UNIX or Linux system service (daemon)

Microsoft: Installing the Active Directory Schema MMC Snap-inThe 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.dllThis 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.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 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ad/ad/active_directory.asp.

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

Microsoft: 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.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.

Microsoft: Installing the Windows Server 2003 Resource KitThe 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

http://www.microsoft.com/downloads/details.aspx?familyid=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en.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 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 click Next.6. In the User Information dialog box, enter your name and organization and 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, 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.

Linux: Installing and Configuring the UNIX and Linux LDAP Client Libraries and ToolsYou 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 http://support.microsoft.com/default.aspx?scid=kb;en-us;315071.Changing these parameters is not covered in this guide.Install and Configure the LDAP Client Libraries and Tools on Red Hat Linux 9The standard installation of Red Hat Linux 9 includes the following LDAP-related Red Hat Package Manager (RPM) packages:

• php-ldap-4.2.2-17

• openldap-2.0.27-8

• nss_ldap-202-5

• openldap-devel-2.0.27-8This list can be verified by typing the following command:rpm –qa | grep ldapThe 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.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/cdromcd /mnt/cdrom/RedHat/RPMSrpm –ivh openldap-clients-2.0.27-8.i386.rpmcd /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 1.4.8.6 2000/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    dc=example, dc=com#URI    ldap://ldap.example.com ldap://ldap-master.example.com:666

#SIZELIMIT    12#TIMELIMIT    15#DEREF        neverHOST win2003ent.example.comBASE cn=Users,dc=example,dc=comNote  These lines can be added automatically using the Red Hat authconfig tool.

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: 20030924161851.0ZsubschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=example,DC=comdsServiceName: CN=NTDS Settings,CN=WIN2003ENT,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=example,DC=comnamingContexts: DC=example,DC=comnamingContexts: CN=Configuration,DC=example,DC=comnamingContexts: CN=Schema,CN=Configuration,DC=example,DC=comnamingContexts: DC=DomainDnsZones,DC=example,DC=comnamingContexts: DC=ForestDnsZones,DC=example,DC=comnamingContexts: DC=TAPI3Directory,DC=example,DC=comdefaultNamingContext: DC=example,DC=comschemaNamingContext: CN=Schema,CN=Configuration,DC=example,DC=comconfigurationNamingContext: CN=Configuration,DC=example,DC=comrootDomainNamingContext: DC=example,DC=comsupportedControl: 1.2.840.113556.1.4.319supportedControl: 1.2.840.113556.1.4.801supportedControl: 1.2.840.113556.1.4.473supportedControl: 1.2.840.113556.1.4.528supportedControl: 1.2.840.113556.1.4.417supportedControl: 1.2.840.113556.1.4.619

supportedControl: 1.2.840.113556.1.4.841supportedControl: 1.2.840.113556.1.4.529supportedControl: 1.2.840.113556.1.4.805supportedControl: 1.2.840.113556.1.4.521supportedControl: 1.2.840.113556.1.4.970supportedControl: 1.2.840.113556.1.4.1338supportedControl: 1.2.840.113556.1.4.474supportedControl: 1.2.840.113556.1.4.1339supportedControl: 1.2.840.113556.1.4.1340supportedControl: 1.2.840.113556.1.4.1413supportedControl: 2.16.840.1.113730.3.4.9supportedControl: 2.16.840.1.113730.3.4.10supportedControl: 1.2.840.113556.1.4.1504supportedControl: 1.2.840.113556.1.4.1852supportedControl: 1.2.840.113556.1.4.802supportedLDAPVersion: 3supportedLDAPVersion: 2supportedLDAPPolicies: MaxPoolThreadssupportedLDAPPolicies: MaxDatagramRecvsupportedLDAPPolicies: MaxReceiveBuffersupportedLDAPPolicies: InitRecvTimeoutsupportedLDAPPolicies: MaxConnectionssupportedLDAPPolicies: MaxConnIdleTimesupportedLDAPPolicies: MaxPageSizesupportedLDAPPolicies: MaxQueryDurationsupportedLDAPPolicies: MaxTempTableSizesupportedLDAPPolicies: MaxResultSetSizesupportedLDAPPolicies: MaxNotificationPerConnsupportedLDAPPolicies: MaxValRangehighestCommittedUSN: 16399supportedSASLMechanisms: GSSAPIsupportedSASLMechanisms: GSS-SPNEGOsupportedSASLMechanisms: EXTERNALsupportedSASLMechanisms: DIGEST-MD5dnsHostName: win2003ent.example.comldapServiceName: example.com:win2003ent$@EXAMPLE.COMserverName: CN=WIN2003ENT,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=example,DC=comsupportedCapabilities: 1.2.840.113556.1.4.800supportedCapabilities: 1.2.840.113556.1.4.1670supportedCapabilities: 1.2.840.113556.1.4.1791isSynchronized: TRUEisGlobalCatalogReady: TRUEdomainFunctionality: 0forestFunctionality: 0domainControllerFunctionality: 2

# search resultsearch: 2result: 0 Success

# numResponses: 2# numEntries: 1The 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.

Linux: Install and Configure the Name Service Cache DaemonThe 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.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 time-based 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 filenamebut 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.

Install and Configure NSCD on Red Hat 9The standard Red Hat 9 distribution includes the NSCD RPM (nscd-2.3.2-11.9.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 nscdIf 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 nscdNote 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

Microsoft: Extending the SchemaThis 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.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 InstallationDuring 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 http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=CCBB506E-418A-4B93-97C0-9CF1A9A11152.Note  More information on installing SFU can be found at http://www.microsoft.com/windows/sfu/.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 SchemaYou 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 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.ldifwhere 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 DirectoryYou 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).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-inSee full-sized image

The attributes beginning with msSFU30 are created by the installation of SFU 3.0 or SFU 3.5

Microsoft: Configuring DNSConfiguring 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.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 192.168.1.493. 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.

Microsoft: 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 http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=8a2643c1-0685-4d89-b655-521ea6c7b4db. 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)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 switch-based 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.

Top of page

Building the LDAP Authentication and Authorization InfrastructureImplementing 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 moduleSee full-sized image

Microsoft: Configuring Active Directory to allow Linux Clients AccessBefore 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 ConfigurationBy 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.

Configuring these solutions is covered in the next two sections.Configuring Active Directory to Allow Anonymous Browsing of the LDAP DirectoryWith 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 attributeThe 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 00000101 in binary. Set the seventh bit to 1 and it becomes 00000111, which is 7 in decimal notation.

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 attributeSee full-sized image

7. Scroll down the list of Attributes and click dSHeuristics.Important  If the value shown is not 0000000, 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 0000002, 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 box20. In the Port: dialog box, enter 389 as the port number, and then click OK.21. On the Browse menu, click Search.22. 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 parameter23. 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 LinuxTo 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 expiresAfter 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

Microsoft: Adding UNIX and Linux Attributes to Active Directory UsersIn 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 UNIXSee full-sized imageAdding user attributes can be automated using simple scripts. The scripts can be Windows, UNIX, or Linux-based.

Microsoft: Adding UNIX and Linux Users to Active DirectoryNew 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.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

Microsoft: Migrating UNIX and Linux Users to Active DirectoryUNIX 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 platformsPADL 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 (www.padl.com). 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 2307-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.

Linux: Configuring the UNIX and Linux ClientsYou 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

Linux: 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 moduleThe 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 9The 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/cdromcd /mnt/cdrom/RedHat/RPMSrpm -ivh nss_ldap-202-5.i386.rpmcd /umount /mnt/cdromNote  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.You should now configure pam_ldap as described in the following section.

Linux: Configuring the PADL pam_ldap ModuleThe 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.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 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://127.0.0.1/uri ldaps://127.0.0.1/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 2003 Active Directory.

sslpath Netscape SDK SSL options.

Tls_checkpeer OpenLDAP SSL options. Require and verify server certificate (yes/no). Default is "no."

Parameter Name Description

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

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

Tls_randfile Seed for the Pseudo-Random Number Generator (PRNG) if the special device /dev/urandom is not available.

Tls_ciphers The SSL cipher suite to be used. See the UNIX or Linux manual page (by using the command man ciphers) for syntax.

Tls_cert The file containing the client certificate. You use this parameter and the tls_key parameter if your server requires client authentication.

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

Parameter Name Description

The aim of this parameter is to address the problem of 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.

Pam_password_prohibit_message 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:base            dc=example,dc=comscope           subtimelimit       30If 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=combindpw            p@dl123.

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    sAMAccountNameYou should also set the pam_filter parameter:pam_filter        objectclass=UserNow 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=comscope           subtimelimit       30

4. 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=combindpw            p"dl123.

5. Configure the attribute to be matched against the logon user name:pam_login_attribute    sAMAccountName

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.

Linux: Configuring PAM to Use the PADL pam_ldap ModuleThe 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:

• AccountThis 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.

• AuthenticationThis 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.

• PasswordThis 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.

• SessionThis 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_passpassword        sufficient    /lib/security/$ISA/pam_ldap.so use_authtokNote  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.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.soauth        sufficient    /lib/security/$ISA/pam_unix.so likeauth nullokauth        sufficient    /lib/security/$ISA/pam_ldap.so use_first_passauth        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 shadowpassword    sufficient    /lib/security/$ISA/pam_ldap.so use_authtokpassword    required      /lib/security/$ISA/pam_deny.so

session     required      /lib/security/$ISA/pam_limits.sosession     required      /lib/security/$ISA/pam_unix.so#session    optional      /lib/security/$ISA/pam_ldap.soNote  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:

Authconfig2. 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.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 configurationSee full-sized image

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 session8. Test the pam_ldap configuration by entering the following command at a shell prompt:

su - michaelallenwhere 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

Top of page

Building the Active Directory Identity StoreImplementing 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:    files nisplus nisshadow:    files nisplus nisgroup:     files nisplus nisThese 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_ldapSee full-sized image

Linux: Installing the PADL nss_ldap NSS ModuleActive 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.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/cdromcd /mnt/cdrom/Redhat/RPMSrpm –ivh nss_ldap-202-5.i386.rpmcd /umount /mnt/cdromNote  These commands also install the pam_ldap module.

You should now configure nss_ldap as described in the following section.

Linux: Configuring the PADL nss_ldap ModuleThe 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.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://127.0.0.1/uri ldaps://127.0.0.1/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.

Parameter Name Description

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

Sslpath Netscape SDK SSL options.

tls_checkpeer OpenLDAP SSL options. Require and verify server certificate (yes/no). Default is no.

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

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

tls_randfile Seed for the Pseudo-Random Number Generator (PRNG) if the special device /dev/urandom is not available.

tls_ciphers The SSL cipher suite to be used. See the UNIX or Linux manual page (by using the command man ciphers) for syntax.

tls_cert The file containing the client certificate. You use this parameter and the tls_key parameter if your server requires client authentication.

tls_key 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 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=Usersand the default base DN will be appended. This may incur a small performance impact.Examples:nss_base_passwd    cn=Users,dc=example,dc=com?onenss_base_shadow    cn=Users,dc=example,dc=com?one

nss_map_attribute The RFC2307attribute mapped_attribute 

nss_map_objectclass The RFC2307objectclass mapped_objectclass 

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 2307.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 8.10.Table 8.10: Recommended Schema Mappings When Using SFU 3.0 or SFU 3.5

RFC2307 (PADL attributes) Map to with SFU 3.0 or SFU 3.5

posixAccount User

shadowAccount User

Uid sAMAccountName

uidNumber msSFU30UidNumber

gidNumber msSFU30GidNumber

Cn sAMAccountName

uniqueMember member

homeDirectory msSFU30HomeDirectory

loginShell msSFU30LoginShell

Gecos name

posixGroup Group

RFC2307 (PADL attributes) Map to with SFU 3.0 or SFU 3.5

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.An example map using the SFU 3.5 schema is shown here:nss_map_objectclass posixAccount Usernss_map_objectclass shadowAccount Usernss_map_attribute uid sAMAccountNamenss_map_attribute uidNumber msSFU30UidNumbernss_map_attribute gidNumber msSFU30GidNumbernss_map_attribute cn sAMAccountNamenss_map_attribute uniqueMember member#nss_map_attribute userPassword msSFU30Passwordnss_map_attribute homeDirectory msSFU30HomeDirectorynss_map_attribute loginShell msSFU30LoginShellnss_map_attribute gecos namenss_map_objectclass posixGroup GroupNote  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?subnss_base_shadow cn=Users,dc=example,dc=com?subNotice 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.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            dc=example,dc=comscope            subtimelimit        30If 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=combindpw            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=comscope           subtimelimit       30

4. 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=comBindpw            p"dl123.

5. Configure the attribute mappings you will use according to Table 8.10.6. Set the base for searches for user information in Active Directory:

nss_base_passwd cn=Users,dc=example,dc=com?subnss_base_shadow cn=Users,dc=example,dc=com?sub

7. Save the file and exit your editor.

Linux: Configuring NSS to Use the PADL nss_ldap ModuleTo 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:     files ldapshadow:     files ldapgroup:      files ldapNote  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.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:

authconfig2. On the User Information Configuration page, use the TAB key to move the cursor to the Use LDAP field. See Figure

8.11.

Figure 8.11 Red Hat 9 authconfig tool — user information configurationSee full-sized image

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.

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 Usernss_map_objectclass shadowAccount Usernss_map_attribute uid sAMAccountNamenss_map_attribute uidNumber msSFU30UidNumbernss_map_attribute gidNumber msSFU30GidNumbernss_map_attribute cn sAMAccountNamenss_map_attribute uniqueMember member#nss_map_attribute userPassword msSFU30Passwordnss_map_attribute homeDirectory msSFU30HomeDirectory

nss_map_attribute loginShell msSFU30LoginShellnss_map_attribute gecos namenss_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?subnss_base_shadow cn=Users,dc=example,dc=com?sub

11. Test the configuration by entering the following command:getent passwdYou 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.

Top of page

SummaryIn 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.Appendix 1Configuration Changes:  In testing 6 key things were done to the system to get things working.  Some of these were documented and some not.  The not pieces were worked out between Microsoft PSS, MCS and Interland:

1. DNS resolution was established between the two systems.  Time was synced manually between the servers.  It is not clear if that is a nice to have or required to get things working.  Additional testing would be required to be sure on this, but given the general need to have time synced between systems and DNS working having this is place seems like a best practice regardless unless there is security barrier issues Interland wants to establish in this area.

2. The Microsoft tool NetMon was used to capture packs going back and forth between the systems.  The LDAP Bind statements were of particular importance as they showed a level of detail on logging that the event logs were not capturing (failed Bind attempts).   I believe the following KB article might have been able to turn of the level of logging required to capture this on the AD server. (This is for W2k, but I believe still is good for W2k3)http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/distrib/dsbi_add_oudd.asp

3. The folder called Users in active directory needs to be referred as a CN not OU in all LDAP statements on the LINUX server. Example  cn=Users,dc=example,dc=com

4. There appeared to be an issue of passwords not being synced for the account Linux uses in AD to authenticate (In the test build case this was for the account DSearch).  It is not clear when the password got out of sync (IE it may have been set properly originally and then during troubleshooting was reset).  

5. The object display name in the Active Directory Users and Computers MMC snap-in is different that the login name (SAMaccount name).  The display name is what LDAP statements needs to reference as the CN of the object.  In the test build the login name was referenced.  Example

In the test environment the object was called Directory Search in AD U&C MMC with a SAMaccount name of DSearch.  Linux was setup to use DSearch which didn’t reference to anything in AD.  To resolve the CN in AD was set to dsearch.  cn=Dsearch,cn=Users,dc=example,dc=com

6. In the ldap.conf file the nss_base parameters to reference the container holding your Active Directory users was instead pointing to the Unixusers group object.  The getend passwd command therefore didn’t show any AD accounts

that were setup as Unix users.  Once this was change the command started to show the unix users in AD and then SSH logins did start working.

Appendix 2Jeff here are some steps for getting a cert installed on the AD box that will be doing the LDAP auth:

1. Login into the server with an administrator account.2. Do a start, run, type in MMC and click on enter.3. Click on the File pull down menu and select Add/Remove Snap-in

4. Click on the Add Button

5. Select the Certificates and click on Add

6. Select Computer accounts on the Certificates Snap-in window and click Next

7. On the select computer screen leave it on local computer and click on finish.8. Click on close and then OK to return to the base MMC window.9. Expand the Certificates (Local Computer) snap and then the personal and Certificates folders..

10. This is the folder where you need to create a certificate or add in the cert you have purchased. 11. In the window above you can see certs that have already been created for testing.12. Right Click on Certificates folder and lick on the all tasks option. Under this you will see create/import options.

13. Click on Next.

14. Click on Domain Controller Authenication and then click on Next.

15. Enter a Friendly name that matches the fully qualified domain name (FQDN) of the Active Directory Server.

16. Click on Next and then Finished. The server Cert now has been created.

17. From there things are a bit trickier. You need to request a cert for the client system. Normally you do this from the client system, but given that the client in not a windows server, the request needs to be made on the server itself and then the cert exported manually from the AD server and imported to the Linux Server. I have created 6 potential Certs that can do this. Which one needed will require testing on the Linux Server.

18. The first way a cert can be created for Linux is to right click on the certificate. 19. click on all tasks20. Click on Request Certificate with the same key. The windows will then follow a similar set of screens as described above for creating a cert. The cert can be the same friendly name as the first cert. 21. Now with the two certificates on the server, the certs can be exported. To do this right click on a cert, select all tasks and select export.

22. Click on Next

23. Click on Next

24. This is the big decision screen. I would recommend exporting both certs created above in each of the three formats. It is not clear to me (Andres) which format the Linux system is going to need to properly access the cert). Once the proper cert and format has been determined then only creating 1 instead of 6 certs (by repeating the export steps of this doc) will be required.

25. Pick a file location to export each cert to.

26. Click on Finish.27. Import the Cert to the Linux System.