CAPÍTULO I. EVOLUCIÓN DE LAS EMPRESAS
1.4. Globalización
supported.
1.4.3 Common user and group IDs
When users are defined on individual UNIX servers, the user and group IDs can be unique on each individual server, but when you combine the users from these servers to a common user repository the differences must be fixed before the migration to an LDAP solution. This is necessary to provide the proper security mechanisms for file and application ownership.
1.5 Sample LDAP integration scenarios
To provide a road map for IT planning, a number of sample scenarios are provided in this book. This section contains a brief overview of the scenarios that are presented.
1.5.1 AIX 5L Version 5.3 LDAP client configuration
A number of new features were added to the LDAP security client daemon in AIX 5L Version 5.3. For example, starting with AIX 5L Version 5.3 the client can use a server-based authentication mechanism and can prioritize authentication against a group of LDAP servers. These and other new functions are presented in Chapter 2, “History of AIX and LDAP” on page 19, and Chapter 4, “AIX 5L Version 5.3 LDAP client configuration” on page 101. Because the setup of the LDAP client is similar for all the supported LDAP servers, the client setup and configuration that is common to all LDAP server platforms is described in Chapter 4, “AIX 5L Version 5.3 LDAP client configuration” on page 101.
1.5.2 Integration with Microsoft Active Directory Server
The number of Microsoft Windows users in most companies today is larger than the number of AIX 5L users or any other UNIX users. Often these users
authenticate against the Microsoft Active Directory Server. Often most of the UNIX users are also Windows users and their information already exists in this directory. For this reason, some administrators desire to combine the Windows and UNIX user authentication into a single directory server. There is currently no standard that includes both UNIX and Microsoft solutions. In Chapter 8,
“Scenario: Microsoft Windows 2003 Active Directory integration” on page 217, we discuss some of the potential solutions that might be applied when integrating
AIX 5L Version 5.3 and Microsoft ADS. Three potential solutions are explored in this chapter:
8.1, “Scenario: Kerberos only” on page 219
In this section AIX authenticates against the Active Directory using the Kerberos KRB5A load module and does user authorization and identification from local AIX files.
8.2, “Scenario: Kerberos and LDAP” on page 233
In this section AIX 5L authenticates against the Active Directory using Kerberos and also retrieves user information from the Active Directory using Microsoft Services for UNIX schemas. This section contains information about how customer mapping files were used.
8.3, “Scenario: LDAP only” on page 259
In this section AIX 5L authenticates against the Active Directory using a server-side authentication with the new AIX 5L Version 5.3
authtype=ldap_auth. The user information is also retrieved from the Active Directory using the mapping files described in the second scenario.
The final section in this chapter discusses troubleshooting techniques for problem determination.
1.5.3 Integration with Sun ONE Directory Server
Many customers who use NIS on AIX come from a Sun background and often have LDAP authentication set up for their Solaris systems using Sun ONE Directory Server, formerly known as Netscape Directory Server. Chapter 5,
“Scenario: Sun ONE LDAP server integration” on page 157, is a case study of how one AIX customer migrated their AIX user management into an already existing Sun ONE Directory Server environment. The major sections in this chapter include:
5.2, “Environment” on page 158
This section describes a typical client’s existing Sun LDAP environment and the desire to integrate AIX users into this environment.
5.3, “AIX 5L client configuration” on page 158
This section describes how the AIX 5L LDAP client was configured to use the LDAP server.
5.4, “Restriction of user login with compat mode (netgroups)” on page 164 This section describes how the login capabilities on AIX 5L clients were configured to use their netgroup.
5.5, “automount configuration” on page 173
This section describes how the user’s home directory was configured to use LDAP-defined automounter files.
5.6, “SSL configuration” on page 178
This section describes how a secure SSL connection was configured to go between the AIX 5L LDAP client and the Sun ONE Directory Server.
1.5.4 Integration with IBM Tivoli Directory Server 6.0
AIX 5L Version 5.3 is shipped with IBM Tivoli Directory Server (ITDS) Version 5.2, but the latest version of ITDS is now Version 6.0. For this reason, we show how to install ITDS Version 6.0 and to configure the AIX 5L Version 5.3 LDAP authentication client to use this directory server. Configuring ITDS Version 5.2 is very similar to configuring Version 6.0.
Chapter 6, “Scenario: IBM Tivoli Directory Server V6.0 integration” on page 187, describes how the ITDS Server is configured to support the AIX 5L LDAP client.
Topics described in this chapter include:
6.1, “Existing environment” on page 188
This section describes the AIX 5L environment before integration with LDAP.
6.2, “Planned environment” on page 188
This section describes the desired environment with LDAP integration for user information.
6.3, “Migration steps” on page 193
This section describes how to migrate the data from the existing AIX files format into the LDAP directory server as well as set up secure
communications between the client and server.
6.4, “Working with the AIX 5L clients” on page 204
This section describes how working with the administration of AIX 5L users is different when they are in the LDAP environment.
Appendix A, “IBM Tivoli Directory Server V6.0 installation” on page 273 This appendix describes how the ITDS Server was set up to support the AIX or other LDAP user clients as well as how to set up security, including generating the SSL key files required for secure communications between the AIX LDAP security client daemon and the ITDS Server.
Chapter 2.
History of AIX and LDAP
This chapter discusses the progression of changes that have occurred in AIX using an LDAP server from the time it was first introduced (in AIX 4.3.3) until now. (The most recent version at the time this book was published is AIX 5L Version 5.3 with the 5300-03 Recommended Maintenance package.) The goal of this chapter is to introduce as many of the new features as possible, placing them in one place. This chapter is not intended to describe the features at the same level as the AIX 5L Differences and Security guides.
In this chapter the following topics are discussed:
2.1, “Historical context for LDAP integration” on page 20
2.2, “Original AIX 4.3.3 and AIX 5L Version 5.1 LDAP authentication” on page 22
2.3, “Improvements to LDAP authentication in AIX 5L Version 5.2” on page 26
2.4, “Improvements to LDAP authentication in AIX 5L Version 5.3” on page 31
2.5, “Improvements to LDAP authentication in AIX 5L Version 5.3 RML3” on page 42
2.6, “LDAP support in AIX versions” on page 46
2
Note: In the remainder of this book we refer to AIX 5L Version 5.3 with the 5300-03 Recommended Maintenance package as AIX 5L Version 5.3 RML3.
2.1 Historical context for LDAP integration
As the number of systems that any user has access to increases, the number of user IDs and passwords that the user must keep track of also increases. As this number increases, the ability to remember and maintain this user information becomes more difficult. The user may try to maintain the same password on all systems, but when forced to change these on a regular basis, the task of making the changes can consume a considerable amount of time and organization. One potential solution to this problem is to create a central repository for this
information to keep track of all the systems the user has access to.
The concept of defining users in a single repository for a UNIX operating system such as AIX is not completely new. Naming services such as NIS and NIS+ have been around for over ten years on AIX. Network authentication with Kerberos has been an integral part of Distributed Computing Environment (DCE) on AIX.
Kerberos and an open source utility called supper have been used on IBM RS/6000® SP systems to synchronize user information across multiple nodes.
This chapter describes the evolution of AIX user management from local user file management to the LDAP server management capability in AIX 5L Version 5.3 ML3 as of September 2005.
2.1.1 Traditional file-based security in AIX
In AIX file-based management, there are a few files that provide all of the user and group information. These files include:
/etc/security/user This file contains the default user information about the system as well as a list of all locally defined users and their password and login restrictions and the type of authentication that the user can use.
/etc/passwd This file contains the user’s user ID, user name, home directory, login shell, primary group ID, and finger information.
/etc/security/passwd This file contains encrypted passwords, password flags, and other security information.
/etc/security/login.cfg This file contains default login information for different TTY ports, other system-wide security attributes such as the valid shells, and starting with AIX 5L Version 5.3 the auth_type.
/etc/group This file contains a list of all the locally defined groups and a list of users assigned to each group.
/etc/security/lastlog This file contains information about the last location that a user logged in from and the date and time of the last unsuccessful login and the unsuccessful login count.
/etc/security/failedlogin This file contains a record of unsuccessful login attempts stored in utmp format and used by the accounting and audit subsystems.
/etc/security/environ This file contains the environment attributes that can be defined for individual users. Global environment variables are defined in /etc/environment.
/etc/security/limits This file contains the process resource limits for users.
When a user tries to log in to AIX 5L, the security subsystem first checks to see whether the user exists in /etc/security/user. If it does, then it uses crypt() to compare the entered password to the data stored in /etc/security/passwd. If the authentication succeeds, then the credentials are returned from /etc/passwd, /etc/group, and /etc/security/user.
2.1.2 NIS services
Network Information Service (NIS, also known as yellow pages) was introduced by Sun in 1985 to enable central administration of operating system data. NIS stores information in maps that are accessible by all computers in the NIS domain through remote procedure calls. NIS clients bind to the NIS server during system boot. If a particular server is down, the client will attempt to bind to another server. Client systems bound to an NIS server resolve TCP/IP names and user name and password information against a combination of local files and the NIS maps from the server.
NIS allows multiple servers in a management domain to prevent clients from being unable to function due to NIS server overload or unavailability. One of the servers in an NIS domain serves as the NIS master server. The local files on the NIS master server (like /etc/passwd, for instance) contain all of the definitions for the domain it is serving. The local files are used to build maps that NIS clients use to resolve various requests. The other NIS servers (called slave servers) in the domain periodically pull read-only copies of the maps from the master server (or the master server may push copies). Map replication has some shortcomings.
Among these are a high amount of network traffic because complete copies are always shipped. More importantly, changes to the master are not automatically pushed to the slaves. So it is possible for the master server to operate with fresh maps after a change while slaves use older map data. An NIS client bound to an un-refreshed slave could have different results than a client bound to the master.
NIS has security shortcomings as well. Early implementations lacked support for
storing user passwords outside of the /etc/passwd file. Such shadow password files are the norm for UNIX systems now, but that was not the case 20 years ago.
All of these deficiencies render NIS less than ideal for enterprise-wide solutions.
Organizations still using NIS may consider moving to LDAP since it addresses these shortcomings and provides a more scalable and flexible administration model.
2.1.3 NIS+
NIS+ was a complete rewrite of NIS that enhanced both the scalability and security capabilities of NIS. Major new features of NIS+ include hierarchal name space, client authentication with encryption and secure RPC, and a more flexible data structure. For a number of reasons, NIS+ was widely adopted by Sun customers but not by those of other UNIX vendors. NIS+ is not a recommended strategy over the long term since both Sun and HP have announced plans to discontinue support for NIS+ in future releases in favor of LDAP. IBM AIX does not fully support NIS+ and has not announced plans to do so in the future.
2.1.4 DCE
Distributed Computing Environment (DCE) is middleware software consisting of development tools, servers, and commands. It is used to manage distributed client and server applications in a heterogeneous computing environment. The security core component of DCE provides services for securing a DCE
application and provides authentication, authorization, delegation, login, and other services. The underlying authentication mechanism used Kerberos. DCE was widely used as a directory service as a part of the RS/6000 SP environment and with PSSP. One of the primary DCE applications was the Distributed File System (DFS™) application. As the IBM DEC product is phased out, other solutions including LDAP are being used to replace this functionality.
2.2 Original AIX 4.3.3 and AIX 5L Version 5.1 LDAP authentication
Significant changes in the way AIX authentication is done were introduced in AIX 5L Version 5.1 using something called the loadable authentication module. This was first described in the AIX Version 4.3.3 /usr/lpp/bos/README framework.
The mechanism is more fully documented in the AIX 5.2 security guide and changes from earlier AIX versions are described in Chapter 9 of IBM Redbook AIX 5L Differences Guide Version 5.2 Edition, SG24-5765.
2.2.1 Loadable authentication module (LAM) framework
Prior to AIX 5L Version 5.1, system administrators could add their own
authentication mechanisms using the auth1 and auth2 user attributes defined in /etc/security/user. This provided methods for customers and vendors to easily add their own security methods to AIX 5L, but also opened up some security issues if they were not careful.
With the introduction of a more formal method of providing authentication modules that could be applied to AIX 5L user management, a more secure user management framework was provided. Now all AIX 5L user management is done through this framework. Any module that implements this interface can be used to perform authentication and identification functions. Authentication functions included password verification and modification. Identification functions include storage, retrieval, and modification of user and group account
information.
When AIX needs to interact with one of the mechanisms, it determines the correct module to use by looking at the SYSTEM and registry parameters defined in /etc/security/user. For example, user Naomi shown in Example 2-1 is defined to use the LDAP server by the following stanza in /etc/security/user.
Example 2-1 Defining individual user for LDAP naomi:
SYSTEM = "LDAP"
registry = LDAP
These parameters point to a module definition stanza in
/usr/lib/security/methods.cfg. This stanza defines the program or programs that will be used for the authentication and identification functions. The AIX 5L supplied program modules that do the work are supplied in /usr/lib/security. The first module supplied in AIX 4.1 was the DCE module. The LDAP module was first supplied in AIX 4.3.3. Example 2-2 shows the entry for an LDAP module definition in /usr/lib/security/methods.cfg that performs both the authentication and identification functions.
Example 2-2 LDAP authentication module definition in methods.cfg file LDAP:
program = /usr/lib/security/LDAP program_64 =/usr/lib/security/LDAP64
It is possible to define one program to perform the authentication and another to provide the identification function. In Example 2-3, KRB5A is used to
authenticate against a Kerberos Key Distribution Center and the identification
functions are done using an LDAP server. This definition is called a compound load module.
Example 2-3 KRB5A, LDAP, and KRB5ALDAP stanzas in methods.cfg LDAP:
program = /usr/lib/security/LDAP program_64 =/usr/lib/security/LDAP64 KRB5A:
program = /usr/lib/security/KRB5A program_64 =/usr/lib/security/KRB5A_64 options = authonly
KRB5ALDAP:
options = auth=KRB5A,db=LDAP
2.2.2 IBM SecureWay Directory V 3.2.2 shipped with AIX 5L V 5.1
The first LDAP server code that was shipped with the AIX was SecureWay®
Directory Server Version 3.2.2. This LDAP server contained AIX proprietary schemas for user management and name services. The directory information was stored in a DB2® 7.1 database and was installed automatically as you installed the SecureWay server, providing a complete LDAP server solution for AIX authentication at no additional cost to the client.
2.2.3 IBM AIX proprietary schema
The first implementation of LDAP authentication on AIX was based on the AIX security model. The AIX proprietary schema supported users, groups, and hosts naming services. This schema can still be used today to provide an AIX-only solution for versions of AIX from 4.3.3 to AIX 5L Version 5.3 and beyond. This solution allows a system administrator to replace all of the information in the /etc/security/user, /etc/passwd, and /etc/security/passwd with information stored on the LDAP server. With this LDAP support, the system administrator could now manage the users of many AIX 5L systems through a central LDAP server.
2.2.4 LDAP security client: secldapclntd
To allow the root user on any of the client machines to be able to add users into the LDAP directory, change user information, and to change user passwords, a client daemon was created that allows special permissions from the AIX client on the LDAP server. As the client daemon started, it read the LDAP administrative bind DN (Distinguished Name) and password from a configuration file (ldap.cfg) that allowed it to gain authority on the LDAP server to create, change, and delete users as well as to change users passwords. All communications between the
AIX client and the LDAP server are done through the secldapclntd daemon. For additional security, a secure connection between the client and server can be set up using SSL encryption. Once again, the secldapclntd daemon gets the SSL key file and key password from the /etc/security/ldap/ldap.cfg file.
When a user authenticates using LDAP with the unix_auth authentication, the secldapclntd actually retrieves the password, which is stored in crypt() format, from the LDAP server, and the authentication is done on the AIX 5L client.
Likewise, it is this daemon that has bind access to add and change users. More details about these mechanisms are in 2.4.1, “Server-side authentication support” on page 31, when ldap_auth is introduced.
2.2.5 AIX naming service
The new LDAP integration added support for various name services, that is, NIS, NIS+, DNS, and LDAP. Systems can be configured to resolve network
information from any supported name services through settings specified in system configurations files. The system uses the following variable/configuration files to determine the search order for name service resolution:
NSORDER environment variable: This variable is used to specify the name service used for host resolution only.
NSORDER environment variable: This variable is used to specify the name service used for host resolution only.