Novell is now a part of Micro Focus

Authenticating Users to UNIX Systems with Novell eDirectory and LDAP

Articles and Tips: article

Britt Courtney
Principal Architect
Novell Consulting
bcourtney@novell.com

Barry Fausnaugh
Principal Architect
Novell Consulting
bfausnaugh@novell.com

01 Jun 2002


This AppNote describes a consulting project that was undertaken to allow users of UNIX systems running Sun Solaris to authenticate to Novell eDirectory via LDAP. It provides both design and implementation details that can be adapted for use in similar projects.


Topics

Novell eDirectory, LDAP, UNIX, integration

Products

Novell eDirectory, Sun Solaris

Audience

network administrators, consultants, integrators

Level

intermediate

Prerequisite Skills

familiarity with Novell and UNIX environments and LDAP

Operating System

n/a

Tools

none

Sample Code

yes

Introduction

This AppNote describes a project that was undertaken to implement a solution to allow Solaris UNIX systems to consume user account and group information from Novell eDirectory using Lightweight Directory Access Protocol (LDAP).

By integrating the necessary Solaris user and group information with the corresponding user information in eDirectory, you create a single point of user and group management which can:

  • Simplify account administration by allowing user administration to be performed from a single location.

  • Secure user credentials by requiring users to use credentials only from eDirectory. Since only one set of credentials are used for both the NetWare/ LAN and Solaris environments, a password change on one system is immediately reflected on the other system.

  • Accelerate user provisioning to the integrated systems. Since user credentials are stored in eDirectory, provisioning of user access to multiple Solaris systems can be integrated into existing user management procedures.

Implementing this solution involves three main steps: extending the eDirectory schema, implementing the LDAP PAM and NSS modules on the Solaris systems, and modifying the configuration files on the Solaris system.

This AppNote first details the design specifications in terms of the Solaris requirements and the eDirectory requirements. It then covers the actual implementation guidelines and procedures used to accomplish the project.

Solaris Design Specifications

The specific information which must be provided to the Solaris system by eDirectory for user authentication and authorization is the information that would ordinarily be maintained in the following files (assuming that traditional UNIX authentication is being used):

  • /etc/passwd

  • /etc/shadow

  • /etc/group

This is the same information that is maintained by NIS (Network Information Service).

Required Modules

Three modules are required on the Solaris system:

  • pam_ldap.so is an open source LDAP Pluggable Authentication Module (PAM) that provides access to and manages functions related to posixAccount information

  • nss_ldap.so is an open source LDAP Name Service Switch (NSS) module that provides access to and manages functions related to shadowAccount information

  • libldapssl40.so is a set of libraries that provides the LDAP library calls used by the PAM and NSS modules

The PAM and NSS modules are public domain software maintained by PADL Software Company in Melbourne, Australia. PADL Software runs three Internet mailing lists which allow users of their software to support each other: nssldap@padl.com, pamldap@padl.com, and ldap-nis@padl.com. To subscribe to any of these mailing lists, send an e-mail to majordomo@padl .com with "subscribe listname" in the message body. PADL Software also offers fee-based support of these modules if required. PADL Software's Web site is at http://www.padl.com.

RFC 2307, entitled "An Approach for Using LDAP as a Network Information Service" (see http://www.ietf.org/rfc/rfc2307.txt), presents a directory schema that was authored by PADL and has been endorsed by all major UNIX vendors. It identifies the information contained in the /etc/passwd file as posixAccount information, information in the /etc/shadow file as shadowAccount information, and information in the /etc/group file as posixGroup information when working with the user and group information contained in eDirectory. RFC 2307 also covers a wide range of NIS/directory-related topics not discussed in this AppNote.

PADL Software's pam_ldap.  The version of the pam_ldap module provided in this solution is pam-ldap-124. This module was downloaded from PADL Software's Web site and compiled using gcc-2.95.3. This module must be installed in the /usr/lib/security directory.

Note: If you want to update to a newer version of this module after it is installed, you will need to download the latest version from PADL Software's Web site and then compile and install the new module.

Solaris 8 comes with a preinstalled LDAP library module. However, the pam_ldap module would not compile properly using the preinstalled LDAP libraries. It was for this reason that Netscape's LDAP libraries were used. In order to make the pam_ldap module link to the Netscape library, it was necessary to disable the preinstalled Solaris LDAP library. This was accomplished by moving the libldap.so.4 file from the /etc directory to /tmp until the module was compiled. Once the module was compiled, the library was returned to its original location.

It is important to note that, for this project, the modules were compiled and delivered to the client in binary form; they were not compiled on the client's system. However, it should be easy for the client to recompile or update modules in the future by following the documentation that comes with pam-ldap-124 from PADL Software and using gcc-2.95.3 with the Netscape LDAP library.

PADL Software's nss_ldap.  The version of the nss_ldap module provided in this solution is nss-ldap-170. This module was downloaded from PADL Software's Web site and compiled using gcc-2.95.3. This module must be installed in the /usr/lib directory.

As with the pam_ldap module, it was necessary to disable the preinstalled LDAP library on Solaris 8 to compile this module.

Netscape's libldapssl40.  This module provides the necessary LDAP libraries for the pam_ldap and nss_ldap modules to interface with eDirectory via LDAP. The libldapssl40.so file is required on every system where these modules are installed. It must be installed in the /usr/lib directory.

The module comes precompiled from Netscape's developer Web site at http://developer.netscape.com. It is included in the Directory SDK download. Also in the Directory SDK are the include files (ending in .h) which must be copied to the /usr/include directory (or another location where you normally put supplemental libraries) if the pam_ldap and nss_ldap modules are to be compiled on a particular system. If you use a location other than /usr/include, you will need to include the appropriate settings for the additional directory when compiling the modules. The include files are only required on systems where the modules are being compiled. (Newer versions of this module are available from Sun's iPlanet Web site at http://www.iplanet.com.)

Other Required Files

Many UNIX systems use a configurable, module-based system for authentication, authorization, session management, and password management. This architecture is known as PAM or Pluggable Authentication Modules. PAM functionality is available on systems running Solaris 2.6 and later.

The pam.conf File.  PAM is configured by editing a file called pam.conf in the /etc directory. An entry in this file defines which services (telnet, ftp, rlogin, and so on) are serviced by which authentication systems (traditional UNIX authentication, LDAP, smart cards, and so on). Modules for the same service can be stacked. Depending on how the modules are stacked and configured, multiple services may be used by the same authentication module.

Each entry in the pam.conf file has four required fields and an optional field.

The first field defines the service to which the entry applies.

The second field defines which of four types of activity the entry applies to:

  • Auth represents authentication services. This is used by the system to check the directory for the user id and other account information such as the login shell, home directory, and other posixAccount information.

  • The Account field is used for account authorization. Once a user has been authenticated, this field can be used to determine if the user is allowed access to the particular system. In the case of pam_ldap, checking whether the user is a member of a particular group or has a particular value in the "host" attribute enforces this authorization.

  • The Session field is not used by pam_ldap.

  • The Password field is used for password management functions. If properly configured, a user can change his or her eDirectory password using the UNIX passwd command. Any password restrictions or constraints imposed by the UNIX system will be enforced when changing the password from the UNIX system.

The third field is called the control flag, which determines how the particular activity uses the PAM module specified in the fourth field. The values of the control flag can be:

  • Required, which means that the user must succeed against the system referenced by the module. Processing stops whether there is success or failure. If the service is successful in using the PAM system, then the process succeeds and returns success. If the service fails against the system, then the process fails and no other attempts are made. In the case of authentication, the user will either be authenticated to the system or they won't.

  • Requisite, which means that for this particular service, the user must succeed against the system interfaced by the module and processing will continue with any additional modules in the list (if any exist). If the user fails against this module, failure will be returned and processing will continue. In the case of authentication, if the user succeeds against this module, processing will continue in case there are other modules against which the user must authenticate. In the case of failed authentication, processing will continue; however, the user will not be authenticated (even if the user would have been successfully authenticated by another module later in the list.)

  • Sufficient, which means that for this particular service, if the user succeeds against the system interfaced by the module, success will be returned and no other attempts are necessary. If the user fails against the system interfaced by the particular module, additional attempts will be made against subsequent modules (if any) in the list for this service. Failure of a sufficient entry does not preclude a later entry from succeeding. In the case of authentication, a user who succeeds against a sufficient entry would be authenticated without any further processing. A user who fails a sufficient entry but succeeds a later module of any type would be authenticated.

  • Optional, which means that for this particular service, success will be returned by the system interfaced by the module, provided the user does not fail any subsequent required or requisite module. In the case of authentication, a user will be authenticated against an optional entry if and only if no subsequent required or requisite flags for the same service fails. If a user fails to authenticate against an optional module, a subsequent optional, sufficient, requisite, or required module may still authenticate the user.

The fourth field specifies the full path to the PAM module to be used.

The fifth field is optional and may contain one of several values. For purposes of this AppNote, we will focus on two of those values: "try_first_pass" and "use_first_pass". Each of these values would be used when you have multiple entries in the pam.conf file for a specific service; they would be placed on the second or subsequent entry.

  • Try_first_pass means that the module should try to use the credentials that were already entered. If the credentials are valid, they are used. If not, the user is prompted for new credentials.

  • Use_first_pass means that the module should try to use the credentials that were already entered. If the credentials are valid, they are used. If not, the authentication fails and the system proceeds accordingly.

For each service configured in PAM, the modules are processed in the order they appear in the pam.conf file. (You can obtain additional information by reading the man pages on pam.conf.)

The following listing shows a sample pam.conf file set up to direct Telnet and FTP authentications to LDAP, as well as traditional UNIX authentication if LDAP authentication fails. The file is also set up to include account authorization and password management via LDAP and then files if the LDAP module fails.

# #ident "@(#)pam.conf 1.15 00/02/14 SMI" # # Copyright (c) 1996-1999 by Sun Microsystems, Inc. # All rights reserved. # # PAM configuration # Authentication management # login auth required /usr/lib/security/$ISA/pam_unix.so.1 login auth required /usr/lib/security/$ISA/pam_dial_auth.so.1 # rlogin auth sufficient /usr/lib/security/$ISA/pam_rhosts_auth.so.1 rlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 # dtlogin auth required /usr/lib/security/$ISA/pam_unix.so.1 # telnet auth sufficient /usr/lib/security/pam_unix.so.1 telnet auth required /usr/lib/security/pam_ldap.so.1 use_first_pass # ftp auth sufficient /usr/lib/security/pam_unix.so.1 ftp auth required /usr/lib/security/pam_ldap.so.1 use_first_pass # rsh auth required /usr/lib/security/$ISA/pam_rhosts_auth.so.1 other auth required /usr/lib/security/$ISA/pam_unix.so.1 # # Account management # login account requisite /usr/lib/security/$ISA/pam_roles.so.1 login account required /usr/lib/security/$ISA/pam_projects.so.1 login account required /usr/lib/security/$ISA/pam_unix.so.1 # dtlogin account requisite /usr/lib/security/$ISA/pam_roles.so.1 dtlogin account required /usr/lib/security/$ISA/pam_projects.so.1 dtlogin account required /usr/lib/security/$ISA/pam_unix.so.1 # telnet account sufficient /usr/lib/security/pam_ldap.so.1 telnet account required /usr/lib/security/pam_unix.so.1 # ftp account sufficient /usr/lib/security/pam_ldap.so.1 ftp account required /usr/lib/security/pam_unix.so.1 # other account requisite /usr/lib/security/$ISA/pam_roles.so.1 other account required /usr/lib/security/$ISA/pam_projects.so.1 other account required /usr/lib/security/$ISA/pam_unix.so.1 # # Session management # other session required /usr/lib/security/$ISA/pam_unix.so.1 # # Password management # other password sufficient /usr/lib/security/pam_ldap.so.1 other password required /usr/lib/security/pam_unix.so.1 dtsession auth required /usr/lib/security/$ISA/pam_unix.so.1

The beauty of the PAM architecture is the ability for developers to write applications that use authentication schemes completely independent of the application. For example, the following listing shows the pam.conf file used on production Solaris servers configured to access Interwoven's TeamSite 5.0. (The TeamSite service entries are shown in boldface type.)

# teamsite auth sufficient /usr/lib/security/pam_ldap.so.1 teamsite auth required /usr/lib/security/pam_unix.so.1 use_first_pass # teamsite account sufficient /usr/lib/security/pam_ldap.so.1 teamsite account required /usr/lib/security/pam_unix.so.1 # # Password management # other password sufficient /usr/lib/security/pam_ldap.so.1 other password required /usr/lib/security/pam_unix.so.1 dtsession auth required /usr/lib/security/$ISA/pam_unix.so.1

The nsswitch.conf File.  The nsswitch.conf file, also located in the /etc directory, is used to configure which system will be used for shadow information (the shadow file) and password information (for authentication purposes). Each entry in the file consists of the name of the function and then a list of the modules to be referenced.

The sample nsswitch.conf file listed below is the one used on the production servers. The lines in boldface type show passwd and group access being directed to the local file system and LDAP.

# # /etc/nsswitch.file: # # An example file that could be copied over to /etc/nsswitch.conf; it # does not use any naming service. # # "hosts:" and "services:" in this file are used only if the # /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports. passwd: files ldap group: files ldap hosts: files dns ipnodes: files networks: files protocols: files rpc: files ethers: files netmasks: files bootparams: files publickey: files # At present there isn't a 'files' backend for netgroup; the system will # figure it out pretty quickly, and won't use netgroups at all. netgroup: files automount: files aliases: files services: files sendmailvars: files printers: user files

The ldap.conf File.  The ldap.conf file is used to configure LDAP-specific information for the pam_ldap.so and nss_ldap.so modules. The following entries are the minimum required in this file to provide SSL-encrypted communication and group level authorization to systems with eDirectory:

  • host <ip address or hostname of eDirectory server>

  • base <container at which to begin searching for information in eDirectory>

  • scope sub - specifies a subtree search. (Other options include base - search only the object specified by the base parameter, and one - search only among the objects directly contained by the object specified by the base parameter.)

  • pam_groupdn <full LDAP DN of group object which a user must be a member of to be authorized for access to the system>

  • pam_member_attribute member (identifies the attribute name to check for the DN of the user object for determining authorization privileges. When a user fails to authorize because he or she is not in the necessary group, a message is displayed informing the user that he or she must be a member of the necessary group. If a different attribute name is used, the user will be informed that he or she must be a different_attribute of the group.)

  • ssl on - turn on SSL transport encryption (the sslpath below is also required)

  • sslpath <file system path name to a Netscape formatted cert7.db file with the Trusted Root from the server against which you will be authenticating> - Directions for installing the Trusted Root certificate taken from eDirectory are provided later in this AppNote.

If it is desired to authenticate as a specific user when retrieving user information instead of performing an anonymous bind, the following parameters must be set (it takes more computing resources to perform an authenticated bind than an anonymous bind):

  • binddn <full LDAP DN of user object to authenticate as>

  • bindpw <password of the above user>

The following listing shows the ldap.conf file used on the production servers for this project, including options other than those listed above to show what is delivered in a full distribution of the LDAP PAM modules.

# @(#)$Id: ldap.conf,v 1.20 2001/08/22 09:53:12 lukeh Exp $ # # This is the configuration file for the LDAP nameservice # switch library and the LDAP PAM module. # # PADL Software # http://www.padl.com # # Your LDAP server. Must be resolvable without using LDAP. host 127.0.0.1 # The distinguished name of the search base. base o=company # Another way to specify your LDAP server is to provide an uri with the server # name. This allows use of 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 # The LDAP version to use (defaults to 3 if supported by client library) #ldap_version 3 # The distinguished name to bind to the server with. # Optional: default is to bind anonymously. binddn cn=admin,o=company # The credentials to bind with. # Optional: default is no credential. bindpw password # The distinguished name to bind to the server with if the effective user ID # is root. Password is stored in /etc/ldap.secret (mode 600) #rootbinddn cn=manager,dc=padl,dc=com # The port. # Optional: default is 389. #port 389 # The search scope. scope sub #scope one #scope base # Search timelimit #timelimit 30 # Bind timelimit # If using Netscape SDK 4.x, this is used to set the TCP connection timeout # as well as the bind timelimit. #bind_timelimit 30 # Filter to AND with uid=%s pam_filter host=serverA # The user ID attribute (defaults to uid) #pam_login_attribute uid # Search the root DSE for the password policy (works # with Netscape Directory Server) #pam_lookup_policy yes # Group to enforce membership of #pam_groupdn cn=solaris,o=admin # Group member attribute pam_member_attribute member # Template login attribute, default template user (can be overriden by value # of former attribute in user's entry) #pam_login_attribute userPrincipalName #pam_template_login_attribute uid #pam_template_login nobody # HEADS UP: the pam_crypt, pam_nds_passwd, and pam_ad_passwd options # are no longer supported. # Do not hash the password at all; presume the directory server will do it, # if necessary. This is the default. #pam_password clear # Hash password locally; required for University of Michigan LDAP server, # and works with Netscape Directory Server if you're using the UNIX-Crypt # hash mechanism and not using the NT Synchronization service. #pam_password crypt # Remove old password first, then update in cleartext. Necessary for use # with Novell Directory Services (NDS) pam_password nds # Update Active Directory password, by creating Unicode password and # updating unicodePwd attribute. #pam_password ad # Use the OpenLDAP password change extended operation to update the password. #pam_password exop # Netscape SDK LDAPS ssl on # Netscape SDK SSL options sslpath /etc/ssl/certs/cert7.db # OpenLDAP SSL mechanism # start_tls mechanism uses the normal LDAP port, LDAPS typically 636 #ssl start_tls #ssl on # OpenLDAP SSL options # Require and verify server certificate (yes/no) # Default is "no" #tls_checkpeer yes # CA certificates for server certificate verification # At least one of these are required if tls_checkpeer is "yes" #tls_cacertfile /etc/ssl/ca.cert #tls_cacertdir /etc/ssl/certs # SSL cipher suite # See man ciphers for syntax #tls_ciphers TLSv1 # Client sertificate and key # Use these, if your server requires client authentication. #tls_cert #tls_key

eDirectory Requirements

To provide the information necessary for each of the Solaris modules to properly set up and maintain a user session, the eDirectory schema must be extended.

Required Object Classes and Attributes

The following LDAP Object Classes are required. The names for all four object classes are the same in LDAP as in eDirectory. Each object class should be created as an auxiliary class in the eDirectory schema:

  • posixAccount

  • shadowAccount

  • posixGroup

  • Account

The following LDAP attributes are associated with the posixAccount object class:

  • uidNumber

  • gidNumber

  • gecos

  • homeDirectory

  • loginShell

The following attributes are associated with the posixAccount object class. These attributes already exist and are associated with a User object in eDirectory when it is created:

  • uid (uniqueID in eDirectory)

  • cn

  • userPassword (This is actually an RSA public/private key pair stored in eDirectory. The LDAP server handles the necessary transformation of data when working with this attribute.)

  • description

The following attributes are associated with the shadowAccount object class (there are no required attributes of this object class). All of the attributes have the same name in LDAP as in eDirectory:

  • shadowLastChange

  • shadowMin

  • shadowMax

  • shadowWarning

  • shadowInactive

  • shadowExpire

  • shadowFlag

The following attributes are associated with the posixGroup object class:

  • cn (This is a required attribute and is already associated with groups in eDirectory.)

  • gidNumber

  • memberUid

  • description

The following attributes are associated with the Account object class described in RFC 1274:

  • host

The following listing is the LDIF file used to extend the production servers' eDirectory schema to support these RFC 2307 attributes.

# Attributes for RFC2307:posixAccount dn: cn=schema changetype: modify add: attributetypes attributeTypes:( 1.3.6.1.1.1.1.0 NAME 'uidNumber' DESC 'uidNumber' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE) dn: cn=schema changetype: modify add: attributetypes attributeTypes: ( 1.3.6.1.1.1.1.4 NAME 'loginShell' DESC 'loginShell' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE) dn: cn=schema changetype: modify add: attributetypes attributeTypes: ( 1.3.6.1.1.1.1.1 NAME 'gidNumber' DESC 'gidNumber' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE) dn: cn=schema changetype: modify add: attributetypes attributeTypes: ( 1.3.6.1.1.1.1.2 NAME 'gecos' DESC 'gecos' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE) dn: cn=schema changetype: modify add: attributetypes attributeTypes: ( 1.3.6.1.1.1.1.3 NAME 'homeDirectory' DESC 'homeDirectory' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE) # Attributes for shadowAccount dn: cn=schema changetype: modify add: attributetypes attributeTypes: ( 1.3.6.1.1.1.1.11 NAME 'shadowFlag' DESC 'shadowFlag' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE) dn: cn=schema changetype: modify add: attributetypes attributeTypes: ( 1.3.6.1.1.1.1.5 NAME 'shadowLastChange' DESC 'shadowLastChange' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE) dn: cn=schema changetype: modify add: attributetypes attributeTypes: ( 1.3.6.1.1.1.1.10 NAME 'shadowExpire' DESC 'shadowExpire' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE) dn: cn=schema changetype: modify add: attributetypes attributeTypes: ( 1.3.6.1.1.1.1.9 NAME 'shadowInactive' DESC 'shadowInactive' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE) dn: cn=schema changetype: modify add: attributetypes attributeTypes: ( 1.3.6.1.1.1.1.8 NAME 'shadowWarning' DESC 'shadowWarning' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE) dn: cn=schema changetype: modify add: attributetypes attributeTypes: ( 1.3.6.1.1.1.1.7 NAME 'shadowMax' DESC 'shadowMax' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE) dn: cn=schema changetype: modify add: attributetypes attributeTypes: ( 1.3.6.1.1.1.1.6 NAME 'shadowMin' DESC 'shadowMin' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE) # Attributes for RFC1274:Account dn: cn=schema changetype: modify add: attributetypes attributeTypes: ( 0.9.2342.19200300.100.1.9 NAME 'host' DESC 'host' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15

The following listing is the LDIF file used to extend the eDirectory schema to support the RFC 2307 object classes.

dn: cn=schema changetype: modify add: objectclasses objectClasses: (0.9.2342.19200300.100.4.5 NAME 'account' DESC 'account' AUXILIARY MAY host) dn: cn=schema changetype: modify add: objectClasses objectClasses: (1.3.6.1.1.1.2.0 NAME 'posixAccount' DESC 'posixAccount' AUXILIARY MAY (uidNumber $ loginShell $ gecos $ gidNumber $ homeDirectory )) dn: cn=schema changetype: modify add: objectClasses objectClasses: (1.3.6.1.1.1.2.1 NAME 'shadowAccount' DESC 'shadowAccount' AUXILIARY MAY (shadowLastChange $ shadowFlag $ shadowExpire $ shadowInactive $ shadowMax $ shadowMin $ shadowWarning ))

Note that before importing these attribute and object class LDIF files, you must delete two attribute mappings from the LDAP Group mappings tab:

  • LDAP: uidNumber NDS: UID

  • LDAP: gidNumber NDS: GID

From an LDAP perspective, uid and gid already exist since they are mapped to UID and GID in the native eDirectory schema. If these two mappings are not deleted, the schema extensions described above will fail.

Directory Trustee Settings

Since UNIX user account information will be stored in eDirectory, it may be desirable to protect that information from unwanted viewing by users who are not authorized to use the information. Typically, in a Solaris environment, a user must be authenticated to the system in order to view the account information for that system.

It is also necessary to make sure the pam_ldap and nss_ldap modules are able to retrieve the information they need to properly establish a user session. Some of this information must be available before the user has authenticated to the directory.

In order to meet both objectives, a special user account used exclusively for retrieving this information should be created in eDirectory. This account should be referenced using the binddn and bindpw parameters in the ldap.conf file. The ldap.conf file permissions should be set to 500. (700 is also acceptable if permanent write permission to this file is desired for the root user.)

This account should have the Browse right to the following attributes:

  • uidNumber

  • gidNumber

  • gecos

  • homeDirectory

  • loginShell

  • shadowLastChange

  • shadowMin

  • shadowMax

  • shadowWarning

  • shadowInactive

  • shadowExpire

  • shadowFlag

The rights of the special user account should be similar to the following ACL listing:

dn: o=company acl: 32#subtree#cn=Server,o=Company#[All Attributes Rights] acl: 16#subtree#cn=Server,o=Company#[Entry Rights] acl: 0#subtree#cn=pamadmin,ou=DS-Services,o=Company#[All Attributes Rights] acl: 1#subtree#cn=pamadmin,ou=DS-Services,o=Company#[Entry Rights] acl: 3#subtree#cn=pamadmin,ou=DS-Services,o=Company#gecos acl: 3#subtree#cn=pamadmin,ou=DS-Services,o=Company#gidNumber acl: 3#subtree#cn=pamadmin,ou=DS-Services,o=Company#host acl: 3#subtree#cn=pamadmin,ou=DS-Services,o=Company#loginShell acl: 3#subtree#cn=pamadmin,ou=DS-Services,o=Company#uidNumber acl: 3#subtree#cn=pamadmin,ou=DS-Services,o=Company#shadowExpire acl: 3#subtree#cn=pamadmin,ou=DS-Services,o=Company#shadowInactive acl: 3#subtree#cn=pamadmin,ou=DS-Services,o=Company#shadowLastChange acl: 3#subtree#cn=pamadmin,ou=DS-Services,o=Company#shadowMax acl: 3#subtree#cn=pamadmin,ou=DS-Services,o=Company#shadowMin acl: 3#subtree#cn=pamadmin,ou=DS-Services,o=Company#shadowWarning acl: 3#subtree#cn=pamadmin,ou=DS-Services,o=Company#shadowFlag

Values in this syntax are encoded according to the following notation:ndsAcl = privileges "#" scope "#" subjectname "#" protectedattrname

The privileges field is a number that represents the kind of access being granted. Performing a bitwise OR on the numbers that represent the desired access arrives at this number. The table below specifies the values:


Value
Individual Attributes
[Entry Rights]

1

Compare Attributes

Browse Entry

2

Read Attributes

Add Entry

4

Write, Add, Delete Attributes

Delete Entry

8

Add/Delete Self

Rename Entry

16

(none)

Supervisory

32

Supervisory

(none)

The scope field specifies whether or not the privileges are applied to the target entry (the entry containing the ACL) or the target and its subtree ("entry" or "subtree").

The subjectname either contains the distinguished name of the entry being granted the privileges, or one of these special values:

  • [Self] - Indicates the user authenticated in the current connection. This can only be used in the Add Entry operation.

  • [Creator] - The user who created the object. This can only be used in the Add Entry operation.

  • [Public] - Includes all objects in the tree.

  • [Inheritance Mask] - Filters or masks the privileges granted to an object.

  • [Root] - Denotes the directory tree root object.

The protectedattrname field either names a specific attribute that the privileges are applied to, or it contains one of the following special values:

  • [Entry Rights] - Privileges apply to the entire object, rather than an attribute.

  • [All Attributes Rights] - Privileges apply to all attributes of the object.

Using SSL

SSL is used to provide an encrypted communications channel between the Solaris server and the eDirectory server running LDAP. This does not provide communication encryption between the Solaris server and other clients (such as Telnet and FTP). For that functionality, it would be necessary to use secure versions of those clients or clients that provide similar functionality (such as SSH or Secure FTP). If SSL is not used, all communications between the Solaris servers and the eDirectory server (including passwords) will be cleartext.

In order to establish an SSL session, the Solaris server must have a copy of the LDAP server's Trusted Root. The Trusted Root must be stored in a file format used by the Netscape LDAP SSL library known as cert7.db format. This is also typically the name of the file used to actually store the key.

Instructions for installing an existing public key from an LDAP server into a cert7.db file and placing it on the Solaris server are included in the implementation section of this AppNote.

Using Filtered Replicas

If filtered replicas are used on the LDAP server(s) that are being access by the Solaris systems, the following object classes should have all attributes on the replica:

  • User

  • posixAccount

  • shadowAccount

  • posixGroup

Other attributes may be present depending on the need of other applications, such as a TeamSite object class created to manage Interwoven's TeamSite 5.0 application.

Implementation Guidelines and Procedures

Much of the implementation process is automated through the use of the pre-built schema files. Procedures are identified below for extending the eDirectory schema, installing the modules on a Solaris system, and installing the cert7.db file with the necessary public key(s).

Extending the eDirectory Schema

The attributes previously identified as being part of the posixAccount object class should be extended into the eDirectory schema. This can be done via Novell's Import/Convert/Export (ICE) utility, ldapmodify, or any other LDAP v3- compliant LDIF processor.

Remember to delete the two LDAP:NDS attribute mappings as described above. Then input the attribute file and the object class file, in that order.

Once this is completed, set the directory trustee permissions as specified above for a special eDirectory access User object that will be used only for eDirectory access by the PAM LDAP modules.

Installing the Modules on Solaris

Installation of the necessary components on the Solaris system involves copying three files (pam_ldap.so, pam_nss.so, and libldapssl40.so) and modifying the three configuration files identified earlier in this AppNote (ldap.conf, pam.conf and nsswitch.conf).

Copy the pam_ldap.so module to /usr/lib/security and set up the permissions as follows:

lrwxrwxrwx 1 root root     15 pam_ldap.so -> ./pam_ldap.so.1 -rwxr-xr-x 1 root sys 109128 pam_ldap.so.1

Copy the pam_nss.so module to /usr/lib and set up the permissions and symbolic links as follows:

lrwxrwxrwx 1 root bin     15 nss_ldap.so -> ./nss_ldap.so.1 -rwxr-xr-x 1 root bin 945144 nss_ldap.so.1

Copy the libldapssl40.so module to /usr/lib and set up the permissions as follows:

-rwxr-xr-x 1 root sys 1574000 libldapssl40.so

You can now configure the Solaris system as identified earlier to allow users to authenticate to the Solaris system using their eDirectory user credentials.

Configuring SSL with cert7.db

As mentioned earlier, the Netscape SSL library requires the Trusted Root to be stored in a cert7.db format. You will need two tools from Netscape that allow a Trusted Root certificate from the Novell PKI system to be converted into the cert7.db format. These tools are named KEYUTIL.EXE and CERTUTIL.EXE, and you can download them from http://developer.netscape.com.

Once you have obtained these two tools, follow these steps to complete the setup.

  1. Export the Trusted Root from the Novell CA via ConsoleOne. If a third-party digital certificate is being used, export the Trusted Root from the KMO object created to store the private key that is being used by the LDAP Server configuration object. Export the Trusted Root using the .der format.

  2. Run the KEYUTIL.EXE utility using the -N option. This will create a new, empty keystore.

  3. Run the CERTUTIL.EXE utility using the -N option. This will create a new, empty certificate store.

  4. Run CERTUTIL.EXE with the following options:

    certutil -A -n LDAP -t "C,C,C" -i xxxxx.der

    Replace xxxxx.der with the name of the .der file exported from the Novell CA.

  5. Copy the newly-created cert7.db file to the /etc/ssl/certs directory on the Solaris server. The system can now be configured to access eDirectory via an SSL encrypted connection.

  6. Edit the ldap.conf file and change the following lines as indicated:

    # Netscape SDK LDAPS ssl on # Netscape SDK SSL options sslpath /etc/ssl/certs/cert7.db

The system should now be able to communicate via SSL with eDirectory.

Conclusion

This AppNote has discussed the design and implementation details of a project undertaken to allow users of UNIX systems to consume user account and group information from eDirectory using LDAP.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates