Chapter 4: Developing a Custom Solution
On This Page
.gif){kind=icon}
Introduction and Goals
Preparing Your Environment
Developing the Solution Using Native OS Features
Developing the Solution Using Open Source Software
Major Milestone: Scope Complete
Introduction and Goals
In the Developing Phase described in this chapter, you investigate how to develop several alternative solutions that establish interoperability between Microsoft® Windows® and UNIX operating systems at the level of authentication and authorization. Developing your own custom, or “do-it-yourself,” solution can be a less expensive alternative to buying a commercial software product, particularly if you have the requisite in-house expertise. This chapter is the first of a set of chapters (chapters 4–8) in this volume that show you how to develop, stabilize, deploy, operate, and evolve a custom solution.
The eight interoperability solutions that are developed in this chapter are designed to reach one of the following end states:
End State 1 solutions—authentication only. An End State 1 solution uses Windows Active Directory® Kerberos to authenticate UNIX or Linux clients. In an End State 1 solution, UNIX clients continue to use your current UNIX-based authorization method.
End State 2 solutions—authentication and authorization. An End State 2 solution uses Windows Active Directory Kerberos to authenticate UNIX clients and uses Active Directory Lightweight Directory Access Protocol (LDAP) to authorize UNIX or Linux clients.
More than one approach is available to achieve either End State 1 or End State 2:
Native OS scenarios. You can develop a solution that uses only components that are found in the native UNIX or Linux operating system. These solutions are referred to in this guide as "native OS" solutions.
Open source scenarios. You can develop a solution that uses open source components and free software downloads in addition to the components native to the operating system. These solutions are referred to in this guide as "open source" solutions.
Both the native OS and the open source scenarios described for each end state in this chapter include two alternative solutions: one for the Solaris 9 version of UNIX and another for version 9 of the Red Hat distribution of Linux. Solaris 9 and Red Hat 9 were used to develop and test the procedures in this chapter.
For more information about authentication and authorization in Active Directory and UNIX environments and for a description of End States 1 and 2, see Volume 1: Chapter 1, "Overview of Authentication and Authorization Technologies and Solution End States."
Intended Audience
The primary audience for the Developing Phase chapter is the Development team. All team leads should also review this chapter.
In addition, the User Experience, Test, and Release Management teams should read the section "Prepare for Training, Testing, and Deployment" and perform the Developing Phase tasks described in that section for those teams.
Knowledge Prerequisites
Ensure that your team possesses the knowledge requirements stated in “About This Volume” and identified in the “Project Team Skills Template” job aid.
Team leads should be familiar with the following Microsoft methodologies:
Microsoft Solutions Framework (MSF). Available at https://www.microsoft.com/technet/itsolutions/msf/default.mspx, MSF provides the methodology for the Envisioning, Planning, Developing, Stabilizing, and Deploying Phases of the solutions described in this guide.
UNIX Migration Project Guide. Available at https://go.microsoft.com/fwlink/?LinkId=20012, this guide, also known as the UMPG, provides "people and process" guidelines for MSF projects.
For more information about MSF and the UMPG, see "About This Guide.”
Major Tasks and Deliverables
The major Developing Phase tasks include:
Preparing your test environment.
Developing one or more of the solution options described in this chapter—the final development environment serves as an initial proof of concept for the solutions that you develop.
Testing the solution components as you develop them.
Designing tests to be used during the Stabilizing Phase.
Preparing training materials and site preparation and rollout checklists.
This chapter provides the technical information needed to enable you to accomplish these tasks. Refer to the UMPG for guidelines about how to organize team members and work processes used to complete this phase.
Overview of Solutions in This Chapter
This overview provides a "Chapter Map" that shows you how to navigate among the eight possible custom solutions available in this chapter and explains how labels for each procedure indicate whether you need to perform that procedure for a given solution. It also briefly summarizes and contrasts the eight types of custom solutions developed in this chapter.
Chapter Map
As indicated earlier, each end state described in this volume of this guide includes more than one technology solution:
End State 1. Encompasses multiple alternative solutions that use Active Directory Kerberos to provide authentication services for UNIX-based computers.
End State 2. Encompasses multiple alternative solutions that use Active Directory Kerberos and LDAP to provide authentication and authorization services, respectively, for UNIX-based computers.
The eight custom solutions for establishing UNIX-to-Windows interoperability included in this chapter (and described further in chapters 5–8 of this volume) were developed and tested on computers running Solaris 9 and Red Hat 9.
The following table shows each solution path that is developed in this chapter.
Table 4.1. Eight Technology Solutions Developed in This Chapter
Solution Type |
Type of UNIX or Linux |
End State |
Begins in Section Titled |
Ends in Section Titled |
|---|---|---|---|---|
Native OS |
Solaris 9 |
1 |
Use Solaris 9 with Native OS Components for End States 1 and 2 |
Milestone Complete: End State 1 (Solaris 9, Native OS) |
Native OS |
Solaris 9 |
2 |
Use Solaris 9 with Native OS Components for End States 1 and 2 |
Milestone Complete: End State 2 (Solaris 9, Native OS) |
Native OS |
Red Hat 9 |
11 |
Use Red Hat 9 with Native OS Components for End States 1 and 2 |
Milestone Complete: End State 1 (Red Hat 9, Native OS) |
Native OS |
Red Hat 9 |
21 |
Use Red Hat 9 with Native OS Components for End States 1 and 2 |
Milestone Complete: End State 2 (Red Hat 9, Native OS) |
Open source |
Solaris 9 |
1 |
Use Solaris 9 with Open Source Components for End States 1 and 2 |
Milestone Complete: End State 1 (Solaris 9, Open Source) |
Open source |
Solaris 9 |
2 |
Use Solaris 9 with Open Source Components for End States 1 and 2 |
Milestone Complete: End State 2 (Solaris 9, Open Source) |
Open source |
Red Hat 9 |
1 |
Use Red Hat 9 with Open Source Components for End States 1 and 2 |
Milestone Complete: End State 1 (Red Hat 9, Open Source) |
Open source |
Red Hat 9 |
2 |
Use Red Hat 9 with Open Source Components for End States 1 and 2 |
Milestone Complete: End State 2 (Red Hat 9, Open Source) |
1. We do not recommend deploying the native OS Red Hat 9 solution in your production environment for either End State 1 or End State 2 because of the security risks inherent in this solution. For more information, see the discussion in the section "Use Red Hat 9 with Native OS Components for End States 1 and 2" later in this chapter.
Before you begin developing one or more of these solutions in your lab, you must first complete the steps in the section "Preparing Your Environment," which follows this introduction.
For detailed information about features available in End States 1 and 2 native OS or open source solutions included in this guide for environments that run either Solaris or Red Hat, see Appendix J: "Custom Technology Solutions Capabilities Matrix." This matrix lists 46 possible features and indicates which of the custom solutions included in this volume support which features.
Procedure Labels
To ensure that you perform all procedures needed for a specific solution and skip procedures not appropriate for that solution, each procedure in this chapter begins with the following labels:
[Operating System] [Solution Type] [End State]
For example:
A label in the section "Preparing Your Environment" might be:
[Windows] [Native OS and Open Source] [End States 1 and 2]
A label in one of the solution sections might be:
[Solaris 9] [Native OS] [End State 2]
Eight Custom Solutions for Solaris or Red Hat
You can deploy in your development lab one, several, or all of the eight custom solutions presented in this chapter. Which solution or solutions are of interest to you depends on whether your organization wants to deploy:
An End State 1 (authentication only) solution or an End State 2 (authentication and authorization) solution.
A native OS solution or an open source solution.
The specific solution that you choose to develop also depends on whether your organization uses Solaris UNIX or Red Hat Linux.
End State 1 or End State 2
Developers and testers responsible for developing and testing the solutions described in this chapter must have experience with authentication and authorization methods used in UNIX and Windows environments and must be familiar with End State 1 and End State 2 solutions as defined in Volume 1: Chapter 1, "Overview of Authentication and Authorization Technologies and Solution End States."
For many organizations, especially medium-size or large organizations, an End State 2 solution is preferable over an End State 1 solution because an End State 2 solution consolidates account management of both authentication and authorization data into a single data store—Active Directory.
An End State 1 solution might be a good starting point for a later implementation of End State 2. An End State 1 solution is also a good choice for organizations that are unable or prefer not to migrate authorization data to Active Directory but still want to make use of Active Directory for managing authentication data. Typically, authorization data is updated less frequently than authentication data, so an End State 1 solution can be a workable solution, especially for a smaller organization.
An End State 2 solution enables much simpler user management than an End State 1 solution because all user information (except for any user information that you might choose to exclude from migrating to Active Directory) can be managed through Active Directory. An End State 2 solution also potentially allows for retirement of data stores for both authentication and authorization data. Depending on how many data stores you have at the outset and how many of those you can retire by moving the data to Active Directory, you might be able to reduce the number of data stores in your environment substantially.
In some cases, however, it is not feasible to retire a data store. User data that you might not migrate to Active Directory includes, for example, data for users of operating systems or operating system versions that are not compatible with Active Directory, or user data stored in databases for applications that must use their own databases and do not support single sign-on authentication.
Investigating whether you want to develop an End State 2 solution includes understanding how you will migrate authorization data for UNIX users to Active Directory later when you are ready to deploy the solution in your production environment. As part of the decision-making process about whether you will choose to deploy an End State 2 solution, you should answer the following questions:
Will you be migrating user authorization data from multiple authorization stores? For an End State 2 solution, migrating authorization data to Active Directory takes more planning if multiple UNIX-based authorization data stores are currently in use. In many cases where multiple data stores are used, the same user might have different authorization information for accounts in two or more data stores. For example, user1's user identification (UID) in data store A is 10004, but in data store B user1's UID is 13303. In Active Directory, a user account can be associated with only one set of UNIX attributes and thus with only one UID. Typically, the UNIX attributes that need to be stored in Active Directory when you implement an End State 2 solution are the UID, primary group ID (GID), home directory, and shell.
If a user has different UNIX attributes stored in different databases, you will need to rationalize the data before migrating it to Active Directory. Rationalization refers to the process of ensuring that each user account that you plan to migrate to Active Directory has the same UNIX UID and GID on different computers. You must also identify differences in UNIX and Active Directory user and group names and make a decision about whether those names should be the same.
How will you handle migration of user authorization data and computers? For an End State 2 solution, you must plan in advance how you will migrate both users and computers to Active Directory in an environment with one or more existing UNIX-based authorization systems. The migration process can be complex because it must take into account the combination of both users and the computers that they use. For example, depending on the extent that you decide to migrate users and computers to Active Directory, you might encounter the following situation:
User1 needs to access computers A and B, and user2 needs to access computers B and C. If user1 is migrated to Active Directory, the computers that user1 needs to access, A and B, must also be migrated to Active Directory.
However, if user1 (only) is migrated to Active Directory, user2 cannot access computer B (which is now in Active Directory) unless user2 also is migrated to Active Directory.
Further, because user2 needs to have access to computer C, if user2 is migrated to Active Directory, computer C also must be migrated to Active Directory.
Configuration, management, and maintenance are greatly complicated in the presence of multiple authorization systems (as is also the case for multiple authentication systems) such as are presupposed to exist in this example. However, accepting short-term additional complexity for some systems in exchange for greater simplicity and commonality of management on other systems might be a feasible tradeoff.
For some organizations, it can be helpful to maintain existing authentication or authorization systems during the transition to Active Directory. Other organizations might choose to maintain existing systems in part of their network over the long term alongside the new Active Directory–based solution. It is possible to maintain multiple authentication and authorization systems because both pluggable authentication modules (PAM) and Name Service Switch (NSS) can be configured to use multiple sources of authentication or authorization data, respectively. PAM and NSS can be configured to try Active Directory first and then, if no data is retrieved, to try an alternative authentication or authorization data source. For example, you can configure a UNIX client to search LDAP for a user’s UID and, if it is not found, to search in Network Information Service (NIS) or in /etc/passwd.
Note PAM is a service that Solaris and Red Hat clients can use to authenticate against Active Directory when Kerberos is used for authentication in either an End State 1 or End State 2 solution. (Alternatively, PAM also supports UNIX client authentication against Active Directory when LDAP is used for authentication.) NSS is a service that Solaris and Red Hat clients can use to obtain identity and authorization information from a variety of sources, including LDAP.
Native OS or Open Source
Native OS solutions use only components that are distributed as part of the operating system by the operating system vendor. Open source solutions use the native operating system as a foundation but add Kerberos and LDAP components and tools, which are available as open source software and free downloads from third parties. Open source solutions, especially on Red Hat, provide many additional features that the native OS solutions lack but are more complex to develop. Whether you choose a native OS or open source solution depends on your assessment of the advantages and limitations of each.
Open source solutions for End State 1, as described in this chapter, use free software from a third-party vendor but do not require you to build or compile that software. By contrast, open source solutions for End State 2 require that you compile and build software for nss_ldap (which enables Solaris and Red Hat clients to retrieve authorization information from an LDAP directory such as Active Directory) and supporting components. Therefore, you might not need a sophisticated development environment and team to evaluate or deploy an open source End State 1 solution, but for an End State 2 open source solution, your organization must either have in-house administrators with the skills to build and support this technology or must contract with a third party for support.
Some of the factors that differentiate native OS solutions from open source solutions are described in the following table.
Table 4.2. Comparing Native OS Solutions and Open Source Solutions
Solution Type |
Advantages |
Limitations |
|---|---|---|
Native OS solutions |
Use only components included in the operating system. Require only that you download updates or patches from a single source to keep the operating system up-to-date. Supported by operating system vendors (with a support contract). Native OS Solaris (but not native OS Red Hat) solutions, include:
|
For both native OS Red Hat and native OS Solaris solutions, fewer features overall. For the native OS Red Hat solutions, no support for a password change during logon. For the native OS Red Hat solution, fewer security features than native OS Solaris or open source solutions, including:
CAUTION We do not recommend deploying the native OS Red Hat 9 solution in your production environment because of the security risks inherent in this solution. For more information, see "Use Red Hat 9 with Native OS Components for End States 1 and 2" later in this chapter. |
Open source solutions |
Provide more features than native OS solutions for both Solaris and Red Hat:
Red Hat open source solutions include features (also supported by native OS Solaris solutions but not by native OS Red Hat solutions) in addition to those in the preceding list:
|
End State 1 and End State 2 open source solutions require that you install additional software—but operating system vendors do not support solutions that use components not included in their operating systems. End State 2 open source solutions require that you install, compile, and build additional software, which requires the appropriate skills (either in-house or contracted out). End State 2 open source solutions also require that that you draw patches and updates from multiple sources and that you integration test those patches and updates before deployment. |
The Solaris open source End State 2 solution described in this chapter uses open source Kerberos for authentication to Active Directory and open source LDAP to retrieve authorization data from Active Directory. By contrast, a possible alternative solution for Solaris is to deploy a heterogeneous End State 2 solution that combines the use of open source Kerberos authentication to Active Directory with the use of native OS LDAP for Active Directory authorization.
This alternative method uses the following:
Open Source pam_krb5 for authentication
Native OS nss_ldap for authorization
Table 4.3. Can You Combine Open Source Authentication with Native OS Authorization?
Solution Type |
Appropriate or Not Appropriate? |
|---|---|
End State 2 Solaris |
Appropriate in some environments for Solaris because the native OS Solaris authorization feature provides adequate security. The open source authentication portion of the End State 2 solution—like an End State 1 solution—does not require you to build or compile software. Many of the additional features of the open source solution on Solaris relate to the authentication portion of the solution. Therefore, you achieve many of the benefits of an open source solution without incurring the additional administrative overhead of building or compiling additional software. |
End State 2 Red Hat |
Not appropriate for Red Hat because of security deficiencies in the native Red Hat authorization feature. |
Preparing Your Environment
This section describes how to build a lab environment for developing the custom solutions for End States 1 and 2 described in this chapter. This section also summarizes documentation, training, and release management tasks that members of those teams should perform during the Developing Phase.
Some procedures in this section are required only for specific end states. Each procedure is marked to indicate the solution or solutions to which it applies.
This section includes the following topics that describe how to:
Build domain controllers.
Build a certification authority.
Prepare for training, testing, and deployment.
Build Domain Controllers
The Microsoft Windows Server™ 2003 or Windows 2000 Server Active Directory domain controller stores and replicates directory data for the domain and provides authentication and authorization services, acting both as a Kerberos KDC and as an LDAP authorization data store. The instructions for End State 1 differ from those for End State 2 because End State 1 uses only the authentication function of the Active Directory domain controller, whereas End State 2 implements both authentication and authorization functions.
When setting up your development environment, the recommended practice is to install and configure two domain controllers so that you can test UNIX authentication and authorization under failover conditions. Installing both domain controllers at the same time helps avoid replication issues.
This section includes the following topics:
Setting up the first domain controller.
Setting up the second domain controller.
Setting Up the First Domain Controller
The procedures in the following subsections show you how to set up your first test Windows Server 2003 domain controller and how to prepare the domain controller to provide Kerberos authentication and LDAP authorization services for UNIX-based computers.
This section includes the following topics:
Install and configure Active Directory and DNS on the first domain controller.
Raise the forest and domain functional levels.
Extend the schema.
Create test OUs, users, and groups.
Create LDAP proxy user.
Add UNIX attributes to test users and groups.
Create Kerberos service key table.
Synchronize time.
In addition to these tasks, you might also want to enable extended Kerberos logging and extended LDAP logging, as described in Appendix E: "Relevant Windows and UNIX Tools."
Install and Configure Active Directory and DNS on the First Domain Controller
[Windows] [Native OS and Open Source] [End States 1 and 2]
The first step in setting up your development lab is to install a domain controller that is running the Domain Name System (DNS) service and to create a test forest.
For detailed steps showing how to install Active Directory and DNS on a domain controller, see Appendix L: "Installing and Configuring Active Directory and DNS in Your Lab."
IMPORTANT It is possible to install the DNS service on a different server than the domain controller, either Windows or UNIX, or to install DNS on the domain controller later after you first install and configure the domain controller itself. For best results when deploying a solution that enables UNIX clients to authenticate to Active Directory, the recommended practice is to install and configure Active Directory and DNS at the same time, as described in Appendix L. The procedures in this guide were developed and tested in a lab in which DNS is configured on the domain controllers as part of the Active Directory installation process.
Raise the Forest and Domain Functional Levels
[Windows] [Native OS and Open Source] [End States 1 and 2]
If all domain controllers in your development environment run Windows Server 2003, raising the functional level to Windows Server 2003 makes available all domain-wide and forest-wide Active Directory features. Including Windows NT® 4.0 or Windows 2000 domain controllers in an Active Directory forest with domain controllers running Windows Server 2003 limits some Active Directory features.
For tables showing how the available domain features and forest features differ depending on functional level, see "Domain and forest functionality" in Windows Server 2003 Help and Support Center.
To raise the functional level for the forest and domain to Windows Server 2003
Raise domain functional level. Open Active Directory Domains and Trusts in Administrative Tools, and then configure the following:
In the console tree, right-click the domain name example.com under Active Directory Domains and Trusts, and then click Raise Domain Functional Level.
In Raise Domain Functional Level, for Select an available domain functional level, select Windows Server 2003.
Click Raise, and then click OK. Click OK again when you see the message indicating that the functional level was raised successfully.
Raise forest functional level. In Active Directory Domains and Trusts, configure the following:
In the console tree, right-click Active Directory Domains and Trusts, and then click Raise Forest Functional Level.
In Raise Forest Functional Level, for Select an available forest functional level, select Windows Server 2003.
Click Raise, and then click OK. Click OK again when you see the message indicating that the functional level was raised successfully.
Navigation Note If you plan to deploy only End State 1, skip to the subsection "Create Test OUs, Users, and Groups" later in this section.
Extend the Schema
[Windows] [Native OS and Open Source] [End State 2]
Note This chapter assumes that you use Microsoft Windows Services for UNIX (which is not compliant with RFC 2307) to extend the Active Directory schema to include UNIX attributes that are used for authorization in the custom End State 2 solutions. Windows Server 2003 Release 2 (R2) includes support for RFC 2307 by default and thus supports LDAP attributes used to store UNIX or Linux user and group account information. However, the solutions developed in this chapter are not designed for and were not tested with Windows Server 2003 R2.
When a user attempts to log on to a UNIX-based computer, the operating system must retrieve both authentication data and authorization data for the user. The authorization data defines the environment in which the user will operate and the tools and files to which the user will have access. The authorization data needed for UNIX logon includes these UNIX attributes for the user:
UID. The user ID or unique ID number associated with the user. This number is assigned to files or directories to which the user has specific permissions (as opposed to permissions assigned through membership in a group). This is similar to the access control mechanisms used in Active Directory and controlled with the user's logon name.
Primary GID. The ID number of the primary group associated with a user. Like Active Directory, UNIX separates group membership into a primary group and multiple secondary groups for a user. A user must be associated with a primary group. The addition of secondary groups is optional. Group IDs are assigned to files and directories to provide access control for groups of users.
Home Directory. The full path and directory name of the user's home directory.
Shell. The program environment in which the user will operate upon initial logon. Examples of this include csh (C Shell), sh (Bourne Shell), and bash (Bourne Again Shell). Some operating systems do not support all shells.
In addition to these required attributes, historical UNIX data stores (such as the local /etc/passwd and /etc/group files or a NIS or LDAP database) allowed for optional attributes including GECOS (General Electric Comprehensive Operating System). The GECOS attribute can be used to hold any data. Traditionally, it holds the user's full name and may contain other data, such as the user's phone number. The GECOS attribute had more uses historically than it does today, but some UNIX applications might expect this field to be populated.
Although, in many cases, Active Directory stores data for a user that includes information that is similar to the UNIX attributes just described, the fields in which or methods by which Active Directory data is stored are not compatible with a UNIX environment. It is therefore necessary to add attributes to Active Directory to accommodate UNIX logons. Installing Windows Services for UNIX extends the Active Directory schema so that it can store UNIX attributes for users and groups for solutions designed to reach End State 2. The Active Directory schema defines each object, and the attributes of each object, that can be stored in Active Directory. The schema is a description of the object classes (the various types of objects) and the attributes for those object classes. For each class of object, the schema defines the attributes that object class must have, the additional attributes it may have, and the object class that can be its parent. Schema definitions are themselves also stored as objects—Class Schema objects and Attribute Schema objects—in Active Directory.
Multiple extensions to the Active Directory schema are available for storing the UNIX attributes. The instructions in this chapter use the Windows Services for UNIX schema extensions. Alternatively, you can use the RFC 2307 schema. If you use an alternative schema extension, you might need to modify the mappings done by the LDAP clients to match the alternative schema.
CAUTION Extending the Active Directory schema requires care. To reduce the chance that problems might arise during the schema extension process, which cannot be reversed, the recommended practice is to select extension mechanisms that Microsoft supports, such as Windows Services for UNIX. Before you extend the schema, see "Extending the schema" in the Windows Server 2003 Help and Support Center.
To extend the schema by installing Windows Services for UNIX
Download Windows Services for UNIX:
Download Windows Services for UNIX at https://www.microsoft.com/windowsserversystem/sfu/downloads/default.mspx.
Double-click SFU35SEL_EN.exe to unzip the Windows Services for UNIX files.
Run the Windows Services for UNIX Setup Wizard:
Double-click Setup.exe to start the Welcome to Microsoft Windows Services for UNIX Setup Wizard.
For your development test lab setup, you can click Next to accept defaults throughout the entire wizard.
CAUTION When you deploy an End State 2 solution in your production environment, you might need to configure specific options in the Windows Services for UNIX Setup Wizard that are appropriate for your production environment. If the Windows Services for UNIX installation fails, you cannot successfully deploy End State 2. Problems that can cause the installation to fail include DNS name resolution failure or failure of Active Directory servers to properly replicate.
For steps showing how to use Active Directory Users and Computers (which, after you install Windows Services for UNIX, now has a new UNIX Attributes tab) to add UNIX attributes to the test groups and users used in this chapter, see "Add UNIX Attributes to Test Groups and Users" later in this section.
Create Test OUs, Users, and Groups
[Windows] [Native OS and Open Source] [End States 1 and 2]
Create a separate organizational unit (OU) in Active Directory to contain all UNIX users, computers, and groups. Using a separate OU lets you apply unique Group Policy settings to the Active Directory objects used by UNIX principals.
To create OUs , test users , and test groups for UNIX objects
Create OU for UNIX objects. Open Active Directory Users and Computers in Administrative Tools, and then configure the following:
In the console tree, right-click the domain name example.com, point to New, and then click Organizational Unit.
In New Object – Organizational Unit, type UNIX-OU for Name, and then click OK.
Create OUs for UNIX principals. Create OUs for testing UNIX users, groups, and computers:
Right-click UNIX-OU, point to New, and then click Organizational Unit.
In New Object – Organizational Unit, type UNIX-Users for Name, and then click OK.
Repeat steps a and b to create OUs for UNIX-Groups and UNIX-Computers.
Note The OU for groups is needed only for the End State 2 solutions.
Create UNIX test user and group accounts. Create Active Directory test user and group accounts for UNIX users and groups, as shown in the following table.
Table 4.4. Creating UNIX Test User and Group Accounts
End State
Tasks
For both End State 1 and End State 2
Note The user test01 is used only to test authentication. Authorization data for test01 is stored in /etc/passwd (not in Active Directory).
Create a user called test01:
Right-click UNIX-Users, point to New, and then click User.
In New Object – User, in Full Name type test01, in User logon name type test01, and then click Next.
In New Object – User, type and confirm a password, clear User must change password at next logon, and then click Next.
CAUTION Selecting an option, such as Change Password on next logon or Password never expires, might cause later tests to fail.
Click Finish.
For End State 2 only
Note These users and groups are used to test authorization—their authorization data is stored in Active Directory.
Create three users called test02 , test03 , and test04:
Repeat the steps that you just used to create test01 to create other users called test02, test03, and test04.
Create two groups , called tstgrp01 and tstgrp02:
Right-click UNIX-Groups, point to New, and then click Group.
In New Object – Group, in Group Name, type tstgrp01, and then click OK.
Repeat steps a and b that you just used to create tstgrp01 to create another group called tstgrp02.
Navigation Note If you plan to use native OS features and want to deploy only End State 1, skip to the subsection "Create Kerberos Service Key Table" later in this section. If you plan to use open source components and plan to deploy only End State 1, skip to the subsection "Synchronize Time."
Create LDAP Proxy User
[Windows] [Native OS and Open Source] [End State 2]
For End State 2 solutions, create an LDAP proxy user called proxyuser in the standard Active Directory Users container. For information about how the proxy user (which performs operations on behalf of the end user) is used in the solutions described in this chapter, see the following procedures later in this chapter:
Configure the LDAP Client ([Native OS] [Solaris 9] [End State 2])
Configure the /etc/ldap.conf File ([Native OS] [Red Hat 9] [End State 2])
Configure the /etc/ldap.conf File ([Open Source] [Solaris 9] [End State 2])
Configure the /etc/ldap.conf File ([Open Source] [Red Hat 9] [End State 2])
To create an LDAP proxy user
Open Active Directory Users and Computers. Open Active Directory Users and Computers in Administrative Tools.
Create proxyuser. Perform the following steps to create proxyuser:
In the console tree under example.com, right-click Users, point to New, and then click User.
In New Object – User, type proxyuser for Full name, type proxyuser for User logon name, and then click Next.
Type and confirm Password1 for the password, select Password never expires, and then click Next.
Note You can use any password for the LDAP proxy user. Password1 is used in the example procedures in this chapter.
Click Finish.
Add UNIX Attributes to Test Groups and Users
[Windows] [Native OS and Open Source] [End State 2]
For End State 2 solutions, you can add UNIX attributes to UNIX test user and group accounts in Active Directory because you extended the Active Directory schema when you installed Windows Services for UNIX.
To add UNIX attributes to your test groups and users
Add UNIX attributes to tstgrp01. Open Active Directory Users and Computers in Administrative Tools, and then add UNIX attributes to tstgrp01 as follows:
In the console tree under example.com, expand UNIX-OU, and then click UNIX-Groups.
In the details pane, right-click tstgrp01, and then click Properties.
On the UNIX Attributes tab, set the following properties for tstgrp01:
.gif)
Figure 4.1. The UNIX Attributes tab for the group called tstgrp02
NIS Domain: example (if your test domain name is not called example.com, use your actual test domain name)
(GID) Group ID: 10001 (use a GID that is not currently in use on your UNIX hosts)
Do not add any members at this time.
Add UNIX attributes to tstgrp02. Repeat step 1 to add UNIX attributes to tstgrp02, using a GID of 10002 (use a GID that is not currently in use on your UNIX hosts).
Add UNIX attributes to test02. In the console tree, under UNIX-OU, click UNIX-Users, and then add UNIX attributes to the user test02 as follows:
.gif)
Figure 4.2. The UNIX Attributes tab for the user called test02
In the details pane, right-click test02, and then click Properties.
On the UNIX Attributes tab, set the following properties for test02:
NIS Domain: example.com (if your test domain name is not called example.com, use your actual test domain name)
UID: 10002 (use a UID that is not currently in use on your UNIX hosts)
Login Shell: /bin/sh (or use the shell of your preference)
Home Directory: /home/test02 (or use the home directory location of your preference)
Primary group name (GID): tstgrp01
Note Do not add UNIX attributes to the test01 user account. Later, you use the user test01 to test the configuration for End State 1, which uses Active Directory for authentication but uses an alternative data store (in this case, the local /etc/passwd and /etc/group files) for authorization data. The UNIX attributes for test01 are added to the local files on the UNIX-based computer. Therefore, adding UNIX attributes for test01 in Active Directory as well could create confusion during testing because it might not be clear from where the data is being retrieved.
Add UNIX attributes to test03 and test04. Repeat step 3 to add UNIX attributes to test03 and test04, using GIDs of 10003 and 10004 (use GIDs that are not currently in use on your UNIX hosts).
Add test02 , test03 , and test04 to the msSFU30MemberUID attribute for tstgrp02. Click Start, click Run, type adsiedit.msc, click OK, and then configure the following:
Note Using ADSI Edit to perform this step is necessary because the UNIX Attribute tab for the group in Active Directory Users and Computers lets you populate the msSFU30PosixMember attribute for groups; however, it does not let you populate the msSFU30MemberUid attribute. You cannot map the msSFU30PosixMember attribute to the memberuid attribute on the UNIX-based computers because msSFU30PosixMember is a distinguished name (also known as DN) and the UNIX memberuid is an IA5String, as is msSFU30MemberUid.
In the console tree, expand Domain [ComputerName.example.com], expand DC=example,DC=com, expand OU=UNIX-OU, and then expand OU=UNIX-Groups.
Right-click CN=tstgrp02, and then click Properties.
On the Attribute Editor tab, click the msSFU30MemberUid attribute, and then click Edit.
In Multi-valued String Editor, in Value to add, type test02, click Add. Repeat to add test03 and test04.
Click OK twice.
For more information about the ADSI Edit snap-in, see:
For information about how to install ADSI Edit, see "To add a snap-in to a new MMC console for a local computer" in Help and Support Center for Windows Server 2003.
For information about ADSI Edit, see "Adsiedit Overview" at https://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/ebca3324-5427-471a-bc19-9aa1decd3d40.mspx.
For information about how to use ADSI Edit, see “Microsoft Active Directory Management Pack Guide: Active Directory Management Pack Operations” at https://www.microsoft.com/technet/prodtechnol/mom/mom2005/maintain/admpguideformom2005_3.mspx.
Create Kerberos Service Key Table
[Windows] [Native OS Only] [End States 1 and 2]
This section describes how to use Windows tools to create a Kerberos service key table on the domain controller for native OS solutions and copy the key table file to the UNIX client.
Note Alternatively, instead of using the steps provided here to create a Kerberos service key table, you can accomplish this task by installing the Certified Security Solutions (CSS) Active Directory Kerberos administration tool (called ADKadmin or css_adkadmin) on the UNIX client. For more information about the css_adkadmin tool, see "Install Kerberos Tools" in "Use Solaris 9 with Open Source Components for End States 1 and 2" or "Install Kerberos Tools" in "Use Red Hat 9 with Open Source Components for End States 1 and 2" later in this chapter; and see Appendix E: "Relevant Windows and UNIX Tools."
Navigation Note If you plan to deploy End State 1 or 2 with open source components and plan to use the css_adkadmin tool to help develop your open source solution, skip this procedure. Instead, proceed to "Synchronize Time" later in this section.
To create a Kerberos key table for the UNIX client host
Create Active Directory account for UNIX host: Open Active Directory Users and Computers in Administrative Tools, and then configure the following:
In the console tree under example.com, expand UNIX-OU, right-click UNIX-Computers, click New, and then click User.
Note A user account is used here instead of a computer account because the ktpass command currently cannot handle computer accounts correctly.
In Full name and User logon name, type a name similar to host_hostname, where hostname is the short host name of the UNIX host. For example, for the computer unix01.example.com, type host_unix01, and then click Next.
For the password, type and confirm Password1, select Password never expires, click Next, and then click Finish.
Confirm UNIX host added to DNS map. Confirm that the UNIX host name has been added to the Active Directory DNS forward zone map before you run the ktpass command in the next step.
Create key table file and map. Open a command prompt, and then use the ktpass command to create a key table file and map the host/hostname principal for the UNIX host to the UNIX Active Directory account just created.
In this example, hostname is the short host name of the UNIX-based computer, fqdn is the fully qualified domain name of the UNIX-based computer, and EXAMPLE.COM is the uppercase REALM name of the Active Directory server (on a Windows network, a Kerberos realm name is the DNS domain name converted to uppercase):
Note: The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks.
C:\Program Files\Support Tools>ktpass -out c:\hostname_keytab1 -pass
Password1 -princ host/fqdn@EXAMPLE.COM -mapuser host_hostname -ptype KRB5_NT_SRV_HST
**Note** Although this example shows the command typed from the Support Tools directory, you can issue commands without changing to the directory where the commands are located.
**Note** The output directory for the Kerberos key table file created in this command, "c:\\" is an example. You can place the file in any directory. You will copy the file from that directory to the UNIX client in a later step.
For example, if the FQDN of your host is unix01.example.com, type the following command:
**Note:** The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks.
<pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">C:\Program Files\Support Tools>ktpass -out c:\unix01_keytab1 -pass
Password1 -princ host/unix01.example.com@EXAMPLE.COM -mapuser host_unix01 -ptype KRB5_NT_SRV_HST
Windows Server 2003 account names are not multipart as are Kerberos principal names. Because of this, you cannot use Active Directory Users and Computers to create an account with the name "host/*hostname*.*example*.com." Instead, you use the **ktpass** command with the switches **-princ** and **-mapuser** to associate the account with a meaningful name (created through Active Directory Users and Computers) with a service principal name for host/*hostname*.*example*.com, and then create a key table containing an entry with the service principal name.
**Note** The following error is printed by **ktpass** if the named host principal does not exist in Active Directory or if an incorrect principal name is specified:
DsCrackNames returned 0x2 in the name entry for host\_*hostname*
Confirm key table exists. Confirm that the key table file C:\hostname_keytab1 (C:\unix01_keytab1 in the example used throughout this procedure) has been created.
Copy key table file to UNIX host. Because the key stored in the key table file must be kept confidential, securely copy the key table file to the UNIX host by using an encrypted channel or a physically secure method (such as a floppy disk).
CAUTION Using a secure method is crucial in a production environment.
For more information about ktpass, see Appendix E: "Relevant Windows and UNIX Tools."
Synchronize Time
[Windows and UNIX/Linux] [Native OS and Open Source] [End States 1 and 2]
You must synchronize the clocks on your Active Directory server and UNIX clients so that the time on all client computers matches the clock maintained by Active Directory. Kerberos requires that the time on all computers in the Kerberos environment be closely synchronized to ensure that the time stamp on Kerberos tickets issued by the KDC are within a valid range. In a Kerberos environment, if your clocks are not synchronized, authentication will fail. The default allowable time skew is 5 minutes. Some implementations, including Active Directory, allow this to be changed. However, the longer the allowable time skew, the more vulnerable your environment becomes to certain classes of attack ("replay" attacks, in which a valid data transmission over a network is maliciously or fraudulently repeated). The recommended best practice is to use the default time skew limit of 5 minutes.
You must also synchronize the clocks on virtual servers running UNIX or Linux.
For information about how to synchronize clocks, see Appendix H: "Configuring Time Services for a Heterogeneous UNIX and Windows Environment."
Setting Up the Second Domain Controller
[Windows] [Native OS and Open Source] [End States 1 and 2]
Deploy a second domain controller using the same steps that you just completed to install the first domain controller. Installing at least two domain controllers is a good practice because, if the first domain controller fails, the second one is available to support client computers.
After both domain controllers are installed, with the DNS service running on each one, all Active Directory changes, including DNS data, automatically replicate to the second domain controller. Although you can install a second domain controller at any time, installing it immediately after installing the first domain controller means that replication occurs quickly and avoids replication delays.
Navigation Note If you plan to deploy only End State 1 or End State 2 with open source software, stop here. Proceed to the section "Prepare for Training, Testing, and Deployment" later in this chapter. The following steps are needed only for End State 2 with native OS components.
Build a Certification Authority
This section describes how to create an enterprise root certification authority (CA) for your development environment, how to enable basic authentication, and how to add an SSL certificate to your Active Directory domain controllers.
IMPORTANT You need a CA only if you plan to deploy the native OS End State 2 solution for Solaris.
This section includes the following topics describing how to:
Create an enterprise root CA.
Enable basic authentication.
Verify that domain controllers have SSL certificates.
Creating an Enterprise Root CA
[Windows] [Native OS] [Solaris 9] [End State 2]
Navigation Note If you do not need a CA, skip this subsection (and also skip the subsections "Enabling Basic Authentication" and "Verifying That Domain Controllers Have SSL Certificates"), and go directly to the section "Prepare for Training, Testing, and Deployment."
You must create a certification authority (CA), or acquire an X.509 certificate from an external CA, for the End State 2 solution using native OS components on Solaris. A server certificate is required for using LDAPS. LDAPS refers to the use of Transport Layer Security (TLS) with Secure Sockets Layer (SSL) to encrypt LDAP traffic between a computer and a directory server. Because the LDAP connection that is used to retrieve authorization data from Active Directory uses a simple bind, which sends the user name and password in plaintext (unencrypted text, also sometimes called clear text), the LDAP connection must be encrypted to protect these credentials.
The instructions provided in this chapter refer to using an enterprise CA, from which your Active Directory servers will automatically acquire a server certificate. If you acquire the server certificate from a third-party vendor or a stand-alone CA, the certificate requirements are:
The LDAPS certificate is located in the local computer's Personal certificate store (programmatically known as the computer's MY certificate store).
A private key that matches the certificate is present in the local computer's store and is correctly associated with the certificate. The private key must not have strong private key protection enabled.
The Enhanced Key Usage extension includes the Server Authentication (1.3.6.1.5.5.7.3.1) object identifier (also known as OID).
The Active Directory fully qualified domain name (FQDN) of the domain controller (for example, DC01.EXAMPLE.COM) must appear in one of the following places:
The Common Name (CN) in the Subject field.
The DNS entry in the Subject Alternative Name extension.
The certificate was issued by a CA that the domain controller and the LDAPS clients trust. You establish trust by configuring the clients and the server to trust the root CA to which the issuing CA chains.
CAUTION You can use an Enterprise Root CA in your development environment. However, in a production environment, you should never use an Enterprise Root CA. In a production environment, a root CA should always be an Offline CA, and you should use an Enterprise Subordinate CA to issue end-user and computer certificates.
To install IIS and create an Enterprise Root CA
Install Windows. Install Windows Server 2003 Standard Edition on the computer that you want to use as the CA.
Join Windows domain. Join the server to the Active Directory domain.
Important You must join the server to the domain before you install Certificate Services because you cannot change the domain of the CA after the service is installed.
For information about how to join a computer to a domain, see "To join a domain" in Help and Support Center for Windows Server 2003.
Install IIS. Internet Information Services (IIS) is available on the computer running Windows Server 2003 through Add or Remove Programs in Control Panel.
For information about how to install IIS, see "Install Internet Information Services (IIS) 6.0" in Help and Support Center for Windows Server 2003.
Create Enterprise Root CA. Install Certificate Services, and then create an Enterprise Root CA. Wherever available, accept default settings during the installation. Where default settings are not specified by the wizard, configure the options in the following table.
Table 4.5 Enterprise Root CA Wizard
For more information about deploying Certificate Services, see: - The Public Key Infrastructure for Windows Server 2003 page at [https://go.microsoft.com/fwlink/?LinkId=19936](https://go.microsoft.com/fwlink/?linkid=19936). - ”Install an enterprise root certification authority” at [https://go.microsoft.com/fwlink/?LinkId=20035](https://go.microsoft.com/fwlink/?linkid=20035). - *Securing Wireless LANs with Certificate Services* at [https://go.microsoft.com/fwlink/?LinkId=14843](https://go.microsoft.com/fwlink/?linkid=14843). **Note** This guide about securing wireless LANs provides detailed information about how to set up Certificate Services that is useful for either a wired or a wireless environment.Wizard Page
Action
Common name for this CA
Type an appropriate name, such as:
Test Enterprise Root CA
Validity period
Specify an appropriate period of time, such as 10 years.
Enabling Basic Authentication
[Windows] [Native OS] [End State 2]
Navigation Note You need to enable basic authentication only if you use a CA. If you do not need a CA, skip this subsection and the subsection "Verifying that Domain Controllers Have SSL Certificates" and go directly to the section "Prepare for Training, Testing, and Deployment.”
Basic authentication is required for UNIX clients to authenticate to IIS and to download certificates from the Web interface of Certificate Services.
CAUTION In a production environment, you should use basic authentication only with an HTTPS (TLS/SSL) connection to the Web server. You can use SSL to encrypt LDAP traffic between UNIX clients and domain controllers. The LDAP connection uses a simple bind, which sends the user name and password in plaintext, so the LDAP connection must be encrypted to protect these credentials.
To enable basic authentication
Open IIS Manager. Open the IIS Manager in Administrative Tools.
Enable basic authentication. In the console tree, expand HOSTNAME (local computer), Web Sites, and Default Web Site, and then configure the following:
Right-click CertSrv, and then click Properties.
On the Directory Security tab, in the Authentication and access control section, click Edit.
In Authentication Methods, clear Enable anonymous access, and then select Basic authentication (password is sent in clear text).
Note You can also select other options (except for Enable anonymous access) because multiple methods are supported.
Click OK, and then click OK.
Verifying That Domain Controllers Have SSL Certificates
[Windows] [Native OS] [End State 2]
Navigation Note You need to verify that domain controllers have SSL certificates only if you use a CA. If you do not need a CA, skip this subsection and go directly to the section "Prepare for Training, Testing, and Deployment."
The following two procedures show how to confirm that your domain controller has received an SSL certificate (this should occur automatically via autoenrollment) and, if necessary, how to force a Group Policy update if a certificate for the domain controller does not appear initially.
To confirm that the domain controller has received a certificate
Add Certificates console to domain controller. Perform the following steps on each Active Directory domain controller:
Click Start, click Run, type mmc, and then click OK.
Click File, click Add/Remove Snap-in, and then click Add.
Click Certificates, and then click Add.
Select the Computer account option, click Next, and then click Finish.
Click Close, and then click OK.
Confirm certificate or force a Group Policy update. In the console tree, expand Certificates (Local Computer) click Personal, and then confirm that a certificate exists, or (if necessary) force a Group Policy update, as instructed in the following table.
Table 4.6.Confirm That a Certificate Exists or Force a Group Policy Update
Confirm That a Certificate Exists
Force a Group Policy Update
Click the Certificates folder and confirm that a certificate for the domain controller appears.
If no Certificates folder appears, open a command prompt and type the following command:
C:\>gpupdate /force
In the Certificates snap-in, check again for the presence of the certificate. If no certificate appears, see "Autoenrollment" under "TLS Certificates" in Appendix D.
Prepare for Training, Testing, and Deployment
During the Developing Phase, Development team members document the solution or solutions they deploy in their test lab. In addition, the User Experience, Test, and Release Management teams prepare for the upcoming test-and-stabilization, deployment, and operations activities.
The following table summarizes the documentation and usability tasks that each team should perform during the Developing Phase. Completing these tasks during the Developing Phase can help ensure success in the subsequent test and production deployment stages and can help facilitate hand-off to Operations after deployment is completed.
Table 4.7 Documentation , Training , and Operations Tasks During the Developing Phase
Team
Tasks
Development
Document configuration of the solution or solutions tested.
Document prototype deployment scripts that you develop (if any).
Document issues that required troubleshooting during development and the resolution for each issue.
User Experience
Update training plan developed earlier in the Planning Phase with information learned in response to the practical experience gained in the test lab.
Prepare training materials for testers.
Prepare training materials for operations personnel.
Prepare informational or training materials for end users.
Work with developers to ensure usability of the tested solutions for administrators and end users.
Test
Perform functional testing for each solution developed in the test lab and provide feedback to developers.
Identify and document any issues or "pain points" for each solution tested.
Design tests for the Stabilizing Phase that test the overall solution and ensure that any potential issues are stabilized. Update the test plan created by using the “Test Plan Template” job aid during the Planning Phase.
Test configuration documentation written by the Development team.
Test training documentation written by the User Experience team.
Release Management
Update pilot and rollout plans developed earlier during the Planning Phase in response to the practical experience gained in the test lab.
Prepare checklists:
Site prep checklist. To prepare the production environment for deployment (site preparation).
Deployment checklist. To ensure a smooth rollout during deployment.
Transfer to operations checklist. To ensure a smooth handoff to operations after deployment is completed.
Developing the Solution Using Native OS Features
Native OS solutions are those that use only components included in the operating system as provided by the operating system vendor.
The following sections provide detailed steps for deploying the following native OS solutions in your development environment:
“Use Solaris 9 with Native OS Components for End States 1 and 2”
“Use Red Hat 9 with Native OS Components for End States 1 and 2”
When you develop a native OS solution, remember the following:
Make sure that you use only native OS features (not open source components or commercial components such as Centrify DirectControl or Quest Software Vintela Authentication Services (VAS). If you mix different components together on the same computer in your development lab, some of the default behavior described in the following procedures might not occur as expected.
You must run all system configuration steps on UNIX-based computers as root user unless otherwise specified.
In a native OS solution, you might not need to specify the path for UNIX tools, depending on where they are stored. If you do experience any problems, be sure to specify the full path.
Use Solaris 9 with Native OS Components for End States 1 and 2
The native OS solution on Solaris can meet the needs of many organizations. This solution provides the basic UNIX functionality that users expect but also adds Active Directory authentication or consolidates both authentication and authorization data in Active Directory.
The native solution for Solaris provides two key features that are not available with the native Red Hat solution:
Password change during logon when a user's password expires.
LDAP authorization data retrieval from the Active Directory database over a secure channel.
In contrast to the native OS Solaris solution described in this section, the open source Solaris solution (described later) provides a few features not available in the native Solaris solution, including providing a warning to users that a password will expire in n days and the capability to secure the LDAP connection to Active Directory using Kerberos. However, the added complexity of configuring the open source Solaris solution and the lack of vendor support for an open source solution makes a native Solaris solution a more attractive option for some organizations.
If you want to use Solaris 9 with native OS components to deploy End State 1 or to deploy End State 2, use the procedures as indicated in the following table.
Table 4.8. Which Procedures in This Section Are Appropriate for Your Native Solaris Solution?
Solution
Do These Procedures
End State 1
Procedures: End States 1 and 2 (Solaris 9, Native OS)
End State 2
Procedures: End States 1 and 2 (Solaris 9, Native OS)
–and–
Procedures: End State 2 Only (Solaris 9, Native OS)
For procedures to implement solutions other than native OS Solaris, see the following sections:
“Use Red Hat 9 with Native OS Components for End States 1 and 2”
“Use Solaris 9 with Open Source Components for End States 1 and 2”
“Use Red Hat 9 with Open Source Components for Ends States 1 and 2”
Procedures: End States 1 and 2 (Solaris 9, Native OS)
If you want to set up a proof-of-concept development lab using Solaris 9 with native OS components to deploy End State 1 or 2, use the procedures in this subsection.
Install and Configure Solaris 9
[Native OS] [Solaris 9] [End States 1 and 2]
Although it is possible to implement the solution described in these steps on a preinstalled Solaris 9 client, the environment on such a client might be different from that assumed for these steps. Starting with a clean install ensures that no preexisting software or configuration will interfere with the solution—this is especially important if you want to test more than one of the custom solutions described in this volume. The packaged solutions, for instance, might install components that conflict with the native (or open source) functionality.
The steps for installing and configuring Solaris for your environment typically differ from the steps described here. The configuration described here is the minimum necessary to implement the solution: configuring DNS, installing Kerberos, and—for End State 2 only—installing LDAP-related patches. These steps are required. Other configuration steps normally done in your environment are optional; some (for example, configuring NIS or NIS+) might conflict with the solution described here.
If you follow the instructions provided in the following procedure, the native Kerberos client tools are automatically installed and a sample Kerberos configuration is created. You can confirm this after the installation completes by verifying that the Kerberos client tools, such as kinit, klist, and kdestroy, are located in /usr/bin/.
Note For more information about how to install Solaris 9, see "Solaris 9 9/04 Installation Guide" in the "Solaris 9 9/05 Release and Installation Collection" at https://docs.sun.com/app/docs/doc/817-5768.
To install and configure Solaris
Install OS. On the UNIX host, install Solaris version 9. Users who have never installed Solaris might find it simplest to use the Default Install option, which offers an installation wizard similar to that used for a Windows install. During the install, you need to choose a nondefault selection only in the following case:
On the Kerberos page of the installation wizard, select Yes to enable (configure) Kerberos.
Note If you select No (the default selection), the installation process still installs Kerberos but does not configure it. In this case, after installing and configuring Solaris, you must manually edit the sample Kerberos configuration file, krb5.conf, to enter the correct information for your environment. See "Configure the Kerberos Client" later in this section for information about configuring Kerberos and the krb5.conf file.
Configure options. After the Solaris installation completes, set the following configuration options:
Include FQDN. Modify the /etc/hosts file to contain the FQDN of the UNIX client followed by the short name.
Note Although, in a production environment, a client computer typically uses a dynamic DNS address, assigning the example UNIX client, unix01, a static IP address in a lab environment when you initially develop the solution eliminates one variable from your test environment.
For example:
10.9.8.12 unix01.example.com unix01
Specify files before DNS. Modify the /etc/nsswitch.conf file to use files first for name resolution (hosts) and then to use DNS. The hosts entry should match the following format:
hosts: files dns
Point to Windows DNS server. Configure the /etc/resolv.conf file to point to the Windows server for DNS. For example:
domain example.com
nameserver IPaddress1 nameserver IPaddress2
where example.com* *is the name of your test domain, and *IPAddress1* and *IPAddress2* are the IP addresses of your DNS servers (in this test environment, the DNS servers are your Windows domain controllers). **Note** See Appendix I: "Sample Configuration Files for Custom Solutions" for the complete configuration file.Identify which patches to install. For this native OS Solaris solution, you need to install the native Kerberos patches and (for End State 2 only) the LDAP patch listed in the following table. These patches update the native Kerberos client tools (such as kinit, klist, and kdestroy) and native LDAP tools (such as ldapsearch) that you use in the quick verification tests described later in this section.
Note You should install the latest versions of Kerberos patches (for both End States 1 and 2 solutions) and the latest LDAP patches (for End State 2 solutions). You may choose to install the latest patches individually or install the latest patch cluster, which should include the latest patches. Patches shown in the table are current as of the publication of this document but might not be the latest version at the time you install the patches.
Table 4.9. Kerberos and LDAP Patches
End State
Patches
[End States 1 and 2]
Kerberos patches. At minimum, you should install Kerberos patches. Currently, the following Kerberos patches relevant for this solution are available:
Patch-ID# 112908-23. SunOS 5.9: krb5 shared object patch
Patch-ID# 112922-02. SunOS 5.9: krb5 lib patch
Patch-ID# 112923-03. SunOS 5.9: krb5 usr/lib patch
Note Other Kerberos patches are also available but are not needed for this solution.
Prerequisite patches. In addition, you might need other patches that are required for correct functionality of the patches in this list. Which additional patches you might need (if any) vary depending on your current system configuration.
[End State 2 only]
LDAP patch. Currently, the following LDAP patch relevant for this solution is available:
Patch-ID# 112960-32. SunOS 5.9: patch libsldap ldap_cachemgr libldap.
Note Other LDAP patches are also available but are not needed for this solution.
Prerequisite patches. In addition, you might need other patches that are required for correct functionality of this patch. Which additional patches you might need (if any) vary depending on your current system configuration.
Determine if a patch is already installed:
Navigation Note If you plan to install the entire patch cluster, skip this step and go directly to step 5: Download and install the latest Solaris patch cluster, or install individual patches (or both).
Use patchadd or showrev to investigate existing patches. Use either of the following commands (where xxxxxx is the patch number) to determine whether a patch is already installed and whether it is the latest revision of the patch available:
# /usr/sbin/patchadd -p | grep xxxxxx
– or –
# /usr/bin/showrev -p | grep xxxxxx
Note Omit any suffixes to the patch number in this command. For example, to check for versions of patch 112396-02, enter only 112396.
Either command produces results as shown in the following table.
Table 4.10. Output Varies Depending on Whether a Patch Is Installed
Result
Description
Output if a patch is already installed
If a patch that matches the number entered is installed, information about this patch and any related patches is returned. You should see output similar to the following:
Note: The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks.
Patch: 112908-04 Obsoletes: 112726-03
Requires: 112907-01 Incompatibles: Packages: SUNWcar SUNWcarx SUNWgssk SUNWgsskx SUNWkrbu SUNWkrbux
This output indicates that revision 04 of patch 112908 is installed.
No patch—no output
If no patch that matches the number that you specify is installed, no message appears and you are returned to the command prompt.
2. **Navigate to Sun site.** You can find the Sun Update Connection – Patches and Updates page at <https://sunsolve.sun.com/pub-cgi/show.pl?target=patchpage>. 3. **Determine whether additional patches need to be installed.** Use the **PatchFinder** tool on the Sun Update Connection – Patches and Updates page to find the latest version of each of the Kerberos and—for End State 2 only—LDAP patches identified earlier (in Table 4.9, "Kerberos and LDAP Patches") and compare that to the installed version on your computer, if any.Download and install latest Solaris patch cluster , or install individual patches (or both):
Decide what to install. Determine if you will install only the patch cluster, install only individual patches, or install the patch cluster and then individual patches:
Install only individual patches? Choose this option if UNIX policy, change management rules, or some other restriction in your organization requires that you do not install the patch cluster.
Install only the patch cluster? Choose this option if you are not restricted from installing the patch cluster and if all of the patches listed earlier (in Table 4.9, "Kerberos and LDAP Patches") are included in the cluster.
Install the patch cluster and then individual patches? Choose this option if you are not restricted from installing the patch cluster, but one or more of the patches listed earlier (in Table 4.9, "Kerberos and LDAP Patches") are not included in the cluster.
Depending on your answers to the preceding questions, download and then install patches as described in the following steps.
Download patches. Use the appropriate method or methods to download patches as described in the following table.
Table 4.11. How to Download Patches
Download Method
Action
Download patch cluster
Download the latest Solaris 9 recommended patch cluster:
Go to the Sun Update Connection – Patches and Updates page at https://sunsolve.sun.com/pub-cgi/show.pl?target=patchpage.
On this page, under Recommended and Security Patches, click Recommended Patch Clusters.
Under Recommended Solaris Patch Clusters, click the appropriate Solaris 9 package for your environment, click Readme, and then click Go to open the CLUSTER_README file.
Review the CLUSTER_README file to confirm that the patch cluster contains the required Kerberos and—for End State 2 only—LDAP patches (see Table 4.9, "Kerberos and LDAP Patches" earlier in this section).
On the Sun Update Connection – Patches and Updates page under Recommended Solaris Patch Clusters, click the appropriate Solaris 9 package for your environment, click Download HTTP or Download FTP, and then click Go to download the patch cluster.
If the patch cluster is missing one or more of the required patches, download them individually using the steps in the next row, "Download individual patches and prerequisites."
Download individual patches and prerequisites
Download the individual Kerberos and—for End State 2 only—LDAP patches identified in the previous steps:
Go to the Sun Update Connection – Patches and Updates page at https://sunsolve.sun.com/pub-cgi/show.pl?target=patchpage.
On this page, under PatchFinder, search for each individual patch.
Read the patch information page for each patch and determine whether the patch requires additional patches for correct functionality (the "Required Patches" section) or has any special installation instructions (the "Special Install Instructions" section).
Download each patch and any additional required patches identified in each patch's patch information page.
Additional patches that you might need vary depending on your current system configuration.
Install patches. Use the appropriate method or methods to install patches as described in the following table.
Table 4.12. How to Install Patches
4. **Restart.** After you complete installing patches, restart the UNIX host.Install Method
Action
Install patch cluster
Follow the instructions in the CLUSTER_README file to install the Solaris 9 patch cluster.
Install patches individually or in groups
On the UNIX host, open a shell, and then use one of the following commands:
To install individual patches. To install patches individually (where patch is the directory name for each individual patch—for example: 112396-02), type:
# /usr/sbin/patchadd /path/patch
To install multiple patches. To install several patches together (where patchlist is a file that contains a list of all patches to be installed), type:
# /usr/sbin/patchadd -M /path/patchlist
For more information about using patchlist files, see the Solaris documentation.
Note If you want to find out if a patch is already installed before you run this command, see the earlier step "Determine if a patch is already installed."
Configure the Kerberos Client
[Native OS] [Solaris 9] [End States 1 and 2]
You configure Kerberos client functionality on a UNIX client in the Kerberos configuration file, the krb5.conf file. This file identifies the REALM of the Kerberos environment, the security servers (KDCs) to which authentication requests will be directed, the administrative and password servers (typically, these servers are the same as the KDCs) to which administrative and password change requests will be directed, and the DNS domain name for the environment. In Windows, the REALM name is the uppercase equivalent of the DNS domain name. In other UNIX environments, using the uppercase name is the convention but is not required. In addition to these standard settings in the krb5.conf file, there are Active Directory–specific settings: the encryption type (because Active Directory does not support all of the encryption types that the UNIX client supports) and password change settings.
The standard Solaris installation process creates a sample file. If you chose to configure Kerberos during the Solaris install, this file will be partially configured for you. However, you must manually add the krb5.conf settings that are specific to Active Directory interoperability.
Kerberos functions are time sensitive to provide added security. This is done, in part, to prevent replay attacks. By default, the time on all Kerberos clients and the Active Directory servers must be within 5 minutes of one another. Because clocks on computers can drift, the best practice is to implement Network Time Protocol (NTP) to maintain synchronization instead of attempting to manually synchronize computers. If the clocks on your client and server drift out of sync, Kerberos functions will begin to fail. Because some functions rely on credentials acquired earlier, these failures might not appear immediately after the clocks go out of sync. It is possible that, for a time, some Kerberos functions fail while others continue to work, which can confuse troubleshooting efforts.
To configure the Kerberos client
Synchronize clocks. Confirm that the clocks on your Active Directory server and UNIX clients are synchronized as described earlier in this chapter in the subsection "Synchronize Time" in "Prepare Your Environment." Kerberos requires that the clocks on all computers in the Kerberos environment be synchronized to within 5 minutes of one another.
Modify file. Modify the sample configuration located in the /etc/krb5.conf file to contain the following entries, where EXAMPLE.COM is the REALM name for your Active Directory server, kdc1.example.com and kdc2.example.com are the FQDNs of your Active Directory servers, and .example.com is the DNS domain name of your Active Directory server.
Note Configuration entries for the krb5.conf file vary by operating system. Those shown here are correct for Solaris 9. On Solaris 9, a sample krb5.conf file is created when the Kerberos client is installed. See Appendix I: "Sample Configuration Files for Custom Solutions" for the complete configuration file.
[libdefaults]
default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false default_tkt_enctypes = des-cbc-md5 des-cbc-crc default_tgs_enctypes = des-cbc-md5 des-cbc-crc [realms] EXAMPLE.COM = { kdc = kdc1.example.com:88 kdc = kdc2.example.com:88 admin_server = kdc1.example.com:749 kpasswd_server = kdc1.example.com:464 kpasswd_protocol = SET_CHANGE default_domain = example.com } [domain_realm] *.example.com = EXAMPLE.COM .example.com = EXAMPLE.COM
**Note** The remainder of the sample file is not shown here because it does not require modification.For more information about krb5.conf files, see:
The Solaris man page for "krb5.conf." A "man page" is a page from the UNIX manual that you access by typing, in this case, man krb5.conf, at a UNIX command prompt.
The Sun Enterprise Authentication Mechanism 1.0.2 Guide at https://docs.sun.com/app/docs/doc/816-5164.
The SEAM sections of the System Administration Guide: Security Services at https://docs.sun.com/app/docs/doc/806-4078.
Install the Service Key Table
[Native OS] [Solaris 9] [End States 1 and 2]
A key table file that contains the key for the UNIX-based computer account in Active Directory is required for both End States 1 and 2 for logon through Kerberos to succeed. This key table is also used by servers that provide Kerberized (that is, Kerberos-aware) services, such as an FTP or telnet server.
CAUTION In a production environment, you must use a secure or encrypted method to transfer the key table file from the domain controller to the UNIX-based computer. If a secure network transport method is unavailable, use a removable disk for the transfer. Be sure to use binary options when transferring the file using FTP or other file transfer programs.
Note For a method to create the key table file that is more secure but easier to use than the method described in the following procedure, you can use the css_adkadmin tool on the UNIX client. For an example of how to use this tool, see "Use Solaris 9 with Open Source Components for End States 1 and 2" later in this chapter.
To install the service key table
Transfer key table file into /etc/krb5. Place the key table file that you created with ktpass on the Active Directory domain controller (see "Create Kerberos Service Key Table" earlier in this chapter) into the /etc/krb5 directory on the UNIX host.
Change the name of the file to krb5.keytab.
Change ownership. The krb5.keytab file must be owned by root to ensure proper Kerberized logon functionality. Use chown to change the ownership to root:
# chown root krb5.keytab
Specify permissions. Because of the secure nature of the file, the file should be accessible only by root. Use chmod to grant the krb5.keytab file permissions of 600 (which makes a file readable and writable only by the owner, that is, by root).
# chmod 600 krb5.keytab
Note Alternatively, it is also possible to use chmod 400 to make the key table file readable but not writable. However, for optimal security, the key table should be re-created periodically; if it is not writable, you must delete it before re-creating it. The key table can also be used to contain additional principals for other purposes for which it would need to be writable, at least when the principals are added to it. By default, the ktutil tool, which is used to update and merge key tables, assumes that the key table file is writable. The steps in this chapter use mode 600.
Perform a Quick Kerberos Configuration Verification Test
[Native OS] [Solaris 9] [End States 1 and 2]
Implementing the solution requires several steps, many of which assume successful completion of earlier steps. It is important to stop periodically and test the configuration completed to that point to confirm that it is correct before moving forward.
You can use the Kerberos client kinit tool to confirm that the krb5.conf file is configured correctly and that DNS is working correctly in your environment. You can use the Kerberos client klist tool to view the contents of the key table that you created to see whether the account is present.
The basic tests provided here do not test every possible function in Kerberos. Therefore, even if these tests complete successfully, you might still encounter Kerberos configuration problems that cause problems in subsequent steps.
Potential problems include:
Subtle DNS configuration problems. Requests for service tickets (sometimes called session tickets) are sensitive to DNS configuration problems. A service ticket might fail as a result of a DNS problem even if an initial ticket-granting ticket (TGT) request made by using kinit succeeds. A service ticket request is made as part of the logon process.
Clock skew problems. Requests for service tickets are sensitive to clock skew problems.
Bad key tables. The key table is used only during the logon process. The test presented here confirms that the key table exists but not that the key table is valid for logon.
For more information about testing Kerberos configuration and troubleshooting Kerberos problems, see Appendix D "Kerberos and LDAP Troubleshooting Tips."
To verify Kerberos configuration
Get Kerberos ticket. Use the kinit command to acquire a Kerberos ticket for a test user. For example, to acquire a ticket for test01, type:
$ kinit test01
Note When you develop a native OS solution, you might not need to specify the path for UNIX tools, depending on where the tools are stored. If you do experience any problems, be sure to specify the full path.
If the command completes successfully, no message appears and the user is returned to the command prompt. A message appears only if an error occurs.
View Kerberos ticket. Use the klist command, which lists currently held Kerberos tickets, to view the ticket just acquired for test01. Type:
$ klist
This command returns output similar to the following:
Note: Some of the lines in the following code have been displayed on multiple lines for better readability.
Ticket cache: /tmp/krb5cc_500
Default principal: test01@EXAMPLE.COM Valid starting Expires Service principal Thu 10 Aug 2006 10:36:15 AM PDT Thu 10 Aug 2006 08:36:15 PM PDT krbtgt /EXAMPLE.COM@EXAMPLE.COM renew until Thu 17 Aug 2006 10:36:15 AM PDT
**Note** If these commands fail, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."Confirm keytab data. Use the klist -k command to confirm that the key table contains correct data:
# klist –k
This command returns output similar to the following:
Keytab name: FILE:/etc/krb5/krb5.keytab
KVNO Principal
2 host/unix01.example.com@EXAMPLE.COM
Configure /etc/pam.conf for Kerberos Authentication
[Native OS] [Solaris 9] [End States 1 and 2]
The pluggable authentication module (PAM) is used to control authentication on UNIX-based computers. On Solaris, PAM is configured with the /etc/pam.conf file. Each line in pam.conf defines a service type (for example, authentication or password change) and a module to be used for this process (for example, pam_unix or pam_krb5). Multiple modules can be associated with each service type. To provide for logon through Kerberos, you must add entries to the pam.conf file to identify the pam_krb5 module as a valid authentication mechanism. Because not all users will have accounts in Active Directory (for example, the UNIX root user does not have an Active Directory account), you must enable such users to log on. This is done with PAM stacking rules.
In this case, the pam_krb5 modules are placed before the pam_unix modules and set to "sufficient." This specifies that, when a user logs on, a test for Kerberos authentication is performed first. If the user passes this test (the user exists in Active Directory and provides the correct Active Directory password), the user is allowed to log on. If the user fails this test, a test for local authentication is performed. If the user passes this test (the user exists in the local /etc/passwd file and provides the correct local password), the user is allowed to log on. All other users are denied access.
CAUTION Perform each step in this section carefully, and then check all pam.conf configurations before proceeding. Incorrectly configuring the pam.conf file or failing to apply the appropriate patches can lead to a state in which no user, including root, can log on (see the Note about configuring failsafe root access in the following procedure).
For information about how to manage potential issues related to pam_krb5, see the table "How to Manage pam_krb5 Issues" that follows the procedure. For more information about PAM and the pam.conf file, see Appendix A: "Architectural Overview of UNIX and Windows Authentication and Authorization."
To configure /etc/pam.conf for Kerberos authentication
Note See Appendix I: "Sample Configuration Files for Custom Solutions" for the complete configuration file.
Back up file. Copy the existing /etc/pam.conf file to /etc/pam.conf.orig:
# cp /etc/pam.conf /etc/pam.conf.orig
Modify Authentication management. Modify the Authentication management section of the pam.conf file as follows:
# Authentication management
login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth sufficient pam_krb5.so use_first_pass login auth required pam_unix_auth.so.1 login auth required pam_dial_auth.so.1
dtlogin (explicit to allow for separate control during
testing)
dtlogin auth requisite pam_authtok_get.so.1 #dtlogin auth sufficient pam_krb5.so use_first_pass dtlogin auth required pam_unix_auth.so.1
su (explicit to provide failsafe root access during testing)
su auth requisite pam_authtok_get.so.1 su auth required pam_unix_auth.so.1
rlogin service (explicit because of pam_rhost_auth)
rlogin auth sufficient pam_rhosts_auth.so.1 rlogin auth requisite pam_authtok_get.so.1 rlogin auth required pam_dhkeys.so.1 #rlogin auth sufficient pam_krb5.so use_first_pass rlogin auth required pam_unix_auth.so.1
rsh service (explicit because of pam_rhost_auth,
and pam_unix_auth for meaningful pam_setcred)
rsh auth sufficient pam_rhosts_auth.so.1 rsh auth required pam_unix_auth.so.1
PPP service (explicit because of pam_dial_auth)
ppp auth requisite pam_authtok_get.so.1 ppp auth required pam_dhkeys.so.1 ppp auth required pam_unix_auth.so.1 ppp auth required pam_dial_auth.so.1
Default definitions for Authentication management
Used when service name is not explicitly mentioned for
authentication
other auth requisite pam_authtok_get.so.1 other auth required pam_dhkeys.so.1 other auth sufficient pam_krb5.so use_first_pass other auth required pam_unix_auth.so.1
End of code for this step.
**Note** In the preceding code, you can see that a section for the superuser (**su**) is added to the pam.conf file and configured to use pam\_unix to provide a failsafe root access method. Later, if you want to use Kerberos authentication for **su**, consider using **ksu** (Kerberized **su**) instead. During initial testing, you might want to comment out the following pam\_krb5 entries for **dtlogin** (if you have GUI console access) and **rlogin** to provide logon options that do not use pam\_krb5: <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">dtlogin auth sufficient pam_krb5.so use_first_passrlogin auth sufficient pam_krb5.so use_first_pass
Commenting out these entries is a safety precaution to ensure continued access to the server while you troubleshoot any configuration issues. After pam\_krb5 authentication is functioning correctly, you can uncomment the pam\_krb5 entries in the dtlogin and rlogin sections of the pam.conf file. For optimal security, we recommend that you configure computers to use the Kerberized versions of **telnetd**, **ftpd**, **krlogind**, and other remote tools. (Kerberized versions of these tools are part of the Sun SEAM package.) When you use Kerberized versions of **telnetd**, **ftpd**, **krlogind**, or other remote tools, the pam\_krb5 entries in the pam.conf file might not be used, depending upon configuration. For more information about using Kerberized versions of these services, see: - The *Sun Enterprise Authentication Mechanism 1.0.2 Guide* at <https://docs.sun.com/app/docs/doc/816-5164>. - The SEAM sections of *System Administration Guide: Security Services* at <https://docs.sun.com/app/docs/doc/806-4078>.Modify Account management. Modify the Account management section of the pam.conf file as follows:
Note See Appendix I: "Sample Configuration Files for Custom Solutions" for the complete configuration file.
#
Default definition for Account management
Used when service name is not explicitly mentioned for
account management
other account requisite pam_roles.so.1 other account required pam_projects.so.1 other account required pam_unix_account.so.1 other account required pam_krb5.so
Modify Password management. Modify the Password management section of the pam.conf file as follows:
#
Default definition for Password management
Used when service name is not explicitly mentioned for
password management
other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password sufficient pam_krb5.so use_first_pass other password required pam_authtok_store.so.1
End of code for this step.
**Note** It is possible to use pam\_krb5 for Kerberos password change for the UNIX **passwd** tool. Configuring the Password management section of pam\_krb5 enables this functionality. However, Active Directory users might find it more reliable to use the **kpasswd** tool to change passwords. In some configurations, the password change process with the **passwd** tool will fail or will prompt repeatedly for the new password. We recommend: Use the UNIX Kerberos **kpasswd** tool for Kerberos password changes. Use the UNIX **passwd** tool for local password changes.The following table describes how to avoid or work around recent or current pam_krb5 issues.
Table 4.13. How to Manage pam_krb5 Issues
Pam_krb5 Issues
Description
Avoiding a segmentation fault
Do not configure the pam.conf file for pam_krb5 until after you successfully install the latest version of the 112908 patch listed earlier (in Table 4.9, "Kerberos and LDAP Patches"). Revision 112908-13 or later corrects a pam_krb5 problem that causes a segmentation fault when trying to access root using pam_krb5.
See the preceding procedure ("Configure /etc/pam.conf for Kerberos Authentication") for information about configuring failsafe root access.
Working around dtlogin issues
Sun reports two defects in Solaris 9 related to the functionality of the graphical user interface (GUI), dtlogin, when pam_krb5 is used for authentication. These defects can cause the dtlogin process to generate a core dump when logon is attempted through the GUI with the pam_krb5 module.
Note Sun is not currently planning to fix these two defects in Solaris 9 (although they are fixed in Solaris 10).
You can use the following workarounds for these problems.
Currently, versions of the pam_krb5 libraries provided by Sun Microsystems for Solaris 9, other than those included in the original distribution of Solaris 9, might cause a core dump in dtlogin in some installations. If you do encounter this problem, you must use the first version of pam_krb5 that was distributed with the original release of Solaris 9.
The first version of the pam_krb5 library is not available for download from Sun. You must request it from Sun technical support and reference Bug ID 4920178. You need two different pam_krb5.so.1 libraries: Put one into /usr/lib/security/sparcv9 and put the other (a different file with the same name) into /usr/lib/security. Ask Sun technical support for instructions for installing each of these files in the correct location.
Note In developing and testing the procedures for this solution (native OS with Solaris 9), we were unable to reproduce this problem.
No version of the pam_krb5 libraries distributed with Solaris 9, including the original distribution version noted previously, operates correctly with Active Directory security principals that use preauthentication. You must configure all principals that will log on through the GUI with the flag "Do not require Kerberos preauthentication" selected. You configure this option under Account options on the Account tab of the user's Properties page in Active Directory Users and Computers.
Note In developing and testing the procedures for this solution (native OS with Solaris 9), we did reproduce this problem.
For more information about this issue, contact Sun technical support and reference RFE 4933940.
CAUTION Operating without preauthentication represents a serious security risk and is not recommended in your production environment. Preauthentication helps protect against certain types of attacks. In addition, operating without preauthentication disables some features of the solution. The most significant of these is password change control. When a user's Active Directory security principal is configured not to use preauthentication, the user is allowed to log on to UNIX-based computers after the Active Directory password expires. The user is not prompted to change the password.
Create Test User Data for User test01
[Native OS] [Solaris 9] [End States 1 and 2]
At this point in the configuration process, you must test that configuration for Kerberos authentication when a user logs on to UNIX is successful. To log on to a UNIX client, a user must have both authentication data and authorization data. Because you have not yet configured the client to use Active Directory (End State 2 only) or another data store for authorization data, for this test, you create a local user account to provide authorization data for a test user locally on the UNIX client. You add an account to the local /etc/passwd file and create a home directory for the user. You must set a password for the user's local account, but you will not use this password for logon. To avoid confusion during testing, this password must not match the Active Directory password for the same user—if the same password is used, it might be unclear during testing whether logon succeeds against Active Directory or locally.
To create test data for test01
Create test01 locally. Use the useradd command to create a local test user, test01:
# useradd -d /home/test01 –m -s /bin/csh test01
Note The /home/test01 directory and /bin/csh shell are examples for the user's home directory location and shell. In your environment, you might use a directory other than /home and a different shell.
Set password. Use the passwd command to set the local UNIX password for this user. Give the user a password different from that used for this test user in Active Directory:
# passwd test01
When prompted to provide a password, type a strong password, not a dictionary-based password. Typing a dictionary-based password returns a BAD PASSWORD message.
Confirm directory ownership. Use the ls command to confirm that the /home/test01 directory has been created and is owned by user test01:
# ls -ld /home/test01
Perform a Quick Verification Test as User test01
[Native OS] [Solaris 9] [End States 1 and 2]
Confirm that a user can log on using Kerberos authentication against Active Directory. You can accomplish this by using a number of different logon methods, but the method that you use must be one that is currently configured for pam_krb5 authentication in the pam.conf file. If you provided for failsafe root access by commenting out the pam_krb5 entries for rlogin or dtlogin, you cannot use those logon methods for testing. On some systems and with some configurations, ssh or Kerberized versions of services, such as telnet, might not make use of the pam.conf configurations defined here.
To verify logon for test01
Log on. Log on as test user test01 either at the console command-line of the UNIX-based computer or by using telnet (if telnetd is installed on the client computer). Use the password configured in Active Directory instead of the local password.
Note If you want to log on by using telnet, you might need to install and configure the telnetd service.
Confirm logon. Confirm that you are successfully logged on.
Note If logon fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."
Confirm TGT. Use the klist command, which lists currently held Kerberos tickets, to confirm that a Kerberos ticket-granting ticket (TGT) has been granted. Check to be sure that the ticket listed in the data returned by klist includes the correct user name and current date and time.
Milestone Complete: End State 1 (Solaris 9, Native OS)
If your goal is to use Solaris 9 with native OS components to deploy only End State 1, which enables your UNIX clients to use Active Directory Kerberos for authentication, stop here. The rest of the instructions in "Use Solaris 9 with Native OS Components for End States 1 and 2" are for End State 2.
If you want to use Solaris 9 with native OS components to deploy End State 2, continue with the procedures in the following section.
Procedures: End State 2 Only (Solaris 9, Native OS)
If you want to expand your test lab using Solaris 9 with native OS components to deploy End State 2 so that your development environment supports both Active Directory Kerberos and Active Directory LDAP, perform the procedures in this section after completing the procedures in "Procedures: End States 1 and 2 (Solaris 9, Native OS)" in the preceding subsection.
Configure the LDAP Client
[Native OS] [Solaris 9] [End State 2]
For this end state, you configure the Solaris client to use LDAP to retrieve authorization data for Active Directory users. These steps create configuration files that identify the server or servers to which LDAP requests are directed, the method by which the LDAP bind is accomplished, the mapping of UNIX authorization attributes to Windows attributes, and the container in which data for UNIX users and groups in Active Directory are found.
The LDAP bind—authentication to retrieve LDAP information—is done using a proxy user. Because attributes for authorization data in UNIX have different names from those added to the schema when you install Windows Services for UNIX on Windows, you must create mappings to associate the UNIX names of certain attributes with the corresponding Windows names for these attributes.
Use the following steps to configure the LDAP client.
To configure the LDAP client
Note See Appendix I: "Sample Configuration Files for Custom Solutions" for the complete configuration file.
Back up file. Running the ldapclient command might delete or modify the /etc/nsswitch.conf file. Therefore, copy the existing /etc/nsswitch.conf file to /etc/nsswitch.conf.orig:
# cp /etc/nsswitch.conf /etc/nsswitch.conf.orig
Create script. To register the Solaris host as an LDAP client, begin by creating the following script:
Note You can find a text file of this script called "Solaris_native_LDAP_config.sh" in the Tools and Templates directory in the same download where you obtained this chapter. Be sure to use a UNIX editor (such as vi) to edit and save the file to ensure that the shell script retains the line terminators required by the UNIX shell. Using a Windows editor (such as Notepad) to edit the file might introduce incorrect line endings.
# !/bin/sh
Note that the defaultServerList entry in the following
example script is the list of Active Directory servers
against which to authenticate.
ldapclient manual
-a credentialLevel=proxy
-a authenticationMethod=simple
-a proxyDN=cn=proxyuser,cn=users,dc=example,dc=com
-a proxyPassword=Password1
-a defaultSearchBase=dc=example,dc=com
-a domainName=example.com
-a "defaultServerList=10.9.8.1 10.9.8.2"
-a attributeMap=group:userpassword=msSFU30Password
-a attributeMap=group:memberuid=msSFU30MemberUid
-a attributeMap=group:gidnumber=msSFU30GidNumber
-a attributeMap=passwd:gecos=msSFU30Gecos
-a attributeMap=passwd:gidnumber=msSFU30GidNumber
-a attributeMap=passwd:uidnumber=msSFU30UidNumber
-a attributeMap=passwd:uid=sAMAccountName
-a attributeMap=passwd:homedirectory=msSFU30HomeDirectory
-a attributeMap=passwd:loginshell=msSFU30LoginShell
-a attributeMap=shadow:shadowflag=msSFU30ShadowFlag
-a attributeMap=shadow:userpassword=msSFU30Password
-a attributeMap=shadow:uid=sAMAccountName
-a objectClassMap=group:posixGroup=group
-a objectClassMap=passwd:posixAccount=user
-a objectClassMap=shadow:shadowAccount=user
-a serviceSearchDescriptor=passwd:ou=unix,?sub
-a serviceSearchDescriptor=group:ou=unix,?subEdit entries. Make the following changes:
CAUTION Use a UNIX editor (such as vi) to edit and save the file to ensure that the shell script retains the line terminators required by the UNIX shell. Using a Windows editor (such as Notepad) to edit the file might introduce incorrect line endings.
Edit the proxyDN, proxyPassword, defaultSearchBase, and defaultServerList entries to contain correct data for your test environment.
The defaultServerList can contain the IP address of a single Active Directory server or a space-separated list of the IP addresses for multiple Active Directory servers.
Edit the serviceSearchDescriptor entries to point to the appropriate locations for your user and group entries.
Note For more information about entering data for the attributes in this command, see the man page for the ldapclient command on the System Administration Commands page of the Sun Web site at https://docs.sun.com/app/docs/doc/817-3937. The man page describes the settings for ldapclient and the type of data you use for each setting, such as the data format to use for the defaultServerList attribute.
Save script. Save and close the script file that you just created (name it, for example, ldapconfig.sh).
Modify permissions. Use the chmod command with 755 to modify the permissions on ldapconfig.sh to make it executable:
# chmod 755 /tmp/ldapconfig.sh
Confirm script OK. Confirm that all entries in the script are correct.
Use script to run ldapclient. Use the script that you just created to run the ldapclient configuration command:
# /tmp/ldapconfig.sh
The ldapclient command creates a file called /var/ldap/ldap_client_file that should contain the entries shown after the CAUTION:
CAUTION Confirm that your values match the values shown following, including the proxyDN, proxyPassword, defaultSearchBase, and defaultServerList entries that contain correct data for your test environment. If one or more values do not match, which might happen if you have installed software unrelated to this solution in your test lab, modify any nonmatching values to match the corresponding values shown here.
#
Do not edit this file manually; your changes will be lost.
Please use ldapclient (1M) instead.
NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_SERVERS= 10.9.8.1 NS_LDAP_SEARCH_BASEDN= dc=example,dc=com NS_LDAP_AUTH= simple NS_LDAP_CACHETTL= 3600 NS_LDAP_CREDENTIAL_LEVEL= proxy NS_LDAP_SERVICE_SEARCH_DESC= passwd:ou=unix,?sub NS_LDAP_SERVICE_SEARCH_DESC= group:ou=unix,?sub NS_LDAP_ATTRIBUTEMAP= group:userpassword=msSFU30Password NS_LDAP_ATTRIBUTEMAP= group:memberuid=msSFU30MemberUid NS_LDAP_ATTRIBUTEMAP= group:gidnumber=msSFU30GidNumber NS_LDAP_ATTRIBUTEMAP= passwd:gecos=msSFU30Gecos NS_LDAP_ATTRIBUTEMAP= passwd:gidnumber=msSFU30GidNumber NS_LDAP_ATTRIBUTEMAP= passwd:uidnumber=msSFU30UidNumber NS_LDAP_ATTRIBUTEMAP= passwd:uid=sAMAccountName NS_LDAP_ATTRIBUTEMAP= passwd:homedirectory=msSFU30HomeDirectory NS_LDAP_ATTRIBUTEMAP= passwd:loginshell=msSFU30LoginShell NS_LDAP_ATTRIBUTEMAP= shadow:shadowflag=msSFU30ShadowFlag NS_LDAP_ATTRIBUTEMAP= shadow:userpassword=msSFU30Password NS_LDAP_ATTRIBUTEMAP= shadow:uid=sAMAccountName NS_LDAP_OBJECTCLASSMAP= group:posixGroup=group NS_LDAP_OBJECTCLASSMAP= passwd:posixAccount=user NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=user
In addition, the **ldapclient** command creates a /var/ldap/ldap\_client\_cred file that should contain the following entries: <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">#Do not edit this file manually; your changes will be lost.
Please use ldapclient (1M) instead.
NS_LDAP_BINDDN= cn=proxyuser,cn=users,dc=example,dc=com NS_LDAP_BINDPASSWD= {NS1}ecfa88f3a945c411
If needed , modify any incorrect entries. You can use the mod switch with the ldapclient command to modify any incorrect entries in the file ldap_client_file.
For example, the following command changes the IP address of the Active Directory server to 5.6.7.8:
# ldapclient mod -a defaultServerList=5.6.7.8
Configure the /etc/nsswitch.conf File
[Native OS] [Solaris 9] [End State 2]
The /etc/nsswitch.conf file is used to configure NSS for a broad range of data sources and many different functions. Much like a PAM configuration, the NSS configuration allows you to specify multiple stacked data sources for any given function.
Note See Appendix I: "Sample Configuration Files for Custom Solutions" for the complete configuration file.
Three sections are defined specifically for this end state:
passwd. Identifies the list of data sources from which user environment configuration data (for example, home directory or shell) is retrieved.
group. Identifies the list of data sources from which user group membership is retrieved.
hosts. Identifies the list of data sources from which name resolution data is retrieved.
For the passwd and group sections, both files (the local /etc/passwd and /etc/group files) and ldap (the Active Directory database) are defined. For the hosts section, both files (/etc/hosts) and dns (domain name system servers) are defined.
See Appendix A: "Architectural Overview of UNIX and Windows Authentication and Authorization" for more information about NSS and the nsswitch.conf file.
To configure /etc/nsswitch.conf
Modify entries. Modify the passwd and group entries in the nsswitch.conf file as follows:
passwd: files ldap [TRYAGAIN=continue]
group: files ldap [TRYAGAIN=continue]
Remove other ldap entries. Remove all other instances of ldap in the file. (Running ldapclient updates many fields that should not contain ldap for the development environment configuration presented here.)
Confirm files listed before DNS. Confirm that the /etc/nsswitch.conf file is still configured to use files first for name resolution (hosts) and then DNS. The hosts entry should match the following format:
hosts: files dns
Back up file. Subsequent execution of the ldapclient command might delete or modify the /etc/nsswitch.conf file. Before proceeding, save a copy of the current /etc/nsswitch.conf file for future reference:
# cp /etc/nsswitch.conf /etc/nsswitch.conf.configured
Restart the LDAP Daemons
[Native OS] [Solaris 9] [End State 2]
After each configuration change, you must restart the LDAP and Name Service Caching Daemon (NSCD) services. The LDAP daemon performs Active Directory database lookups and is necessary for functionality. The NSCD service caches LDAP data retrieved from Active Directory to reduce lookups for duplicate data. Restarting NSCD is not necessary for functionality but can reduce network traffic.
To restart the LDAP daemons
Restart services. Use the following commands to stop and restart the LDAP daemons:
# /etc/init.d/ldap.client stop
/etc/init.d/ldap.client start
/etc/init.d/nscd stop
/etc/init.d/nscd start
Test LDAP Connectivity to the Active Directory Server
[Native OS] [Solaris 9] [End State 2]
You can use one of the following commands to confirm that the UNIX host has LDAP connectivity to the Active Directory server. These commands confirm that your UNIX host can communicate via LDAP with your Active Directory server but do not validate the LDAP configuration steps completed to this point. Only a logon test can validate the LDAP configuration.
To test LDAP connectivity to Active Directory , run one of the following commands
You can use the ldapsearch command as follows to test your LDAP connection, where the command options are defined as described in the following table.
Table 4.14. Options for the ldapsearch Command
Here is the generic command: **Note:** The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks.Variable
Description
IPAddress
The IP address of your Active Directory server.
ProxyDN
The distinguished name of your LDAP proxy user.
Password1
The password of your LDAP proxy user.
BaseDN
The base distinguished name where your UNIX users and computers are stored (for example, ou=unix,dc=example,dc=com)
# ldapsearch -h IPAddress -D ProxyDN -w Password1 -b BaseDN -s sub '(cn=test*)'
For example: **Note:** The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks. <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml"># ldapsearch -h 10.9.8.1 -D cn=proxyuser,cn=users,dc=example,dc=com -wPassword1 –b ou=unix,dc=example,dc=com -s sub (cn=test*)'
If this command completes successfully, you see output that includes several attributes associated with each user (test\*) in Active Directory. The first line of returned data displays information similar to the following: <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">CN=test01,OU=Users,OU=UNIX,DC=example,DC=com</pre> If the command fails, the system displays an error message. **Note** If this command fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."You can use the ldapsearch command as follows to test your LDAP connection, where IPAddress is the IP address of your Active Directory server:
# ldapsearch -h IPAddress -s base -b "" "(objectclass=*)"
For example:
# ldapsearch -h 10.9.8.1 -s base -b "" "(objectclass=*)"
The output from the command should be similar to the following:
currentTime=20031217100255.0Z
subschemaSubentry=CN=Aggregate,CN=Schema,CN=Configuration,DC=example,DC=com [...]
**Note** If this command fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."Create Test User Data for User test02
[Native OS] [Solaris 9] [End State 2]
At this point in the configuration process, you must test that the configuration for Kerberos authentication and LDAP authorization at UNIX logon completed successfully. To log on to a UNIX client as an Active Directory user, you must create a home directory for the Active Directory user on each UNIX client. For correct functionality, the home directory must be owned by the test user. If the home directory does not exist or its ownership is incorrect, logon or some post-logon functions might fail.
For this test, do not create a local user account in /etc/passwd. If a local account exists for the same user name, it might be unclear at logon whether data was retrieved locally or from Active Directory.
To create test data for test02
Create directory. Create a home directory for user test02:
# mkdir /home/test02
Note The /home/test02 directory is an example location for the user's home directory. In your environment, a directory other than /home might be used.
Specify permissions. Give the directories correct user permissions:
# chown test02 test02
chgrp tstgrp01 test02
**Note** If the **chown** or **chgrp** command fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."Perform a Quick Verification Test as User test02
[Native OS] [Solaris 9] [End State 2]
Confirm that a user can log on using Kerberos authentication and LDAP authorization against Active Directory. You can accomplish this by using a number of different logon methods, but the method you use must be one that is currently configured for pam_krb5 authentication in the pam.conf file. If you provided for failsafe root access by commenting out the pam_krb5 entries for rlogin and/or dtlogin, those logon methods cannot be used for testing. On some systems and with some configurations, ssh or Kerberized versions of services, such as telnet, might not make use of the pam.conf configurations defined here.
After you log on, run the id and groups commands to confirm that the user's UID and GID are correctly mapped to the user's user name and primary group name and that a complete list of all groups of which the user is a member can be retrieved. If the output of the id command includes only the UID and GID numbers but not the user and group names in parentheses, or if the groups command returns no data or only one group, the test has failed.
To verify logon for test02
Log on. Log on either at the console command-line of the UNIX-based computer or by using telnet (if telnetd is installed on the client computer) as test user test02.
Note If you want to log on by using telnet, you might need to install and configure the telnetd service.
Confirm logon. Confirm that you are successfully logged on.
Note If logon fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."
Confirm id and group output. Confirm that the output of the id and group commands contains complete data, as illustrated in this example:
$ id
uid=10002(test02) gid=10001(tstgrp01) $ groups tstgrp01 tstgrp02
**Note** If this test fails, refer to Appendix D: "Kerberos and LDAP Troubleshooting Tips."Configure TLS for LDAP Authentication
[Native OS] [Solaris 9] [End State 2]
Up to this point, the proxy account password and all LDAP data have been transmitted over the network in clear (unencrypted) text. Setting up Transport Layer Security (TLS) using Secure Sockets Layer (SSL) will encrypt this traffic.
When preparing your development environment, you configured the Active Directory server to acquire a certificate to be used for the server-side SSL certificate (see "Build a Certification Authority" earlier in this chapter). Now, you must set up the client-side Solaris host to trust the root CA that issued the certificate. You can accomplish this by downloading the root CA certificate and performing the other procedures in this subsection.
Note Here, "LDAP authentication" refers only to the LDAP proxy user, not to end users using LDAP authentication when logging on to their UNIX workstations.
Download Root CA Certificate
[Native OS] [Solaris 9] [End State 2]
Use the following procedure to download the root CA certificate to the Solaris host.
To download the root CA certificate
Log on. Log on as root user.
Download certificate. Use the following steps to download the root CA certificate onto your Solaris host:
Open Netscape through the Solaris GUI.
Browse to one of the following addresses, where hostname is the short host name of your CA server.
If you have not configured your Web server for SSL, the URL is:
https://hostname/certsrv.
If you have configured your Web server for SSL, the URL is:
https://hostname/certsrv.
Provide a user name and password for an Active Directory domain user. The user account does not need to be an administrator account.
On the Welcome screen, click Download a CA certificate, certificate chain, or CRL.
On the Download a CA certificate, certificate chain, or CRL screen, select Base 64, and then choose Download CA certificate to start the New Certificate Authority wizard:
In the wizard, click Next until you reach the page on which you choose the purpose for which you want to accept the certificate; select the option Accept this Certificate Authority for Certifying network sites, and then click Next.
Click Next until you reach the page prompting for the short name of the certification authority, enter the short name of the certification authority, and then click Finish. This process downloads the certificate—clicking Finish creates the certificate store files (cert7.db, key3.db, and secmodule.db) in the temporary .netscape directory. (In the next procedure, you copy these files into the /var/ldap directory).
Install Root CA Certificate
[Native OS] [Solaris 9] [End State 2]
Use the following procedure to install the root CA certificate on the Solaris host.
To install a root CA certificate
Copy files. Copy the certificate store files, cert7.db, key3.db, and secmodule.db, from the /.netscape directory to the /var/ldap directory:
# cd /
cp .netscape/*.db /var/ldap
Modify permissions. Use chmod with 644 to modify the permissions on the certificate store files so that these files can be read by all users:
# chmod 644 /var/ldap/*.db
Modify the LDAP Client Configuration
[Native OS] [Solaris 9] [End State 2]
Use the following procedure to modify the LDAP client configuration on the UNIX host for TLS.
To modify the configuration for the LDAP client
Change configuration to tls. Modify the /var/ldap/ldap_client_file as follows to change the NS_LDAP_AUTH configuration to tls:
# ldapclient mod -a authenticationMethod=tls:simple
This command modifies the following line in the ldap_client_file file:
NS_LDAP_AUTH= tls:simple
Note If this command fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."
Restart the LDAP Daemons
[Native OS] [Solaris 9] [End State 2]
Use the following procedure to restart the LDAP services.
To restart the LDAP daemons
Restart services. Use the following commands to stop and restart the LDAP daemons:
# /etc/init.d/ldap.client stop
/etc/init.d/ldap.client start
/etc/init.d/nscd stop
/etc/init.d/nscd start
Perform a Quick Verification Test as User test01
[Native OS] [Solaris 9] [End State 2]
Use the following procedure to verify that test01 can log on.
Note Recall that user test01 is used only to test authentication (authorization data for user test01 is stored in /etc/passwd). For steps to test authorization, see the next procedure, "Perform a Quick Verification Test as User test02."
To verify logon for test01
Log on. Log on as test user test01 either at the console command-line of the UNIX-based computer or by using telnet (if telnetd is installed on the client computer). Use the password configured in Active Directory instead of the local password.
Note If you want to log on by using telnet, you might need to install and configure the telnetd service.
Confirm logon. Confirm that you are successfully logged on.
Note If logon fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."
Confirm TGT. Use the klist command, which lists currently held Kerberos tickets, to confirm that a Kerberos ticket-granting ticket (TGT) has been granted. Check to be sure that the ticket listed in the data returned by klist includes the correct user name and current date and time.
Perform a Quick Verification Test as User test02
[Native OS] [Solaris 9] [End State 2]
Use the following procedure to verify that user test02 can log on.
To verify logon for test02
Log on. Log on either at the console command-line of the UNIX-based computer or by using telnet (if telnetd is installed on the client computer) as test user test02.
Note If you want to log on by using telnet, you might need to install and configure the telnetd service.
Confirm logon. Confirm that you are successfully logged on.
Note If logon fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."
Confirm id and group output. Confirm that the output of the id and group commands contains complete data, as illustrated in this example:
$ id
uid=10002(test02) gid=10001(tstgrp01) $ groups tstgrp01 tstgrp02
**Note** If this test fails, refer to Appendix D: "Kerberos and LDAP Troubleshooting Tips."Milestone Complete: End State 2 (Solaris 9, Native OS)
You have used native OS components and Solaris 9 to deploy End State 2, which enables your UNIX clients to use Active Directory Kerberos for authentication and Active Directory LDAP for authorization. If this is the only solution in which you are interested, stop here.
If you want to try one or more of the other solutions developed in this chapter, continue to the next solution that you want to deploy in your development environment. For a list showing each of the available solutions, see "Chapter Map" earlier in this chapter.
Use Red Hat 9 with Native OS Components for End States 1 and 2
The native OS solution on Red Hat has substantial limitations and is therefore appropriate only for a very limited number of organizations.
CAUTION We do not recommend deploying the native OS Red Hat 9 solution in your production environment because of the security risks inherent in this solution. Red Hat does not plan to update the Red Hat 9 Kerberos distribution (built on version 1.2.7 of MIT Kerberos) with a fixed implementation of Kerberos or, for End State 2 solutions, address the lack of support of a secure channel for LDAP authorization. Later versions of Red Hat products might not have these vulnerabilities but were not tested for this guide.
The major shortcomings of the native Red Hat solution are:
For End States 1 and 2—Kerberos shared libraries vulnerability. The native OS Red Hat 9 distribution is based on MIT Kerberos 1.2.7. The pam_krb5 library in the native Red Hat 9 distribution relies on a set of Kerberos shared libraries that contain known security vulnerabilities. The Kerberos client utilities in this distribution, known as the "k-utils" (such as kinit, klist, kpasswd, ktutil) are also affected by these security vulnerabilities because they rely on the same libraries.
Although you are not required to deploy the k-utils in order to enable End State 1 or 2, these tools are often quite useful for troubleshooting during a development deployment in your lab as well as for troubleshooting and help desk support later if you deploy this solution in your production environment.
In addition to being used by the k-utils, the insecure libraries provided in the MIT Kerberos version 1.2.7 package might also be used by other Kerberos-enabled applications on the UNIX client computers where the solution is deployed, depending on the design of these applications. For more information, see the note about the Fedora legacy project later in this introductory subsection.
For End States 1 and 2—Kerberos key table vulnerability. A security failure in native OS Red Hat 9 allows a user to log on even when the key table is missing or incorrect because credential verification is not performed. For best security practice, the UNIX-based computer should deny logon to any Active Directory user when pam_krb5 is the logon method if the Kerberos key table file on the UNIX-based computer is missing or does not contain the correct key for the UNIX-based computer. Failure to validate Kerberos credentials—that is, if the absence of a key table does not cause logon to fail as it should—is a significant security weakness in native OS Red Hat 9. Security implications include:
The Kerberos client on the UNIX host cannot verify that replies to Kerberos requests are being received from the correct (or a valid) KDC.
Any Kerberos credentials that might be received by the UNIX-based computer or are found in credentials cache on the UNIX-based computer cannot be validated as valid credentials.
For End State 2—LDAP connection vulnerability. With native OS Red Hat 9, the LDAP connection to Active Directory used to retrieve authorization data cannot be secured with TLS/SSL (or by any other method). This means that the password of the LDAP proxy user travels to the Active Directory server in plaintext and potentially can be captured and used by an attacker. In addition, authorization data for users is transmitted in plaintext. Because none of the authorization data is especially sensitive (no passwords are included), this is a lesser risk but still allows an attacker to gather some information about users. Additional risks are possible from attackers who modify the data in transit, for example, by adding their user accounts to an administrative group.
For End States 1 and 2—password expiration issue. With native OS Red Hat 9, when a user's password expires, the user is unable to log on. Although the user is prompted to change the password during logon (because the pam_krb5 library has functionality to prompt the user to change an expired password during logon), the password change is not successful. This is a bug in the native Red Hat 9 pam_krb5 library. The user must contact the help desk or administrator for a password reset.
These limitations are not present in the native or open source Solaris solutions and can be avoided in the open source Red Hat solution (see "Use Red Hat 9 with Open Source Components for End States 1 and 2" later in this chapter). This makes any of these three other options a much better choice than native OS Red Hat 9 for most organizations. The native OS Red Hat solution might be a good choice for users wanting to do a proof-of-concept test deployment that does not demonstrate password change during logon.
Note The Fedora Legacy project has made available Red Hat install packages (RPMs) with a patched version of Kerberos 1.2.7 for Red Hat 9. Although this patch was not released by Red Hat directly, you might choose to apply it to your solution using Red Hat 9 with native OS components to resolve the security vulnerabilities in the Kerberos libraries. This patch addresses only the vulnerabilities in the underlying Kerberos libraries, which affect the native pam_krb5 module and the k-utils. It does not resolve the credential validation and LDAP connection vulnerabilities mentioned earlier. For more information, see the "Fedora Legacy Update Advisory," available at https://www.fedoralegacy.org/updates/FC1/2005-07-24-FLSA_2005_154276__Updated_krb5_packages_fix_security_issues.html.
If you want to use Red Hat 9 with native OS components to deploy End State 1 or to deploy End State 2, use the procedures as indicated in the following table.
Table 4.15. Which Procedures in This Section Are Appropriate for Your Native Red Hat Solution?
Solution
Do These Procedures
End State 1
Procedures: End States 1 and 2 (Red Hat 9, Native OS)
End State 2
Procedures: End States 1 and 2 (Red Hat 9, Native OS)
–and–
Procedures: End State 2 Only (Red Hat 9, Native OS)
For procedures to implement solutions other than native OS Red Hat, see the following sections:
“Use Solaris 9 with Native OS Components for End States 1 and 2”
“Use Solaris 9 with Open Source Components for End States 1 and 2”
“Use Red Hat 9 with Open Source Components for Ends States 1 and 2”
Procedures: End States 1 and 2 (Red Hat 9, Native OS)
If you want to set up a proof-of-concept development lab using Red Hat 9 with native OS components to deploy End State 1 or 2, use the procedures in this subsection.
Install and Configure Red Hat 9
[Native OS] [Red Hat 9] [End States 1 and 2]
Although it is possible to implement the solution described in these steps on a preinstalled Red Hat 9 client, the environment on such a client might be different from that assumed for these steps. Starting with a clean install ensures that no preexisting software or configuration will interfere with the solution—this is especially important if you want to test more than one of the custom solutions described in this volume. The packaged solutions, for instance, might install components that conflict with the native (or open source) functionality.
The steps for installing and configuring Red Hat for your environment and the type of installation usually done might differ from the steps provided here. The configurations described here are the minimum necessary to implement the solution: selecting the Workstation installation type, configuring DNS, and installing the latest Kerberos packages. These steps are required. Other configuration steps normally done in your environment are optional; some (for example, configuring NIS or NIS+) might conflict with the solution described here.
To install and configure Red Hat
Install OS. On the UNIX host, install Red Hat version 9, selecting the Workstation installation type.
Specify settings. Specify a host name, IP address, and DNS domain name appropriate for your test environment (do not accept the defaults).
Configure options. After the installation is complete, set the following configuration options:
Modify file. Modify the /etc/hosts file to contain the IP address, FQDN, and short host name of the UNIX host as follows, where IPAddress is the IP address of the UNIX host, unix01 is the host name of the UNIX host, and example.com is the DNS domain name of the UNIX host:
IPAddress unix01.example.com unix01
Confirm files before DNS. Confirm that the /etc/nsswitch.conf file is configured to use files first for name resolution (hosts) and then DNS. The hosts entry should match the following format:
hosts: files dns
Point to Windows-based DNS server. Confirm that the /etc/resolv.conf file points to the Windows-based server for DNS and sets the DNS domain name, where example.com is your DNS domain name and the IPaddress is that of your primary DNS server (your Active Directory server). It might be necessary to add the DNS domain name.
domain example.com
nameserver IPaddress
Download and Install the Latest Red Hat Kerberos Client Packages
[Native OS] [Red Hat 9] [End States 1 and 2]
The Kerberos packages included as part of the standard Red Hat 9 installation are not the latest versions available and might not offer all of the functionality described for the custom solutions in this chapter.
To download and install Red Hat Kerberos client packages
Find installed packages. Use the following commands to determine whether the krb5-workstation and krb5-libs RedHat Package Manager (RPM) packages are installed on the host and to ascertain the version of each package:
# rpm –q krb5-workstation
rpm –q krb5-libs
If a package is currently installed, the output from each of these commands displays the full package name, including its version number. For example, the following output indicates that version 10 of the krb5-workstation package, built on MIT version 1.2.7, is installed: <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">krb5-workstation-1.2.7-10</pre> **Note** The Red Hat Kerberos packages built on version 1.2.7 of MIT are the latest versions available from Red Hat for native Red Hat 9 installation packages. We do not recommend deploying the native OS Red Hat 9 solution in your production environment because Red Hat does not plan to update the Red Hat 9 distribution to resolve the security issues in this Kerberos implementation. (This installation package is not the same as the 1.3.5 version of the MIT Kerberos open source package, krb5-1.3.5.tar, which you use in an open source Red Hat solution if you configure End State 2).Download latest versions. Download the latest versions of the krb5-workstation and krb5-libs packages from one of the following locations:
Certified Security Solutions at https://www.css-security.com/mirrors/mirrors.html.
RPM Repository at https://rpmfind.net. Either search for the package name (for instance, krb5-workstation-1.2.7-14) or try these specific links:
Search Engine: Open a Web browser and search for "download krb5-workstation-1.2.7-14 krb5-libs-1.2.7-14 krb5-devel-1.2.7-14." Use caution when downloading packages from unknown sources.
Currently, the latest package versions are 1.2.7–14.
Copy packages. Copy the krb5-workstation and krb5-libs RPM packages to a temporary directory on the UNIX host.
Change directory. Change to the directory to which you copied the RPM packages.
Upgrade or install. Use the following command to upgrade any existing krb5 packages (for example, krb5-libs) and install any missing packages (for example, krb5-workstation):
# rpm -Uvh krb5*
CAUTION Some Kerberos packages require that other Kerberos packages of the same version be installed. These are referred to as dependencies. For instance, the krb5-workstation package is dependent on the krb5-libs package. If a package you are attempting to install depends on another package that is missing or of an older version, you might receive a dependency error. Packages can have many dependencies, so a package install might also generate dependency errors about non-Kerberos packages. You must resolve the dependencies before proceeding by installing the package referenced in the dependency check. The command given here installs all of the krb5 packages at once, so a dependency error should not occur.
Configure the Kerberos Client
[Native OS] [Red Hat 9] [End States 1 and 2]
You configure Kerberos client functionality on a UNIX client in the krb5.conf file. This file identifies the REALM of the Kerberos environment, the security servers (KDCs) to which authentication requests will be directed, the administrative and password servers (typically, these servers are the same as the KDCs) to which administrative and password change requests will be directed, and the DNS domain name for the environment. In Windows, the REALM name is the uppercase equivalent of the DNS domain name. In other UNIX environments, using the uppercase name is the convention but is not required. In addition to these standard settings in the krb5.conf file, there are Active Directory–specific settings: the encryption type (because Active Directory does not support of all of the encryption types that the UNIX client supports) and password change settings.
The Red Hat installation process described here creates a sample file. You must modify the sample krb5.conf file to match your environment and add the settings that are specific to Active Directory interoperability.
Kerberos functions are time sensitive to provide added security. This is done, in part, to prevent replay attacks. By default, the time on all Kerberos clients and the Active Directory servers must be within 5 minutes of one another. Because clocks on computers can drift, the best practice is to implement Network Time Protocol (NTP) to maintain synchronization instead of attempting to manually synchronize computers. If the clocks on your client and server drift out of sync, Kerberos functions will begin to fail. Because some functions rely on credentials acquired earlier, these failures might not appear immediately after the clocks go out of sync. It is possible that, for a time, some Kerberos functions fail while others continue to work, which can confuse troubleshooting efforts.
To configure the Kerberos client
Synchronize clocks. Confirm that the clocks on your Active Directory server and UNIX clients are synchronized, as described earlier in this chapter in the subsection "Synchronize Time" in "Prepare Your Environment." Kerberos requires that the clocks on all computers in the Kerberos environment be synchronized to within 5 minutes of one another.
Modify file. Modify the sample configuration located in the /etc/krb5.conf file to contain the following entries, where EXAMPLE.COM is the REALM name for your Active Directory server, kdc1.example.com and kdc2.example.com are the FQDNs of your Active Directory servers, and .example.com is the DNS domain name of your Active Directory server.
Note For information about DNS lookups to determine whether you want to enable the entries for dns_lookup_realm and dns_lookup_kdc, see RFC 2782, "A DNS RR for specifying the location of services (DNS SRV)" at https://www.ietf.org/rfc/rfc2782.txt. The instructions provided for the custom solutions in this volume assume that DNS lookups have not been enabled. (See Appendix I: "Sample Configuration Files for Custom Solutions" for the complete configuration file.)
[libdefaults]
ticket_lifetime = 24000 default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false default_tkt_enctypes = des-cbc-md5 des-cbc-crc default_tgs_enctypes = des-cbc-md5 des-cbc-crc [realms] EXAMPLE.COM = { kdc = kdc1.example.com:88 kdc = kdc2.example.com:88 admin_server = kdc1.example.com:749 kpasswd_server = kdc1.example.com:464 kpasswd_protocol = SET_CHANGE default_domain = example.com } [domain_realm] *.example.com = EXAMPLE.COM .example.com = EXAMPLE.COM
**Note** The remainder of the sample file is not shown here because it does not require modification. **Note** This guide provides instructions for configuring the solution to use the DES-MD5 and/or DES-CRC encryption types. (Microsoft does not recommend the use DES-CRC. Use DES-CRC only if no other option is available.) Recent versions of the open source tools described here also support the standard Windows RC4-HMAC encryption type. However, the native Kerberos client tools such as **kinit** and Kerberized versions of services such as **telnetd** and **ftpd** do not support RC4-HMAC. If you choose to configure the solution with RC4-HMAC support, change the following lines to add RC4-HMAC as a valid encryption type: default\_tkt\_enctypes = rc4-hmac des-cbc-md5 des-cbc-crc default\_tgs\_enctypes = rc4-hmac des-cbc-md5 des-cbc-crc Some native Kerberos client tools and services might not function correctly when the krb5.conf file is configured in this way.Install the Service Key Table
[Native OS] [Red Hat 9] [End States 1 and 2]
A key table file that contains the key for the UNIX-based computer account in Active Directory is required for both End States 1 and 2 for pam_krb5 authentication to occur. This key table is also used by servers that provide Kerberized services, such as an FTP or telnet server.
CAUTION In a production environment, you must use a secure or encrypted method to transfer the key table file from the domain controller to the UNIX-based computer. If a secure network transport method is unavailable, use a removable disk for the transfer. Be sure to use binary options when transferring the file using FTP or other file transfer programs.
Note For a method to create the key table file that is more secure but easier to use than the method described in the following procedure, you can use the css_adkadmin tool on the UNIX client. For an example of how to use this tool, see "Use Red Hat 9 with Open Source Components for End States 1 and 2" later in this chapter."
To install the service key table
Transfer key table file into /etc. Place the key table file that you created with ktpass on the Active Directory domain controller (see "Create Kerberos Service Key Table" earlier in this chapter) into the /etc directory on the UNIX host.
Change the name of the file to krb5.keytab.
Change ownership. The krb5.keytab file must be owned by root to ensure proper pam_krb5 functionality. Use chown to change the ownership to root:
# chown root krb5.keytab
Specify permissions. Because of the secure nature of the file, the file should be accessible only by root. Use chmod to grant the krb5.keytab file permissions of 600 (which makes a file readable and writable only by the owner, that is, by root).
# chmod 600 krb5.keytab
Note Alternatively, it is also possible to use chmod 400 to make the key table file readable but not writable. However, for optimal security, the key table should be re-created periodically; if it is not writable, you must delete it before re-creating it. The key table can also be used to contain additional principals for other purposes for which it would need to be writable, at least when the principals are added to it. By default, the ktutil tool, which is used to update and merge key tables, assumes that the key table file is writable. The steps in this chapter use mode 600.
Perform a Quick Kerberos Configuration Verification Test
[Native OS] [Red Hat 9] [End States 1 and 2]
Implementing the solution requires several steps, many of which assume successful completion of earlier steps. It is important to stop periodically and test the configuration completed to that point to confirm that it is correct before moving forward.
You can use the Kerberos client kinit tool to confirm that the krb5.conf file is configured correctly and that DNS is working correctly in your environment. You can use the Kerberos client klist tool to view the contents of the key table that you created to see whether the correct account is present.
The basic tests provided here do not test every possible function in Kerberos. Therefore, even if these tests complete successfully, you might still encounter Kerberos configuration problems that cause problems in subsequent steps.
Potential problems include:
Subtle DNS configuration problems. Requests for service tickets are sensitive to DNS configuration problems. A service ticket might fail as a result of a DNS problem even if an initial ticket-granting ticket (TGT) request made by using kinit succeeds. A service ticket request is made as part of the logon process.
Clock skew problems. Requests for service tickets are sensitive to clock skew problems.
Bad key tables. The key table is used only during the logon process. The test presented here confirms that the key table exists but not that the key table is valid for logon.
For more information about testing Kerberos configuration and troubleshooting Kerberos problems, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."
To verify Kerberos configuration
Get Kerberos ticket. Use the kinit command to acquire a Kerberos ticket for a test user. For example, to acquire a ticket for test01, type:
$ kinit test01
Note When you develop a native OS solution, you might not need to specify the path for UNIX tools, depending on where the tools are stored. If you do experience any problems, be sure to specify the full path.
If the command completes successfully, no message appears and the user is returned to the command prompt. A message appears only if an error occurs.
View Kerberos ticket. Use the klist command to view the ticket just acquired for test01:
$ klist
This command returns output similar to the following:
Note: Some of the lines in the following code have been displayed on multiple lines for better readability.
Ticket cache: /tmp/krb5cc_500
Default principal: test01@EXAMPLE.COM Valid starting Expires Service principal THU 10 Aug 2006 10:36:15 AM PDT THU 10 Aug 2006 08:36:15 PM PDT krbtgt /EXAMPLE.COM@EXAMPLE.COM renew until THU 17 Aug 2006 10:36:15 AM PDT
**Note** If these commands fail, see Appendix C: "Kerberos and LDAP Troubleshooting Tips."Confirm keytab data. Use the klist -k command to confirm that the key table contains correct data:
# klist –k
This command returns output similar to the following:
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
2 host/unix01.example.com@EXAMPLE.COM
Configure the /etc/pam.d/system-auth file for Kerberos Authentication
[Native OS] [Red Hat 9] [End States 1 and 2]
The pluggable authentication module (PAM) is used to control authentication on UNIX-based computers. On Red Hat, you configure PAM with the files in the /etc/pam.d directory. The files define the behavior of the service—one file for each service—with each file name specifying the service to which it relates. Services that are not specifically defined by a service name file (such as telnetd) read configuration information from the system-auth file. Many of the service-specific files reference the system-auth file in order to inherit configuration from this file. Each line in these files defines a service type (for example, authentication or password change) and a module to be used for this process (for example, pam_unix or pam_krb5). Multiple modules can be associated with each service type.
To provide for logon through Kerberos, you must add entries to these files to identify the pam_krb5 module as a valid authentication mechanism. To set up the environment and tests described here, you need modify only the system-auth file.
Because not all users will have accounts in Active Directory (for example, the UNIX root user does not have an Active Directory account), you must enable such users to log on. This is done with PAM stacking rules.
In this case, the pam_krb5 modules are placed before the pam_unix modules and set to "sufficient." This specifies that, when a user logs on, a test for Kerberos authentication is performed first. If the user passes this test (the user exists in Active Directory and provides the correct Active Directory password), the user is allowed to log on. If the user fails this test, a test for local authentication is performed. If the user passes this test (the user exists in the local /etc/passwd file and provides the correct local password), the user is allowed to log on. All other users are denied access.
CAUTION Perform each step in this section carefully, and then check all PAM configuration before proceeding. Incorrectly configuring the system-auth file can lead to a state in which no user, including root, can log on. (See the Note about configuring failsafe root access in the following procedure.)
For more information about PAM, the pam.d directory, and the system-auth file, see Appendix A: "Architectural Overview of UNIX and Windows Authentication and Authorization."
To configure the /etc/pam.d/system-auth file for Kerberos
Back up file. Copy /etc/pam.d/system-auth to /etc/pam.d/system-auth.orig:
# cp /etc/pam.d/system-auth /etc/pam.d/system-auth.orig
Modify and add entries. Modify the existing pam_unix.so entries and add pam_krb5.so entries as follows.
Note See Appendix I: "Sample Configuration Files for Custom Solutions" for the complete configuration file.
Make sure that you place the entries in the order shown:
Note: Some of the lines in the following code have been displayed on multiple lines for better readability.
#%PAM-1.0
This file is auto-generated.
User changes will be destroyed the next time authconfig is
run.
auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_krb5.so auth sufficient /lib/security/$ISA/pam_unix.so use_first_pass likeauth nullok auth required /lib/security/$ISA/pam_deny.so account required /lib/security/$ISA/pam_unix.so password required /lib/security/$ISA/pam_cracklib.so retry=3 type= password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow password required /lib/security/$ISA/pam_deny.so session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so session optional /lib/security/$ISA/pam_krb5.so
Modify Password management (optional—not recommended in system-auth). It is also possible to modify the Password section of the system-auth file to enable Kerberos password change for the UNIX passwd tool. However, configuring the Password management section of system-auth might cause the password change process to prompt repeatedly for the new password.
Instead, we recommend:
Use the UNIX Kerberos kpasswd tool for Kerberos password changes.
Use the UNIX passwd tool for local password changes.
Create Test User Data for User test01
[Native OS] [Red Hat 9] [End States 1 and 2]
At this point in the configuration process, you must test that configuration for Kerberos authentication when a user logs on to Linux is successful. To log on to a Linux client, a user must have both authentication data and authorization data. Because you have not yet configured the client to use Active Directory (End State 2 only) or another data store for authorization data, for this test, you create a local user account to provide authorization data for a test user locally on the UNIX client. You add an account to the local /etc/passwd file and create a home directory for the user. You must set a password for the user's local account, but you will not use this password for logon. To avoid confusion during testing, this password must not match the Active Directory password for the same user; if the same password is used, it might be unclear during testing whether logon succeeds against Active Directory or locally.
To create test data for test01
Create test01 locally. Use the useradd command to create a local test user, test01:
# useradd -d /home/test01 –m -s /bin/csh test01
Note The /home/test01 directory and /bin/csh shell are examples for the user's home directory location and shell. In your environment, you might use a directory other than /home and a different shell.
Set password. Use the passwd command to set the local UNIX password for this user. Give the user a password different from that used for this test user in Active Directory:
# passwd test01
When prompted to provide a password, type a strong password, not a dictionary-based password. Typing a dictionary-based password returns a BAD PASSWORD message.
Confirm directory ownership. Use the ls command to confirm that the /home/test01 directory has been created and is owned by user test01:
# ls -ld /home/test01
Perform a Quick Verification Test as User test01
[Native OS] [Red Hat 9] [End States 1 and 2]
Confirm that a user can log on using Kerberos authentication against Active Directory. You can accomplish this by using a number of different logon methods, but the method that you use must be one that is currently configured for pam_krb5 authentication in the correct file in the pam.d directory. On some systems and with some configurations, Kerberized versions of services such as telnet might not make use of the PAM configurations defined here.
To verify logon for test01
Log on. Log on as test user test01 either at the console command-line of the UNIX-based computer or by using telnet (if telnetd is installed on the client computer). Use the password configured in Active Directory instead of the local password.
Note If you want to log on by using telnet, you might need to install and configure the telnetd service.
Confirm logon. Confirm that you are successfully logged on.
Note If logon fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."
Confirm TGT. Use the klist command, which lists currently held Kerberos tickets, to confirm that a Kerberos ticket-granting ticket (TGT) has been granted. Check to be sure that the ticket listed in the data returned by klist includes the correct user name and current date and time.
Milestone Complete: End State 1 (Red Hat 9, Native OS)
If your goal is to use Red Hat 9 and native OS components to deploy only End State 1, which enables your UNIX clients to use Active Directory Kerberos for authentication, stop here. The rest of the instructions in "Use Red Hat 9 with Native OS Components for End States 1 and 2" are for End State 2.
If you want to use Red Hat 9 and native OS components to deploy End State 2, continue with the procedures in the following section.
Procedures: End State 2 Only (Red Hat 9, Native OS)
If you want to expand your test lab using Red Hat 9 with native OS components to deploy End State 2 so that your development environment supports both Active Directory Kerberos and Active Directory LDAP, perform the procedures in this section after completing the procedures in "Procedures: End States 1 and 2 (Red Hat 9, Native OS)" in the preceding subsection.
Install the LDAP Client Tools
[Native OS] [Red Hat 9] [End State 2]
By default, LDAP client tools are not installed when you install Red Hat as described earlier in the subsection "Install and Configure Red Hat 9." You must copy the LDAP client package from the installation media and install it manually.
To install LDAP client tools
Copy package. Copy the openldap-clients-2.0.27-8.i386.rpm package from the Red Hat installation media (CD number 2) to a temporary directory on the UNIX-based computer.
Install package. Use the following command to install the LDAP client tools packages:
# rpm -i openldap-clients-2.0.27-8.i386.rpm
Note The extension rpm stand for RedHat Package Manager.
Configure the /etc/ldap.conf File
[Native OS] [Red Hat 9] [End State 2]
The /etc/ldap.conf file includes configuration items for many functions of OpenLDAP, but only a few of these configuration items are used for this end state. The sections of the ldap.conf file shown here represent a small fraction of the ldap.conf file and are the only sections of the sample file that you need to modify.
The items that you configure for this end state identify the server or servers to which LDAP requests are directed, the method by which the LDAP bind is accomplished, the mapping of UNIX authorization attributes to Windows attributes, and the container in which data for UNIX users and groups in Active Directory is found.
The LDAP bind—authentication to retrieve LDAP information—is done by using a proxy user. Because attributes for authorization data in UNIX have different names from those used by Windows Services for UNIX, you must create mappings to associate the UNIX names of certain attributes with the corresponding Windows names for these attributes.
Use the following steps to configure the LDAP client.
To configure /etc/ldap.conf
Note See Appendix I: "Sample Configuration Files for Custom Solutions" for the complete configuration file.
Back up file. Copy the existing /etc/ldap.conf file to ldap.conf.orig:
# cp /etc/ldap.conf /etc/ldap.conf.orig
Modify file. Modify the sections of the file shown below as follows (only modified sections of the file are shown here):
# Your LDAP server. Must be resolvable without using LDAP.
host server1.example.com
The distinguished name of the search base.
base dc=example,dc=com
Another way to specify your LDAP server is to provide an
uri with the server name. This allows to use
Unix Domain Sockets to connect to a local LDAP Server.
#uri ldap://127.0.0.1/ #uri ldaps://127.0.0.1/ #uri ldapi://%2fvar%2frun%2fldapi_sock/
Note: %2f encodes the '/' used as directory separator
uri ldap://adserver01.example.com/
The distinguished name to bind to the server with.
Optional: default is to bind anonymously.
binddn cn=proxyuser,cn=users,dc=example,dc=com
The credentials to bind with.
Optional: default is no credential.
bindpw Password1
The search scope.
scope sub #scope one #scope base
Search timelimit
timelimit 30
RFC2307bis naming contexts
Syntax:
nss_base_XXX base?scope?filter
where scope is {base,one,sub}
and filter is a filter to be &'d with the
default filter.
You can omit the suffix eg:
nss_base_passwd ou=People,
to append the default base DN but this
may incur a small performance impact.
nss_base_passwd ou=unix,dc=example,dc=com?sub nss_base_shadow ou=unix,dc=example,dc=com?sub nss_base_group ou=unix,dc=example,dc=com?sub #nss_base_passwd ou=People,dc=example,dc=com?one #nss_base_shadow ou=People,dc=example,dc=com?one #nss_base_group ou=Group,dc=example,dc=com?one #nss_base_hosts ou=Hosts,dc=example,dc=com?one #nss_base_services ou=Services,dc=example,dc=com?one #nss_base_networks ou=Networks,dc=example,dc=com?one #nss_base_protocols ou=Protocols,dc=example,dc=com?one #nss_base_rpc ou=Rpc,dc=example,dc=com?one #nss_base_ethers ou=Ethers,dc=example,dc=com?one #nss_base_netmasks ou=Networks,dc=example,dc=com?ne #nss_base_bootparams ou=Ethers,dc=example,dc=com?one #nss_base_aliases ou=Aliases,dc=example,dc=com?one #nss_base_netgroup ou=Netgroup,dc=example,dc=com?one
configure --enable-mssfu-schema is no longer supported.
For MSSFU now do:
nss_map_objectclass posixAccount User nss_map_objectclass shadowAccount User nss_map_objectclass posixGroup Group nss_map_attribute uid sAMAccountName nss_map_attribute uidNumber msSFU30UidNumber nss_map_attribute gidNumber msSFU30GidNumber nss_map_attribute loginShell msSFU30LoginShell nss_map_attribute uniqueMember msSFU30posixMember #nss_map_attribute userPassword msSFU30Password nss_map_attribute homeDirectory msSFU30HomeDirectory nss_map_attribute memberUid msSFU30MemberUid
**Note** The location of the LDAP server (the Active Directory server) can be specified either with a host entry or a uri entry. In the example, uri is used.Change ownership. Change the ownership on the /etc/ldap.conf file to nscd:
# chown nscd /etc/ldap.conf
Note The standard system user nscd is added during the operating system installation.
Specify permissions. Grant the ldap.conf file permissions of 600 (which makes a file readable and writable only by the owner, that is, by nscd):
# chmod 600 /etc/ldap.conf
Note The steps in this chapter were tested with chmod 600. Alternatively, you can use chmod 400 to make the LDAP configuration file (ldap.conf) readable but not writable.
Configure the /etc/nsswitch.conf File
[Native OS] [Red Hat 9] [End State 2]
The /etc/nsswitch.conf file is used to configure NSS for a broad range of data sources and many different functions. Much like a PAM configuration, the NSS configuration allows you to specify multiple stacked data sources for any given function.
Note See Appendix I: "Sample Configuration Files for Custom Solutions" for the complete configuration file.
Three sections are defined specifically for this end state:
passwd. Identifies the list of data sources from which user environment configuration data (for example, home directory or shell) is retrieved.
group. Identifies the list of data sources from which user group membership is retrieved.
hosts. Identifies the list of data sources from which name resolution data is retrieved.
For the passwd and group sections, both files (the local /etc/passwd and /etc/group files) and ldap (the Active Directory database) are defined. For the hosts section, both files (/etc/hosts) and dns (domain name system servers) are defined.
See Appendix A: "Architectural Overview of UNIX and Windows Authentication and Authorization" for more information about NSS and the nsswitch.conf file.
To configure /etc/nsswitch.conf
Back up file. Copy the existing /etc/nsswitch.conf file to /etc/nsswitch.conf.orig:
# cp /etc/nsswitch.conf file /etc/nsswitch.conf.orig
Modify entries. Modify the passwd and group entries in the nsswitch.conf file as follows:
passwd: files ldap [TRYAGAIN=continue]
group: files ldap [TRYAGAIN=continue]
Confirm files listed before DNS. Confirm that the /etc/nsswitch.conf file is still configured to use files first for name resolution (hosts) and then DNS. The hosts entry should match the following format:
hosts: files dns
Restart the NSCD Service
[Native OS] [Red Hat 9] [End State 2]
After each configuration change, you must restart the Name Service Caching Daemon (NSCD) service to allow the daemon to reread the configuration. The NSCD service caches LDAP data retrieved from Active Directory to reduce lookups for duplicate data. The NSCD service, which is required for functionality, can also help reduce network traffic.
To restart the NSCD service
Restart NSCD. Run the following command to restart the NSCD service:
# /etc/rc.d/init.d/nscd restart
Test LDAP Connectivity to the Active Directory Server
[Native OS] [Red Hat 9] [End State 2]
You can use one of the following commands to confirm that the UNIX host has LDAP connectivity to the Active Directory server. These commands confirm that your UNIX host can communicate via LDAP with your Active Directory server but do not validate the LDAP configuration steps completed to this point. Only a logon test can validate the LDAP configuration.
To test LDAP connectivity to Active Directory , run one of the following commands
You can use the ldapsearch command as follows to test your LDAP connection, where the command options are defined as described in the following table.
Table 4.16. Options for the ldapsearch Command
Here is the generic command: **Note:** The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks.Variable
Description
IPAddress
The IP address of your Active Directory server.
ProxyDN
The distinguished name of your LDAP proxy user.
Password1
The password of your LDAP proxy user.
BaseDN
The base distinguished name where your UNIX users and computers are stored (for example, ou=unix,dc=example,dc=com)
# ldapsearch –x -h IPAddress -D ProxyDN -w Password1 -b BaseDN -s sub '(cn=test*)'
For example: **Note:** The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks. <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml"># ldapsearch –x -h 10.9.8.1 -D cn=proxyuser,cn=users,dc=example,dc=com -wPassword1 –b ou=unix,dc=example,dc=com -s sub (cn=test*)'
If this command completes successfully, you see output that includes several attributes associated with each user (test\*) in Active Directory. The first line of returned data displays information similar to the following: <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">CN=test01,OU=Users,OU=UNIX,DC=example,DC=com</pre> If the command fails, the system displays an error message. **Note** If this command fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."You can use the ldapsearch command as follows to test your LDAP connection, where IPAddress is the IP address of your Active Directory server:
# ldapsearch –x -h IPAddress -s base -b "" "(objectclass=*)"
For example:
# ldapsearch –x -h 10.9.8.1 -s base -b "" "(objectclass=*)"
The output from the command should be similar to the following:
currentTime=20031217100255.0Z
subschemaSubentry=CN=Aggregate,CN=Schema,CN=Configuration,DC=example,DC=com [...]
**Note** If this command fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."Create Test User Data for User test02
[Native OS] [Red Hat 9] [End State 2]
At this point in the configuration process, you must test that configuration for Kerberos authentication and LDAP authorization at UNIX logon completed successfully. To log on to a UNIX client as an Active Directory user, you must create a home directory for the Active Directory user on each UNIX client. For correct functionality, the home directory must be owned by the test user. If the home directory does not exist or its ownership is incorrect, logon or some post-logon functions might fail.
For this test, do not create a local user account in /etc/passwd. If a local account exists for the same user name, it might be unclear at logon whether data was retrieved locally or from Active Directory.
To create test data for test02
Create directory. Create a home directory for user test02:
# mkdir /home/test02
Note The /home/test02 directory is an example location for the user's home directory. In your environment, a directory other than /home might be used.
Specify permissions. Give the directories correct user permissions:
# chown test02 test02
chgrp tstgrp01 test02
**Note** If the **chown** or **chgrp** command fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."Perform a Quick Verification Test as User test02
[Native OS] [Red Hat 9] [End State 2]
Confirm that a user can log on using Kerberos authentication and LDAP authorization against Active Directory. You can accomplish this by using a number of different logon methods, but the method you use must be one that is currently configured for pam_krb5 authentication in the correct file in the pam.d directory. On some systems and with some configurations, Kerberized versions of services such as telnet might not make use of the PAM configurations defined here.
After you log on, run the id and groups commands to confirm that the user's UID and GID are correctly mapped to the user's user name and primary group name and that a complete list of all groups of which the user is a member can be retrieved. If the output of the id command includes only the UID and GID numbers but not the user and group names in parentheses, or if the groups command returns no data or only one group, the test has failed.
To verify logon for test02
Log on. Log on either at the console command-line of the UNIX-based computer or by using telnet (if telnetd is installed on the client computer) as test user test02.
Note If you want to log on by using telnet, you might need to install and configure the telnetd service.
Confirm logon. Confirm that you are successfully logged on.
Note If logon fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."
Confirm id and group output. Confirm that the output of the id and group commands contains complete data, as illustrated in this example:
$ id
uid=10002(test02) gid=10001(tstgrp01)groups=10001(tstgrp01),10002(tstgrp02) $ groups tstgrp01 tstgrp02
**Note** If this test fails, refer to Appendix D: "Kerberos and LDAP Troubleshooting Tips."Milestone Complete: End State 2 (Red Hat 9, Native OS)
You have used native OS components and Red Hat 9 to deploy End State 2, which enables your UNIX clients to use Active Directory Kerberos for authentication and Active Directory LDAP for authorization. If this is the only solution in which you are interested, stop here.
If you want to try one or more of the other solutions developed in this chapter, continue to the next solution that you want to deploy in your development environment. For a list showing each of the available solutions, see "Chapter Map" earlier in this chapter.
Developing the Solution Using Open Source Software
Open source solutions add open source Kerberos and LDAP components as well as free tools to the existing base operating system. In order to deploy an open source solution, you must know how to install and, in some cases, compile and build third-party software.
With an End State 1 open source solution, you use the native OS Kerberos tools such as kinit, klist, kdestroy, and kpasswd, whereas with an End State 2 open source solution you can use either the native OS Kerberos tools or the Kerberos tools built during the nss_ldap (authorization) build process.
The following sections provide detailed steps for deploying these open source solutions in your development environment:
“Use Solaris 9 with Open Source Components for End States 1 and 2”
“Use Red Hat 9 with Open Source Components for End States 1 and 2”
When you develop an open source solution, remember the following:
Make sure that you install only open source components (not commercial components such as Centrify DirectControl or Quest Software Vintela Authentication Services (VAS). If you mix different components together on the same computer in your development lab, some of the default behavior described in the following procedures might not occur as expected.
You must run all system configuration steps on UNIX-based computers as root user unless otherwise specified.
In an open source solution, you might need to specify the path for UNIX tools, depending on where the tools are stored. If you do experience any problems, be sure to specify the full path.
Use Solaris 9 with Open Source Components for End States 1 and 2
The open source solution on Solaris can meet the needs of many organizations. This solution provides the basic UNIX functionality that users expect but also adds Active Directory authentication or consolidates both authentication and authorization data in Active Directory.
The open source solution for Solaris offers several additional features that the native Solaris solution lacks, including:
Warnings to the user that the user's password will expire in n days.
Specific error messages to the user explaining why a logon failed.
For End State 2, the option to use Kerberos to secure the LDAP connection to Active Directory data when retrieving authorization data. Depending on the environment, this can help reduce network load and processor load on the domain controllers (the Active Directory servers).
Unlike the native OS solutions, there is little difference in functionality between the Solaris 9 and Red Hat 9 open source solutions. Configuration and deployment steps are essentially the same for both operating systems (although different binaries are used). In addition, it might be possible to extend the open source solution to operating system platforms not included in this chapter.
If you want to use Solaris 9 with open source components to deploy End State 1 or to deploy End State 2, use the procedures as indicated in the following table.
Table 4.17. Which Procedures in This Section Are Appropriate for Your Open Source Solaris Solution?
Solution
Do These Procedures
End State 1
Procedures: End States 1 and 2 (Solaris 9, Open Source)
End State 2
Procedures: End States 1 and 2 (Solaris 9, Open Source)
–and–
Procedures: End State 2 Only (Solaris 9, Open Source)
For procedures to implement solutions other than open source Solaris, see the following sections:
“Use Solaris 9 with Native OS Components for End States 1 and 2”
“Use Red Hat 9 with Native OS Components for End States 1 and 2”
“Use Red Hat 9 with Open Source Components for Ends States 1 and 2”
Procedures: End States 1 and 2 (Solaris 9, Open Source)
If you want to set up a proof-of-concept development lab using Solaris 9 with open source components to deploy End State 1 or 2, use the procedures in this subsection.
Install and Configure Solaris 9
[Open Source] [Solaris 9] [End States 1 and 2]
Although it is possible to implement the solution described in these steps on a preinstalled Solaris 9 client, the environment on such a client might be different from that assumed for these steps. Starting with a clean install ensures that no preexisting software or configuration will interfere with the solution—this is especially important if you want to test more than one of the custom solutions described in this chapter. The packaged solutions, for instance, might install components that conflict with the open source (or native OS) functionality.
The steps for installing and configuring Solaris for your environment typically differ from the steps described here. The configurations described here are the minimum necessary to implement the solution: configuring DNS, installing Kerberos, and—for End State 2 only—installing LDAP-related patches. These steps are required. Other configuration steps normally done in your environment are optional; some (for example, configuring NIS or NIS+) might conflict with the solution described here.
The core of the open source solution (pam_krb5 and nss_ldap) does not make use of the native Kerberos or LDAP. However, you can use native Kerberos and LDAP tools, such as kinit and ldapsearch, for testing, so installation of native Kerberos and LDAP patches is recommended.
If you follow the instructions provided in the following procedure, the native Kerberos client tools are automatically installed and a sample Kerberos configuration is created. You can confirm this after the installation completes by verifying that the Kerberos client tools, such as kinit, klist, and kdestroy, are located in /usr/bin/.
Note For more information about how to install Solaris 9, see "Solaris 9 9/04 Installation Guide" in the "Solaris 9 9/05 Release and Installation Collection" at https://docs.sun.com/app/docs/doc/817-5768.
To install and configure Solaris
Install OS. On the UNIX host, install Solaris version 9. Users who have never installed Solaris might find it simplest to use the Default Install option, which offers an installation wizard similar to that used for a Windows install. During the install, you need to choose a nondefault selection only in the following case:
On the Kerberos page of the installation wizard, select Yes to enable (configure) Kerberos.
Note If you select No (the default selection), the installation process still installs Kerberos but does not configure it. In this case, after installing and configuring Solaris, you must manually edit the sample Kerberos configuration file, krb5.conf, to enter the correct information for your environment. See "Configure the Kerberos Client" later in this section for information about configuring Kerberos and the krb5.conf file.
Configure options. After the Solaris installation completes, set the following configuration options:
Include FQDN. Modify the /etc/hosts file to contain the FQDN of the UNIX client followed by the short name.
Note Although, in a production environment, a client computer typically uses a dynamic DNS address, assigning the example UNIX client, unix01, a static IP address in a lab environment when you initially develop the solution eliminates one variable from your test environment.
For example:
10.9.8.12 unix01.example.com unix01
Specify files before DNS. Modify the /etc/nsswitch.conf file to use files first for name resolution (hosts) and then to use DNS. The hosts entry should match the following format:
hosts: files dns
Point to Windows DNS server. Configure the /etc/resolv.conf file to point to the Windows server for DNS. For example:
domain example.com
nameserver IPaddress1 nameserver IPaddress2
where example.com* *is the name of your test domain, and *IPAddress1* and *IPAddress2* are the IP addresses of your DNS servers. (In this test environment, the DNS servers are your Windows domain controllers.) **Note** See Appendix I: "Sample Configuration Files for Custom Solutions" for the complete configuration file.Identify which patches to install. The core of the open source solution (pam_krb5 and nss_ldap) does not make any use of the native Kerberos or (for End State 2 only) LDAP. However, the native Kerberos client tools (such as kinit, klist, and kdestroy) and native LDAP tools (such as ldapsearch) are used in the quick verification tests described later in this section, so installation of the native Kerberos patches and (for End State 2 only) the LDAP patch listed in the following table is recommended.
Note You should install the latest versions of Kerberos patches (for both End States 1 and 2 solutions) and the latest LDAP patches (for End State 2 solutions). You might be able to install the entire patch cluster for Solaris 9 instead of installing individual patches. Patches shown in the table are current as of the publication of this document but might not be the latest version at the time you install the patches.
Table 4. 18. Kerberos and LDAP Patches
End State
Patches
[End States 1 and 2]
Kerberos patches. At minimum, you should install Kerberos patches. Currently, the following Kerberos patches relevant for this solution are available:
Patch-ID# 112908-23. SunOS 5.9: krb5 shared object patch
Patch-ID# 112922-02. SunOS 5.9: krb5 lib patch
Patch-ID# 112923-03. SunOS 5.9: krb5 usr/lib patch
Note Other Kerberos patches are also available but are not needed for this solution.
Prerequisite patches. In addition, you might need other patches that are required for correct functionality of the patches in this list. Which additional patches you might need (if any) vary depending on your current system configuration.
[End State 2 Only]
LDAP patch. Currently, the following LDAP patch relevant for this solution is available:
Patch-ID# 112960-32. SunOS 5.9: patch libsldap ldap_cachemgr libldap.
Note Other LDAP patches are also available but are not needed for this solution.
Prerequisite patches. In addition, you might need other patches that are required for correct functionality of this patch. Which additional patches you might need (if any) vary depending on your current system configuration.
Determine if a patch is already installed:
Navigation Note If you plan to install the entire patch cluster, skip this step and go directly to step 5. Download and install latest Solaris patch cluster, or install individual patches (or both).
Use patchadd or showrev to investigate existing patches. Use either of the following commands (where xxxxxx is the patch number) to determine whether a patch is already installed and whether it is the latest revision of the patch available:
# /usr/sbin/patchadd -p | grep xxxxxx
– or –
# /usr/bin/showrev -p | grep xxxxxx
Note Omit any suffixes to the patch number in this command. For example, to check for versions of patch 112396-02, enter only 112396.
Either command produces results as shown in the following table.
Table 4.19. Output Varies Depending on Whether a Patch Is Installed
Result
Description
Output if a patch is already installed
If a patch that matches the number entered is installed, information about this patch and any related patches is returned. You should see output similar to the following:
Patch: 112908-04 Obsoletes: 112726-03
Requires: 112907-01 Incompatibles: Packages: SUNWcar SUNWcarx SUNWgssk SUNWgsskx SUNWkrbu SUNWkrbux
Note: The command line above has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks.
This output indicates that revision 04 of patch 112908 is installed.
No patch—no output
If no patch that matches the number that you specify is installed, no message appears and you are returned to the command prompt.
2. **Navigate to Sun site.** You can find the Sun Update Connection – Patches and Updates page at <https://sunsolve.sun.com/pub-cgi/show.pl?target=patchpage>. 3. **Determine whether additional patches need to be installed.** Use the **PatchFinder** tool on the Sun Update Connection – Patches and Updates page to find the latest version of each of the Kerberos and—for End State 2 only—LDAP patches identified earlier (in Table 4.9, "Kerberos and LDAP Patches") and compare that to the installed version on your computer, if any.Download and install latest Solaris patch cluster , or install individual patches (or both):
Decide what to install. Determine if you will install only the patch cluster, install only individual patches, or install the patch cluster and then individual patches:
Install only individual patches? Choose this option if UNIX policy, change management rules, or some other restriction in your organization requires that you do not install the patch cluster.
Install only the patch cluster? Choose this option if you are not restricted from installing the patch cluster and if all of the patches listed earlier (in Table 4.18, "Kerberos and LDAP Patches") are included in the cluster.
Install the patch cluster and then individual patches? Choose this option if you are not restricted from installing the patch cluster, but one or more of the patches listed earlier (in Table 4.18, "Kerberos and LDAP Patches") are not included in the cluster.
Depending on your answers to the preceding questions, download and then install patches as described in the following steps.
Download patches. Use the appropriate method or methods to download patches as described in the following table.
Table 4.20. How to Download Patches
Download Method
Action
Download patch cluster
Download the latest Solaris 9 recommended patch cluster:
Go to the Sun Update Connection – Patches and Updates page at https://sunsolve.sun.com/pub-cgi/show.pl?target=patchpage.
On this page, under Recommended and Security Patches, click Recommended Patch Clusters.
Under Recommended Solaris Patch Clusters, click the appropriate Solaris 9 package for your environment, click Readme, and then click Go to open the CLUSTER_README file.
Review the CLUSTER_README file to confirm that the patch cluster contains the required Kerberos and—for End State 2 only—LDAP patches (see Table 4.18, "Kerberos and LDAP Patches" earlier in this section).
On the Sun Update Connection – Patches and Updates page under Recommended Solaris Patch Clusters, click the appropriate Solaris 9 package for your environment, click Download HTTP or Download FTP, and then click Go to download the patch cluster.
If the patch cluster is missing one or more of the required patches, download them individually using the steps in the next row, "Download individual patches and prerequisites."
Download individual patches and prerequisites
Download the individual Kerberos and—for End State 2 only—LDAP patches identified in the previous steps:
Go to the Sun Update Connection – Patches and Updates page at https://sunsolve.sun.com/pub-cgi/show.pl?target=patchpage.
On this page, under PatchFinder, search for each individual patch.
Read the patch information page for each patch and determine whether the patch requires additional patches for correct functionality (the "Required Patches" section) or has any special installation instructions (the "Special Install Instructions" section).
Download each patch and any additional required patches identified in each patch's patch information page.
Additional patches that you might need vary depending on your current system configuration.
Install patches. Use the appropriate method or methods to install patches as described in the following table.
Table 4.21. How to Install Patches
4. **Restart.** After you complete installing patches, restart the UNIX host.Install Method
Action
Install patch cluster
Follow the instructions in the CLUSTER_README file to install the Solaris 9 patch cluster.
Install patches individually or in groups
On the UNIX host, open a shell, and then use one of the following commands:
To install individual patches. To install patches individually (where patch is the directory name for each individual patch—for example: 112396-02), type:
# /usr/sbin/patchadd /path/patch
To install multiple patches. To install several patches together (where patchlist is a file that contains a list of all patches to be installed), type:
# /usr/sbin/patchadd -M /path/patchlist
For more information about using patchlist files, see the Solaris documentation.
Note If you want to find out if a patch is already installed before you run this command, see the earlier step "Determine if a patch is already installed."
Install Kerberos Tools
[Open Source] [Solaris 9] [End States 1 and 2]
In this section, you download and install the following Kerberos tools:
css_adkadmin. You can use the Certified Security Solutions (CSS) Active Directory Kerberos administration tool (called ADKadmin or css_adkadmin) to assist in the configuration of any solution described in this chapter, including the open source Solaris solution described in this section. The css_adkadmin tool provides functionality similar to that of the MIT kadmin tool. This tool simplifies deployment and management of UNIX-based computers that are configured to use Active Directory as their authentication or authorization data source. You can use css_adkadmin to manage and view Active Directory user and computer accounts from a UNIX or Linux host.
CAUTION Before you install and use the css_adkadmin tool for this solution, read the "Known Issues" section in the CSS readme file. To ensure that you obtain the latest version of the readme file, start at the Certified Security Solutions page at https://www.css-security.com, click Downloads, click ADKadmin vn.n (for example, ADKadmin v2.2), select Yes twice to agree to the CSS download conditions, click Submit, and then click ADKadmin Utility README to open the readme file.
pam_krb5. The CSS pam_krb5 tool provides functionality that enhances the user logon experience by providing warnings to a user that the user's password will expire in n days and by providing specific error messages to a user when the user's logon fails because the Active Directory account is expired or locked out.
For more information about the css_adkadmin and pam_krb5 tools, see Appendix E: "Relevant Windows and UNIX Tools."
To install the css_adkadmin and pam_krb5 tools
Install css_adkadmin. Install the Certified Security Solutions css_adkadmin package:
Download the css_adkadmin tool, which is available free from the CSS Tools and Downloads page at https://www.css-security.com/downloads.html.
Copy the CSS css_adkadmin installation package to a temporary directory on the UNIX-based computer.
Untar the files:
# uncompress css_adkadmin-2.2_solaris.tar.Z
tar -xf css_adkadmin-2.2_solaris.tar
**Note** The **tar** command creates and adds a set of files to an archive file in tar format. Originally, a tar archive was stored solely on a magnetic tape (tar is short for "tape archive"), but currently **tar** can use other formats to create an archive, such as a floppy disk or a hard disk file. The **untar** command restores (unpacks) the files from the archive. 4. Run the **install.sh** script to install **css\_adkadmin**. 5. Review the README file.Install pam_krb5. Install the Certified Security Solutions pam_krb5 package:
Download the pam_krb5 tool, which is available free from the CSS Tools and Downloads page at https://www.css-security.com/downloads.html.
Copy the CSS pam_krb5 installation package to a temporary directory on the UNIX-based computer.
Untar the files:
# uncompress pam_krb5-1.60.1-css_solaris.tar.Z
tar -xf pam_krb5-1.60.1-css_solaris.tar
4. Run the **install.sh** script to install **pam\_krb5**. 5. Review the README file.Configure the Kerberos Client
[Open Source] [Solaris 9] [End States 1 and 2]
You configure Kerberos client functionality on a UNIX client in the krb5.conf file. This file identifies the REALM of the Kerberos environment, the security servers (KDCs) to which authentication requests will be directed, the administrative and password servers (typically, these servers are the same as the KDCs) to which administrative and password change requests will be directed, and the DNS domain name for the environment. In Windows, the REALM name is the uppercase equivalent of the DNS domain name. In other UNIX environments, using the uppercase name is the convention but is not required. In addition to these standard settings in the krb5.conf file, there are Active Directory–specific settings: the encryption type (because Active Directory does not support all of the encryption types that the UNIX client supports) and password change settings.
The standard Solaris installation process creates a sample file. If you chose to configure Kerberos during the Solaris install, this file will be partially configured for you. However, you must manually add the krb5.conf settings that are specific to Active Directory interoperability.
Kerberos functions are time sensitive to provide added security. This is done, in part, to prevent replay attacks. By default, the time on all Kerberos clients and the Active Directory servers must be within 5 minutes of one another. Because clocks on computers can drift, the best practice is to implement Network Time Protocol (NTP) to maintain synchronization instead of attempting to manually synchronize computers. If the clocks on your client and server drift out of sync, Kerberos functions will begin to fail. Because some functions rely on credentials acquired earlier, these failures might not appear immediately after the clocks go out of sync. It is possible that, for a time, some Kerberos functions fail while others continue to work, which can confuse troubleshooting efforts.
To configure the Kerberos client
Synchronize clocks. Confirm that the clocks on your Active Directory server and UNIX clients are synchronized as described earlier in this chapter in the subsection "Synchronize Time" in "Prepare Your Environment." Kerberos requires that the clocks on all computers in the Kerberos environment be synchronized to within 5 minutes of one another.
Modify file. Modify the sample configuration located in the /etc/krb5.conf file to contain the following entries, where EXAMPLE.COM is the REALM name for your Active Directory server, kdc1.example.com and kdc2.example.com are the FQDNs of your Active Directory servers, and .example.com is the DNS domain name of your Active Directory server:
Note Configuration entries for the krb5.conf file vary by operating system. Those shown here are correct for Solaris 9. On Solaris 9, a sample krb5.conf file is created when the Kerberos client is installed. (See Appendix I: "Sample Configuration Files for Custom Solutions" for the complete configuration file.)
[libdefaults]
default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false default_tkt_enctypes = des-cbc-md5 des-cbc-crc default_tgs_enctypes = des-cbc-md5 des-cbc-crc [realms] EXAMPLE.COM = { kdc = kdc1.example.com:88 kdc = kdc2.example.com:88 admin_server = kdc1.example.com:749 kpasswd_server = kdc1.example.com:464 kpasswd_protocol = SET_CHANGE default_domain = example.com } [domain_realm] *.example.com = EXAMPLE.COM .example.com = EXAMPLE.COM
**Note** The remainder of the sample file is not shown here because it does not require modification. **Note** This guide provides instructions for configuring the solution to use the DES-MD5 and/or DES-CRC encryption types. Recent versions of the open source tools described here also support the standard Windows RC4-HMAC encryption type. However, the native Kerberos client tools such as **kinit** and Kerberized versions of services such as **telnetd** and **ftpd** do not support RC4-HMAC. If you choose to configure the solution with RC4-HMAC support, change the following lines to add RC4-HMAC as a valid encryption type: default\_tkt\_enctypes = rc4-hmac des-cbc-md5 des-cbc-crc default\_tgs\_enctypes = rc4-hmac des-cbc-md5 des-cbc-crc Some native Kerberos client tools and services might not function correctly when the krb5.conf file is configured in this way. **Note** Installing **css\_adkadmin** modifies the krb5.conf to add the following entry to the libdefaults stanza: default\_keytab\_name = FILE:/etc/krb5/krb5.keytab For more information about krb5.conf files, see: - The Solaris **man** page for "krb5.conf." - The *Sun Enterprise Authentication Mechanism 1.0.2 Guide* at <https://docs.sun.com/app/docs/doc/816-5164>. - The SEAM sections of *System Administration Guide: Security Services* at <https://docs.sun.com/app/docs/doc/806-4078>.Create a Service Key Table
[Open Source] [Solaris 9] [End States 1 and 2]
A key table file that contains the key for the UNIX-based computer account in Active Directory is required for both End States 1 and 2 for pam_krb5 authentication to occur. This key table is also used by servers that provide Kerberized services, such as an FTP or telnet server.
To create a Kerberos service key table
Create key table on UNIX host. Run the following command to create a key table on the UNIX host, where fqdn is the fully qualified domain name of the UNIX host, Administrator is a principal (user account) in the Active Directory database with sufficient permissions to add, modify, and delete users and computers from the database, and BaseDN is the base distinguished name for the Active Directory container holding the UNIX-based computer accounts:
css_adkadmin -p Administrator -q "ank +use_des -group BaseDN -k host/fqdn"
For example: **Note:** The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks. <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">css_adkadmin -p Administrator1 -q "ank +use_des -group ou=computers,
ou=unix,dc=example,dc=com -k host/unix01.example.com"
**Note** This guide provides instructions for configuring the solution to use the DES-MD5 and/or DES-CRC encryption types. Recent versions of the open source tools described here also support the standard Windows RC4-HMAC encryption type. However, the native Kerberos client tools such as **kinit** and Kerberized versions of services such as **telnetd** and **ftpd** do not support RC4-HMAC. If you choose to configure the solution with RC4-HMAC support, omit the switch **+use\_des** from this command. When the key table is created with the RC4-HMAC encryption type, it will not function correctly with native Kerberized client tools and services. **Note** For more information about the **css\_adkadmin** tool, see "Install Kerberos Tools" earlier in this section and see Appendix E: "Relevant Windows and UNIX Tools."Perform a Quick Kerberos Configuration Verification Test
[Open Source] [Solaris 9] [End States 1 and 2]
Implementing the solution requires several steps, many of which assume successful completion of earlier steps. It is important to stop periodically and test the configuration completed to that point to confirm that it is correct before moving forward.
You can use the Kerberos client kinit tool to confirm that the krb5.conf file is configured correctly and that DNS is working correctly in your environment. You can use the Kerberos client klist tool to view the contents of the key table that you created to see whether the correct account is present.
The basic tests provided here do not test every possible function in Kerberos. Therefore, even if these tests complete successfully, you might still encounter Kerberos configuration problems that cause problems in subsequent steps. Potential problems include:
Subtle DNS configuration problems. Requests for service tickets are sensitive to DNS configuration problems. A service ticket might fail as a result of a DNS problem even if an initial ticket-granting ticket (TGT) request made by using kinit succeeds. A service ticket request is made as part of the logon process.
Clock skew problems. Requests for service tickets are sensitive to clock skew problems.
Bad key tables. The key table is used only during the logon process. The test presented here confirms that the key table exists but not that the key table is valid for logon.
For more information about testing Kerberos configuration and troubleshooting Kerberos problems, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."
To verify Kerberos configuration
Get Kerberos ticket. Use the kinit command to acquire a Kerberos ticket for a test user. For example, to acquire a ticket for test01, type:
$ kinit test01
Note In an open source solution, you might need to specify the path for UNIX commands or add their directories to the PATH variable because the commands are not stored by default in a specific directory. You can use either the native versions of these tools or the open source versions for testing. However, if you have configured an encryption type that is not supported by the native versions of the tools, the commands might fail.
If the command completes successfully, no message appears and the user is returned to the command prompt. A message appears only if an error occurs.
View Kerberos ticket. Use the klist command to view the ticket just acquired for test01. Type:
$ klist
This command returns output similar to the following:
Note: Some of the lines in the following code have been displayed on multiple lines for better readability.
Ticket cache: /tmp/krb5cc_500
Default principal: test01@EXAMPLE.COM Valid starting Expires Service principal THU 10 Aug 2006 10:36:15 AM PDT THU 10 Aug 2006 08:36:15 PM PDT krbtgt/EXAMPLE.COM@EXAMPLE.COM renew until THU 17 Aug 2006 10:36:15 AM PDT
**Note** If these commands fail, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."Confirm keytab data. Use the klist -k command to confirm that the key table contains correct data:
# klist –k
This command returns output similar to the following:
Keytab name: FILE:/etc/krb5/krb5.keytab
KVNO Principal
2 host/unix01.example.com@EXAMPLE.COM
Configure /etc/pam.conf for Kerberos Authentication
[Open Source] [Solaris 9] [End States 1 and 2]
The pluggable authentication module (PAM) is used to control authentication on UNIX-based computers. On Solaris, PAM is configured with the /etc/pam.conf file.
Note See Appendix I: "Sample Configuration Files for Custom Solutions" for the complete configuration file.
Each line in pam.conf defines a service type (for example, authentication or password change) and a module to be used for this process (for example, pam_unix or pam_krb5). Multiple modules can be associated with each service type. To provide for logon through Kerberos, you must add entries to the pam.conf file to identify the pam_krb5 module as a valid authentication mechanism. Because not all users will have accounts in Active Directory (for example, the UNIX root user does not have an Active Directory account), you must enable such users to log on. This is done with PAM stacking rules.
In this case, the pam_krb5 modules are placed before the pam_unix modules and set to "sufficient." This specifies that, when a user logs on, a test for Kerberos authentication is performed first. If the user passes this test (the user exists in Active Directory and provides the correct Active Directory password), the user is allowed to log on. If the user fails this test, a test for local authentication is performed. If the user passes this test (the user exists in the local /etc/passwd file and provides the correct local password), the user is allowed to log on. All other users are denied access.
CAUTION Perform each step in this section carefully, and then check all pam.conf configurations before proceeding. Incorrectly configuring the pam.conf file or failing to apply the appropriate patches can lead to a state in which no user, including root, can log on (see the Note about configuring failsafe root access in the following procedure).
For more information about PAM and the pam.conf file, see Appendix A: "Architectural Overview of UNIX and Windows Authentication and Authorization."
To configure /etc/pam.conf for Kerberos authentication
Back up file. Copy the existing /etc/pam.conf file to /etc/pam.conf.orig:
# cp /etc/pam.conf /etc/pam.conf.orig
Modify Authentication management. Modify the Authentication management section of the pam.conf file as follows:
# Authentication management
login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth sufficient pam_krb5.so use_first_pass login auth required pam_unix_auth.so.1 login auth required pam_dial_auth.so.1
dtlogin (explicit to allow for separate control during
testing)
dtlogin auth requisite pam_authtok_get.so.1 #dtlogin auth sufficient pam_krb5.so use_first_pass dtlogin auth required pam_unix_auth.so.1
su (explicit to provide failsafe root access during testing)
su auth requisite pam_authtok_get.so.1 su auth required pam_unix_auth.so.1
rlogin service (explicit because of pam_rhost_auth)
rlogin auth sufficient pam_rhosts_auth.so.1 rlogin auth requisite pam_authtok_get.so.1 rlogin auth required pam_dhkeys.so.1 #rlogin auth sufficient pam_krb5.so use_first_pass rlogin auth required pam_unix_auth.so.1
rsh service (explicit because of pam_rhost_auth,
and pam_unix_auth for meaningful pam_setcred)
rsh auth sufficient pam_rhosts_auth.so.1 rsh auth required pam_unix_auth.so.1
PPP service (explicit because of pam_dial_auth)
ppp auth requisite pam_authtok_get.so.1 ppp auth required pam_dhkeys.so.1 ppp auth required pam_unix_auth.so.1 ppp auth required pam_dial_auth.so.1
Default definitions for Authentication management.
Used when service name is not explicitly mentioned for
authentication
other auth requisite pam_authtok_get.so.1 other auth required pam_dhkeys.so.1 other auth sufficient pam_krb5.so use_first_pass other auth required pam_unix_auth.so.1
End of code for this step.
**Note** In the preceding code, you can see that a section for the superuser (**su**) is added to the pam.conf file and configured to use pam\_unix to provide a failsafe root access method. Later, if you want to use Kerberos authentication for **su**, consider using **ksu** (Kerberized **su**) instead. During initial testing, you might want to comment out the following pam\_krb5 entries for **dtlogin**, if you have GUI console access, and **rlogin** to provide logon options that do not use pam\_krb5: <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">dtlogin auth sufficient pam_krb5.so use_first_passrlogin auth sufficient pam_krb5.so use_first_pass
Commenting out these entries is a safety precaution to ensure continued access to the UNIX client while you troubleshoot any configuration issues. After pam\_krb5 authentication is functioning correctly, you can uncomment the pam\_krb5 entries in the dtlogin and rlogin sections of the pam.conf file. For optimal security, we recommend that you configure computers to use the Kerberized versions of **telnetd**, **ftpd**, **krlogind**, and other remote tools (Kerberized versions of these tools are part of the Sun SEAM package). When you use Kerberized versions of **telnetd**, **ftpd**, **krlogind**, or other remote tools, the pam\_krb5 entries in the pam.conf file might not be used, depending upon configuration. For more information about using Kerberized versions of these services, see: - The *Sun Enterprise Authentication Mechanism 1.0.2 Guide* at <https://docs.sun.com/app/docs/doc/816-5164>. - The SEAM sections of the *System Administration Guide: Security Services* at <https://docs.sun.com/app/docs/doc/806-4078>.Modify Account management. Modify the Account management section of the pam.conf file as follows:
Note See Appendix I: "Sample Configuration Files for Custom Solutions" for the complete configuration file.
#
Default definition for Account management
Used when service name is not explicitly mentioned for
account management
other account requisite pam_roles.so.1 other account required pam_projects.so.1 other account sufficient pam_krb5.so other account required pam_unix_account.so.1
Modify Password management (optional—not recommended in pam.conf). It is also possible to modify the Password management section of the pam.conf file to enable Kerberos password change for the UNIX passwd tool. However, configuring the Password management section of pam.conf might cause the password change process to prompt repeatedly for the new password.
Instead, we recommend:
Use the UNIX Kerberos kpasswd tool for Kerberos password changes.
Use the UNIX passwd tool for local password changes.
Create Test User Data for User test01
[Open Source] [Solaris 9] [End States 1 and 2]
At this point in the configuration process, you must test that configuration for Kerberos authentication when a user logs on to UNIX is successful. To log on to a UNIX client, a user must have both authentication data and authorization data. Because you have not yet configured the client to use Active Directory (End State 2 only) or another data store for authorization data, for this test, you create a local user account to provide authorization data for a test user locally on the UNIX client. You add an account to the local /etc/passwd file and create a home directory for the user. You must set a password for the user's local account, but you will not use this password for logon. To avoid confusion during testing, this password must not match the Active Directory password for the same user; if the same password is used, it might be unclear during testing whether logon succeeds against Active Directory or locally.
To create test data for test01
Create test01 locally. Use the useradd command to create a local test user, test01:
# useradd -d /home/test01 –m -s /bin/csh test01
Note The /home/test01 directory and /bin/csh shell are examples for the user's home directory location and shell. In your environment, you might use a directory other than /home and a different shell.
Set password. Use the passwd command to set the local UNIX password for this user. Give the user a password different from that used for this test user in Active Directory:
# passwd test01
When prompted to provide a password, type a strong password, not a dictionary-based password. Typing a dictionary-based password returns a BAD PASSWORD message.
Confirm directory ownership. Use the ls command to confirm that the /home/test01 directory has been created and is owned by user test01:
# ls -ld /home/test01
Perform a Quick Verification Test as User test01
[Open Source] [Solaris 9] [End States 1 and 2]
Confirm that a user can log on using Kerberos authentication against Active Directory. You can accomplish this by using a number of different logon methods, but the method that you use must be one that is currently configured for pam_krb5 authentication in the pam.conf file. If you provided for failsafe root access by commenting out the pam_krb5 entries for rlogin or dtlogin, you cannot use those logon methods for testing. On some systems and with some configurations, ssh or Kerberized versions of services, such as telnet, might not make use of the pam.conf configurations defined here.
To verify logon for test01
Log on. Log on as test user test01 either at the console command-line of the UNIX-based computer or by using telnet (if telnetd is installed on the client computer). Use the password configured in Active Directory instead of the local password.
Note If you want to log on by using telnet, you might need to install and configure the telnetd service.
Confirm logon. Confirm that you are successfully logged on.
Note If logon fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."
Confirm TGT. Use the klist command, which lists currently held Kerberos tickets, to confirm that a Kerberos ticket-granting ticket (TGT) has been granted. Check to be sure that the ticket listed in the data returned by klist includes the correct user name and current date and time.
Milestone Complete: End State 1 (Solaris 9, Open Source)
If your goal is to use Solaris 9 with native OS features and open source components to deploy only End State 1, which enables your UNIX clients to use Active Directory Kerberos for authentication, stop here. The rest of the instructions in "Use Solaris 9 with Open Source Components for End States 1 and 2" are for End State 2.
If you want to use Solaris 9 with open source components to deploy End State 2, continue with the procedures in the following section.
Procedures: End State 2 Only (Solaris 9, Open Source)
If you want to expand your test lab using Solaris 9 with open source components to deploy End State 2 so that your development environment supports both Active Directory Kerberos and Active Directory LDAP, perform the procedures in this section after completing the procedures in "Procedures: End States 1 and 2 (Solaris 9, Open Source)" in the preceding subsection.
Build and Install LDAP Tools
[Open Source] [Solaris 9] [End State 2]
For this end state, the Solaris client is configured to use LDAP to retrieve authorization data for Active Directory users. This solution uses the OpenLDAP nss_ldap module so you must download and build the source code for this module. Although the goal is to create one module, several packages upon which the module is dependent—including the MIT Kerberos and Cyrus SASL packages that provide Kerberos authentication for the LDAP bind to Active Directory—must be built before building the final nss_ldap module.
The steps provided here for the Solaris open source solution to download and install prebuilt packages let you create a development environment in which to build the tools. If you have an existing development environment for Solaris, you might be able to build OpenLDAP and its package dependencies in your preexisting environment. However, the build steps provided here might not be correct for that environment.
Specific package versions are identified here because build instructions and product behavior varies from version to version for these products. New versions of some of these packages are released frequently, so the versions available to you will likely be more recent than the ones identified here. You might choose to implement the solution with more recent versions of the products, but be aware that the build instructions provided here might not be correct for more recent versions and that the configuration steps given might vary from those needed for more recent versions. It is possible that more recent versions of some packages might introduce changes that make the solution described here unusable. Therefore, we recommend that you implement the solution by using the exact packages described here for your first test. After that, you might choose to try newer versions of packages.
To build and install LDAP tools for the open source Solaris solution
Download packages. Download the software packages required to create an LDAP client with Kerberos authentication:
Download the following software packages from Sunfreeware at https://www.sunfreeware.com/:
The installation package (not the source code) for the 3.80 version of make, make-3.80-sol9-sparc-local.gz
The small installation package (not the source code) for the 3.4.2 version of gcc, gcc_small-3.4.2-sol9-sparc-local.gz
The installation package (not the source code) for the 1.8 version of libiconv, libiconv-1.8-sol9-sparc-local.gz
Download the 1.3.5 version of the MIT Kerberos open source package, krb5-1.3.5.tar, from Kerberos V5 Release 1.3 Source Distributions at https://web.mit.edu/kerberos/dist/historic.html#krb5-1.3-src. (If the link does not open when you click it, copy it into your browser.)
Note The configuration described here is not directly compatible with 1.4.x versions of MIT Kerberos and will need some modification to work with that version of the software.
Download the 2.1.19 version of cyrus-sasl from Download Cyrus Software at https://asg.web.cmu.edu/cyrus/download/.
The Cyrus Simple Authentication and Security Layer (SASL) package uses a Kerberos provider to authenticate and encrypt the LDAP connection.
Download the 4.2.52 version of Berkeley DB, db-4.2.52.tar.gz, and any recommended patches, from Sleepycat Software Developer Zone at https://www.sleepycat.com/download/.
Download the 2.2.17 version of openldap, openldap-2.2.17.tgz, from OpenLDAP Download at https://www.openldap.org/software/download/ (in the section "Other OpenLDAP Releases")
Download the 220 version of nss_ldap, nss_ldap-220.tar.gz, from the PADL Index of /download site at https://www.padl.com/download/.
Prepare downloaded files. Prepare to install the software packages that you just downloaded by performing the following steps:
Untar (unpack) and/or gunzip (uncompress) each downloaded file to a temporary working directory.
Apply any recommended Berkeley DB patches. See the patch install instructions on Sleepycat Software Developer Zone at https://dev.sleepycat.com/downloads/patching.html.
Install make package. Install the make package using the Solaris pkgadd command:
Change to the directory in which you gunzipped the installation package.
Run the following command to install the make package (do not use path statements in the package name):
# pkgadd -d make-3.80-sol9-sparc-local
Install libiconv. Install the libiconv package using the Solaris pkgadd command:
Change to the directory in which you gunzipped the installation package.
Run the following command to install the libiconv package (do not use path statements in the package name):
# pkgadd -d libiconv-1.8-sol9-sparc-local
Install gcc. Install the gcc package using the Solaris pkgadd command:
Change to the directory in which you gunzipped the installation package.
Run the following command to install the gcc package (do not use path statements in the package name):
# pkgadd -d gcc_small-3.4.2-sol9-sparc-local
Create a symbolic link for the gcc library:
# ln -s /usr/local/lib/libgcc_s.so.1 /usr/lib/libgcc_s.so.1
Modify PATH. Use the following commands to add /usr/local/bin and /usr/ccs/bin to your PATH:
# PATH=/usr/local/bin:$PATH:/usr/ccs/bin
export PATH
Install MIT Kerberos. Build and install the MIT Kerberos open source package:
Change to the /path/krb5-1.3.5/src directory, and then run the following commands:
$ ./configure --enable-shared
$ make
make install
2. Create symbolic links for the Kerberos libraries: <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml"># ln -s /usr/local/lib/libgssapi_krb5.so.2 /usr/lib/libgssapi_krb5.so.2ln -s /usr/local/lib/libkrb5.so.3 /usr/lib/libkrb5.so.3
ln -s /usr/local/lib/libk5crypto.so.3 /usr/lib/libk5crypto.so.3
ln -s /usr/local/lib/libcom_err.so.3 /usr/lib/libcom_err.so.3
Install Cyrus SASL. Build and install the Cyrus SASL package:
Change to the /path/cyrus-sasl-2.1.19 directory, and then run the following commands:
Note: Some of the lines in the following code have been displayed on multiple lines for better readability.
$ env LDFLAGS="-L/usr/local/lib" ./configure --disable-digest --without
-saslauthd $ make
make install
2. Create symbolic links for the SASL libraries: <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml"># ln -s /usr/local/lib/sasl2 /usr/lib/sasl2ln -s /usr/local/lib/libsasl2.so.2 /usr/lib/libsasl2.so.2
Install openldap. Build and install the openldap package:
Change to the /path/openldap-2.2.17 directory, and then run the following commands:
Note: Some of the lines in the following code have been displayed on multiple lines for better readability.
$ env CC=gcc LDFLAGS="-L/usr/local/lib -L`gcc -print-libgcc-file-name | sed
's//libgcc.a//'`" LIBS="-lgcc" ./configure -disable-slapd --disable-slurpd $ make
make install
2. Create symbolic links for the openldap libraries: <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml"># ln -s /usr/local/lib/libldap-2.2.so.7.0.10 /usr/lib/libldap-2.2.so.7ln -s /usr/local/lib/liblber-2.2.so.7.0.10 /usr/lib/liblber-2.2.so.7
Install Berkeley DB. Build and install the Berkeley DB package:
Change to the /path/db-4.2.52.NC/build_unix directory, and then run the following commands:
$ env CC=gcc LIBS="-lgcc" ../dist/configure --prefix=/usr/local
$ make
make install
2. Create a symbolic link for the Berkeley DB library: <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml"># ln -s /usr/local/lib/libdb-4.2.so /usr/lib/libdb-4.2.so</pre>Install PADL nss_ldap. Build and install the PADL nss_ldap package:
Change to the /path/nss_ldap-220 directory.
Edit the Makefile.in file, and change the line that reads:
Note: The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks.
@USE_NATIVE_LINKER_TRUE@NATIVE_LINK = @USE_NATIVE_LINKER_TRUE@$
(nss_ldap_so_LD) $(AM_LDFLAGS) -o $@
to the following: **Note:** The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks. <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">@USE_NATIVE_LINKER_TRUE@NATIVE_LINK = @USE_NATIVE_LINKER_TRUE@$(nss_ldap_so_LD) $(AM_LDFLAGS) $(LDFLAGS) -o $@
3. Run the following commands: **Note:** Some of the lines in the following code have been displayed on multiple lines for better readability. <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">$ env CC=gcc LDFLAGS="-L/usr/local/lib -L`gcc -print-libgcc-file-name | sed's//libgcc.a//'`" LIBS="-lgcc" ./configure -enable-schema-mapping --enable-configurable-krb5-ccname-env $ make
make install
Configure the /etc/ldap.conf File
[Open Source] [Solaris 9] [End State 2]
The /etc/ldap.conf file includes configuration items for many functions of OpenLDAP, but only a few of these configuration items are used for this end state. The sections of the ldap.conf file shown here represent a small fraction of the ldap.conf file and are the only sections of the sample file that you need to modify.
Note See Appendix I: "Sample Configuration Files for Custom Solutions" for the complete configuration file.
The items that you configure for this end state identify the server or servers to which LDAP requests are directed, the method by which the LDAP bind is accomplished, the mapping of UNIX authorization attributes to Windows attributes, and the container in which data for UNIX users and groups in Active Directory are found.
The LDAP bind—authentication to retrieve LDAP information—is done by using a proxy user. Because attributes for authorization data in UNIX have different names from those used by Windows Services for UNIX, you must create mappings to associate the UNIX names of certain attributes with the corresponding Windows names for these attributes.
Use the following steps to configure the LDAP client.
To configure /etc/ldap.conf
Back up file. Copy the existing /etc/ldap.conf file to ldap.conf.orig:
# cp /etc/ldap.conf /etc/ldap.conf.orig
Modify file. Modify the sections of the file shown below as follows (only modified sections of the file are shown here):
# Your LDAP server. Must be resolvable without using LDAP.
host server1.example.com
The distinguished name of the search base.
base dc=example,dc=com
Another way to specify your LDAP server is to provide an
uri with the server name. This allows to use
Unix Domain Sockets to connect to a local LDAP Server.
#uri ldap://127.0.0.1/ #uri ldaps://127.0.0.1/ #uri ldapi://%2fvar%2frun%2fldapi_sock/
Note: %2f encodes the '/' used as directory separator
uri ldap://adserver01.example.com/
The distinguished name to bind to the server with.
Optional: default is to bind anonymously.
binddn cn=proxyuser,cn=users,dc=example,dc=com
The credentials to bind with.
Optional: default is no credential.
bindpw Password1
The search scope.
scope sub #scope one #scope base
Search timelimit
timelimit 30
RFC2307bis naming contexts
Syntax:
nss_base_XXX base?scope?filter
where scope is {base,one,sub}
and filter is a filter to be &'d with the
default filter.
You can omit the suffix eg:
nss_base_passwd ou=People,
to append the default base DN but this
may incur a small performance impact.
nss_base_passwd ou=unix,dc=example,dc=com?sub nss_base_shadow ou=unix,dc=example,dc=com?sub nss_base_group ou=unix,dc=example,dc=com?sub #nss_base_passwd ou=People,dc=example,dc=com?one #nss_base_shadow ou=People,dc=example,dc=com?one #nss_base_group ou=Group,dc=example,dc=com?one #nss_base_hosts ou=Hosts,dc=example,dc=com?one #nss_base_services ou=Services,dc=example,dc=com?one #nss_base_networks ou=Networks,dc=example,dc=com?one #nss_base_protocols ou=Protocols,dc=example,dc=com?one #nss_base_rpc ou=Rpc,dc=example,dc=com?one #nss_base_ethers ou=Ethers,dc=example,dc=com?one #nss_base_netmasks ou=Networks,dc=example,dc=com?ne #nss_base_bootparams ou=Ethers,dc=example,dc=com?one #nss_base_aliases ou=Aliases,dc=example,dc=com?one #nss_base_netgroup ou=Netgroup,dc=example,dc=com?one
configure --enable-mssfu-schema is no longer supported.
For MSSFU now do:
nss_map_objectclass posixAccount User nss_map_objectclass shadowAccount User nss_map_objectclass posixGroup Group nss_map_attribute uid sAMAccountName nss_map_attribute uidNumber msSFU30UidNumber nss_map_attribute gidNumber msSFU30GidNumber nss_map_attribute loginShell msSFU30LoginShell nss_map_attribute uniqueMember msSFU30posixMember #nss_map_attribute userPassword msSFU30Password nss_map_attribute homeDirectory msSFU30HomeDirectory nss_map_attribute memberUid msSFU30MemberUid
**Note** The location of the LDAP server (the Active Directory server) can be specified either with a host entry or a uri entry. In the example, uri is used.Configure the /etc/nsswitch.conf File
[Open Source] [Solaris 9] [End State 2]
The /etc/nsswitch.conf file is used to configure NSS for a broad range of data sources and many different functions. Much like a PAM configuration, the NSS configuration allows you to specify multiple stacked data sources for any given function.
Note See Appendix I: "Sample Configuration Files for Custom Solutions" for the complete configuration file.
Three sections are defined specifically for this end state:
passwd. Identifies the list of data sources from which user environment configuration data (for example, home directory or shell) is retrieved.
group. Identifies the list of data sources from which user group membership is retrieved.
hosts. Identifies the list of data sources from which name resolution data is retrieved.
For the passwd and group sections, both files (the local /etc/passwd and /etc/group files) and ldap (the Active Directory database) are defined. For the hosts section, both files (/etc/hosts) and dns (domain name system servers) are defined.
See Appendix A: "Architectural Overview of UNIX and Windows Authentication and Authorization," for more information about NSS and the nsswitch.conf file.
To configure /etc/nsswitch.conf
Back up file. Copy the existing /etc/nsswitch.conf file to /etc/nsswitch.conf.orig:
# cp /etc/nsswitch.conf file /etc/nsswitch.conf.orig
Modify entries. Modify the passwd and group entries in the nsswitch.conf file as follows:
passwd: files ldap [TRYAGAIN=continue]
group: files ldap [TRYAGAIN=continue]
Confirm files listed before DNS. Confirm that the /etc/nsswitch.conf file is still configured to use files first for name resolution (hosts) and then DNS. The hosts entry should match the following format:
hosts: files dns
Restart the NSCD Service
[Open Source] [Solaris 9] [End State 2]
After each configuration change, you must restart the Name Service Caching Daemon (NSCD) service to allow the daemon to reread the configuration. The NSCD service caches LDAP data retrieved from Active Directory to reduce lookups for duplicate data. The NSCD service is not necessary for functionality but can reduce network traffic.
To restart the NSCD service
Restart NSCD. Run the following command to restart the NSCD service:
# /etc/init.d/nscd stop; /etc/init.d/nscd start
Test LDAP Connectivity to the Active Directory Server
[Open Source] [Solaris 9] [End State 2]
You can use one of the following commands to confirm that the UNIX host has LDAP connectivity to the Active Directory server. These commands confirm that your UNIX host can communicate via LDAP with your Active Directory server but do not validate the LDAP configuration steps completed to this point. Only a logon test can validate the LDAP configuration.
To test LDAP connectivity to Active Directory , run one of the following commands
You can use the ldapsearch command as follows to test your LDAP connection, where the command options are defined as described in the following table.
Table 4.22. Options for the ldapsearch Command
**Note** When you build the LDAP tools, the open source version of **ldapsearch** is installed. You can use either the open source or the native version of **ldapsearch** to perform these tests. However, the open source command string is slightly different, requiring the addition of an **–x** switch. For example: \# ldapsearch –x -h *IPAddress* -D *ProxyDN* -w *Password1* -b *BaseDN* -s sub '(cn=test\*)' Here is the generic command that uses the native version of **ldapsearch**: **Note:** The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks.Variable
Description
IPAddress
The IP address of your Active Directory server.
ProxyDN
The distinguished name of your LDAP proxy user.
Password1
The password of your LDAP proxy user.
BaseDN
The base distinguished name where your UNIX users and computers are stored (for example, ou=unix,dc=example,dc=com)
# ldapsearch -h IPAddress -D ProxyDN -w Password1 -b BaseDN -s sub '(cn=test*)'
For example: **Note:** The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks. <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml"># ldapsearch -h 10.9.8.1 -D cn=proxyuser,cn=users,dc=example,dc=com -wPassword1 –b ou=unix,dc=example,dc=com -s sub '(cn=test*)'
If this command completes successfully, you see output that includes several attributes associated with each user (test\*) in Active Directory. The first line of returned data displays information similar to the following: <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">CN=test01,OU=Users,OU=UNIX,DC=example,DC=com</pre> If the command fails, the system displays an error message. **Note** If this command fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."You can use the ldapsearch command as follows to test your LDAP connection, where IPAddress is the IP address of your Active Directory server:
# ldapsearch -h IPAddress -s base -b "" "(objectclass=*)"
For example:
# ldapsearch -h 10.9.8.1 -s base -b "" "(objectclass=*)"
The output from the command should be similar to the following:
currentTime=20031217100255.0Z
subschemaSubentry=CN=Aggregate,CN=Schema,CN=Configuration,DC=example,DC=com [...]
**Note** If this command fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."Create Test User Data for User test02
[Open Source] [Solaris 9] [End State 2]
At this point in the configuration process, you must test that configuration for Kerberos authentication and LDAP authorization at UNIX logon completed successfully. To log on to a UNIX client as an Active Directory user, you must create a home directory for the Active Directory user on each UNIX client. For correct functionality, the home directory must be owned by the test user. If the home directory does not exist or its ownership is incorrect, logon or some post-logon functions might fail.
For this test, do not create a local user account in /etc/passwd. If a local account exists for the same user name, it might be unclear at logon whether data was retrieved locally or from Active Directory.
To create test data for test02
Create directory. Create a home directory for user test02:
# mkdir /home/test02
Note The /home/test02 directory is an example location for the user's home directory. In your environment, a directory other than /home might be used.
Specify permissions. Give the directories correct user permissions:
# chown test02 test02
chgrp tstgrp01 test02
**Note** If the **chown** or **chgrp** command fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."Perform a Quick Verification Test as User test02
[Open Source] [Solaris 9] [End State 2]
Confirm that a user can log on using Kerberos authentication and LDAP authorization against Active Directory. You can accomplish this by using a number of different logon methods, but the method you use must be one that is currently configured for pam_krb5 authentication in the pam.conf file. If you provided for failsafe root access by commenting out the pam_krb5 entries for rlogin and/or dtlogin, those logon methods cannot be used for testing. On some systems and with some configurations, ssh or Kerberized versions of services, such as telnet, may not make use of the pam.conf configurations defined here.
After you log on, run the id and groups commands to confirm that the user's UID and GID are correctly mapped to the user's user name and primary group name and that a complete list of all groups of which the user is a member can be retrieved. If the output of the id command includes only the UID and GID numbers but not the user and group names in parentheses, or if the groups command returns no data or only one group, the test has failed.
To verify logon for test02
Log on. Log on either at the console command-line of the UNIX-based computer or by using telnet (if telnetd is installed on the client computer) as test user test02.
Note If you want to log on by using telnet, you might need to install and configure the telnetd service.
Confirm logon. Confirm that you are successfully logged on.
Note If logon fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."
Confirm id and group output. Confirm that the output of the id and group commands contains complete data, as illustrated in this example:
$ id
uid=10002(test02) gid=10001(tstgrp01) $ groups tstgrp01 tstgrp02
**Note** If this test fails, refer to Appendix D: "Kerberos and LDAP Troubleshooting Tips."Configure Kerberos Authentication for LDAP Bind
[Open Source] [Solaris 9] [End State 2]
Up to this point, the proxy account password and all LDAP data have been transmitted over the network in clear (unencrypted) text. Setting up Kerberos authentication for the LDAP bind to Active Directory eliminates the need to transmit the proxy account password over the network and encrypts the LDAP data retrieval traffic. Kerberos authentication for LDAP also eliminates the need to store the proxy account password in a clear text file on the UNIX client.
To configure Kerberos authentication for LDAP authentication
Note See Appendix I: "Sample Configuration Files for Custom Sources" for the complete configuration file.
Add entries to file. Add the following entries to the /etc/ldap.conf file (at any location in the file):
# Enable Kerberos authentication for server bind.
use_sasl on rootuse_sasl on krb5_ccname /var/tmp/proxycreds
Modify entries. Modify the following entries in the /etc/ldap.conf file:
# The distinguished name to bind to the server with.
Optional: default is to bind anonymously.
binddn cn=proxyuser,cn=users,dc=example,dc=com
binddn cn=service_proxy,cn=users,dc=example,dc=com
The credentials to bind with.
Optional: default is no credential.
bindpw secret [any password that isn't a real password]
Create account and key table. Use the following command (where Administrator is a user with sufficient permissions to read and update Active Directory) to create a new proxy service account and to create a key table for it in order to allow for automation of the ticket acquisition for this principal:
Note: The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks.
# css_adkadmin -p Administrator -q "ank +use_des -k /etc/proxy.keytab
service/proxy"
**Note** For more information about the **css\_adkadmin tool**, see "Install Kerberos Tools" earlier in this solution and see Appendix E: "Relevant Windows and UNIX Tools." The proxy service account is required because the user has not yet authenticated to Active Directory, but the system needs to make a query to Active Directory. Using the proxy service account avoids the need to enable anonymous access to Active Directory and therefore avoids the security risk of allowing anonymous access. **CAUTION** If you plan to implement the solution on more than one UNIX-based computer, you must either create a separate proxy service account (for example, proxy/hostname1, proxy/hostname2) for each UNIX client on which the solution will be implemented, or you must create the key table for the proxy service account once and then securely distribute it to each UNIX client that you configure. If you create a new key table for the same proxy service account, the password for the account will be changed, invalidating any previously created key tables for this account. **Note** This guide provides instructions for configuring the solution to use the DES-MD5 and/or DES-CRC encryption types. Recent versions of the open source tools described here also support the standard Windows RC4-HMAC encryption type. However, the native Kerberos client tools such as **kinit** do not support RC4-HMAC. If you choose to configure the solution with RC4-HMAC support, omit the switch **+use\_des** from this command. When the key table is created with the RC4-HMAC encryption type, it will not function correctly with native **kinit**. You will need to specify the open source **kinit** in order to acquire a credential using this key table.Create cron job. Create a cron job to automatically acquire a TGT for the service/proxy user. Configure the cron job to acquire the ticket periodically at an interval that is less than the ticket lifetime. The default ticket lifetime is typically 8 or 10 hours—this example acquires the ticket every 6 hours to ensure that there is always a valid ticket.
Edit crontab.
Note See Appendix I: "Sample Configuration Files for Custom Solutions" for the complete configuration file.
Run the following command to open the crontab file for editing:
# crontab -e
The -e option of the crontab command lets you use the editor (such as vi) specified by your EDITOR environment variable to open and edit the file that is also called crontab. For more information, see the man page for crontab.
Add the following two lines to the file:
Note: Some of the lines in the following code have been displayed on multiple lines for better readability.
# Run at 5:07, 11:07, 17:07, 23:07 every day
07 5,11,17,23 * * * /usr/bin/kinit -k -t /etc/proxy.keytab -c /var/tmp /proxycreds service/proxy && chmod 644 /var/tmp/proxycreds
2. **Create test entry.** To allow for immediate testing, create a second, temporary entry in the crontab file to run the preceding command in the immediate future. For example, if the current time is 12:34, create an entry such as the following to run at 12:38: **Note:** The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks. <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">38 12 * * * /usr/bin/kinit -k -t /etc/proxy.keytab -c /var/tmp/proxycredsservice/proxy && chmod 644 /var/tmp/proxycreds
3. **Run the test.** Wait approximately 5 minutes, and then run the following command to confirm that the /var/tmp/proxycreds file has been created, has a 12:38 date stamp, and is owned by nscd: <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml"># ls -l /var/tmp/proxycreds</pre> The command produces output similar to the following: <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">-rw-r--r-- 1 root other 1182 Aug 19 12:38 proxycreds</pre> 4. **Edit crontab.** Open the crontab file for editing again using the preceding command and delete the test entry that you created in the crontab file. **Note** You might find it helpful to create a script to allow you to run these commands manually during testing. In addition, it is also important to run a test at least once using the crontab entry to be certain that it will work correctly with this method. **Note** If you deploy this solution in your production environment, you should also add a script that uses the command described previously for the **cron** job to acquire the credentials automatically at system startup.Restart the NSCD Service
[Open Source] [Solaris 9] [End State 2]
Use the following procedure to restart the NSCD service.
To restart the NSCD service
Restart NSCD. Run the following command to restart the NSCD service:
# /etc/init.d/nscd stop; /etc/init.d/nscd start
Perform a Quick Verification Test as User test01
[Open Source] [Solaris 9] [End State 2]
Use the following procedure to verify that test01 can log on.
Note Recall that user test01 is used only to test authentication (authorization data for user test01 is stored in /etc/passwd). For steps to test authorization, see the next procedure, "Perform a Quick Verification Test as User test02."
To verify logon for test01
Log on. Log on as test user test01 either at the console command-line of the UNIX-based computer or by using telnet (if telnetd is installed on the client computer). Use the password configured in Active Directory instead of the local password.
Note If you want to log on by using telnet, you might need to install and configure the telnetd service.
Confirm logon. Confirm that you are successfully logged on.
Note If logon fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."
Confirm TGT. Use the klist command, which lists currently held Kerberos tickets, to confirm that a Kerberos ticket-granting ticket (TGT) has been granted. Check to be sure that the ticket listed in the data returned by klist includes the correct user name and current date and time.
Perform a Quick Verification Test as User test02
[Open Source] [Solaris 9] [End State 2]
Use the following procedure to verify that user test02 can log on.
To verify logon for test02
Log on. Log on either at the console command-line of the UNIX-based computer or by using telnet (if telnetd is installed on the client computer) as test user test02.
Note If you want to log on by using telnet, you might need to install and configure the telnetd service.
Confirm logon. Confirm that you are successfully logged on.
Note If logon fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."
Confirm id and group output. Confirm that the output of the id and group commands contains complete data, as illustrated in this example:
$ id
uid=10002(test02) gid=10001(tstgrp01) $ groups tstgrp01 tstgrp02
**Note** If this test fails, refer to Appendix D: "Kerberos and LDAP Troubleshooting Tips."Milestone Complete: End State 2 (Solaris 9, Open Source)
You have used open source components and Solaris 9 to deploy End State 2, which enables your UNIX clients to use Active Directory Kerberos for authentication and Active Directory LDAP for authorization. If this is the only solution in which you are interested, stop here.
If you want to try one or more of the other solutions developed in this chapter, continue to the next solution that you want to deploy in your development environment. For a list showing each of the available solutions, see "Chapter Map" earlier in this chapter.
Use Red Hat 9 with Open Source Components for End States 1 and 2
The open source solution on Red Hat can meet the needs of many organizations. This solution provides the basic UNIX functionality that users expect but also adds Active Directory authentication or consolidates both authentication and authorization data in Active Directory.
The open source solution on Red Hat offers many features that the native Red Hat solution lacks. The major limitations of the native OS solution include security vulnerabilities in MIT Kerberos 1.2.7 on which the native OS Red Hat 9 distribution is based, allowing a user to log on when the Kerberos key table is missing or incorrect, weak security of the LDAP connection to Active Directory, and the inability to log on after password changes. These limitations are corrected by the open source Red Hat solution.
In addition, the open source solution on Red Hat offers the same supplementary features as those found in the open source solution for Solaris:
Warnings to the user that the user's password will expire in n days.
Specific error messages to the user explaining why a logon failed.
For End State 2, the option to use Kerberos to secure the LDAP connection to Active Directory data when retrieving authorization data. Depending on the environment, this can help reduce network load and processor load on the domain controllers (the Active Directory servers).
Because of the security risks inherent in the native OS Red Hat solution, we strongly recommend the use of the open source Red Hat solution instead of the native OS Red Hat solution in a production environment.
Before you start developing the open source Red Hat 9 solution, you need to understand how MIT Kerberos version 1.2.7 and MIT Kerberos 1.3.5 are used as this solution is developed in the lab:
End State 1. The development procedures for End State 1 for this open source Red Hat solution rely on the Kerberos client utilities, known as the "k-utils" (such as kinit, klist, kpasswd, ktutil), which are available in the native Red Hat 9 distribution. Red Hat does not plan to update the native Red Hat 9 Kerberos distribution, which is built on version 1.2.7 of MIT Kerberos and contains a number of known security vulnerabilities. Although the k-utils are not required to enable End State 1, these tools are often quite useful for troubleshooting during a development deployment in your lab as well as for troubleshooting and help desk support later if you deploy this solution in your production environment.
Because the k-utils rely on a set of Kerberos shared libraries that contain security vulnerabilities, you use the 1.2.7 package in the development of the open source Red Hat solution only for development testing. Later, when you deploy the solution in your production environment, you should use either updated packages from another source or the 1.3.5 version of MIT Kerberos (which you will use later in this section for the Red Hat open source solution if you configure End State 2).
For a description of the security vulnerabilities in native OS Red Hat 9, see "Use Red Hat 9 with Native OS Components for End States 1 and 2" earlier in this chapter.
Note The Fedora Legacy project has made available Red Hat install packages (RPMs) with a patched version of Kerberos 1.2.7 for Red Hat 9. Although this patch was not released by Red Hat directly, you might choose to apply it to your End State 1 solution using Red Hat 9 to resolve the security vulnerabilities in the Kerberos libraries. Alternatively, you might choose to follow the End State 2 instructions for downloading and building MIT Kerberos 1.3.5 and use the k-utils and underlying Kerberos libraries in this package for your deployment. For more information, see the "Fedora Legacy Update Advisory," available at https://www.fedoralegacy.org/updates/FC1/2005-07-24-FLSA_2005_154276__Updated_krb5_packages_fix_security_issues.html.
Note The pam_krb5 module downloaded and installed as part of the Red Hat 9 open source solution does not rely on underlying Kerberos libraries and thus is not affected by the security vulnerabilities found in the native Red Hat 9 Kerberos client install packages.
End State 2. The development procedures for End State 2 for the open source Red Hat solution include building Kerberos client-side code from the MIT Kerberos 1.3.5 version. This version of the code does not have the security vulnerabilities mentioned previously for the 1.2.7 version, and no additional steps are required to close known security vulnerabilities. When deploying your End State 2 solution, be sure to deploy the k-utils and underlying Kerberos libraries built using MIT Kerberos 1.3.5 (or later) instead of the native Red Hat 9 versions of these tools and libraries.
If you want to use Red Hat 9 with open source components to deploy End State 1 or to deploy End State 2, use the procedures as indicated in the following table.
Table 4.23. Which Procedures in This Section Are Appropriate for Your Open Source Red Hat Solution?
Solution
Do These Procedures
End State 1
Procedures: End States 1 and 2 (Red Hat 9, Open Source)
End State 2
Procedures: End States 1 and 2 (Red Hat 9, Open Source)
–and–
Procedures: End State 2 Only (Red Hat 9, Open Source)
For procedures to implement solutions other than open source Red Hat, see the following sections:
“Use Solaris 9 with Native OS Components for End States 1 and 2”
“Use Red Hat 9 with Native OS Components for End States 1 and 2”
“Use Solaris 9 with Open Source Components for End States 1 and 2”
Procedures: End States 1 and 2 (Red Hat 9, Open Source)
If you want to set up a proof-of-concept development lab using Red Hat 9 with open source components to deploy End State 1 or 2, use the procedures in this subsection.
Install and Configure Red Hat 9
[Open Source] [Red Hat 9] [End States 1 and 2]
Although it is possible to implement the solution described in these steps on a preinstalled Red Hat 9 client, the environment on such a client might be different from that assumed for these steps. Starting with a clean install ensures that no preexisting software or configuration will interfere with the solution—this is especially important if you want to test more than one of the custom solutions described in this chapter. The packaged solutions, for instance, might install components that conflict with the open source (or native OS) functionality.
The steps for installing and configuring Red Hat for your environment and the type of installation usually done might differ from the steps provided here. The configurations described here are the minimum necessary to implement the solution: selecting the workstation installation type, configuring DNS, and installing the latest Kerberos packages. These steps are required. Other configuration steps normally done in your environment are optional; some (for example, configuring NIS or NIS+) might conflict with the solution described here.
To install and configure Red Hat
Install OS. On the UNIX host, install Red Hat version 9, selecting the Workstation installation type.
Specify settings. Specify a host name, IP address, and DNS domain name appropriate for your test environment (do not accept the defaults).
Configure options. After the installation is complete, set the following configuration options:
Modify file. Modify the /etc/hosts file to contain the IP address, FQDN, and short host name of the UNIX host as follows, where IPAddress is the IP address of the UNIX host, unix01 is the host name of the UNIX host, and example.com is the DNS domain name of the UNIX host:
IPAddress unix01.example.com unix01
Confirm files before DNS. Confirm that the /etc/nsswitch.conf file is configured to use files first for name resolution (hosts) and then DNS. The hosts entry should match the following format:
hosts: files dns
Point to Windows DNS server. Confirm that the /etc/resolv.conf file points to the Windows server for DNS and sets the DNS domain name, where example.com is your DNS domain name and the IPaddress is that of your primary DNS server (your Active Directory server). It might be necessary to add the DNS domain name.
domain example.com
nameserver IPaddress
Download and Install the Latest Red Hat Kerberos Client Packages
[Open Source] [Red Hat 9] [End States 1 and 2]
The Kerberos packages included as part of the standard Red Hat 9 installation are not the latest versions available and might not offer all of the functionality described in this chapter. The core of the open source solution (pam_krb5 and nss_ldap) does not make use of the native Kerberos. However, you can use native Kerberos tools such as kinit for testing, so installation of latest native Kerberos packages is recommended.
To download and install Red Hat Kerberos client packages
Find installed packages. Use the following commands to determine whether the krb5-workstation, krb5-libs, and krb5-devel RedHat Package Manager (RPM) packages are installed on the host and to ascertain the version of each package:
# rpm –q krb5-workstation
rpm –q krb5-libs
rpm –q krb5-devel
If a package is currently installed, the output from each of these commands displays the full package name, including its version number. For example, the following output indicates that version 10 of the krb5-workstation package, built on MIT version 1.2.7, is installed: <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">krb5-workstation-1.2.7-10</pre> **Note** The Red Hat Kerberos packages built on version 1.2.7 of MIT Kerberos are the latest versions available from Red Hat for *native* Red Hat 9 installation packages. As explained in the introduction to this section about developing an *open source* Red Hat solution, you use the 1.2.7 version of the MIT Kerberos packages only for development testing. Later, when you deploy the solution in your production environment, you should use either updated packages from another source or the 1.3.5 version of MIT Kerberos (which you will use later in this section for the Red Hat open source solution if you configure End State 2).Download latest versions. Download the latest versions of the krb5-workstation, krb5-libs, and krb5-devel packages from one of the following locations:
Certified Security Solutions at https://www.css-security.com/mirrors/mirrors.html.
RPM Repository at https://rpmfind.net. Either search for the package name (for instance, krb5-workstation-1.2.7-14) or try these specific links:
Search Engine: Open a Web browser and search for "download krb5-workstation-1.2.7-14 krb5-libs-1.2.7-14 krb5-devel-1.2.7-14." Use caution when downloading packages from unknown sources.
Currently, the latest package versions are 1.2.7–14.
Copy packages. Copy the krb5-workstation, krb5-libs, and krb5-devel RPM packages to a temporary directory on the UNIX host.
Change directory. Change to the directory to which you copied the RPM packages.
Upgrade or install. Use the following command to upgrade any existing krb5 packages (for example, krb5-libs) and install any missing packages (for example, krb5-workstation):
# rpm -Uvh krb5*
CAUTION Some Kerberos packages require that other Kerberos packages of the same version be installed. These are referred to as dependencies. For instance, the krb5-workstation package is dependent on the krb5-libs package. If a package you are attempting to install depends on another package that is missing or of an older version, you might receive a dependency error. Packages can have many dependencies, so a package install might also generate dependency errors about non-Kerberos packages. You must resolve the dependencies before proceeding by installing the package referenced in the dependency check. The command given here installs all of the krb5 packages at once, so a dependency error should not occur.
Install Kerberos Tools
[Open Source] [Red Hat 9] [End States 1 and 2]
In this section, you download and install the following Kerberos tools:
css_adkadmin. You can use the Certified Security Solutions (CSS) Active Directory Kerberos administration tool (called ADKadmin or css_adkadmin) to assist in the configuration of any solution described in this chapter, including the open source Red Hat solution described in this section. The css_adkadmin tool provides functionality similar to that of the MIT kadmin tool. This tool simplifies deployment and management of UNIX-based computers that are configured to use Active Directory as their authentication or authorization data source. You can use css_adkadmin to manage and view Active Directory user and computer accounts from a UNIX or Linux host.
CAUTION Before you install and use the css_adkadmin tool for this solution, read the "Known Issues" section in the CSS readme file. To ensure that you obtain the latest version of the readme file, start at the Certified Security Solutions page at https://www.css-security.com, click Downloads, click ADKadmin vn.n (for example, ADKadmin v2.2), select Yes twice to agree to the CSS download conditions, click Submit, and then click ADKadmin Utility README to open the readme file.
pam_krb5. The CSS pam_krb5 tool provides functionality that ensures that a UNIX user can successfully change an expired password during logon. It also enhances the user logon experience by providing warnings to a user that the user's password will expire in n days and by providing specific error messages to a user when the user's logon fails because the Active Directory account is expired or locked out.
For more information about the css_adkadmin and pam_krb5 tools, see Appendix E: "Relevant Windows and UNIX Tools."
To install the css _ adkadmin and pam_krb5 tools
Install css_adkadmin. Install the Certified Security Solutions css_adkadmin package:
Download the css_adkadmin tool, which is available free from the CSS Tools and Downloads page at https://www.css-security.com/downloads.html.
Copy the CSS css_adkadmin installation package to a temporary directory on the UNIX-based computer.
Untar the files:
# gunzip css_adkadmin-2.2_linux.tar.Z
tar -xf css_adkadmin-2.2_linux.tar.Z
**Note** The **tar** command creates and adds a set of files to an archive file in tar format. Originally, a tar archive was stored solely on a magnetic tape (tar is short for "tape archive"), but currently **tar** can use other formats to create an archive, such as a floppy disk or a hard disk file. The **untar** command, or the **–x** (extract) command with tar, restores (unpacks) the files from the archive. 4. Run the **install.sh** script to install **css\_adkadmin**. 5. Review the README file.Install pam_krb5. Install the Certified Security Solutions pam_krb5 package:
Download the pam_krb5 tool, which is available free from the CSS Tools and Downloads page at https://www.css-security.com/downloads.html.
Copy the CSS pam_krb5 installation package to a temporary directory on the UNIX-based computer.
Untar the files:
# gunzip pam_krb5-1.60.1-css1_linux.tar.Z
tar -xf pam_krb5-1.60.1-css1_linux.tar
4. Run the **install.sh** script to install **pam\_krb5**. 5. Review the README file.Configure the Kerberos Client
[Open Source] [Red Hat 9] [End States 1 and 2]
You configure Kerberos client functionality on a UNIX client in the krb5.conf file. This file identifies the REALM of the Kerberos environment, the security servers (KDCs) to which authentication requests will be directed, the administrative and password servers (typically, these servers are the same as the KDCs) to which administrative and password change requests will be directed, and the DNS domain name for the environment. In Windows, the REALM name is the uppercase equivalent of the DNS domain name.
In other UNIX environments, using the uppercase name is the convention but is not required. In addition to these standard settings in the krb5.conf file, there are Active Directory–specific settings: the encryption type (because Active Directory does not support all of the encryption types that the UNIX client supports) and password change settings.
The Red Hat installation process described here creates a sample file. You must modify the sample krb5.conf file to match your environment and add the settings that are specific to Active Directory interoperability.
Kerberos functions are time sensitive to provide added security. This is done, in part, to prevent replay attacks. By default, the time on all Kerberos clients and the Active Directory servers must be within 5 minutes of one another. Because clocks on computers can drift, the best practice is to implement Network Time Protocol (NTP) to maintain synchronization instead of attempting to manually synchronize computers. If the clocks on your client and server drift out of sync, Kerberos functions will begin to fail. Because some functions rely on credentials acquired earlier, these failures might not appear immediately after the clocks go out of sync. It is possible that, for a time, some Kerberos functions fail while others continue to work, which can confuse troubleshooting efforts.
To configure the Kerberos client
Synchronize clocks. Confirm that the clocks on your Active Directory server and UNIX clients are synchronized as described earlier in this chapter in the subsection "Synchronize Time" in "Prepare Your Environment." Kerberos requires that the clocks on all computers in the Kerberos environment be synchronized to within 5 minutes of one another.
Modify file. Modify the sample configuration located in the /etc/krb5.conf file to contain the following entries, where EXAMPLE.COM is the REALM name for your Active Directory server, kdc1.example.com and kdc2.example.com are the FQDNs of your Active Directory servers, and .example.com is the DNS domain name of your Active Directory server.
Note For information about DNS lookups to determine whether you want to enable the entries for dns_lookup_realm and dns_lookup_kdc, see RFC 2782, "A DNS RR for specifying the location of services (DNS SRV)" at https://www.ietf.org/rfc/rfc2782.txt. The instructions provided in this chapter assume that DNS lookups have not been enabled. (See Appendix I: "Sample Configuration Files for Custom Solutions" for the complete configuration file.)
[libdefaults]
ticket_lifetime = 24000 default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false default_tkt_enctypes = des-cbc-md5 des-cbc-crc default_tgs_enctypes = des-cbc-md5 des-cbc-crc [realms] EXAMPLE.COM = { kdc = kdc1.example.com:88 kdc = kdc2.example.com:88 admin_server = kdc1.example.com:749 kpasswd_server = kdc1.example.com:464 kpasswd_protocol = SET_CHANGE default_domain = example.com } [domain_realm] *.example.com = EXAMPLE.COM .example.com = EXAMPLE.COM
**Note** The remainder of the sample file is not shown here because it does not require modification. **Note** This guide provides instructions for configuring the solution to use the DES-MD5 and/or DES-CRC encryption types. Recent versions of the open source tools described here also support the standard Windows RC4-HMAC encryption type. However, the native Kerberos client tools such as **kinit** and Kerberized versions of services such as **telnetd** and **ftpd** do not support RC4-HMAC. If you choose to configure the solution with RC4-HMAC support, change the following lines to add RC4-HMAC as a valid encryption type: default\_tkt\_enctypes = rc4-hmac des-cbc-md5 des-cbc-crc default\_tgs\_enctypes = rc4-hmac des-cbc-md5 des-cbc-crc Some native Kerberos client tools and services might not function correctly when the krb5.conf file is configured in this way.Create a Service Key Table
[Open Source] [Red Hat] [End States 1 and 2]
A key table file that contains the key for the UNIX-based computer account in Active Directory is required for both End States 1 and 2 for pam_krb5 authentication to occur. This key table is also used by servers that provide Kerberized services, such as an FTP or telnet server.
To create a Kerberos service key table
Create key table on UNIX host. Run the following command to create a key table on the UNIX host, where fqdn is the fully qualified domain name of the UNIX host, Administrator is a principal (user account) in the Active Directory database with sufficient permissions to add, modify, and delete users and computers from the database, and BaseDN is the base distinguished name for the Active Directory container holding the UNIX-based computer accounts:
css_adkadmin -p Administrator -q "ank +use_des -group BaseDN -k host/fqdn"
For example:
Note: The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks.
css_adkadmin -p Administrator1 -q "ank +use_des -group ou=computers,
ou=unix,dc=example,dc=com -k host/unix01.example.com"
**Note** This guide provides instructions for configuring the solution to use the DES-MD5 and/or DES-CRC encryption types. Recent versions of the open source tools described here also support the standard Windows RC4-HMAC encryption type. However, the native Kerberos client tools such as **kinit** and Kerberized versions of services such as **telnetd** and **ftpd** do not support RC4-HMAC. If you choose to configure the solution with RC4-HMAC support, omit the switch **+use\_des** from this command. When the key table is created with the RC4-HMAC encryption type, it will not function correctly with native Kerberized client tools and services. **Note** For more information about the **css\_adkadmin** tool, see "Install Kerberos Tools" earlier in this section and see Appendix E: "Relevant Windows and UNIX Tools."Perform a Quick Kerberos Configuration Verification Test
[Open Source] [Red Hat 9] [End States 1 and 2]
Implementing the solution requires several steps, many of which assume successful completion of earlier steps. It is important to stop periodically and test the configuration completed to that point to confirm that it is correct before moving forward.
You can use the Kerberos client kinit tool to confirm that the krb5.conf file is configured correctly and that DNS is working correctly in your environment. You can use the Kerberos client klist tool to view the contents of the key table you created to see whether the correct account is present.
The basic tests provided here do not test every possible function in Kerberos. Therefore, even if these tests complete successfully, you might still encounter Kerberos configuration problems that cause problems in subsequent steps. Potential problems include:
Subtle DNS configuration problems. Requests for service tickets are sensitive to DNS configuration problems. A service ticket might fail as a result of a DNS problem even if an initial ticket-granting ticket (TGT) request made by using kinit succeeds. A service ticket request is made as part of the logon process.
Clock skew problems. Requests for service tickets are sensitive to clock skew problems.
Bad key tables. The key table is used only during the logon process. The test presented here confirms that the key table exists but not that the key table is valid for logon.
For more information about testing Kerberos configuration and troubleshooting Kerberos problems, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."
To verify Kerberos configuration
Get Kerberos ticket. Use the kinit command to acquire a Kerberos ticket for a test user. For example, to acquire a ticket for test01, type:
$ kinit test01
Note In an open source solution, you might need to specify the path for UNIX commands or add their directories to the PATH variable because the commands are not stored by default in a specific directory. You can use either the native versions of these tools or the open source versions for testing. However, if you have configured an encryption type that is not supported by the native versions of the tools, the commands might fail.
If the command completes successfully, no message appears and the user is returned to the command prompt. A message appears only if an error occurs.
View Kerberos ticket. Use the klist command to view the ticket just acquired for test01:
$ klist
This command returns output similar to the following:
Note: Some of the lines in the following code have been displayed on multiple lines for better readability.
Ticket cache: /tmp/krb5cc_500
Default principal: test01@EXAMPLE.COM Valid starting Expires Service principal THU 10 Aug 2006 10:36:15 AM PDT THU 10 Aug 2006 08:36:15 PM PDT krbtgt/EXAMPLE.COM@EXAMPLE.COM renew until THU 17 Aug 2006 10:36:15 AM PDT
**Note** If these commands fail, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."Confirm keytab data. Use the klist -k command to confirm that the key table contains correct data:
# klist –k
This command returns output similar to the following:
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
2 host/unix01.example.com@EXAMPLE.COM
Configure the /etc/pam.d/system-auth file for Kerberos Authentication
[Open Source] [Red Hat 9] [End States 1 and 2]
The pluggable authentication module (PAM) is used to control authentication on UNIX-based computers. On Red Hat, you configure PAM with the files in the /etc/pam.d directory. The files define the behavior of the service—one file for each service—with each file name specifying the service to which it relates. Services that are not specifically defined by a service name file (such as telnetd) read configuration information from the system-auth file. Many of the service-specific files reference the system-auth file in order to inherit configuration from this file. Each line in these files defines a service type (for example, authentication or password change) and a module to be used for this process (for example, pam_unix or pam_krb5) Multiple modules can be associated with each service type.
To provide for logon through Kerberos, you must add entries to these files to identify the pam_krb5 module as a valid authentication mechanism. To set up the environment and tests described here, you need modify only the system-auth file.
Because not all users will have accounts in Active Directory (for example, the UNIX root user does not have an Active Directory account), you must enable such users to log on. This is done with PAM stacking rules.
In this case, the pam_krb5 modules are placed before the pam_unix modules and set to "sufficient." This specifies that, when a user logs on, a test for Kerberos authentication is performed first. If the user passes this test (the user exists in Active Directory and provides the correct Active Directory password), the user is allowed to log on. If the user fails this test, a test for local authentication is performed. If the user passes this test (the user exists in the local /etc/passwd file and provides the correct local password), the user is allowed to log on. All other users are denied access.
CAUTION Perform each step in this section carefully, and then check all PAM configurations before proceeding. Incorrectly configuring the system-auth file can lead to a state in which no user, including root, can log on. (See the Note about configuring failsafe root access in the following procedure.)
For more information about PAM, the pam.d directory, and the system-auth file, see Appendix A: "Architectural Overview of UNIX and Windows Authentication and Authorization."
To configure the /etc/pam.d/system-auth file for Kerberos
Back up file. Copy /etc/pam.d/system-auth to /etc/pam.d/system-auth.orig:
# cp /etc/pam.d/system-auth /etc/pam.d/system-auth.orig
Modify and add entries. Modify the existing pam_unix.so entries and add pam_krb5.so entries as follows.
Note See Appendix I: "Sample Configuration Files for Custom Solutions" for the complete configuration file.
Make sure that you place the entries in the order shown:
Note: Some of the lines in the following code have been displayed on multiple lines for better readability.
#%PAM-1.0
This file is auto-generated.
User changes will be destroyed the next time authconfig is
run.
auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_krb5.so auth sufficient /lib/security/$ISA/pam_unix.so use_first_pass likeauth nullok auth required /lib/security/$ISA/pam_deny.so account required /lib/security/$ISA/pam_unix.so password required /lib/security/$ISA/pam_cracklib.so retry=3 type= password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow password required /lib/security/$ISA/pam_deny.so session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so session optional /lib/security/$ISA/pam_krb5.so
Modify Password management (optional—not recommended in system-auth). It is also possible to modify the Password management section of the system-auth file to enable Kerberos password change for the UNIX passwd tool. However, configuring the Password management section of system-auth might cause the password change process to prompt repeatedly for the new password.
Instead, we recommend:
Use the UNIX Kerberos kpasswd tool for Kerberos password changes.
Use the UNIX passwd tool for local password changes.
Create Test User Data for User test01
[Open Source] [Red Hat 9] [End States 1 and 2]
At this point in the configuration process, you must test that configuration for Kerberos authentication when a user logs on to Linux is successful. To log on to a Linux client, a user must have both authentication data and authorization data. Because you have not yet configured the client to use Active Directory (End State 2 only) or another data store for authorization data, for this test, you create a local user account to provide authorization data for a test user locally on the UNIX client. You add an account to the local /etc/passwd file and create a home directory for the user. You must set a password for the user's local account, but you will not use this password for logon. To avoid confusion during testing, this password must not match the Active Directory password for the same user—if the same password is used, it might be unclear during testing whether logon succeeds against Active Directory or locally.
To create test data for test01
Create test01 locally. Use the useradd command to create a local test user, test01:
# useradd -d /home/test01 –m -s /bin/csh test01
Note The /home/test01 directory and /bin/csh shell are examples for the user's home directory location and shell. In your environment, you might use a directory other than /home and a different shell.
Set password. Use the passwd command to set the local UNIX password for this user. Give the user a password different from that used for this test user in Active Directory:
# passwd test01
When prompted to provide a password, type a strong password, not a dictionary-based password. Typing a dictionary-based password returns a BAD PASSWORD message.
Confirm directory ownership. Use the ls command to confirm that the /home/test01 directory has been created and is owned by user test01:
# ls -ld /home/test01
Perform a Quick Verification Test as User test01
[Open Source] [Red Hat 9] [End States 1 and 2]
Confirm that a user can log on using Kerberos authentication against Active Directory. You can accomplish this by using a number of different logon methods, but the method that you use must be one that is currently configured for pam_krb5 authentication in the correct file in the pam.d directory. On some systems and with some configurations, Kerberized versions of services such as telnet might not make use of the PAM configurations defined here.
To verify logon for test01
Log on. Log on as test user test01 either at the console command-line of the UNIX-based computer or by using telnet (if telnetd is installed on the client computer). Use the password configured in Active Directory instead of the local password.
Note If you want to log on by using telnet, you might need to install and configure the telnetd service.
Confirm logon. Confirm that you are successfully logged on.
Note If logon fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."
Confirm TGT. Use the klist command, which lists currently held Kerberos tickets, to confirm that a Kerberos ticket-granting ticket (TGT) has been granted. Check to be sure that the ticket listed in the data returned by klist includes the correct user name and current date and time.
Milestone Complete: End State 1 (Red Hat 9, Open Source)
If your goal is to use Red Hat 9 with native OS features and open source components to deploy only End State 1, which enables your UNIX clients to use Active Directory Kerberos for authentication, stop here. The rest of the instructions in "Use Red Hat 9 with Open Source Components for End States 1 and 2" are for End State 2.
If you want to use Red Hat 9 with open source components to deploy End State 2, continue with the procedures in the following section.
Procedures: End State 2 Only (Red Hat 9, Open Source)
If you want to expand your test lab using Red Hat 9 with open source components to deploy End State 2 so that your development environment supports both Active Directory Kerberos and Active Directory LDAP, perform the procedures in this section after completing the procedures in "Procedures: End States 1 and 2 (Red Hat 9, Open Source)" in the preceding subsection.
Build and Install LDAP Tools
[Open Source] [Red Hat 9] [End State 2]
For this end state, the Red Hat client is configured to use LDAP to retrieve authorization data for Active Directory users. This solution uses the OpenLDAP nss_ldap module, so you must download and build the source code for this module. Although the goal is to create one module, several packages upon which the module is dependent—including the MIT Kerberos and Cyrus SASL packages that provide Kerberos authentication for the LDAP bind to Active Directory—must be built before building the final nss_ldap module.
Specific package versions are identified here because build instructions and product behavior vary from version to version for these products. New versions of some of these packages are released frequently, so the versions available to you will likely be more recent than the ones identified here. You might choose to implement the solution with more recent versions of the products, but be aware that the build instructions provided here might not be correct for more recent versions and that the configuration steps given might vary from those needed for more recent versions. It is possible that more recent versions of some packages might introduce changes that make the solution described here unusable. Therefore, we recommend that you implement the solution by using the exact packages described here for your first test. After that, you might choose to try newer versions of packages.
To build and install LDAP tools for the open source Red Hat solution
Download packages. Download the software packages required to create openldap nss_ldap with Kerberos authentication:
Download the 1.3.5 version of the MIT Kerberos open source package, krb5-1.3.5.tar, from Kerberos V5 Release 1.3 Source Distributions at https://web.mit.edu/kerberos/dist/historic.html#krb5-1.3-src. (If clicking the link does not work, copy the link into your browser.)
Note The configuration described here is not directly compatible with 1.4.x versions of MIT Kerberos and will need some modification to work with that version of the software.
Download the 2.1.19 version of cyrus-sasl from Download Cyrus Software at https://asg.web.cmu.edu/cyrus/download/.
The Cyrus Simple Authentication and Security Layer (SASL) package uses a Kerberos provider to authenticate and encrypt the LDAP connection.
Download the 2.2.17 version of openldap, openldap-2.2.17.tgz, from OpenLdap Download at https://www.openldap.org/software/download/ (in the section "Other OpenLDAP Releases").
Download the 220 version of nss_ldap, nss_ldap-220.tar.gz, from the PADL Index of /download site at https://www.padl.com/download/.
Confirm that the native Berkeley DB package is installed. Check for the existence of the /usr/lib/libdb.so file.
Prepare downloaded files. Prepare to install the software packages that you just downloaded by performing the following steps:
Untar (unpack) each downloaded file to a temporary working directory.
If you retrieve the result.c file separately from your OpenLDAP download, replace the original /path/openldap-2.2.17/libraries/libldap/result.c file with the patched version retrieved separately.
Copy the existing /etc/ld.so.conf file to /etc/ld.so.conf_orig.
Edit the /etc/ld.so.conf file to remove the /usr/kerberos/lib entry.
Install MIT Kerberos. Build and install the MIT Kerberos package:
Change to the /path/krb5-1.3.5/src directory.
Run the following commands:
$ ./configure
$ make
make install
Install Cyrus SASL. Build and install the Cyrus SASL package:
Change to the /path/cyrus-sasl-2.1.19 directory, and then run the following commands:
$ ./configure
$ make
make install
2. Rename the /usr/lib/libsasl2.so.2 file to /usr/lib/libsasl2.so.2.orig: <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml"># mv /usr/lib/libsasl2.so.2 /usr/lib/libsasl2.so.2.orig</pre> 3. Rename the /usr/lib/sasl2 directory to /usr/lib/sasl2.orig: <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml"># mv /usr/lib/sasl2 /usr/lib/sasl2.orig</pre> 4. Create symbolic links for the SASL libraries: <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml"># ln -s /usr/local/lib/sasl2 /usr/lib/sasl2ln -s /usr/local/lib/libsasl2.so.2 /usr/lib/libsasl2.so.2
Install openldap. Build and install the openldap package:
Change to the /path/openldap-2.2.17 directory, and then run the following commands:
$ ./configure --disable-slapd --disable-slurpd --without-tls
$ make
make install
2. Create symbolic links for the openldap libraries: <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml"># ln -s /usr/local/lib/libldap-2.2.so.7.0.10 /usr/lib/libldap-2.2.so.7ln -s /usr/local/lib/liblber-2.2.so.7.0.10 /usr/lib/liblber-2.2.so.7
Install nss_ldap. Build and install the nss_ldap package:
Change to the /path/nss_ldap-220 directory.
Edit the Makefile.in file, and change the line that reads:
Note: The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks.
@USE_NATIVE_LINKER_TRUE@NATIVE_LINK = @USE_NATIVE_LINKER_TRUE@$
(nss_ldap_so_LD) $(AM_LDFLAGS) -o $@
to the following: **Note:** The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks. <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">@USE_NATIVE_LINKER_TRUE@NATIVE_LINK = @USE_NATIVE_LINKER_TRUE@$(nss_ldap_so_LD) $(AM_LDFLAGS) $(LDFLAGS) -o $@
3. Run the following commands: **Note:** The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks. <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">$ env LDFLAGS=”-L/usr/local/lib” ./configure--enable-schema-mapping --enable-configurable-krb5-ccname-env $ make
make install
Configure the /etc/ldap.conf File
[Open Source] [Red Hat 9] [End State 2]
The /etc/ldap.conf file includes configuration items for many functions of OpenLDAP, but only a few of these configuration items are used for this end state. The sections of the ldap.conf file shown here represent a small fraction of the ldap.conf file and are the only sections of the sample file that you need to modify.
Note See Appendix I: "Sample Configuration Files for Custom Solutions" for the complete configuration file.
The items that you configure for this end state identify the server or servers to which LDAP requests are directed, the method by which the LDAP bind is accomplished, the mapping of UNIX authorization attributes to Windows attributes, and the container in which data for UNIX users and groups in Active Directory is found.
The LDAP bind—authentication to retrieve LDAP information—is done by using a proxy user. Because attributes for authorization data in UNIX have different names from those used by Windows Services for UNIX, you must create mappings to associate the UNIX names of certain attributes with the corresponding Windows names for these attributes.
Use the following steps to configure the LDAP client.
To configure /etc/ldap.conf
Back up file. Copy the existing /etc/ldap.conf file to ldap.conf.orig:
# cp /etc/ldap.conf /etc/ldap.conf.orig
Modify file. Modify the sections of the file shown below as follows (only modified sections of the file are shown here):
# Your LDAP server. Must be resolvable without using LDAP.
host server1.example.com
The distinguished name of the search base.
base dc=example,dc=com
Another way to specify your LDAP server is to provide an
uri with the server name. This allows to use
Unix Domain Sockets to connect to a local LDAP Server.
#uri ldap://127.0.0.1/ #uri ldaps://127.0.0.1/ #uri ldapi://%2fvar%2frun%2fldapi_sock/
Note: %2f encodes the '/' used as directory separator
uri ldap://adserver01.example.com/
The distinguished name to bind to the server with.
Optional: default is to bind anonymously.
binddn cn=proxyuser,cn=users,dc=example,dc=com
The credentials to bind with.
Optional: default is no credential.
bindpw Password1
The search scope.
scope sub #scope one #scope base
Search timelimit
timelimit 30
RFC2307bis naming contexts
Syntax:
nss_base_XXX base?scope?filter
where scope is {base,one,sub}
and filter is a filter to be &'d with the
default filter.
You can omit the suffix eg:
nss_base_passwd ou=People,
to append the default base DN but this
may incur a small performance impact.
nss_base_passwd ou=unix,dc=example,dc=com?sub nss_base_shadow ou=unix,dc=example,dc=com?sub nss_base_group ou=unix,dc=example,dc=com?sub #nss_base_passwd ou=People,dc=example,dc=com?one #nss_base_shadow ou=People,dc=example,dc=com?one #nss_base_group ou=Group,dc=example,dc=com?one #nss_base_hosts ou=Hosts,dc=example,dc=com?one #nss_base_services ou=Services,dc=example,dc=com?one #nss_base_networks ou=Networks,dc=example,dc=com?one #nss_base_protocols ou=Protocols,dc=example,dc=com?one #nss_base_rpc ou=Rpc,dc=example,dc=com?one #nss_base_ethers ou=Ethers,dc=example,dc=com?one #nss_base_netmasks ou=Networks,dc=example,dc=com?ne #nss_base_bootparams ou=Ethers,dc=example,dc=com?one #nss_base_aliases ou=Aliases,dc=example,dc=com?one #nss_base_netgroup ou=Netgroup,dc=example,dc=com?one
configure --enable-mssfu-schema is no longer supported.
For MSSFU now do:
nss_map_objectclass posixAccount User nss_map_objectclass shadowAccount User nss_map_objectclass posixGroup Group nss_map_attribute uid sAMAccountName nss_map_attribute uidNumber msSFU30UidNumber nss_map_attribute gidNumber msSFU30GidNumber nss_map_attribute loginShell msSFU30LoginShell nss_map_attribute uniqueMember msSFU30posixMember #nss_map_attribute userPassword msSFU30Password nss_map_attribute homeDirectory msSFU30HomeDirectory nss_map_attribute memberUid msSFU30MemberUid
**Note** The location of the LDAP server (the Active Directory server) can be specified either with a host entry or a uri entry. In the example, uri is used.Change ownership. Change the ownership on the /etc/ldap.conf file to nscd:
# chown nscd /etc/ldap.conf
Note The standard system user nscd is added during the operating system installation.
Specify permissions. Grant the ldap.conf file permissions of 600 (which makes a file readable and writable only by the owner, that is, by nscd):
# chmod 600 /etc/ldap.conf
Note The steps in this chapter were tested with chmod 600. Alternatively, you can use chmod 400 to make the LDAP configuration file (ldap.conf) readable but not writable.
Configure the /etc/nsswitch.conf File
[Open Source] [Red Hat 9] [End State 2]
The /etc/nsswitch.conf file is used to configure NSS for a broad range of data sources and many different functions. Much like a PAM configuration, the NSS configuration allows you to specify multiple stacked data sources for any given function.
Note See Appendix I: "Sample Configuration Files for Custom Solutions" for the complete configuration file.
Three sections are defined specifically for this end state:
passwd. Identifies the list of data sources from which user environment configuration data (for example, home directory and shell) is retrieved.
group. Identifies the list of data sources from which user group membership is retrieved.
hosts. Identifies the list of data sources from which name resolution data is retrieved.
For the passwd and group sections, both files (the local /etc/passwd and /etc/group files) and ldap (the Active Directory database) are defined. For the hosts section, both files (/etc/hosts) and dns (domain name system servers) are defined.
See Appendix A: "Architectural Overview of UNIX and Windows Authentication and Authorization," for more information about NSS and the nsswitch.conf file.
To configure /etc/nsswitch
Back up file. Copy the existing /etc/nsswitch.conf file to /etc/nsswitch.conf.orig:
# cp /etc/nsswitch.conf file /etc/nsswitch.conf.orig
Modify entries. Modify the passwd and group entries in the nsswitch.conf file as follows:
passwd: files ldap [TRYAGAIN=continue]
group: files ldap [TRYAGAIN=continue]
Confirm files listed before DNS. Confirm that the /etc/nsswitch.conf file is still configured to use files first for name resolution (hosts) and then DNS. The hosts entry should match the following format:
hosts: files dns
Restart the NSCD Service
[Open Source] [Red Hat 9] [End State 2]
After each configuration change, you must restart the Name Service Caching Daemon (NSCD) service to allow the daemon to reread the configuration. The NSCD service caches LDAP data retrieved from Active Directory to reduce lookups for duplicate data. The NSCD service, which is required for functionality, can also help reduce network traffic.
To restart the NSCD service
Restart NSCD. Run the following command to restart the NSCD service:
# /etc/rc.d/init.d/nscd restart
Test LDAP Connectivity to the Active Directory Server
[Open Source] [Red Hat] [End State 2]
You can use one of the following commands to confirm that the UNIX host has LDAP connectivity to the Active Directory server. These commands confirm that your UNIX host can communicate via LDAP with your Active Directory server, but the commands do not validate the LDAP configuration steps completed to this point. Only a logon test can validate the LDAP configuration.
To test LDAP connectivity to Active Directory , run one of the following commands
You can use the ldapsearch command as follows to test your LDAP connection, where the command options are defined as described in the following table.
Table 4.24. Options for the ldapsearch Command
**Note** When you build the LDAP tools, the open source version of **ldapsearch** is installed. You can use either the open source or the native version of **ldapsearch** to perform these tests. Here is the generic command: **Note:** The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks.Variable
Description
IPAddress
The IP address of your Active Directory server.
ProxyDN
The distinguished name of your LDAP proxy user.
Password1
The password of your LDAP proxy user.
BaseDN
The base distinguished name where your UNIX users and computers are stored (for example, ou=unix,dc=example,dc=com)
# ldapsearch –x -h IPAddress -D ProxyDN -w Password1 -b BaseDN -s sub '(cn=test*)'
For example: **Note:** The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks. <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml"># ldapsearch –x -h 10.9.8.1 -D cn=proxyuser,cn=users,dc=example,dc=com -wPassword1 –b ou=unix,dc=example,dc=com -s sub '(cn=test*)'
If this command completes successfully, you see output that includes several attributes associated with each user (test\*) in Active Directory. The first line of returned data displays information similar to the following: <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">CN=test01,OU=Users,OU=UNIX,DC=example,DC=com</pre> If the command fails, the system displays an error message. **Note** If this command fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."You can use the ldapsearch command as follows to test your LDAP connection, where IPAddress is the IP address of your Active Directory server:
# ldapsearch –x -h IPAddress -s base -b "" "(objectclass=*)"
For example:
# ldapsearch –x -h 10.9.8.1 -s base -b "" "(objectclass=*)"
The output from the command should be similar to the following:
currentTime=20031217100255.0Z
subschemaSubentry=CN=Aggregate,CN=Schema,CN=Configuration,DC=example,DC=com [...]
**Note** If this command fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."Create Test User Data for User test02
[Open Source] [Red Hat 9] [End State 2]
At this point in the configuration process, you must test that configuration for Kerberos authentication and LDAP authorization at UNIX logon completed successfully. To log on to a UNIX client as an Active Directory user, you must create a home directory for the Active Directory user on each UNIX client. For correct functionality, the home directory must be owned by the test user. If the home directory does not exist or its ownership is incorrect, logon or some post-logon functions might fail.
For this test, do not create a local user account in /etc/passwd. If a local account exists for the same user name, it might be unclear at logon whether data was retrieved locally or from Active Directory.
To create test data for test02
Create directory. Create a home directory for user test02:
# mkdir /home/test02
Note The /home/test02 directory is an example location for the user's home directory. In your environment, a directory other than /home might be used.
Specify permissions. Give the directories correct user permissions:
# chown test02 test02
chgrp tstgrp01 test02
**Note** If the **chown** or **chgrp** command fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."Perform a Quick Verification Test as User test02
[Open Source] [Red Hat 9] [End State 2]
Confirm that a user can log on using Kerberos authentication and LDAP authorization against Active Directory. You can accomplish this by using a number of different logon methods, but the method you use must be one that is currently configured for pam_krb5 authentication in the correct file in the pam.d directory. On some systems and with some configurations, Kerberized versions of services such as telnet might not make use of the PAM configurations defined here.
After you log on, run the id and groups commands to confirm that the user's UID and GID are correctly mapped to the user's user name and primary group name and that a complete list of all groups of which the user is a member can be retrieved. If the output of the id command includes only the UID and GID numbers but not the user and group names in parentheses, or if the groups command returns no data or only one group, the test has failed.
To verify logon for test02
Log on. Log on either at the console command-line of the UNIX-based computer or by using telnet (if telnetd is installed on the client computer) as test user test02.
Note If you want to log on by using telnet, you might need to install and configure the telnetd service.
Confirm logon. Confirm that you are successfully logged on.
Note If logon fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."
Confirm id and group output. Confirm that the output of the id and group commands contains complete data, as illustrated in this example:
$ id
uid=10002(test02) gid=10001(tstgrp01) groups=10001(tstgrp01),10002(tstgrp02) $ groups tstgrp01 tstgrp02
**Note** If this test fails, refer to Appendix D: "Kerberos and LDAP Troubleshooting Tips."Configure Kerberos Authentication for LDAP Bind
[Open Source] [Red Hat 9] [End State 2]
Up to this point, the proxy account password and all LDAP data have been transmitted over the network in clear (unencrypted) text. Setting up Kerberos authentication for the LDAP bind to Active Directory eliminates the need to transmit the proxy account password over the network and encrypts the LDAP data retrieval traffic. Kerberos authentication for LDAP also eliminates the need to store the proxy account password in a clear text file on the UNIX client.
To configure Kerberos authentication for LDAP authentication
Add entries to file. Add the following entries to the /etc/ldap.conf file (at any location in the file):
# Enable Kerberos authentication for server bind.
use_sasl on rootuse_sasl on krb5_ccname /var/tmp/proxycreds
Modify entries. Modify the following entries in the /etc/ldap.conf file:
# The distinguished name to bind to the server with.
Optional: default is to bind anonymously.
binddn cn=proxyuser,cn=users,dc=example,dc=com
binddn cn=service_proxy,cn=users,dc=example,dc=com
The credentials to bind with.
Optional: default is no credential.
bindpw secret [any password that isn't a real password]
Create account and key table. Use the following command (where Administrator is a user with sufficient permissions to read and update Active Directory) to create a new proxy service account and to create a key table for it in order to allow for automation of the ticket acquisition for this principal:
Note: The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks.
# css_adkadmin -p Administrator -q "ank +use_des -k /etc/proxy.keytab
service/proxy"
**Note** For more information about the **css\_adkadmin tool**, see "Install Kerberos Tools" earlier in this solution and see Appendix E: "Relevant Windows and UNIX Tools." The proxy service account is required because the user has not yet authenticated to Active Directory, but the system needs to make a query to Active Directory. Using the proxy service account avoids the need to enable anonymous access to Active Directory and therefore avoids the security risk of allowing anonymous access. **CAUTION** If you plan to implement the solution on more than one UNIX-based computer, you must either create a separate proxy service account (for example, proxy/hostname1, proxy/hostname2) for each UNIX client on which the solution will be implemented, or you must create the key table for the proxy service account once and then securely distribute it to each UNIX client that you configure. If you create a new key table for the same proxy service account, the password for the account will be changed, invalidating any previously created key tables for this account. **Note** This guide provides instructions for configuring the solution to use the DES-MD5 and/or DES-CRC encryption types. Recent versions of the open source tools described here also support the standard Windows RC4-HMAC encryption type. However, the native Kerberos client tools such as **kinit** do not support RC4-HMAC. If you choose to configure the solution with RC4-HMAC support, omit the switch **+use\_des** from this command. When the key table is created with the RC4-HMAC encryption type, it will not function correctly with native **kinit**. You will need to specify the open source **kinit** in order to acquire a credential using this key table.Create cron job. Create a cron job to automatically acquire a TGT for the service/proxy user. Configure the cron job to acquire the ticket periodically at an interval that is less than the ticket lifetime. The default ticket lifetime is typically 8 or 10 hours—this example acquires the ticket every 6 hours to ensure that there is always a valid ticket.
Edit crontab. Run the following command to open the crontab file for editing:
# crontab -e
The -e option of the crontab command lets you use the editor (such as vi) specified by your EDITOR environment variable to open and edit the file that is also called crontab. For more information, see the man page for crontab.
Add the following two lines to the file:
Note: Some of the lines in the following code have been displayed on multiple lines for better readability.
# Run at 5:07, 11:07, 17:07, 23:07 every day
07 5,11,17,23 * * * /usr/kerberos/bin/kinit -k -t /etc/proxy.keytab -c /var/tmp/proxycreds service/proxy && chown nscd:sshd /var/tmp/proxycreds && chmod 640 /var/tmp/proxycreds
2. **Create test entry.** To allow for immediate testing, create a second, temporary entry in the crontab file to run the preceding command in the immediate future. For example, if the current time is 12:34, create an entry such as the following to run at 12:38: **Note:** The line has been split into multiple lines for readability.However, while trying it out on a system you must enter it as one line without breaks. <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">38 12 * * * /usr/kerberos/bin/kinit -k -t /etc/proxy.keytab -c /var/tmp/proxycreds service/proxy && chown nscd:sshd /var/tmp/proxycreds && chmod 640 /var/tmp/proxycreds
3. **Run the test.** Wait approximately 5 minutes, and then run the following command to confirm that the /var/tmp/proxycreds file has been created, has a 12:38 date stamp, and is owned by nscd: <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml"># ls -l /var/tmp/proxycreds</pre> The command produces output similar to the following: <pre IsFakePre="true" xmlns="https://www.w3.org/1999/xhtml">-rw-r----- 1 nscd sshd 1182 Aug 19 12:38 proxycreds</pre> 4. **Edit crontab.** Open the crontab file for editing again using the preceding command and delete the test entry that you created in the crontab file. **Note** The group permissions and ownership of sshd on /var/tmp/proxycreds is necessary only if you plan to use nss\_ldap for the sshd application. **Note** If you deploy this solution in your production environment, you should also add a script that uses the command described previously for the **cron** job to acquire the credentials automatically at system startup. **Note** You might find it helpful to create a script to allow you to run these commands manually during testing. In addition, it is also important to run a test at least once using the crontab entry to be certain that it will work correctly with this method.Restart the NSCD Service
[Open Source] [Red Hat 9] [End State 2]
Use the following procedure to restart the NSCD service.
To restart the NSCD service
Restart NSCD. Run the following command to restart the NSCD service:
# /etc/rc.d/init.d/nscd restart
Perform a Quick Verification Test as User test01
[Open Source] [Red Hat 9] [End State 2]
Use the following procedure to verify that user test01 can log on.
Note Recall that user test01 is used only to test authentication (authorization data for user test01 is stored in /etc/passwd). For steps to test authorization, see the next procedure, "Perform a Quick Verification Test as User test02."
To verify logon for test01
Log on. Log on as test user test01 either at the console command-line of the UNIX-based computer or by using telnet (if telnetd is installed on the client computer). Use the password configured in Active Directory instead of the local password.
Note If you want to log on by using telnet, you might need to install and configure the telnetd service.
Confirm logon. Confirm that you are successfully logged on.
Note If logon fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."
Confirm TGT. Use the klist command, which lists currently held Kerberos tickets, to confirm that a Kerberos ticket-granting ticket (TGT) has been granted. Check to be sure that the ticket listed in the data returned by klist includes the correct user name and current date and time.
Perform a Quick Verification Test as User test02
[Open Source] [Red Hat 9] [End State 2]
Use the following procedure to verify that user test02 can log on.
To verify logon for test02
Log on. Log on either at the console command-line of the UNIX-based computer or by using telnet (if telnetd is installed on the client computer) as test user test02.
Note If you want to log on by using telnet, you might need to install and configure the telnetd service.
Confirm logon. Confirm that you are successfully logged on.
Note If logon fails, see Appendix D: "Kerberos and LDAP Troubleshooting Tips."
Confirm id and group output. Confirm that the output of the id and group commands contains complete data, as illustrated in this example:
$ id
uid=10002(test02) gid=10001(tstgrp01) groups=10001(tstgrp01),10002(tstgrp02) $ groups tstgrp01 tstgrp02
**Note** If this test fails, refer to Appendix D: "Kerberos and LDAP Troubleshooting Tips."Milestone Complete: End State 2 (Red Hat 9, Open Source)
You have used open source components and Red Hat 9 to deploy End State 2, which enables your UNIX clients to use Active Directory Kerberos for authentication and Active Directory LDAP for authorization. If this is the only solution in which you are interested, stop here.
If you want to try one or more of the other solutions developed in this chapter, return to any earlier sections in this chapter that you want to deploy in your development environment. For a list showing each of the available solutions, see "Chapter Map" earlier in this chapter.
Major Milestone: Scope Complete
The Developing Phase ends with the Scope Complete Milestone. At this point, you have developed in your lab one or more solutions of the eight possible solutions for reaching End State 1 or End State 2 presented in this chapter.
At this major milestone, you should gain formal approval from the sponsor and key stakeholders that all solution elements that you want to test are built and that solution features and functionality are complete according to the functional specifications agreed upon during the Planning Phase.
You can now move into the Stabilizing Phase to test your solution and perform a pilot deployment.
Download
[Get the Windows Security and Directory Services for UNIX Guide