Communication Manager Administrator Logins

Issue 1.4 April 2009

Contents 1. Introduction 2. Reference Material 3. The Linux PAM 3.1 Overview 3.2 PAM Configuration File Structure 3.3 PAM Modules 3.4 Related Modules 3.5 PAM Configuration File Content 3.6 Constraints and Recommendations 4. Communication Manager Default PAM Files 5. Configuration file for "su" 6. Making Changes 7. RAMDISK 8. Recovery 9. User Login Characteristics 10. Home Directories 11. Configuring Multiple Servers 12. Tested AAA Server Configurations 12.1 LDAP / NSS / NSCD 12.1.1 Open LDAP 12.1.2 OpenLDAP Server 12.1.3 Other LDAP servers 12.2 RSA SecurID 12.3 SafeWord 12.4 RADIUS 12.5 Other Configurations 13. Other PAM Features 13.1 pam_access 13.2 pam_cracklib 13.3 Login Messages (pam_issue and pam_motd) 13.3.1 pam_issue 13.3.2 pam_motd (Message of the Day) 13.3.3 SSH 13.3.4 Telnet 13.3.5 HTTP 13.3.6 FTP/SFTP 13.4 pam_lastlog 13.5 pam_limits 13.6 pam_tally 13.7 pam_time

1 1 2 2 4 6 9 10 14 15 16 17 19 19 19 20 20 22 22 22 27 30 32 34 38 40 40 40 41 42 43 43 43 44 44 45 45 45 45 46

1. Introduction This document provides an overview of the processing of administrator logins in Communication Manager (CM). Beginning with release 4.0, customer access to the Linux Pluggable Authentication Module (PAM) subsystem’s configuration files is supported. The PAM subsystem controls user1 login processing. Both local host accounts as well as Authentication, Authorization, and Accounting (AAA) via an external server (e.g. LDAP) are supported. In releases prior to Communication Manager 4.0, all logins were required to be local host accounts and login administration was accomplished through the Communication Manager System Administration Terminal (SAT) interface. Beginning in CM4.0, the requirement that all logins be local host accounts is removed for most accounts, and management of user accounts is removed from the SAT. Standard Linux commands (e.g. useradd) plus enhanced "wrapper" commands (e.g. cmuseradd) as well as web pages are provided to configure logins appropriate to the CM platform. Note that this document is not a programming or administration manual. Rather, it is a collection of information related to the supported features and configuration of the PAM subsystem as it pertains to a Communication Manager server. Administrators will need to study the PAM Administrator’s Guide, documentation for individual PAM modules, documents for the applications running on external servers, and the Administrator Guide for Avaya Communication Manager before attempting to administer this aspect of a CM server. Root access to the CM server is required to perform this administration. This document is targeted at experienced Linux administrators. The information in this document and the features described apply specifically to Communication Manager servers. This information specifically does not apply to the Server Availability Management Processor (SAMP) card present in selected Communication Manager servers.

2. Reference Material Key documentation on PAM can be obtained from the kernel web site here: http://www.kernel.org/pub/linux/libs/pam/ There are 3 PAM documents of interest on the kernel site: • The System Administrators’ Guide: http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html • The Module Writers’ Manual: http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/Linux-PAM_MWG.html • The Application Developers’ Manual: http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/Linux-PAM_ADG.html The original RFC for PAM can be obtained form the Open Group web site here: • http://www.opengroup.org/tech/rfc/mirror-rfc/rfc86.0.txt LDAP documents: • • • •

http://www.tldp.org/HOWTO/LDAP-HOWTO/index.html http://www.faqs.org/docs/Linux-HOWTO/LDAP-Implementation-HOWTO.html http://www.ldapman.org/articles/ http://www-128.ibm.com/developerworks/linux/library/l-openldap/ An LDAP Server and associated tools • http://www.openldap.org

1. Throughout this document "user" refers to administrative logins and specifically excludes telephone users.

Issue 1.4

Communication Without Boundaries

1

• • • • • •

A GPL’d PAM LDAP module -http://www.padl.com LDAP Howto -http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/pdf/ http://www.tldp.org/HOWTO/LDAP-Implementation-HOWTO/pamnss.html Security with LDAP, a white paper by Andrew Findlay -http://www.skills-1st.co.uk/papers/afindlay.html#ldapsec20020214 System Administration Using LDAP, a paper by Brad Marshall -http://quark.humbug.org.au/publications/system_auth/sage-au/system_auth.html SASL software-http://asg.web.cmu.edu/sasl/sasl-library.html

RADIUS documents: • Remote Authentication Dial In User Service (RADIUS) RFC 2865. A free radius client -• http://freeradius.org/pam_radius_auth/ or http://www.linux.org/apps/AppId_159.html Another client implementation -• http://mail.python.org/pipermail/python-announce-list/2002-October/001744.html GNU version -• http://www.gnu.org/software/radius/manual/html_node/radius_131.html Steel-Belted RADIUS -• http://www.funk.com Other sources: • http://www.linuxmanpages.com • The configuration files for PAM modules often contain comments which describe how to make entries • Administrator Guide for Avaya Communication Manager

3. The Linux PAM 3.1 Overview When a user logs into a computer system, the following user management tasks must be addressed: • The user needs to be identified. (Authentication) In the simplest case this means a user name or login ID and a password. But in the most general case it could also mean a retinal scan or a fingerprint, or a voice print, or an X.509 certificate, or any one of a number of one-time passwords such as employed by2 RSA SecurID® or SafeWord®. • The user’s access restrictions and permissions must be set. (Authorization/Accounting) In Linux, access is commonly accomplished by assigning the user group membership. In addition, the user needs a home directory and a program to start with (shell). The user may also have restrictions on when they can log in (time of day or days of the week), or they may have conditions applied such as forced change of password. • The user may be required to change their identifier. (Password)

2. RSA SecurID® is a registered trademark of RSA Security®. SafeWord® is a registered trademark of Secure Computing.

Issue 1.4

Communication Without Boundaries

2

The user’s identifier is typically a password, but could be an encryption key, a pin, a token serial number, etc. • A user must be given resources. (Session) For example, if this is the user’s first login, their home directory may need to be created. Users generally don’t just have a login on a single system. Users have logins on multiple computer systems. Barring a solution (which is about to be described), separate administration would need to be done on each such system for each user. If there were no PAM subsystem, then every service access (e.g. ssh, https) into the computer system would have to manage these tasks on its own. To change or support a new form of authentication, such as adding support for facial scans in place of passwords, would require each of these software modules to be modified. If user logins were maintained on an external central server, then the software for each service access would have to know how to communicate with that external service. Messy. The answer? Pluggable Authentication Modules or PAM. The PAM subsystem centralizes (within one server) all this processing so that individual service access modules do not have to understand exactly how a user’s identity is proven. All the access point really cares about is the answer -- is the user identified or not -- yes or no. The PAM subsystem consists of 3 components as shown in Figure 1: • The PAM engine with PAM modules ( a collection of libraries called by PAM applications) • PAM engine configuration file(s) • Module configuration files A user (= a program) of this subsystem is called a PAM Application. The PAM application interacts only with the PAM through a PAM Conversation. When the PAM application wants to process a new login session, it calls the PAM engine to begin this conversation (pam_authenticate, for example). The PAM engine then looks in its configuration file(s) to determine what to do. The configuration file is divided into 4 sections for authentication, accounting, password, and session processing. Each section of the PAM configuration file contains a list of the PAM modules to be used and the rules for using them. Finally, each of the PAM modules may have an individual configuration file to govern its operation. For example, the LDAP module needs to know the name or IP address of the LDAP server; this information is in its configuration file. The PAM engine orchestrates the process, calling PAM modules in the proper order and interacting with the user through the calling PAM application.

PAM Modules

PAM Application

PAM Engine

securetty Module Config Files

config

Figure 1. PAM Not every point of access into the server "talks" to the PAM engine directly as Figure 2. on page 4 illustrates. The direct CM SAT interface (def-sat), secure FTP (sftp), tftp, and telnet (in.telnet) are accessed through xinet.d and in turn all use a module named login to handle logins. Getty, which listens on serial ports in a general Linux system, also uses login. Other modules such as PPP and SSH are "PAM-ified" and talk to the PAM engine directly. These modules are PAM Applications. You will notice that http.d is crossed out. Although http.d can use the PAM subsystem, the web pages in Communication Manager are themselves PAM applications and do user authentication directly as opposed Issue 1.4

Communication Without Boundaries

3

to authenticating users through the Apache web server. The PAM system gets its Pluggable characteristic from the fact that login processing can be completely changed by simply changing the PAM configuration file(s), plugging-in a PAM module, and editing its configuration file. In Communication Manager, all of the supported PAM software is already resident3 and needs only to be configured to be used. Only the PAM configuration file and the configuration files for PAM modules are edited to change the AAA behavior.

PAM Applications

def-sat

ppp.d

vsftpd

ssh.d

PAM Modules

xinet.d

PAM in.tftpd

securetty

login

in.telnetd

su

getty

Module Config Files

config

http.d

Figure 2. AAA Structure

3.2 PAM Configuration File Structure PAM supports multiple options for its configuration and the reader is advised to study the PAM Administrator’s Guide for complete information. Only the method used with the Communication Manager server is discussed here. It is possible to place the configuration information for the PAM engine in a single file, /etc/pam.conf, as implied by Figure 2. Another option is to provide one configuration file for each PAM application with these files being stored in the directory /etc/pam.d. This is the method that Communication Manager uses. The directory /etc/pam.d contains a series of files, one for each PAM application. For example: • crond • sudo

• sshd • other

• login • mv-auth

• vsftpd

• passwd

• su

Generally, each file corresponds to a service with the same or similar name. This provides great flexibility in configuring PAM applications independently, and reduces errors when altering the behavior of just one application. There are also two methods for PAM applications to share all or portions of their configuration, one using a special module named pam_stack and another using pam_include. Communication Manager currently uses the pam_stack method. This method is currently deprecated by Red Hat to be replaced by pam_include, although some files delivered by Red Hat still use the pam_stack method. When Red Hat converts to pam_include, Communication Manager will as well. The pam_stack method uses a common file whose default name is system_auth. Communication Manager does not use this file. Communication Manger uses a file named mv-auth. This allows the system_auth file to remain 3. This is not strictly true. The PAM modules to support RSA SecurID and SafeWord are not provided. To use one of these services directly from the Communication Manager server (as opposed to being behind a RADIUS or LDAP server), a license must be purchased from RSA Security® or Secure Computing respectively, and the client software installed on the Communication Manager server in the field.

Issue 1.4

Communication Without Boundaries

4

unchanged (and not used) and allows Communication Manager to deliver mv-auth without concern that other tools might modify it as they might system-auth. Usually, the only PAM engine configuration file that needs to be edited is the mv-auth file, with one exception. The exception is the file for su which is discussed in section 5 on page 16. The file named other has a special use. If a PAM application attempts to start a PAM conversation and there is no configuration file matching this application, the configuration in other is used. Generally, this configuration file causes access to be denied as a safety measure in a system that has been misconfigured. Each of the PAM application configuration files as well as the common file has the same structure. Each configuration file is organized into 4 sections as shown in Table 1. Table 1. PAM Configuration File Sections Authentication Accounting Password Session

Each configuration file is a flat text file with lines containing 4 fields separated by white space as follows: module-type

control-flag

module-path

arguments

Table 2 indicates the content of each of the fields in each line in a configuration file. Table 2. PAM Configuration File Fields Module Type

Control Flag

auth account password session

required sufficient requisite optional include

Module Path

args

in /lib/security unless name begins with a /

• The first field, Module Type, identifies one of the 4 sections of the configuration file and must contain one of the values shown in column 1 of Table 2 . Lines pertaining to auth appear at the beginning of the file, followed by lines for account, password and session. • The third field contains the PATH to the PAM module to be invoked. If the supplied PATH does not begin with a slash, the module must be stored in /lib/security. • The fourth field contains arguments to be passed to the PAM module identified in the module path and documentation for the specific module must be consulted for details. The second field is the most complicated and must contain one of the keywords shown4. The PAM engine processes entries in each section of a configuration file in the order in which they appear in the file. The value of the control flag (field 2) affects how the lines are processed as follows: required

If the control flag has the value required, then the PAM module identified on this line must return success for this section of the PAM processing to succeed. If this PAM module returns

4. Actually, the keywords are short hand for a more precise set of specific keyword value pairs. Most of the time these short-hand keywords are all that is needed. Consult the PAM Administrator’s Guide for complete details.

Issue 1.4

Communication Without Boundaries

5

requisite

sufficient

optional

include

failure, lines following this one in the configuration file for this module type will still be processed, but the PAM application will receive a failure return. If the control flag has the value requisite, and if the PAM module identified on this line returns failure, control is immediately returned to the PAM application with a failure response; other entries for the same module type following this line are not processed. A requisite module must return success for this module type to succeed. If the control flag has the value sufficient, and if the PAM module identified on this line returns: failure Lines following this one for the same module type (if any) are processed. If all other required and requisite modules returned or return success, then success is returned to the PAM application; otherwise failure is returned. success If the module returns success and there were no previous entries marked required that returned failure for this module type, then processing stops for this module type and success is returned to the PAM application. Any following lines in the configuration file for this module type are not processed. This includes lines marked required. If a prior module marked required has returned failure, then the remaining lines are processed, but the PAM application will receive failure. In general, optional modules do not affect the result returned to the PAM application but could determine the result if all other modules return an ambiguous result. e.g PAM_IGNORE. The include control flag causes lines to be included from the configuration file identified by the module path field for this line.

3.3 PAM Modules Important! Communication Manager is built upon the Linux operating system from Red Hat. Red Hat delivers operating system components in files known as Red Hat Package Manager (RPM) files. RPM files are somewhat like a sophisticated version of ZIP files and contain the software as well as scripts to install it in appropriate places and perform other tasks. Although Communication Manager does not load all the RPMs available from Red Hat, when Communication Manager needs some portion of the software in an RPM, the entire RPM is usually loaded. If the RPM contains components that are not used by Communication Manager, these components are usually still loaded but just never configured to be used. This is done to manage deliveries from Red Hat in an economical manner. Components within an RPM may have cross linkages such that even though a given component is not used directly, it may use another component "under the covers". Additionally, contents of RPMs may change from operating system release to release. It is therefore much safer (bug-wise) and less work to just load the entire RPM. It also allows security updates to be provided more quickly than would be possible if Avaya repackaged the RPM. An exception is made to this policy if such action would introduce a security vulnerability. The RPM for PAM modules delivers a number of components that Communication Manager does not use or that may not be appropriate for use on Communication Manager. For example, the module pam_xauth is related to X-windows which Communication Manager does not support. Table 3. on page 7 illustrates the PAM modules that might be resident in /lib/security. However, just because the module is here doesn’t imply that its use is recommended or supported. Comments in the table identify PAM modules not suited for use with Communication Manager.

Issue 1.4

Communication Without Boundaries

6

Table 3. Supplied PAM Modules Module Name

Module Type

Purpose

Configuration or other related File

Comments

pam_access

account

Controls access by individual users or groups through specific ports or from specific hosts.

/etc/security/access.conf

pam_chroot

auth account session

Isolates a user to a subset of the total file system by changing the meaning of "/" for this user to be some other directory. e.g. /a/b/c

This is more applicable to general computing environments and not used in Communication Manager.

pam_console

auth session

Allows a user special permissions and control if logged in through the system console.

Since Communication Manager systems have no local keyboard and monitor, this is not useful.

pam_cracklib

password

Defines acceptable user password characteristics.

pam_debug

This module is used by debugging code and should only be used by Avaya Tier IV support.

pam_deny

auth account password session

Always denies access.

Generally, this should appear at the end of a PAM section to deny by default.

pam_env

auth

Used to set environment variables for this user.

pam_filter

auth account password session

Designed to invoke "filters".

A filter is a program that needs to be provided by a software developer to work in conjunction with a PAM application. There are no useful filters provided so this module has no purpose on a Communication Manager server.

pam_ftp

auth

Intended to be used with FTP to provide anonymous login.

Use of FTP is not secure and not recommended. Even when FTP is enabled on a Communication Manager server, this module is not used.

pam_group

auth

Used to assign group membership based on requested service.

This module is generally not used on Communication Manager servers.

pam_issue

auth

Prepends the content of an issue file to the ID prompt during login.

/etc/issue

Use of this module is not recommended because not all clients support it and its use can sometimes prevent users from logging in at all.

pam_lastlog

session

Displays time of last login.

/var/log/lastlog

pam_ldap

auth account password

LDAP authentication module.

/etc/ldap.conf

Although not a module to be configured via mv-auth, nss-ldap uses LDAP and uses the same configuration file, /etc/ldap.conf default ports = 389 TCP for LDAP, and 636 TCP for LDAPS

pam_limits

session

Sets resource limits for groups and users. e.g. max memory, max logins

/etc/security/limits.conf

Only maxlogins and maxsyslogins should be set on a Communication Manager system.

pam_listfile

auth

Used to grant or deny access to a user based on the content of a specified file.

Generally not used on Communication Manager servers.

pam_localuser

account

Allows a users authorization information to be obtained from the local files in order to prevent attempts to access an external AAA server.

This module needs to be used in the account section to support local host accounts whenever there are also external accounts in LDAP or RADIUS.

Issue 1.4

Communication Without Boundaries

7

Table 3. Supplied PAM Modules Module Name

Module Type

Purpose

Configuration or other related File

Comments

pam_loginuid

session

Sets the loginuid for the process that was just authenticated.

Use of this module is not appropriate for the software supplied with Communication Manager. It should never be placed in mv-auth as it will interfere with things like su or sudo whose purpose is to change the effective UID of the user.

pam_mail

auth session

Displays "you have new mail" to the user.

Since Communication Manager servers do not support incoming mail, this module has no use.

pam_mkhomedir

session

Creates home directories on the fly.

See section 10 on page 20 for use of this module.

pam_motd

session

Outputs a message after successful login.

/etc/motd

pam_nologin

auth account

If the file /etc/nologin exists only root may login. Other users are denied access but are shown the content of /etc/nologin.

/etc/nologin

pam_permit

auth account password session

Always allow access.

Do not use this feature if root is not allowed direct login access. Root is not allowed to log in directly in Communication Manager by default. One might envision logging in, followed by su to root and then creating this file. However, if the root session is terminated for any reason, all logins will be blocked. You have been warned. Don’t use this module.

pam_postgresok

Not supported on Communication Manager servers.

pam_pwdb

auth account password session

Specifies locations for user credentials.

/etc/pwdb.conf

Not supported on Communication Manager servers.

pam_radius_auth

auth account

RADIUS authentication module.

/etc/raddb/server

Default ports = 1812 and 1813 udp.

pam_rhosts_auth

auth

Allows access by users already logged in at another specified host to login without additional authentication.

/etc/hosts.equiv ~/.rhosts

Not recommended.

pam_root_login

auth

Restricts unauthorized root logins based on product offer.

Should always be present.

pam_rootok

auth

Used to allow root access to a service without having to enter a password.

Not recommended.

pam_rps

auth

Provides challenge response authentication.

From Nalin Dahyabhai "never use this module". Not supported on Communication Manager servers.

pam_securetty

auth

Limits root login to a specified list of ports which may be a null list.

pam_selinux

session

Used to set the default security context.

Communication Manager does not support selinux due to performance issues.

pam_shells

auth

Authentication is granted if the users shell is listed in /etc/shells. If no shell is in /etc/passwd (empty), the /bin/sh is used (following ftpd's convention). Also checks to make sure that /etc/shells is a plain file and not world writable.

Not used on Communication Manager.

Issue 1.4

/etc/securetty

Communication Without Boundaries

8

Table 3. Supplied PAM Modules Module Name pam_stack

Module Type auth account password session

Purpose

Configuration or other related File

Supports a common configuration for multiple services.

Comments See a discussion of this module in the previous section of this document.

pam_stress

Not supported on Communication Manager servers.

pam_succeed_if

account

Succeeds based on characteristics of the account such as UID value.

pam_tally

auth account

Counts user login attempts and denies access after a specified number of failed attempts.

/var/log/faillog

pam_time

account

Used to restrict access by time of day or day or week.

/etc/security/time.conf

pam_timestamp

auth

When an application opens a session using pam_timestamp, a timestamp file is created in the timestampdir directory for the user. When an application attempts to authenticate the user, a pam_timestamp will treat a sufficientlyrecent timestamp file as grounds for succeeding.

pam_unix

auth account session password

This is the standard Linux module for authentication of local host accounts.

Not supported by Communication Manager.

pam_unix_acct

Not used on Communication Manager servers.

pam_unix_auth

Not used on Communication Manager servers.

pam_unix_passwd

Not used on Communication Manager servers.

pam_unix_session

Not used on Communication Manager servers.

pam_userdb

auth

Authenticates users based on content of a "Berkeley DB".

This module is not supported on Communication Manager.

pam_warn

auth password

Logs information about a login attempt to syslog. Useful in the "other" configuration file to warn of attempts to use unknown services.

pam_wheel

auth account

Restricts root access to members of the wheel group.

This is not used by default on Communication Manager because root accounts are very restricted.

pam_xauth

session

Used for x-windows environments.

not supported on Communication Manager servers.

In addition to the above PAM modules, modules for RSA SecurID and SafeWord may be loaded in the field. These modules are licensed and must be obtained from their respective vendors. 3.4 Related Modules Communication Manager also contains an audit program to look for and lock user logins that have not been used for a specified period of time. This audit is named unused_login_audit and expects a configuration file in /etc/opt/ecs/unused_login_audit.conf. This file must contain at least two lines: MaxUnusedDays=N Exceptions=root,sroot,init,inads,craft,dadmin where 2 < N < 365 and is the number of days a login may remain unused before it is locked. The exception line contains a list of logins that should not be locked by this audit. Additional logins may be added to the list and Issue 1.4

Communication Without Boundaries

9

additional exception lines may be added as needed. This audit depends on the output of pam_lastlog in /var/log/lastlog. By default this audit is not running. To run the audit, a schedule must be defined for it to run via the Linux CRON service. Create a file named /etc/cron.d/unused_login_audit.cron with content similar to the following. # [minute] [hour] [day of month] [month] [day of week] [program to be run] 0 0 * * * /opt/ecs/bin/unused_login_audit >>/dev/null 2>&1

The first line is a comment line indicating the structure for lines in this file. The second line would cause the audit to run every day at midnight. An asterisk (*) means "all". See "man -S 5 crontab" for further information. 3.5 PAM Configuration File Content The PAM configuration file for a given PAM application is illustrated generically as a single file in Figure 3. The syntax auth #auth #auth auth #auth auth auth #auth auth auth

required required required required required required sufficient sufficient sufficient required

pam_env pam_issue (optional) pam_tally (optional) pam_root_login securetty (optional) pam_asg collect_password pam_asg audit pam_external_AAA_goes_here (optional) pam_unix pam_deny

account account #account #account #account #account

required required required required sufficient sufficient

pam_unix pam_access pam_time (optional) pam_tally (optional) pam_local_user (optional) pam_external_AAA_goes_here(optional)

password #password password #password password

sufficient required sufficient sufficient required

pam_asg pam_cracklib (optional) pam_unix pam_external_AAA_goes_here (optional) pam_deny

#session session #session session

required required required required

pam_limits (optional) pam_lastlog never pam_motd (optional) pam_unix

Figure 3. Generic PAM Configuration File is not complete and specific arguments are omitted for clarity. Lines marked as optional are added or removed to support specific behavior or external AAA servers. In particular pam_external_AAA_goes_here is a place holder for something like PAM_LDAP. The notation (optional) is not a parameter but indicates that the entry is optional in the PAM configuration. The following points are worth noting: • The appearance of pam_asg twice is NOT a typographical error or mistake! The two lines must be entered in the order shown and can then be considered to act in unison as a single module. Logins that are ASG logins must not be processed by subsequent modules; the double entry implements this constraint while allowing non-ASG logins to be processed normally. • As explained in the previous section, order of lines in this file is very important; lines are processed in each section in the order in which they appear in the file.

Issue 1.4

Communication Without Boundaries

10

• In the auth section, the pair of pam_asg entries MUST be the first modules that attempt to verify user identity. That is, not necessarily the first modules in the section, but the first modules that are capable of issuing a user prompt. The pam_asg module processes accounts which are authenticated with the Access Security Gateway (ASG) method of one-time-passwords which is proprietary to Avaya. All Avaya services accounts are ASG authenticated accounts. To see why this order is required, consider the following two cases. For purposes in understanding these examples, ignore the fact that the pam_asg entry appears twice; consider the two entries to act together as one entry. Case 1: pam_asg before pam_unix auth auth auth

required sufficient sufficient

pam_asg pam_asg audit pam_unix

Case 2: pam_unix before pam_asg auth auth auth

Case 1

sufficient required sufficient

pam_unix pam_asg pam_asg audit

pam_asg will prompt the user for an ID and then attempt to find this ID in the ASG data base. If the ID is not found, pam_asg passes the ID to the next module; control will be passed to pam_unix. Pam_unix will receive the ID from pam_asg, prompt for a password, and attempt to find this user in the local /etc/passwd, /etc/shadow files. The prompt sequence would appear to the user something like this, with the data finally validated by pam_unix:

Screen 1

Login: joesmo Password: ******

In this case the user, joesmo, is completely unaware that pam_asg was called. A "normal" password set of prompts appears. If the ID is found by pam_asg, then pam_asg will prompt the user with a challenge and the user will see Screen 2 instead of Screen 1:

Screen 2

Login: joesmo Challenge: 651-9306 Response:

Product ID: 1000000001

In either case (ASG login or password login), the user sees a "normal" prompt sequence which matches the user’s expectations. Case 2 pam_unix will prompt the user for an ID and a password; the user will see a screen like Screen 1 above. Pam_unix will then attempt to find the user in the /etc/passwd, /etc/shadow files. If the ID is found, the user will experience a "normal" login sequence. However, if the ID is not found, pam_asg will be called and be passed both the ID and password. If pam_asg finds this user in the ASG data base, pam_asg will ignore the entered password and prompt with an ASG one-time-password challenge. If this user is expecting to be authenticated via ASG, then the user is expecting a screen like Screen 2. However, the user will first see a screen like Screen1 above; pam_unix will wait for the user to enter a password. Since the user does not have a "password", the user will not

Issue 1.4

Communication Without Boundaries

11

know what to enter. The user could be told to enter anything, including just pressing return, which would result in a sequence like this:

Screen 3

Login: joesmo Password: ***** Challenge: 651-9306 Response:

Product ID: 1000000001

Although confusing to a user, the user might make a guess, enter a return to the password prompt, see the expected challenge, and log in successfully. Automated services tools, however, would not make such a guess and would fail to log in. These tools would have to be re-programmed to get past this situation. • Pam modules that are capable of prompting the user for an ID or password generally accept two parameters, try_first_pass and use_first_pass. These parameters control how the module prompts the user when multiple pam_modules that might prompt the user are active in the PAM configuration file. Generally the first module that prompts the user (must be pam_asg for Communication Manager) is not configured with either parameter and subsequent modules are configured with "use_first_pass". The first module (pam_asg) passes the credentials entered by the user to the subsequent modules and these modules use this information to try to authenticate the user. This causes the user to be prompted once. If the subsequent modules are coded with "try_first_pass" then they may re-prompt the user again if the passed credentials are not valid. Pam_asg normally prompts the user for an ID. Pam_asg then looks for this ID in the ASG files on the server. If the user is found there, then pam_asg handles the user’s validation. However, if the user is not found in the ASG files, then pam_asg passes the ID to the subsequent modules. Pam_asg supports a special command line parameter, collect_password, that causes pam_asg to prompt the user for a password if the user is not found in the ASG files. This password is not used by pam_asg but is passed to the subsequent modules. If the PAM configuration file is as follows: auth auth auth

required sufficient sufficient

pam_asg pam_asg audit pam_ldap try_first_pass

and the user is not found in the ASG files, then the user may see a prompt like this: Login: joesmo LDAP Password: *****

If the PAM configuration file is as follows: auth auth auth

required sufficient sufficient

pam_asg collect_password pam_asg audit pam_ldap use_first_pass

and the user is not found in the ASG files, then the user will see a prompt like this: Login: joesmo Password: *****

A slightly different situation occurs with pam_securid. Pam_securid does not support the use_first_pass parameter. So if the PAM configuration file looks like this: auth auth auth

Issue 1.4

required sufficient sufficient

pam_asg pam_asg audit pam_securid

Communication Without Boundaries

12

and the user is not found in the ASG files, then the user will see a prompt like this: Login: joesmo Enter Passcode:

However, if the PAM configuration file looks like this: auth auth auth

required sufficient sufficient

pam_asg collect_password pam_asg audit pam_securid

and the user is not found in the ASG files, then the user will see a prompt like this: Login: joesmo Password:******* Enter Passcode:

Even if the user enters the correct SecurID credential to the password prompt, they will still see the passcode prompt and must respond to it with the correct pass code. A local host account that is neither ASG protected nor SecurID protected will also receive the "Enter Passcode" prompt because the pam_securid entry occurs in the mv-auth file before the pam_unix entry. If the pam_asg line does not contain the "collect_password" parameter, then the user will see the passcode prompt followed by the password prompt. If the pam_asg line is coded with the "collect_password" parameter, then the user will see the password prompt first, followed by the passcode prompt. The user will need to enter the correct password to the password prompt and just enter a return to the passcode prompt in either case. This is an unfortunate consequence of the way the SecurID module is designed. • Pam_deny always denies access, when present is the last entry in a section, and its control flag = required. This means that if all the preceding modules were not able to validate the user, the default behavior is to deny access. For example, one could have an auth section like this: auth auth auth

required sufficient required

pam_env pam_ldap pam_deny

In the event that the LDAP server is unreachable, the user is denied access. This example illustrates a particularly bad configuration to make a point. If the LDAP server is not reachable, no one logs into this machine. A local host account should always be provided so that the machine can be accessed locally regardless of network connectivity. For example: auth auth auth auth

required sufficient sufficient required

pam_env pam_ldap pam_unix pam_deny

• The control flag is very important. Generally all entries in a section of the PAM configuration file are not set to "required". Consider what would happen in the example above if both pam_ldap and pam_unix were set to "required". The user would have to have a valid password in the local host as well as in the ldap server and if the ldap server were not reachable for any reason, no one logs in; not even local host accounts. • Pam_securetty is used to control which ports root may log in from. Ideally, one should never be able to log in as root directly. Rather, a user should be required to log in first as a non-root user and then "su" to root. Pam_access provides a more sophisticated and flexible way to accomplish the same goal. Pam_access is used instead of pam_securetty on all Communication Manager servers because it provides greater flexibility in configuration. • Pam_issue is supplied but its use is not recommended. See section 13.3 on page 42 for a more complete discussion. Issue 1.4

Communication Without Boundaries

13

• Various Avaya services and administration tools connect to the Communication Manager server in an automated fashion. These tools parse the prompt strings during the login sequence to understand how to respond. Unfortunately these tools were developed over time for various systems and do not all parse the prompt strings in the same way. For this reason, when constructing a Message of the Day (pam_motd) or messages for pam_issue, the following strings are not permitted in the message: - [513] used by FPM, CMSA, VAM - 513] used by connect2 - ] used by MSA - Software Version used by ASA - Login: - Password: - ogin - ogin: i.e. with or without a colon - incorrect login - assword i.e. from Password or password - hallenge - SAT - SAT cannot be executed on a standby server These strings are case sensitive, so SAT is not permitted, but sat is OK. Software Version is not permitted but software version or Software-Version are OK. It would be better to not use any form of these strings, but if the message requires them for any reason, a change of case or punctuation is needed. • With the exception that pam_asg must be the first authenticator in the auth section, entries for external AAA servers can occur in any order. i.e. before or after local host account processing. • Local host accounts (pam_unix) and LDAP (pam_ldap) are complete AAA services. RADIUS, SecurID and SafeWord, however, are not. If one of these services is specified in the auth section of mv-auth, the authorization information must be provided either by a parallel local host account or via an LDAP server. The Name Service Switch (NSS) is used in this case. • Communication Manager provides an unused login audit utility that can be configured to look for logins that have not been used for a specified period of time and lock these logins. This audit program depends on pam_lastlog. 3.6 Constraints and Recommendations When configuring the PAM subsystem, the following should be noted: 1. 2. 3. 4. 5.

6. 7. Issue 1.4

Pam_asg must be the first pair of modules that prompts a user. All ASG authenticated accounts must be local host accounts. A PAM module to support ASG authentication via an external server does not exist. At least one local host account should be present in all servers so that access is possible even if external AAA servers are not reachable. "Password" aging must not be enabled for Avaya Services accounts. Care must be used in enabling "password" aging for accounts authenticated via external servers that do not support the user changing their "password" through the Communication Manager server. If such a user’s account expires, PAM will prompt them to change their "password". If this is not possible through Communication Manager, then this user will be locked out. RADIUS accounts are an example. See constraints on use of pam_limits in section 13.5 on page 45. SASL authentication is not supported. Communication Without Boundaries

14

8.

9. 10.

RADIUS, RSA SecurID and Safeword are not complete AAA services. These services must be used in conjunction with a parallel local host account or LDAP/NSS. When configuring a local host account, the local account should be locked to prevent a stale local password from being used in the event that the external AAA server is not reachable. When configuring NSS for LDAP use, "files" should be specified before LDAP in the search order in nsswitch.conf. If Tripwire is enabled on the Communication Manager server, the Tripwire data base may need to be rebuilt after changes to the PAM configuration.

4. Communication Manager Default PAM Files The previous section described the general structure of PAM module configuration files using a single file for illustration purposes. As section 3.2 on page 4 described, each PAM application has an individual file and there is also a common file, mv-auth. This section illustrates how Communication Manager is configured by default. The PAM application login will be used as an example. This example was accurate at the time of publication but may have changed since that time; the actual server file content should be viewed and understood prior to making changes. Communication Manager is configured by default to support only local host accounts as illustrated in Figure 4. PAM /etc/passwd /etc/shadow /etc/group lacfile asgfile

CM Server

Note: In all cases, local host accounts can be used at the same time as any of the external AAA services. At least one local host account should always be present so that the server is accessible when access to an external AAA server is blocked for any reason.

Figure 4. Local Host Accounts Only

The content of the configuration file for the login process looks like this: #%PAM-1.0 auth auth auth account password #pam_selinux.so session session session session #pam_selinux.so session

required required required required required close required required required optional open required

pam_securetty.so pam_stack.so service=mv-auth pam_nologin.so pam_stack.so service=mv-auth pam_stack.so service=mv-auth should be the first session rule pam_selinux.so close pam_stack.so service=mv-auth pam_loginuid.so pam_console.so should be the last session rule pam_selinux.so multiple open

Figure 5. PAM Configuration File for Login In all configuration files, lines beginning with a pound symbol (#) are comment lines. The lines for pam_selinux are inherited from the Red Hat distribution and not used. Selinux is not supported by Communication Manager due to serious performance problems with this version of Linux. Notice the lines containing pam_stack.so. These lines invoke the content of the file mv-auth as described earlier. Normally, only the mv-auth file needs to be changed to use an external authentication server.

Issue 1.4

Communication Without Boundaries

15

The content of mv-auth looks like this: #

serial)

• cert.cnf • serial

certs

newcerts

private

• index.txt

First create the configuration file and edit as needed for your particular situation. Then run the makeCA script to create a root and name it myCA. Next run the makeServer script to create a certificate for a server.

A1. Create a Self Signed Root Certificate (makeCA) openssl req \ -config cert.cnf \ -days 365 \ -x509 \ -nodes \ -newkey rsa:1024 \ -keyform PEM \ -keyout myCA.key \ -outform PEM \ -out myCA.pem openssl x509 \ -text \ -in myCA.pem \ -out myCA.txt

A2. Create a Server Certificate (makeServer) # Script file for creation of # Server Certificates # under an myCA ServCert=$1 if [ -z $ServCert ]; then echo " USAGE: makeServerCert " exit 1 fi echo "" echo "" echo "(1)make a key" openssl genrsa -out $ServCert.key 1024

Issue 1.4

Communication Without Boundaries

48

echo "" echo "" echo "(2)Making a Signing Request..." openssl req -new \ -config cert.cnf \ -nodes \ -keyform PEM \ -key $ServCert.key \ -outform PEM \ -out $ServCert.csr echo "" echo "" echo "(3) Sign the Request..." openssl ca \ -verbose \ -days 365 \ -config cert.cnf \ -extensions usr_cert \ -cert myCA.pem \ -keyfile myCA.key \ -in $ServCert.csr \ -out $ServCert.pem echo "" echo "" echo "(4) Creating Text Output of Certificate" openssl x509 \ -text \ -in $ServCert.pem \ -out $ServCert.txt

A3. Openssl Configuration File # # This is the certificate configuration file # This definition stops the following lines choking if HOME isn't # defined. HOME =. RANDFILE = $ENV::HOME/.rnd # Extra OBJECT IDENTIFIER info: oid_section = new_oids # To use this configuration file with the "-extfile" option of the # "openssl x509" utility, name here the section containing the # X.509v3 extensions to use: # extensions = # (Alternatively, use a configuration file that has only # X.509v3 extensions in its main [= default] section.) [ new_oids ]

#################################################################### [ ca ] default_ca = CA_default # The default ca section

Issue 1.4

Communication Without Boundaries

49

#################################################################### [ CA_default ] dir = .# Where everything is kept certs = $dir/certs# Where the issued certs are kept crl_dir = $dir/crl# Where the issued crl are kept database = $dir/certs/index.txt# database index file. new_certs_dir = $dir/newcerts# default place for new certs. serial RANDFILE

= $dir/serial # The current serial number = $dir/private/.rand# private random number file

x509_extensions= usr_cert

# The extensions to add to the cert

# Extensions to add to a CRL. Note: Netscape communicator chokes on V2 CRLs # so this is commented out by default to leave a V1 CRL. # crl_extensions= crl_ext default_days = 365

default_crl_days= 60 default_md = sha1 preserve = no

# how long to certify for (in days) # 1 year = 365 days # 5 years = 1825 days # 10 yrs = 3650 days # 25 yrs = 9125 days # 30 years = 10950 days # how long before next CRL # which md to use # keep passed DN ordering

# A few different ways of specifying how similar the request should look # For type CA, the listed attributes must be the same, and the optional # and supplied fields are just that :-) policy = policy_match # For the CA policy [ policy_match ] countryName = supplied organizationName= supplied organizationalUnitName= supplied commonName = supplied ######################################################## [ req ] default_bits = 1024 default_keyfile = privkey.pem distinguished_name= req_distinguished_name attributes = req_attributes x509_extensions = v3_ca# The extentions to add to the self signed cert # This sets a mask for permitted string types. There are several options. # default: PrintableString, T61String, BMPString. # pkix : PrintableString, BMPString. # utf8only: only UTF8Strings. # nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings). # MASK:XXXX a literal mask value. # WARNING: current versions of Netscape crash on BMPStrings or UTF8Strings # so use this option with caution! string_mask = nombstr # req_extensions = v3_req # The extensions to add to a certificate request

Issue 1.4

Communication Without Boundaries

50

[ req_distinguished_name ] # Country countryName countryName_default countryName_min countryName_max

= Country Name (2 letter code) = US =2 =2

# Organization Name shall be Avaya Inc. 0.organizationName = Organization Name 0.organizationName_default= CM_LDAP_TEST # Organizational Names: 0.organizationalUnitName= Org Unit Name 1 0.organizationalUnitName_default = TEST # Common Name: commonName commonName_default commonName_max

= Common Name = myldapserver.someplace.com = 64

[ usr_cert ] # These extensions are added when 'ca' signs a request. # This goes against PKIX guidelines but some CAs do it and some software # requires this to avoid interpreting an end user certificate as a CA. basicConstraints=CA:FALSE # This is key usage for server certificate. keyUsage = digitalSignature, keyEncipherment # PKIX recommendations harmless if included in all certificates. subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer:always # Certificate Policies certificatePolicies = ia5org,@capol [ req_attributes ] # Nothing here [ v3_req ] # Extensions to add to a certificate request BasicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment certificatePolicies = ia5org,@capol

###################################################### # Extensions for a CA ###################################################### [ v3_ca ] subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer:always

Issue 1.4

Communication Without Boundaries

51

# This is what PKIX recommends but some broken software chokes on critical # extensions. #basicConstraints = critical,CA:true # So we do this instead. basicConstraints = CA:true # Key usage: this is typical for a CA certificate. However since it will # prevent it being used as an test self-signed certificate it is best # left out by default. keyUsage = cRLSign, keyCertSign # Certificate Policies certificatePolicies=ia5org,@capol

###################################################### # Extensions for a SA ###################################################### [ v3_sa ] subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer:always basicConstraints = CA:false # Key Usage keyUsage = digitalSignature extendedKeyUsage = codeSigning # Certificate Policies certificatePolicies=ia5org,@capol ##################################################### # Generic Certificate Policies ##################################################### [capol] #policyIdentifier= #CPS.1= #userNotice= [capoln] #explicitText= #organization= #noticeNumbers= [ crl_ext ] # CRL extensions. # Only issuerAltName and authorityKeyIdentifier make any sense in a CRL. # issuerAltName=issuer:copy authorityKeyIdentifier=keyid:always,issuer:always [ engine ] default = openssl # rsa = openssl # dsa = openssl # dh = openssl

Issue 1.4

Communication Without Boundaries

52

# rand = openssl # bn_mod_exp = openssl # bn_mod_exp_crt = openssl

Issue 1.4

Communication Without Boundaries

53

Glossary 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59

AAA CD CM FTP LDAP Local Host Account Microsoft Active Directory PAM PAM Application PC PPP RADIUS RFC RSA SecurID® SASL SAT SSH SafeWord® Sun ONE Telnet ASG Cron NSCD NSS SU SUDO Tripwire VSFTP

Issue 1.4

Authentication, Authorization and Accounting Compact Disk Communication Manager File Transfer Protocol. A non-secure protocol for file transfer (RFC 0959, STD0009) Lightweight Directory Access Protocol (RFC 2251) A user login account for which all AAA information is maintained on the same server the user is logging in to. A Microsoft implementation of LDAP Pluggable Authentication Module A software module that has been enhanced to interact directly with the Linux PAM subsystem Personal Computer Point to Point Protocol Remote Authentication Dial In User Service (RFC 2865) Request for Comment. An Internet standard A token based authentication mechanism from RSA Security Simple Authentication and Security Layer (RFC 2222) Communication Manager System Administration Terminal interface Secure Shell. A protocol for secure remote login and other secured network services over an insecure network. (RFC 4251) A token based authentication mechanism from Secure Computing Sun ONE (Sun Open Net Environment) is a marketing strategy and set of products from Sun Microsystems. A non-secure protocol for interfacing terminal oriented processes to each other (RFC 855, STD0008) Access Security Gateway. A one-time-password implementation proprietary to Avaya. A process provided by Linux to run jobs periodically Name Service Caching Daemon. A daemon that provides a cache for user variables obtained via name service requests. Name Service Switch. A module to obtain/search-for user authorization variables from an order list of databases. Substitute User. A command to allow one to run a shell as another user/group Superuser Do. A command to allow a system administrator to give certain users or groups of users the ability to run some or all commands as root or as another user. An auditing program that monitors for file changes. Very Secure File Transfer Protocol. A secure version of FTP.

Communication Without Boundaries

54