AppNote: PAM Integration with eDirectory and LDAP

Novell Cool Solutions: AppNote
By Madhavi Phanse

Reader Rating from 2 ratings

Digg This - Slashdot This

Posted: 29 Mar 2005

PAM Integration with eDirectory and LDAP Server

Madhavi Phanse
Senior Software Engineer
pmadhavi@novell.com

Introduction

User authentication, to manage the user account and session is an important part of any service. This AppNote provides as overview of how to PAM-enable the OES Linux pure-ftpd service, using Novell eDirectory through LDAP Server. It covers the PAM concepts and gives an introduction to LDAP, as well as the installation and configuration aspects of PAM enabling pure-ftpd. Steps for extending eDirectory schema and adding, modifying new users/groups using LDAP tools are also included.

Pluggable Authentication Module

Pluggable Authentication Module (PAM) is the UNIX interface that enables applications to use an independent mechanism for authentication, without having to write a separate one. PAM also provides functionalities such as accounts management, session management and password management. This configuration can be set by adding a single entry in the /etc/pam.conf file; or, each application can have its own configuration file under the /etc/pam.d directory.

An entry in the /etc/pam.conf file will have the following format:

service-name module-type control-flag module-path arguments

Only module-path and argument entries are case sensitive. The service-name is the name of the service associated with this entry, such as telnetd, ftpd, etc. (In the case of telnet, ftp services having their own configuration file under the /etc/pam.d "service-name" token above would be redundant.)

Supported Module Types

The following module types are supported by PAM.

Auth - Provides authentication to the user. It establishes that the user is who he claims to be, by instructing the application to prompt the user for a password.

Account - Performs non-authentication based account management. For example, this could be restricting or permitting access to a service, based on a condition or currently available system resources.

Session - Handles any session-related management, such as logging of information after a successful user login.

Password - Required for updating the password associated with the user.

Sample pure-ftpd Entry

An entry in /etc/pam.d/pure-ftpd will look something like the following:

Auth     required/sufficient      /lib/security/pam_ldap.so     arg1,arg2,etc.

where "Auth" is the type of module stack, "required/sufficient" are Control Flag values, "/lib/security/pam_ldap.so" is the module path, and "arg1,arg2,etc." is the list of arguments passed to the module. For the module path, you can also use /lib/security/pam_nam.so.

Each of these elements is explained below.

About the Control Flag

The Control Flag indicates how the PAM library will react to the success or failure of the module it is associated with. This flag is a single keyword defined to indicate the severity of the success or failure of a specific module.

When multiple modules are be stacked in the PAM configuration file, the application is not aware that modules are being stacked. It receives the authentication result for the combined stack rather than a specific module in the stack. So without the Control Flag, the application would not know which of the modules failed to authenticate.

Control Flag Values

Required:

The success of the module is required for the module-type facility to succeed. If this value is specified in the auth (authentication) module in the stack, the success of that module is important in evaluating the authentication to the application/user. Failure of this module will not be apparent to the user until all of the remaining modules in the module stack of same module type have executed.

Requisite:

If the module returns a failure, control is directly returned to the application.

Sufficient:

In a stack of same type of modules (such as "auth" modules), the "sufficient" value first looks for the success of all previous modules in the stack with the control flag set to "required." Then if this module succeeds, no more stacked modules with the control flag "sufficient" will be invoked. So, in a stack of "auth" modules where no "required" type of module fails, one successful "sufficient" control type can grant authentication to the application. However, failure of this module does not diminish the success of the stack.

Optional:

The module is not critical for the success or failure of the user's application for service. In case of previous failures, this module can determine the success or failure of the stack. ??

Module-path

This is the path-name of the dynamically loadable object file, or the pluggable module itself. The path indicates the PAM library providing the functionality specified by module-type. By default, the path is /lib/security. For example, the pam_ldap.so and pam_nam.so libraries that support the "auth" module-type for FTP service on a Linux machine can be found under /lib/security.

Arguments

The arguments are the tokens passed to the module when it is invoked.

Lightweight Directory Access Protocol

Lightweight Directory Access Protocol (LDAP) is used to look up information from a server or directory. It is also used for storing user account information so multiple and distributed applications can use a single list of authorized users.

Each time you log in through ftp, a binding is done from your PAM_LDAP module to the directory server. The server will then validate the presented credentials and allow you to authenticate. This is achieved through the open-LDAP client on OES-Linux, which takes care of LDAP binding to eDirectory LDAP server.

LDAP uses LDIF as its data interchange format. LDIF files are a common, text-based format for describing directory structures; these structures are derived from schemas. Schemas are detailed specifications that include dependencies, required types of data, role description and other options for each attribute or object class found in the eDirectory.

To store UNIX user information in eDirectory you need to have the POSIX account class for the users in eDirectory. This can be done by extending the eDirectory schema. By default, the eDirectory schema is not extended with RFC2307; it ships with the schema files rfc2307-nis.sch and rfc2307-usergroup.sch. For Linux, these files can be found under the directory /usr/lib/nds-schema; for NetWare, these files can be found under the directory sys\system\schema. LDAP tools can be used to extend the eDirectory schema to include the rfc2307 schema.

Name Service Switch

The Name Service Switch (NSS) is similar to PAM in terms of allowing applications to use different sources for authentication, but its primary purpose is simple lookups (such as mapping from a Login ID to a UID). The NSS_LDAP module gets user-attribute related information from the LDAP server for UNIX/LINUX workstations. It also provides LDAP/ DNS resolution for PAM modules. Depending on the configuration specified in nsswitch.conf file, it decides whether to look in local files for user/group attribute information or to ask the LDAP server to get the information from eDirectory.

PAM-LDAP Setup for NSS

In this setup, when an ftp client requests login to the ftp server, PAM takes care of handling login-related tasks, as shown in the following figure. Here is the basic task flow:

PAM requests NSS for user login information.
NSS sends a LDAP bind request to eDirectory through LDAP server.
The openldap2-client forwards the NSS request to LDAP server.
On a successful bind a user search - for new user login- is done to validate the user credentials.

PAM provides its own libraries for UNIX/LINUX and the configuration file(s). The application needing the PAM libraries can either modify the PAM.conf file (/etc/ directory) or can add its own configuration file (/etc/pam.d directory) with the relevant authentication stack.

The PAM configuration file on OES-Linux used in this setup is /etc/pam.d/pure-ftpd. The PAM module handling login requests is /lib/security/pam_ldap.so. The NSS configuration file is /etc/nsswitch.conf, and the NSS library processing the PAM requests is nss_ldap.so.

Figure 1: PAM-LDAP setup

Alternative approach using NAM

The same results above can be achieved using PAM-NAM services instead of PAM-LDAP services. Novell Account Management for UNIX (NAM) is an eDirectory-enabled application that simplifies and unifies user and group management on UNIX-based platforms. With NAM, you can eliminate many complexities of administering a mixed platform network. You can configure and use these services to open the source LDAP standards specified above. The PAM requests for authentication and credential validation forwarded to NAM will be directed to files or to eDirectory through nss_nam. The related module is /usr/lib/nss_nam.so.

Here in the NAM setup, /lib/security/pam_nam.so will replace the pam_ldap.so module, and /usr/lib/nss_nam.so will replace the nss_ldap.so module. However, the nsswitch.conf functionality remains same, irrespective of NAM and LDAP services.

Installation

For non-NAM services, as shown in the figure above, two servers are required in the setup: Server A with OES-Linux or SLES, and Server B with OES-Linux/NetWare. For NAM services, if the server and client are both OES-Linux/SLES, then only one server needs to be used in the setup, with all packages specified below installed and configured on it. For LDAP services, however, the single- server method could cause problems for the NDSServ package and openldap2-client package.

Server A will run the pure-ftpd, which needs to be PAM-enabled. The setup for LDAP and NAM are described below.

Server A: LDAP Setup

The OpenLDAP2 client will act as the LDAP client for the remote LDAP server. Following are the libraries required to be installed/selected when installing Linux:

/lib/security/pam_ldap.so
nss_ldap.so
openldap2-client.so

Server A: NAM Setup

For the alternate NAM setup, the following libraries are required to be installed/selected when installing Linux:

/lib/security/pam_nam.so
/usr/lib/nss_nam.so

Server B Setup

Server B will be where eDirectory will be installed /configured and LDAP server will be configured to store user authentication information to be stored in eDirectory.

Note the following prerequisites:

eDirectory installed and configured
Extended schema (eDirectory comes with a default LDAP server)
NDSServ packag

The configuration steps include:

PAM-enabling pure-ftpd
Using eDirectory to store FTP user information through LDAP Server
Integrating PAM with LDAP for user credentials stored in eDirectory

PAM-enabling of pure-ftpd

PAM-enabling of pure-ftpd can be achieved by modifying the /etc/pam.d/pure-ftpd file with required functionality changes. These changes are for authentication management, account management and session management.

By default, the pure-ftpd package that ships with OES-Linux is PAM-enabled for local UNIX profiles using the pam_unix.so library. However, the pure-ftpd configuration file (/etc/pam.d/pure-ftpd) must be modified to fit the authentication requirements, using the appropriate PAM library for eDirectory authentication.

Using eDirectory to store FTP user information through the LDAP Server

To eDirectory-enable any application so it uses a directory for storing and validating authentication information, you need to follow LDAP standards. That will ensure eDirectory tree connectivity using a referral on LDAP client (in /etc/ldap.conf file) and extend the eDirectory schema (using 'ndssch' utility) on the LDAP server.

By default, UNIX/Linux user/group accounts are POSIX accounts. Each user and group is assigned uid and gid number, respectively, and all users under same group will have the same gid number.

This information is maintained in local files (/etc/passwd and /etc/group) on the UNIX machine. But eDirectory does not support these attributes by default for user/groups created in eDirectory. So you need to extend the rfc2307 eDirectory schema to support these attributes (make it POSIX-compliant).

With the NAM setup, you do not need to extend the schema manually; the namconfig utility does that internally for you. You just need to specify the preferred eDirectory server in /etc/nam.conf, then run namconfig.

Integrating PAM with LDAP for User Credentials Stored in eDirectory

To get PAM/LDAP integration of this type, you need to redirect calls related to PAM user login to eDirectory. This is where NSS (Name Service Switch) comes into the picture. The figure below shows how the ftp login request is processed.

Figure 2: FTP User Login request

When a login request comes to Server A, PAM (pam_ldap.so) directs the request to the openldap2-client, which forwards the request to the LDAP Server (on Server B).

For NAM, the pam_nam.so library takes care of forwarding the request to the eDirectory LDAP Server.

For an FTP session, PAM asks NSS (nss_ldap.so/nss_nam.so) to retrieve the information, as shown in Figure 3. In the absence of nss_ldap.so, pam_ldap can get only the authentication information from eDirectory. For the session, user uid and gid validation are required through nss_ldap.

NSS looks into its own configuration file (/etc/nsswitch.conf) to check whether to direct requests for user information to local files, or to services like NAM/LDAP to get the information from eDirectory.

Figure 3: FTP Session

To configure Server A,

1. Link to pam_ldap.so to use LDAP Server for authentication, by changing the authentication stack in /etc/pam.d/pure-ftpd to refer to pam_ldap.so. For NAM services, note that "pam_nam.so" will replace the "pam_ldap.so" shown below.

2. Add the following lines to /etc/pam.d/pure-ftpd:

auth sufficient pam_ldap.so
account sufficient pam_ldap.so
session optional pam_ldap.so

Note: By default pure-ftpd is PAM-enabled.

3. Modify /etc/ldap.conf (Configuration file for the pam_ldap and nss_ldap modules.)

This involves modifying the host, port, base and binddn to point to LDAP Server and bindpw. "Host" is the IP address of LDAP Server; "port" is LDAP TCP port; "base" is the location in the eDirectory tree where the search starts, for subordinate reference configuration (configuring for superior references is not possible). "Binddn" is the identity you use for initial binding to the tree and for searching for the user in the ftp login request. Each user must log in with name and password, then the tree connectivity is done at the basedn. The username DN becomes the binddn after a successful search with the initial basedn.

For example, if you want to give access to users under container "o=novell", the basedn will be "o=novell". The PAM password is "nds", and the remaining things can be left as default. See Figure 4 below for details.

If you do not want bind password to be sent on wire in clear text you can set 'ssl on' Most of the configuration options in /etc/ldap.conf by default are set to work with OpenLDAP server.

Figure 4: /etc/ldap.conf contents

For NAM services setup, you need to modify /etc/nam.conf to add the preferred eDirectory server IP Address, as shown in Figure 5 below.

Figure 5: /etc/nam.conf

4. Modify /etc/nsswitch.conf to add the following entries:

passwd: files ldap
group: files ldap

The above sequence for "files" and "ldap" acts as a switch for nss_ldap.so. When PAM asks nss for login information, it will look in "files" first. If nothing is returned, it will forward the request to LDAP server.

For NAM setup, replace the "ldap" value above with "nam".

To configure Server B (OES-Linux or NetWare),

1. Modify /etc/ldap.conf to add "pam_password nds".

2. Extend eDirectory schema with the ndssch utility using the following files:

/usr/lib/nds-schema/rfc2307-nis.sch
/usr/lib/nds-schema/rfc2307-usergroup.sch

For example:

ndssch -h server IP:524 -t tree-name cn=admin.o=novell /usr/lib/rfc2307-nis.sch
ndssch -h server IP:524 -t tree-name cn=admin.o=novell /usr/lib/rfc2307-usergroup.sch

Note that ndssch uses NDAP, which is running on port 524. Occasionally you may need to specify the whole path for ndssch (/usr/ldaptools/bin/ndssch).

To configure for eDirectory on NetWare (5.x and above),

Follow the steps below to use NWConfig.nlm to extend the schema on NetWare servers. Schema files (*.sch) that come with eDirectory are installed into the sys:\system\schema directory.
At the server console, enter "nwconfig".
Choose Directory Options > Extend Schema.
Log in as a user with administrative rights.
Press F3 to specify a different path.
Type sys:\system\schema.
Press Enter.
Disable 'Require TLS for Simple Binds with password' option to value 'no'. This can be achieved from linux server with openldap2-client installed on it, that is from Server A console in our setup.

Syntax:

ldapconfig -s "Require TLS for Simple Binds with Password:no" -p <IP add of NW Server>

To configure Server B for NAM setup, run namconfig with the syntax shown below:

namconfig add -a adminFDN -r base_context -w workstation_context -S ldap_servername [:port] -l sslport
Example:
namconfig add -a cn=admin,o=novell -r o=novell -w o=novell -S MYSERVER:389
Example (secure LDAP):
namconfig add -a cn=admin,o=novell -r o=novell -w o=novell -S MYSERVER:389 -l 636

To configure users and groups for eDirectory,

Create an eDirectory group and add the PosixGroup extension to it. These groups are used as primary groups for Linux users.
Create an eDirectory user and add PosixAccount for it.
Associate the user with the groups you created earlier.
You can also configure existing eDirectory user/group for pure-ftpd by adding POSIX extensions to them.

PosixAccount/PosixGroup

UNIX user and group accounts are POSIX by default. The user has group membership and certain permissions that are mandatory by standards. On a typical Linux system using files for authentication, the account information is stored in "/etc/passwd" and "/etc/shadow". However, in eDirectory this information is maintained in attributes of the POSIX schema. But because directory schema by default does not support these attributes and does not mandate them, you must add the POSIX extension to that user/group explicitly.

Using the LDAP Service to Add Groups

To add a group using the LDAP service (OES-Linux and NetWare), you use ldapmodify, or ldapadd if you're creating a new user/group creation. This Posix extension information will then be stored in eDirectory.

Here is the syntax for group add:

ldapadd -x -h server IP -D binddn -w password 
dn: cn=ftpgrp,o=novell 
gidNumber: 
memberuid:
objectClass:Top
objectClass:namedObject
objectClass:posixGroup

The fields in the LDAP group record are:

cn: Group name
gidNumber: Group ID Number
memberuid: User ID of a user who is a member of this group. Usually groups have many memberuid fields.
objectClass: The node type

To add a user, use the following syntax:

ldapadd -x -h server IP -D binddn -w password 
dn: cn=user,o=novell
sn:sn1
userpassword:
uid:
gid:
objectClass:person
objectClass:inetorgperson

The fields in the LDAP user record are:

uid: User Identification code
cn: Full name
sn: Surname
givenname (optional): Given (usually first) name
objectClass: The type of record that this node is
ou: Organizational Unit
uidnumber:User ID Number (what the UID is mapped to)
gidnumber: Group ID Number (the user's primary group)
homedirectory: The user's home directory (usually a network drive)
loginshell (optional): The login shell of the user (full path)

If the user is already created, you need to do an ldapmodify separately. Otherwise, you can use the attributes below as part of the ldapadd itself.

ldapmodify -x -h server IP -D binddn -w password 
dn: cn=user,o=novell
changetype:modify
add:objectClass
objectClass:posixAccount
-
add:uid
uid:user
-
add:uidNumber
uidNumber:
-
add:gidNumber
gidNumber:
-
add:homeDirectory
homeDirectory:

Notes: The gidNumber specifies the user with uid belongs to that specific group. You need to modify /etc/passwd and /etc/group if uid and gid already exist. You can use 'ndstrace' for debugging if needed. Before adding a new user and group you can do an ldapsearch for 'schema' to find out the available classobjects supported for User and Group. Then you can add/modify the new objects as specified in the syntax above.

Using the NAM service to Add Groups

For NAM service setup, you do not need to add the Posix extension to the user/group externally. NAM takes care of creating the posix extension for you. You just need to add group and user with following syntax:

namgroupadd [-a adminFDN][-w bindpasswd] [- x group_context] [-A | -W workstation_name [,workstation_name...]] [-g gid[-o]] [-P] [-n] group_name

Example 1:

namgroupadd -W MYSERVER -g 110 grp1
namuseradd [-a adminFDN][-w bindpasswd][-x user_context][-c comment][-d directory][-e expiry_date][-g primary_groupFDN][-G groupFDN][-G groupFDN]...][-m [-k skeldir]][-n][-s shell][-D][-P][-p passwd][-u uid][-o]] user_name

Example 2:

namuseradd -a cn=admin,o=novell -x o=novell - g cn=grp1,o=novell User1

The NAM service seems to be simpler for setting up and adding the new group and users. This service also enables you to move existing UNIX users to eDirectory. Although PAM integration for eDirectory can be achieved either way - using the LDAP service or the NAM service - the NAM Service approach as an eDirectory interface is more feature-rich.

To add Posix information in the NetWare eDirectory setup, using ConsoleOne:

In ConsoleOne, select the user/group object.
Right-click the object and select Properties.
Click the UNIXProfile tab.
For a group object add "gid" information - for a user object add uid, group, and homedirectory information.

To add Posix information in the NetWare eDirectory setup, using iManager:

In iManager, select the role 'Schema'.
Select the 'Object Extension' task.
Extend the schema for the group object by adding gid for the Posix group.
Extend the schema for the user object by adding uid, group, home directory information for the Posix account.

AppNote: PAM Integration with eDirectory and LDAP

Novell Cool Solutions: AppNote
By Madhavi Phanse

Introduction

Pluggable Authentication Module

Sample pure-ftpd Entry

Lightweight Directory Access Protocol

Name Service Switch

Related Links

Reader Comments

AppNote: PAM Integration with eDirectory and LDAP

Novell Cool Solutions: AppNoteBy Madhavi Phanse

Introduction

Pluggable Authentication Module

Sample pure-ftpd Entry

Lightweight Directory Access Protocol

Name Service Switch

Related Links

Reader Comments

Novell Cool Solutions: AppNote
By Madhavi Phanse