CM Administrator Logins

Communication Manager Administrator Logins
Issue 1.4
April 2009
Contents
1. Introduction 1
2. Reference Material 1
3. The Linux PAM 2
3.1 Overview 2
3.2 PAM Configuration File Structure 4
3.3 PAM Modules 6
3.4 Related Modules 9
3.5 PAM Configuration File Content 10
3.6 Constraints and Recommendations 14
4. Communication Manager Default PAM Files 15
5. Configuration file for "su" 16
6. Making Changes 17
7. RAMDISK 19
8. Recovery 19
9. User Login Characteristics 19
10. Home Directories 20
11. Configuring Multiple Servers 20
12. Tested AAA Server Configurations 22
12.1 LDAP / NSS / NSCD 22
12.1.1 Open LDAP 22
12.1.2 OpenLDAP Server 27
12.1.3 Other LDAP servers 30
12.2 RSA SecurID 32
12.3 SafeWord 34
12.4 RADIUS 38
12.5 Other Configurations 40
13. Other PAM Features 40
13.1 pam_access 40
13.2 pam_cracklib 41
13.3 Login Messages (pam_issue and pam_motd) 42
13.3.1 pam_issue 43
13.3.2 pam_motd (Message of the Day) 43
13.3.3 SSH 43
13.3.4 Telnet 44
13.3.5 HTTP 44
13.3.6 FTP/SFTP 45
13.4 pam_lastlog 45
13.5 pam_limits 45
13.6 pam_tally 45
13.7 pam_time 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 restric-
tions 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.

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

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
PAM Modules
vsftpd ssh.d
xinet.d
PAM securetty
in.tftpd
login Module Config
Files
in.telnetd
su config
getty 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 • sshd • login • vsftpd • passwd • su
• sudo • other • mv-auth
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.

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 Control
Module Path args
Type Flag
auth required in /lib/security
account sufficient unless name begins
password requisite with a /
session optional
include
• 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.

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.
requisite 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.
sufficient 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.
optional 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.
include 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.

Table 3. Supplied PAM Modules
Module Configuration or other
Module Name Purpose Comments
Type related File
pam_access account Controls access by individual users or groups /etc/security/access.conf
through specific ports or from specific hosts.
pam_chroot auth Isolates a user to a subset of the total file sys- This is more applicable to general
account tem by changing the meaning of "/" for this computing environments and not
session user to be some other directory. e.g. /a/b/c used in Communication Manager.
pam_console auth Allows a user special permissions and control if Since Communication Manager sys-
session logged in through the system console. tems have no local keyboard and mon-
itor, this is not useful.
pam_cracklib password Defines acceptable user password characteris-
tics.
pam_debug This module is used by debugging
code and should only be used by
Avaya Tier IV support.
pam_deny auth Always denies access. Generally, this should appear at the
account end of a PAM section to deny by
password default.
session
pam_env auth Used to set environment variables for this user.
pam_filter auth Designed to invoke "filters". A filter is a program that needs to be
account provided by a software developer to
password work in conjunction with a PAM
session application. There are no useful filters
provided so this module has no pur-
pose on a Communication Manager
server.
pam_ftp auth Intended to be used with FTP to provide anon- Use of FTP is not secure and not rec-
ymous login. ommended. Even when FTP is
enabled on a Communication Man-
ager server, this module is not used.
pam_group auth Used to assign group membership based on This module is generally not used on
requested service. Communication Manager servers.
pam_issue auth Prepends the content of an issue file to the ID /etc/issue Use of this module is not recom-
prompt during login. mended because not all clients sup-
port 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 LDAP authentication module. /etc/ldap.conf Although not a module to be config-
account ured via mv-auth, nss-ldap uses LDAP
password 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. /etc/security/limits.conf Only maxlogins and maxsyslogins
max memory, max logins should be set on a Communication
Manager system.
pam_listfile auth Used to grant or deny access to a user based on Generally not used on Communica-
the content of a specified file. tion Manager servers.
pam_localuser account Allows a users authorization information to be This module needs to be used in the
obtained from the local files in order to pre- account section to support local host
vent attempts to access an external AAA server. accounts whenever there are also
external accounts in LDAP or
RADIUS.

Type related File
pam_loginuid session Sets the loginuid for the process that was just Use of this module is not appropriate
authenticated. for the software supplied with Com-
munication Manager. It should never
be placed in mv-auth as it will inter-
fere with things like su or sudo whose
purpose is to change the effective
UID of the user.
pam_mail auth Displays "you have new mail" to the user. Since Communication Manager serv-
session ers 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 If the file /etc/nologin exists only root may /etc/nologin Do not use this feature if root is not
account login. Other users are denied access but are allowed direct login access. Root is
shown the content of /etc/nologin. not allowed to log in directly in Com-
munication Manager by default. One
might envision logging in, followed by
su to root and then creating this file.
However, if the root session is termi-
nated for any reason, all logins will be
blocked. You have been warned.
pam_permit auth Always allow access. Don’t use this module.
account
password
session
pam_postgresok Not supported on Communication
Manager servers.
pam_pwdb auth Specifies locations for user credentials. /etc/pwdb.conf Not supported on Communication
account Manager servers.
password
session
pam_radius_auth auth RADIUS authentication module. /etc/raddb/server Default ports = 1812 and 1813 udp.
account
pam_rhosts_auth auth Allows access by users already logged in at /etc/hosts.equiv Not recommended.
another specified host to login without addi- ~/.rhosts
tional authentication.
pam_root_login auth Restricts unauthorized root logins based on Should always be present.
product offer.
pam_rootok auth Used to allow root access to a service without Not recommended.
having to enter a password.
pam_rps auth Provides challenge response authentication. From Nalin Dahyabhai
<nalin@redhat.com>
"never use this module".
Not supported on Communication
Manager servers.
pam_securetty auth Limits root login to a specified list of ports /etc/securetty
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 Not used on Communication Man-
listed in /etc/shells. If no shell is in ager.
/etc/passwd (empty), the /bin/sh is used (fol-
lowing ftpd's convention). Also checks to make
sure that /etc/shells is a plain file and not
world writable.

Type related File
pam_stack auth Supports a common configuration for multiple See a discussion of this module in the
account services. previous section of this document.
password
session
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 Counts user login attempts and denies access /var/log/faillog
account after a specified number of failed attempts.
pam_time account Used to restrict access by time of day or day or /etc/security/time.conf
week.
pam_timestamp auth When an application opens a session using Not supported by Communication
pam_timestamp, a timestamp file is created in Manager.
the timestampdir directory for the user. When
an application attempts to authenticate the
user, a pam_timestamp will treat a sufficiently-
recent timestamp file as grounds for succeed-
ing.
pam_unix auth This is the standard Linux module for authen-
account tication of local host accounts.
session
password
pam_unix_acct Not used on Communication Man-
ager servers.
pam_unix_auth Not used on Communication Man-
ager servers.
pam_unix_passwd Not used on Communication Man-
ager servers.
pam_unix_session Not used on Communication Man-
ager servers.
pam_userdb auth Authenticates users based on content of a "Ber- This module is not supported on
keley DB". Communication Manager.
pam_warn auth Logs information about a login attempt to sys-
password log. Useful in the "other" configuration file to
warn of attempts to use unknown services.
pam_wheel auth Restricts root access to members of the wheel This is not used by default on Com-
account group. munication 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

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 required pam_env

#auth required pam_issue (optional)
#auth required pam_tally (optional)
auth required pam_root_login
#auth required securetty (optional)
auth required pam_asg collect_password
auth sufficient pam_asg audit
#auth sufficient pam_external_AAA_goes_here (optional)
auth sufficient pam_unix
auth required pam_deny
account required pam_unix

account required pam_access
#account required pam_time (optional)
#account required pam_tally (optional)
#account sufficient pam_local_user (optional)
#account sufficient pam_external_AAA_goes_here(optional)
password sufficient pam_asg

#password required pam_cracklib (optional)
password sufficient pam_unix
#password sufficient pam_external_AAA_goes_here (optional)
password required pam_deny
#session required pam_limits (optional)

session required pam_lastlog never
#session required pam_motd (optional)
session required 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.

• In the auth section, the pair of pam_asg entries MUST be the first modules that attempt to verify user iden-
tity. 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 pur-
poses 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 required pam_asg
Case 2: pam_unix before pam_asg
Case 1 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:
Login: joesmo
Screen 1
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:
Login: joesmo
Challenge: 651-9306 Product ID: 1000000001
Screen 2
Response:
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

know what to enter. The user could be told to enter anything, including just pressing
return, which would result in a sequence like this:
Login: joesmo
Screen 3 Password: *****
Challenge: 651-9306 Product ID: 1000000001
Response:
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 mod-
ule 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 sufficient 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 sufficient 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 sufficient pam_securid

Login: joesmo
Enter Passcode:
However, if the PAM configuration file looks like this:

auth sufficient pam_securid
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 Pass-
code" 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 sufficient pam_ldap
In the event that the LDAP server is unreachable, the user is denied access. This example illustrates a particu-
larly 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 net-
work connectivity. For example:
auth sufficient pam_ldap
• 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 dis-
cussion.

• Various Avaya services and administration tools connect to the Communication Manager server in an auto-
mated 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 mes-
sages 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 authoriza-
tion 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. Pam_asg must be the first pair of modules that prompts a user.
2. All ASG authenticated accounts must be local host accounts. A PAM module to support ASG authentica-
tion via an external server does not exist.
3. 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.
4. "Password" aging must not be enabled for Avaya Services accounts.
5. 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 Commu-
nication Manager, then this user will be locked out. RADIUS accounts are an example.
6. See constraints on use of pam_limits in section 13.5 on page 45.
7. SASL authentication is not supported.

8. RADIUS, RSA SecurID and Safeword are not complete AAA services. These services must be used in con-
junction 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.
9. When configuring NSS for LDAP use, "files" should be specified before LDAP in the search order in
nsswitch.conf.
10. 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 Note: In all cases, local host

accounts can be used at the same
time as any of the external AAA
/etc/passwd
/etc/shadow
services. At least one local host
/etc/group account should always be present
lacfile so that the server is accessible
asgfile when access to an external AAA
CM Server
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 required pam_securetty.so
auth required pam_stack.so service=mv-auth
auth required pam_nologin.so
account required pam_stack.so service=mv-auth
password required pam_stack.so service=mv-auth
#pam_selinux.so close should be the first session rule
session required pam_selinux.so close
session required pam_stack.so service=mv-auth
session required pam_loginuid.so
session optional pam_console.so
#pam_selinux.so open should be the last session rule
session required 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.

The content of mv-auth looks like this:
# <MESA:01:@(.............
auth required /lib/security/pam_env.so

auth required /lib/ecs/lib/pam_tally.so deny=5 unlock_time=600
auth required /lib/ecs/lib/pam_root_login.so
auth required /lib/security/pam_asg.so collect_password
auth sufficient /lib/security/pam_asg.so audit
#auth sufficient /lib/security/pam_radius_auth.so use_first_pass
#auth sufficient /lib/security/pam_ldap.so use_first_pass
#auth sufficient /lib/security/pam_safeword.so.1 try_first_pass
#auth sufficient /lib/security/pam_securid.so
auth sufficient /lib/security/pam_unix.so try_first_pass
auth required /lib/security/pam_deny.so
#
# Account modules
#
account required /lib/security/pam_unix.so
account required /lib/security/pam_access.so
#account required /lib/security/pam_time.so
account required /lib/security/pam_tally.so
#account sufficient /lib/security/pam_local_user.so
#account [default=die success=ok user_unknown=ignore service_err=ignore authinfo_unavail=ignore] \
/lib/security/pam_ldap.so
#account sufficient /lib/security/pam_radius.so
#
# Password modules
#
password sufficient /lib/security/pam_asg.so
password required /lib/security/pam_cracklib.so retry=3 minlen=6
password sufficient /lib/security/pam_unix.so use_authtok
#password sufficient /lib/security/pam_ldap.so use_authok
password required /lib/security/pam_deny.so
#
# Session modules
#
session required /lib/security/pam_limits.so
#session required /lib/security/pam_lastlog.so never
#session required /lib/security/pam_motd.so
session required /lib/security/pam_unix.so
Figure 6. Default mv-auth File
Notice that lines for external AAA servers are included in the configuration but commented out. Note also that in
order to use either RSA SecurID® or SafeWord®, a license must be purchased and the PAM application software
loaded.
Remember that the configuration files for the PAM modules need to be edited for use with the external AAA server.
Recall from section 3.2 on page 4 that there are two ways of specifying the second field in the PAM configuration files.
The simple way uses a single key word such as required or sufficient. The more detailed way uses a series of keyword/value
pairs to more precisely define behavior. The LDAP entry in the account section in Figure 6 is an example. The purpose
of this entry is to reduce the delay time for logins if the LDAP server is not available or the user not known in LDAP.
Configuration here has important implications for policy enforcement. See the following for further discussion.
http://meltin.net/people/martin/publications/polythenepam.pdf
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=55193
5. Configuration file for "su"

Linux includes a command, "su", or "substitute user" which allows a command to be run as a different user, typically

as root. If the su command is to work to execute a program as root, then it is important that the account section of su’s
PAM configuration file does NOT invoke pam_access. The reason is that pam_access is configured (by default) to deny
root access. Pam_access would therefore prevent an su to root. Since a direct login to root is blocked, it is required that
an su to root is possible. The default mv-auth file shown in Figure 6. on page 16 includes pam_access it its account
section, so the PAM configuration file for su cannot just reference its account section. Instead, the configuration file
for su in /etc/pam.d/su must contain its own account section as illustrated in Figure 7.
#%PAM-1.0
auth sufficient /lib/security/pam_rootok.so
auth required /lib/security/pam_stack.so service=mv-auth
# su should not call pam_stack, because mv-auth uses pam_access which will fail when trying to su to root.

#account required /lib/security/pam_time.so
# External AAA uncomment as and when needed
#account sufficient /lib/security/pam_localuser.so

#account [default=die success=ok user_unknown=ignoreservice_err=ignoreauthinfo_unavail=ignore] /lib/security/pam_ldap.so
#account sufficient /lib/security/pam_radius.so
password required /lib/security/pam_stack.so service=mv-auth

session required /lib/security/pam_stack.so service=mv-auth
session optional /lib/security/pam_xauth.so
Figure 7. PAM Configuration for "su"
6. Making Changes
Important! The PAM subsystem is a very critical component of the system. It controls all user access. The PAM
subsystem is also completely unforgiving. It will do exactly as it is programmed. The problem here is that what the
programmer believes to be the direction and how PAM interprets the instruction may be two completely different
things. The result can be that all administrative users are locked out of the system. A conservative approach to making
changes should be employed. The following conservative guidelines should be considered carefully.
1. Think through and document all changes in advance of making changes on the Communication Manager
server.
2. Perform a full system backup of all configuration files, especially Communication Manager translation files.
3. If at all possible, use a sacrificial PC running the same version of Linux as is used on Communication Man-
ager and test the PAM configuration on that PC first. Only when it is proven on this PC, make changes to
the Communication Manager server.
4. If possible, do initial testing using a non-production AAA server. This will support greater freedom in
enabling debugging or trying solutions that may be more difficult to do on the production server.
5. Make changes via a laptop/PC connected to the Communication Manager server’s dedicated laptop inter-
face. If this is not possible make changes via a laptop/PC co-located with the Communication Manager
server. The tools and procedure will work remotely, but if a network disruption causes the session to be dis-
connected at the wrong time, the Communication Manager server could be rendered inaccessible.
6. Make sure the firewall is open when needed. Specifically, open the firewall ports first before enabling use of
an external AAA service. Close the firewall last when removing use of an external AAA service.

7. When configuring NSS for LDAP, specify "files" before "ldap". If "ldap" is specified first, not all operations are
well behaved. Adding local host accounts may not work correctly and long delays could result when the
LDAP server is not reachable for any reason.
8. When making changes on the Communication Manager server, use three separate, simultaneous sessions as
follows:
a. Using an SSH client, log in and then su to root. (session 1). Change directory to /etc/pam.d
and make a local copy of mv-auth. For example,
cp mv-auth mv-auth.local5
Edit mv-auth.local and comment out all the lines that refer to an external AAA server. That
is, configure this file for local host accounts only. Enter the command
cp mv-auth.local mv-auth
but do not press enter. Minimize this window.
b. Using an SSH client, log in a second time and su to root. (session 2). This is the session
where changes are made.
c. Using session 2 make a local backup of the files that will be changed. This is in addition to
the full backup of step 2. The purpose of this local backup is to allow easy restore to the orig-
inal configuration if something doesn’t work.
d. Using session 2 make the needed changes.
e. Using an SSH client, verify that you can log in and su to root. (session 3)
f. Test other logins that might be affected by the change. For example, if an LDAP interface
was added, log in using an ID that will invoke this interface and make sure it works.
g. When all tests are complete, close all three sessions.
The reason for session 1 is to provide a fall-back in case something happens in session 2. For example a "fat
finger" entry might close the window. Or something may otherwise hang. Don’t use session 1 unless abso-
lutely necessary and don’t close this session until step "f" has been completed successfully.
It is especially important to not close session 1 prematurely. If the server appears to be locked up, try
to return focus to this window/session and then press return to execute the pre--typed copy command,
after which a reboot will regain control of the server. Wait at least 30 minutes or the sum of the bind
and time-out values in the ldap.conf configuration when using LDAP, whichever is longer. The server may be
very busy attempting to work with an external AAA service. Session 1 is a window with root access. If the
server appears to "hang" while making configuration changes and the server is rebooted, the reboot will NOT
fix it. Instead, the root window will be lost and a recovery action described in the next section will likely be
needed.
9. Do not make large changes all at once. If the desire is to change from the default configuration to one that
enables LDAP, provides a message of the day, removes most of the local host accounts, changes the login
restriction rules or limits and changes password rules or expiration policy, do not make all these changes at
one time. Make the changes one at a time and test after each change. Make sure not only that the current
users can log in, but that changes which affect future events will work. For example, if the rules for cracklib
are changed, make sure the password for a login can still be changed.
10. During initial testing, begin with the least amount of security possible. Use a dummy account which can be
deleted later. Send passwords in the clear. Use unencrypted links. Not only is such a configuration less diffi-
cult to set up, but it allows more effective use of protocol sniffers if things aren’t working. Add the security
features after the basic configuration is working. This is one advantage of using a test AAA server and a test
PC rather than the production servers to begin with.
5. The file name mv-auth.local is descriptive, but the file name z is easier to type correctly when under stress.

7. RAMDISK
Selected Communication Manager servers (S8300, S8500) are capable of continuing to run even if the hard disk fails.
In these systems, a copy of critical files is kept in a special area of memory called RAMDISK. Additional steps are
required when making changes to critical files that are part of RAMDISK.
When RAMDISK is in use, the path "/" refers to the RAMDISK files. The path "/diskroot" refers to the real hard disk.
For example, /diskroot/etc is the directory on the hard disk. /etc is the directory in the RAMDISK. When making
changes to configuration files identified in this document on systems with RAMDISK, the following special
procedures must be followed:
• Use only the files and directories specified herein.
• If a file already exists, edit it in the RAMDISK. i.e. path begins with "/".
• If a file is added, such as adding the file /etc/sd_pam.conf, create the file in /disk-
root/etc/sd_pam.conf. Then create a soft link in the RAMDISK. Example:
ln -s /diskroot/etc/sd_pam.conf /etc/sd_pam.conf
When adding the software for this feature (/diskroot/lib/security/pam_securid.so) a soft link must
be created for the RAMDISK. Example:
ln -s /diskroot/lib/security/pam_securid.so /etc/lib/security/pam_securid.so
• Files may be added to /diskroot/etc/aaa without creating the link.
• Do not use useradd, userdel, or usermod for login management. Use the asguseradd, asgusermod
and asguserdel commands or the cmuseradd, cmuserdel, and cmusermod commands instead. The
useradd, userdel, and usermod commands can break the links for RAMDISK.
8. Recovery
In a Linux desktop PC, recovery from serious problems can be accomplished by booting the system into single user
mode. This provides console root access without a password and bypasses the PAM system entirely. However, the
Communication Manager server does not have a console (monitor, keyboard, mouse) and some server versions do not
have a video card present; some do not support a video card (e.g. S8400). For those server models that support adding
a monitor, keyboard and mouse (possibly by adding a video card), a single user boot is a possible recovery mechanism.
Another possibility for recovery is to physically remove the hard drive from the Communication Manager server,
mount this hard drive in Linux PC as a second drive, edit the files on that PC, and finally return the hard drive to the
Communication Manager server. If such a PC is not available, a third recovery option is to boot the server from the
Compact Disk (CD) software distribution and re-install the software from the beginning. A final recovery action is to
return the system to Avaya for repair.
If the Communication Manager server becomes inaccessible due to an incorrect PAM configuration, the process of
recovery can be very painful and result in a serious system outage. A conservative and careful approach to making
changes is recommended.
9. User Login Characteristics

User authorization for administrator logins for Communication Manager servers is specified and controlled by
assignment to one or more Linux login groups. Each login must be assigned a primary login group and possibly a
second login group. The primary login group must be one of the groups shown in Table 4.
Table 4. Primary Login Group

Group
Group Name Purpose
Number
susers 555 Privileged access to the CM platform
users 100 Non privileged access to the CM platform

Table 4. Primary Login Group
Group
Group Name Purpose
Number
remote 888 PPP access to the CM platform
voice 102 access to the coresident voice mail product on
the CM platform
Logins that are to have access to either the Communication Manager telephony application or the server web pages
must also be a member of exactly one "profile" group. These groups have a default number in the range 10,000 to
10,069 inclusive and are named prof0 through prof69 respectively. This range can be moved via administration on
the server’s web page. For example it could be moved to 20,000 to 20,069. See the Communication Manager
documentation for further information.
The output of the Linux "id" command would look similar to this for the dadmin login, for example.
$ id
uid=2000(dadmin) gid=555(susers) groups=555(susers),10002(prof2)
See also Figure 15. on page 28 for an example LDAP entry for this login. Note that PosixAccounts, PosixGroups and
shadowAccount are required or a suitable mapping provided. Ensure that group names are spelled correctly and the numbers
are as shown above or results may be unpredictable. Also ensure that data entered in the LDAP store is entered consistently with
respect to letter case. A user name entered in upper or mixed case in the PosixAccounts entry but in lower case in the PosixGroups
entry will not work properly. Logins assigned to the remote group should not be members of any other group.
Logins that are members of the susers group have root level access to many commands, including the ability to
create and modify logins. Be aware of this when assigning logins to this group.
10. Home Directories

The Communication Manager server is not a general purpose computing platform. It is a server dedicated to a specific
purpose. Many of the broad capabilities of Linux are not needed in this environment. One of these capabilities is to
have each user assigned their own home directory. Individual home directories on a general platform allow each user
to configure their own environment, save private files, etc. Prior to CM4.0, all logins shared a common home directory
in /var/home/defty. Starting with CM4.0, the administrator has a choice of using this common home or creating
individual homes. The cmuser series of commands create individual home directories in /var/home by default. If
individual home directories are used, the following should be noted:
• All home directories should be created in /var/home
• Users should be cautioned about customizing the content of their home (and should definitely never do so
in /var/home/defty). Changes here are not covered by backup and restore.
• If accounts are created in LDAP, either the user’s home directory must be created on the Communication
Manager server prior to first access, or the PAM module, pam_mkhomedir must be added to the session sec-
tion of mv-auth. i.e
session required pam_mkhomedir.so
11. Configuring Multiple Servers

Communication Manager systems can employ multiple servers in 3 different roles, main (active or standby), ESS
(active or standby) and LSP. Each of these servers must be individually configured for AAA support. This configuration
information is not file synchronized among the servers, in part because it changes very infrequently and in part because
the configuration information can be slightly different server to server. However, to facilitate initial configuration of
multiple servers, a special backup data set is supported. This data set includes the following files:
• /etc/opt/ecs/lsfile • /etc/asg/lacfile • /etc/asg/asgfile

• /etc/passwd • /etc/passwd- • /etc/shadow
• /etc/shadow- • /etc/group • /etc/group-
• /etc/login.defs • all files in /etc/aaa • all files in /etc/pam.d
• /etc/ldap.conf • /etc/openldap/ldap.conf • /etc/nsswitch.conf
• /etc/nscd.conf • /etc/sd_pam.conf • all files in /var/ace
• /etc/pam_safeword.cfg • /etc/raddb/server • /etc/opt/ecs/unused_login_audit.conf
• /etc/motd • /etc/issue • /etc/issue.net
• /var/home/defty/.hushlogin • /etc/sshd/sshd_config • all files in /etc/security
• /etc/securetty • /etc/cron.d/unused_login_audit.cron
To use the backup data set, first configure the main server. If the server is duplicated, either server can be configured
first. Configuring the standby first is perhaps better because if there are problems, the active server is not disturbed,
although access to the SAT cannot be tested on the standby. View the content of the backup data set by examining its
file list as follows so that you are aware of exactly which files are being copied:
cat /etc/opt/ecs/backup/pam_config_ds.conf
On the server where the configuration was done, execute a backup of this dataset as follows (note the double dash in
front of the verbose keyword):
/opt/ecs/sbin/backup -b -d scp://username:password@hostname/dirname -k "pass phrase" ---verbose pam_config
On the next server to be configured execute a restore as follows:
/opt/ecs/sbin/restore -r -d scp://username:password@hostname/dirname/name-of-file -k "pass phrase" ---verbose -p /
This will set the content of the files listed above to the same content as on the originally configured server. This
configuration WILL NOT necessarily be correct. For example, any server unique digital certificates in /etc/aaa will be
those of the source server and will need to be replaced with certificates for the specific server being configured. If
different servers are using different external AAA servers, or use them in a different order, then appropriate files must
be edited to change the address of the external server. This method of using backup and restore is only useful and
appropriate if the configuration of the target server is very nearly identical to that on the source server.
All of the files in the special pam_config backup set are included in the security set. When the security set is
restored, special code is used to attempt to prevent loss of data such as might happen when restoring from a prior
release. These special checks are not performed when restoring the pam_config backup set. The files in the backup are
simply copied in place without modification. The pam_config backup set is expressly for manual movement of files to
another server running the same release of software and it is expected that the administrator will ensure correctness
following the restore.
When restoring this backup set on a system running RAMDISK, the following steps must be followed:
• Disable ramdisk: /opt/ecs/sbin/ramdisk -sf disable

• Reboot the server
• Perform the restore of pam_config
• Make any changes to the restored files as needed
• Enable ramdisk: /opt/ecs/sbin/ramdisk -sf enable
• Reboot the server
When configuring the AAA servers, do NOT use the shared IP address of a duplicated pair of Communication
Manager servers; use the individual address of each server.

12. Tested AAA Server Configurations
When the Communication Manager software is first installed, only local host accounts are configured. The PAM files
must be edited to incorporate support for any other type of account. The following configurations using external AAA
servers have been tested:
• LDAP/NSS (openLDAP, Microsoft Active Directory, Sun ONE6)
• RSA SecurID for Authentication + LDAP/NSS/NSCD
• SafeWord for Authentication + LDAP/NSS/NSCD
• RADIUS for Authentication + LDAP/NSS/NSCD
• RSA SecurID and SafeWord behind a RADIUS server
The next subsections will describe sample content of the configuration files for each of the above configurations. These
files serve as a guide for administration. However, they will not work as shown because parameter values must be
customized for a particular environment. These samples illustrate simple configurations and do not constitute a
recommendation for a real enterprise.
It is recommended that commented lines remain in the actual configuration files to guide modifications or debugging.
Commented lines have been removed from the following examples to increase visibility of the lines that were active.
12.1 LDAP / NSS / NSCD

NSS or Name Service Switch is a feature of Linux which allows user’s authorization credentials (group membership,
default home directory, default shell) to be imported from an external server. NSCD or Name Service Caching
Daemon is an ability to cache user’s credentials that are obtained via NSS from an external server. When the external
data base is large, caching credentials locally improves response time for login processing. The tested configuration is
illustrated in Figure 8. When configuring NSS, list "files" before "ldap"; configuring the reverse order may produce
CM Server PAM
pam_ldap
LDAP
Network
NSCD NSS Server
Figure 8. LDAP Accounts
Login requires an entry in LDAP only
undesirable behavior.
Some references on configuring LDAP for user authentication include the following:
• 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/
12.1.1 Open LDAP
At a very high level, the process for configuring a Communication Manager server to use LDAP authentication
involves the following activities:
6. Sun ONE (Sun Open Net Environment) is a marketing strategy and set of products from Sun Microsystems.

1. Determine the structure/schema for the LDAP server and how users will be represented in this data base. An
enterprise is likely to already have a corporate LDAP server in place and the schema and choices will be con-
strained by what already exists. The LDAP clients on the Communication Manager server require a posixAc-
count, posixGroup, and shadowAccount for each user or suitable mappings to cover all the attributes. See
rfc2307.
2. Determine corporate policy for connection to the LDAP server (or create one). Will a TLS connection be
used? Will one way or two way authentication be employed? What certificates will be used?
3. If TLS will be used, create or obtain the needed certificates and create the trusted root authority files.
Important! Certificates contain an expiration date. If certificates are allowed to expire,
login to the Communication Manager server will be blocked as soon as the certificate expires. Care is
needed to manage certificates on an on-going basis. Also care must be taken if data is restored from backup
and a certificate, now expired, is part of the backup.
4. Add at least one user and at least the login groups for susers and one profile group (prof18-prof69) to the
LDAP data store.
5. If two-way TLS is used, configure the LDAP server as necessary to accept the certificate being used by
pam_ldap in the Communication Manager server.
6. Make sure the that firewall is open for this service. LDAP uses port 389 and secure LDAP port 636 by
default, but these ports are administrable in the ldap configuration file.
7. Configure a Linux PC to use as a test vehicle and configure its PAM and ldap files.
8. Test that the login added to the LDAP store can be used to log into the test PC.
a. Configure a login on the LDAP server first, as indicated in step 4 above.
b. On the test PC, configure the ldap.conf files.
c. On the test PC, use the command /usr/bin/ldapsearch to retrieve the record for the user that was
created in the LDAP store. This is the least restrictive test. It verifies that the administrator account
used to access LDAP is correct and that the user account can be retrieved. Do not proceed to the
next step until ldapsearch works.
d. On the test PC, configure the /etc/nsswitch.conf file to use ldap (files, ldap).
e. On the test PC, use the commands
/usr/bin/getent passwd xxx
/usr/bin/getent shadow xxx
where xxx= the user ID created in step 4 above, to verify you can obtain this data. Do not proceed
until getent works for both passwd and shadow.
f. On the test PC, configure /etc/pam.d/mv-auth to use LDAP.
g. Verify that the login created in step 4 can be used to log into the test PC.
9. When the above works, configure the mv-auth, ldap.conf, and nsswitch.conf files on the Communication
Manager server.
10. Test the login on the Communication Manager server.
Content of mv-auth, NSS Switch and NSS Cache configuration files for this configuration is illustrated in Figure 9. on
page 24 through Figure 11. on page 24.

auth sufficient /lib/security/pam_ldap.so use_first_pass
#
account sufficient /lib/security/pam_local_user.so
account required /lib/security/pam_ldap.so
#
password [default=die success=ok user_unknown=ignore service_err=ignore
authinfo_unavail=ignore]/lib/security/pam_ldap.so use_authok
#
Figure 9. /etc/pam.d/mv-auth for LDAP Authentication
server-user nscd passwd: files ldap

debug-level 0 shadow: files ldap
paranoia no group: files ldap
enable-cache passwd yes hosts: files dns
positive-time-to-live passwd 600 bootparms: files
negative-time-to-live passwd 20 ethers: files
suggested-size passwd 211 netmasks: files
check-files passwd yes networks: files
shared passwd yes protocols: files
enable-cache group yes rpc: files
positive-time-to-live group 3600 services: files
negative-time-to-live group 60 netgroup: files
suggested-size group 211 publickey: files
check-files group yes automount: files
persistent group yes aliases: files
shared group yes
enable-cache hosts no
Figure 10. /etc/nscd.conf for

NSCD Figure 11. /etc/nsswitch.conf
for NSS
There are two configuration files for the LDAP interface. The PAM modules use the configuration file in
/etc/ldap.conf. The LDAP tools (e.g. ldapsearch) use the file in /etc/openldap/ldap.conf. Both ldap.conf files should
contain the same content.

There are multiple ways of configuring the LDAP interface depending on security needs. Three of the methods are (1)
unencrypted links, (2) TLS with one-way authentication and (3) TLS with two-way authentication. In the one-way case,
the LDAP server has a digital certificate which is validated by the client (pam_ldap). In the two-way case, both sides
have a digital certificate and each validates the certificate it receives. The pam_ldap configuration file is illustrated in
Figure 12 through Figure14 for the three cases.
#host 111.222.333.444 #host 111.222.333.444

host myldapserver.someplace.com host myldapserver.someplace.com
base o=avaya, c=us base o=avaya, c=us
ldap_version 3 ldap_version 3
binddn uid=root, ou=people, o=avaya, c=us binddn uid=root, ou=people, o=avaya, c=us
bindpw eugene1998 bindpw eugene1998
timelimit 120 timelimit 120
bind_timelimit 30 bind_timelimit 30
pam_login_attribute uid pam_login_attribute uid
pam_password exop pam_password exop
nss_base_passwd ou=People, o=avaya, c=us nss_base_passwd ou=People, o=avaya, c=us
nss_base_shadow ou=People, o=avaya, c=us nss_base_shadow ou=People, o=avaya, c=us
nss_base_group ou=Group, o=avaya, c=us nss_base_group ou=Group, o=avaya, c=us
nss_map_attribute rfc2307attribute mapped_attribute nss_map_attribute rfc2307attribute mapped_attribute
nss_map_objectclass rfc2307objectclass mapped_objectclass nss_map_objectclass rfc2307objectclass mapped_objectclass
tls_reqcert never ssl start_tls
ssl on
tls_cacertfile /etc/aaa/ca.pem
tls_reqcert demand
Figure 12. /etc/ldap.conf for openLDAP Figure 13. /etc/ldap.conf for openLDAP
(unencrypted link) (one way authentication)

#host 111.222.333.444
host myldapserver.someplace.com
base o=avaya, c=us
ldap_version 3
binddn uid=root, ou=people, o=avaya, c=us
bindpw eugene1998
timelimit 120
bind_timelimit 30
pam_login_attribute uid
pam_password exop
nss_base_passwd ou=People, o=avaya, c=us
nss_base_shadow ou=People, o=avaya, c=us
nss_base_group ou=Group, o=avaya, c=us
nss_map_attribute rfc2307attribute mapped_attribute
nss_map_objectclass rfc2307objectclass mapped_objectclass
ssl start_tls
ssl on
tls_cacertfile /etc/aaa/ca.pem
tls_cert /etc/aaa/client.pem
tls_key /etc/aaa/client.key
tls_reqcert demand
Figure 14. /etc/ldap.conf for openLDAP

(two way authentication)
When configuring the ldap.conf files, the following points are worth noting:
• The host entry generally expects an FQDN rather than an absolute IP address. This creates a depen-
dency on DNS which may not be desirable. An entry for this FQDN can be made in the local
/etc/host file to avoid this dependency. e.g.
111.222.333.444 myldapserver.someplace.com
• Although documentation indicates that an FQDN must be used in the Common Name (CN) of the
certificates, experimentation suggests this is not strictly true. At least for the openLDAP server, the
following is observed:
- The value assigned to "host" in the ldap.conf files must be the same string as assigned to the
CN of the LDAP server’s certificate. That is, the "host" value can be a numeric IP address if
the CN is an IP address or the host can be an FQDN if the CN is an FQDN.
- The openLDAP server does not seem to check the CN of the client’s certificate. i.e. the CN
of the client’s certificate does not have to have an FQDN.
- Your LDAP server may enforce different rules.
• When using two-way authentication with TLS, the Communication Manager server needs a digital
certificate. There are multiple options for this certificate including the following:
1. The certificate already assigned to the Communication Manager server may be used if the
LDAP server will accept a certificate that does NOT have the server’s FQDN in the common
name in the certificate. That is, the Communication Manager certificate contains
Subject: C=US, O=Avaya Inc., OU=Communications Manager, OU=ID-s1-0-1-1, CN=Communication Man-
ager-0-1-1
where the 0-1-1 will vary by server. This type of certificate is acceptable to the openLDAP
server.

These certificates are in the directory /etc/opt/ecs/certs/server. The Avaya Product Root
CA certificate is located in /etc/opt/ecs/certs/CA/apr-ca.crt. When this certificate needs to
be combined with other trusted certificates , this should be done in a file in /etc/aaa. DO
NOT modify apr-ca.crt.
2. A server certificate can be obtained from a public authority such as Verisign. In this case,
place the certificate file and its key file in /etc/aaa. The trusted root CA for the signing
authority is also needed and should also be in /etc/aaa.
3. Create a self-signed certificate and place the appropriate files in /etc/aaa. The appendices to
this document illustrate scripts for this purpose.
• Be careful when setting the time-out values. Too short a time may mean some logins are denied
when the network/LDAP server is busy. Too long a time and some automated scripts attempting to
log in may time out. If the LDAP server is unreachable for any reason, even local login sessions may
be extended until the timer expires.
• The pam_config and security data sets will back up all files in the directory /etc/aaa. Therefore,
when creating certificates or trusted authority lists for TLS, these certificate files should be placed in
/etc/aaa.
• pam_ldap understands the following password encodings: clear, crypt, md5, nds, ad, exop, and
exop_send_old.
• When creating certificates, the key file CANNOT be password protected. i.e. the PAM and NSS
modules cannot deal with a password/pass phrase.
• Entries for the schema in ldap.conf must match what is configured on the LDAP server.
• Any root level login, defined as a login with UID=0, can change the password of any other local host
user on the local host via the command passwd. This is not possible if the account is stored exter-
nally. Only the LDAP database administrator user defined in the LDAP server can perform this func-
tion in LDAP, for example.
12.1.2 OpenLDAP Server
Note: the openLDAP server being discussed in this section is NOT the Communication Manager server, but a separate
machine. The LDAP software from OpenLDAP employs a configuration file named slapd.conf. Figure 16. on page 28
illustrates a simple example configuration for this file7. Actual content will vary greatly depending on choices for
LDAP data in the enterprise. Figure 15. on page 28 illustrates a simple example of an LDAP data base for user
authentication. Two users (dadmin, user18) are present along with three login groups (susers, prof2 and prof18).
Dadmin is a member of susers + prof2 and user18 is a member of susers + prof18.
Note that the slapd.conf file is configured for convenience in testing and a more secure configuration (e.g. encrypted
passwords, etc.) is needed for a real enterprise.
A java-based LDAP browser is available from http://www.jxplorer.org that can be used to enter data in the openLDAP
data base. "JXplorer is an open source ldap browser originally developed by Computer Associates' eTrust Directory
development lab. It is a standards compliant general purpose ldap browser that can be used to read and search any
ldap directory, or any X500 directory with an ldap interface. It is available for immediate free download under a
standard OSI-style open source licence."
7. Perhaps a more modern structure than the one illustrated is to base the DN on the enterprise internet presence. e.g. dn: cn=dadmin ou=Peo-
ple dc=mycompany dc=com for the login, dadmin, at company mycompany.com.

include /usr/local/etc/openldap/schema/core.schema # extended LDIF
include /usr/local/etc/openldap/schema/cosine.schema #
include /usr/local/etc/openldap/schema/inetorgperson.schema # LDAPv3
include /usr/local/etc/openldap/schema/nis.schema # base <> with scope sub
include /usr/local/etc/openldap/schema/openldap.schema # filter: cn=*
include /usr/local/etc/openldap/schema/ppolicy.schema # requesting: ALL
include /usr/local/etc/openldap/schema/misc.schema #
# dadmin, People, Avaya, US
dn: cn=dadmin,ou=People,o=Avaya,c=US
cn: dadmin
pidfile /usr/local/var/run/slapd.pid gidNumber: 555
argsfile /usr/local/var/run/slapd.args homeDirectory: /var/home/defty
objectClass: posixAccount
TLSCACertificateFile /etc/aaa/myCA.pem objectClass: shadowAccount
TLSCertificateFile /etc/aaa/ldap.pem objectClass: person
TLSCertificateKeyFile /etc/aaa/ldap.key objectClass: top
TLSVerifyClient demand sn: dadmin
uid: dadmin
database bdb uidNumber: 2000
suffix "o=Avaya,c=US" loginShell: /bin/bash
rootdn "uid=root,ou=People,o=Avaya,c=US"
rootpw eugene1998 # user18, People, Avaya, US
dn: cn=user18,ou=People,o=Avaya,c=US
directory /usr/local/var/openldap-data cn: user18
gidNumber: 555
index objectClass,uid,uidNumber,gidNumber eq homeDirectory: /var/home/defty
index cn,mail,surname,givenname eq,subinitial objectClass: posixAccount
objectClass: shadowAccount
access to attrs=userPassword objectClass: person
by self write objectClass: top
# by dn="uid=root,ou=People,o=Avaya,c=US" writ sn: user18
by anonymous auth uid: user18
by * read uidNumber: 2018
access to dn.base="o=CMdomain,c=US" by * write loginShell: /bin/bash
access to dn.base="ou=People,o=CMdomain,c=US" by * write
# susers, Group, Avaya, US
access to * dn: cn=susers,ou=Group,o=Avaya,c=US
# by dn="uid=root,ou=people,o=Avaya,c=US" write cn: susers
by self write gidNumber: 555
by users write memberUid: dadmin
by anonymous write memberUid: user18
password-hash {CLEARTEXT} objectClass: posixGroup
loglevel -1 objectClass: top
# prof2, Group, Avaya, US

dn: cn=prof2,ou=Group,o=Avaya,c=US
cn: prof2
description: dadmin account
gidNumber: 10002
memberUid: dadmin
objectClass: posixGroup
objectClass: top
# prof18, Group, Avaya, US

dn: cn=prof18,ou=Group,o=Avaya,c=US
cn: prof18
gidNumber: 10018
Figure 16. slapd.conf file memberUid: user18
objectClass: posixGroup
objectClass: top
Figure 15. LDAP Data Base

Account Control:
The /etc/shadow file contains a series of values to define a password change policy for a local user. Table 5 shows these
values and the corresponding variables in the LDAP store. Note that not all LDAP servers properly support these
variables. Test your configuration explicitly.
Table 5. Password Change Policy

LDAP Attribute /etc/shadow entry
shadowLastChange The number of days (since January 1, 1970) since the password was last changed
shadowMin The number of days before password may be changed (0 indicates it may be changed at any time)
shadowMax The number of days after which password must be changed (99999 indicates user can keep his or her password unchanged for
many, many years)
ShadowWarning The number of days to warn user of an expiring password (7 for a full week)
shadowInactive The number of days after password expires that account is disabled
shadowExpire The date (number of days since January 1, 1970) on which an account will be disabled
When accounts are created on the local host, the file /etc/login.defs contains default values for these parameters that
are used in the initial account creation only. Parameters are stored in /etc/shadow for each user and /etc/login.defs
has no effect after the login is created.
Host Restriction:
The configurations shown in Figures 9 on page 24 and 12 on page 25 through Figure 15. on page 28 will allow all
users access to all Communication Manager servers that are configured for LDAP authentication. It is possible to
restrict users to specific Communication Manager servers. The ldap.conf file supports the following two configuration
variables:
pam_filter
pam_check_host_attr
The pam_filter variable expects an attribute name and value. Virtually any attribute may be chosen. For example, the
sample user configuration above contains a class, ipHost, which contains the attribute, ipHostNumber. (This is not
shown in the figures but is present in the schema.) If the LDAP entry for a userX has
ipHostNumber = CM_main_serverA
and the ldap.conf file for server someserver.com contains the entry,
pam_filter ipHostNumber=CM_main_serverA,
then userX can log into the server someserver.com. A user configured without this value cannot. This approach has the
advantage that the LDAP schema does not have to be modified if there is a spare attribute in the user’s record and the
disadvantage that the chosen variable is probably not intended for this purpose.
The pam_check_host_attr variable is set to either yes or no. For example,
pam_check_host_attr yes
When set to yes, a user attempting to log in must have a HOST attribute configured and the value of this attribute
must be the FQDN of the server to which the user needs access. This can have one little problem. In the sample LDAP
schema shown above, the user does not have a HOST attribute. Further, the default schema that arrives with
openLDAP does have an account class that has a host attribute, but it is structurally incompatible with class, person.
But to use pam_check_host_attr, the user MUST have a host attribute. The schema must be augmented or modified
to make this possible. There is an existing schema named ldapns.schema available from
http://www.math.ias.edu/doc/nss_ldap-226/ldapns.schema
that includes a host attribute. Copy this schema to the LDAP server, edit the slapd.conf file to include the schema and
restart the LDAP server. Then add the host variable to each user record and assign an FQDN. Multiple host variables

may be added to give the user access to multiple hosts. The ldapns.schema contains the following definitions:
Although the whole schema can be added, only the objectclass, hostObject, is needed so it is possible to create a file
with just this definition and add it as a schema.
# $Id: ldapns.schema,v 1.3 2003/05/29 12:57:29 lukeh Exp $
# LDAP Name Service Additional Schema
# http://www.iana.org/assignments/gssapi-service-names8
attributetype ( 1.3.6.1.4.1.5322.17.2.1 NAME 'authorizedService'

DESC 'IANA GSS-API authorized service name'
EQUALITY caseIgnoreMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
objectclass ( 1.3.6.1.4.1.5322.17.1.1 NAME 'authorizedServiceObject'
DESC 'Auxiliary object class for adding authorizedService attribute'
SUP top
AUXILIARY
MAY authorizedService )
objectclass ( 1.3.6.1.4.1.5322.17.1.2 NAME 'hostObject'
DESC 'Auxiliary object class for adding host attribute'
SUP top
AUXILIARY
MAY host )
In order to enforce the local host check, the mv-auth file entry for ldap must be configured equivalent to required in
the account section. If the entry is only sufficient, for example, the user will see something similar to the following on
login but will still log in successfully anyway.
Access denied for this host
-bash-3.00$
In this case the user received the denied message but was logged in just fine.
12.1.3 Other LDAP servers
LDAP servers from SUN ONE and Microsoft (Active Directory) are supported using the same PAM_LDAP client as
is used for openLDAP on the Communication Manager server. Configuration files for these servers (/etc/ldap.conf
and /etc/openldap/ldap.conf) have the same structure (but different content) as for the openLDAP server. Active
Directory requires use of a TLS link if the user is allowed to change their password via Communication Manager.
Although the other two LDAP servers do not enforce this condition, TLS should be used. Otherwise, the user’s
password is passed in the clear.
The LDAP.conf file for SUN ONE is shown in Figure 17. on page 31.
8. This link is not valid but is shown here because it is included in the file.

host sunone.avaya.com
base dc=avaya,dc=com
ldap_version 3
#binddn
uid=root,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot
binddn cn=Directory Manager
bindpw root1234
timelimit 10
bind_timelimit 10
pam_login_attribute uid
#pam_password exop
#pam_password crypt
pam_password clear
nss_base_passwd ou=People,dc=avaya,dc=com
nss_base_shadow ou=People,dc=avaya,dc=com
nss_base_group ou=Groups,dc=avaya,dc=com
#nss_map_attribute rfc2307attributemapped_attribute
nss_map_objectclass rfc2307objectclassmapped_objectclass
#ssl start_tls
#ssl on
tls_cacertfile /etc/aaa/myCA.pem
#tls_reqcert allow
#tls_reqcert demand
tls_reqcert never
tls_cert /etc/aaa/server.pem
tls_key /etc/aaa/server.key
Figure 17. ldap.conf File for SunOne
Earlier versions of Active Directory required a special plug-in (AD4Unix) on Active Directory which is described here:
http://www.securityfocus.com/infocus/1563. The ldap.conf file content for that case is illustrated in Figure 18. on
page 32. A separate white paper (available from the same web site as this paper) titled, Avaya CM Login with Windows
Active Directory Services, is available for configuration and setup of the later releases of Active Directory.

base dc=AAAtest,dc=vita,dc=local
uri ldaps://148.147.7.164/
ldap_version 3
binddn cn=Administrator,cn=Users,dc=AAAtest,dc=vita,dc=local
bindpw secret
scope sub
timelimit 10
pam_password ad
nss_base_passwd cn=Users,dc=AAAtest,dc=vita,dc=local
nss_base_shadow cn=Users,dc=AAAtest,dc=vita,dc=local
nss_map_objectclass posixAccount user

nss_map_objectclass shadowAccount user
nss_map_objectclass posixGroup Group
nss_map_attribute uid sAMAccountName

nss_map_attribute homeDirectory msSFUHomeDirectory
nss_map_attribute uniqueMember member
nss_map_attribute cn sAMAccountName
nss_map_attribute shadowLastChange pwdLastSet
pam_login_attribute sAMAccountName
pam_filter objectclass=User
ssl on
TLS_CACERT /etc/aaa/adcert.pem
TLS_REQCERT demand
Figure 18. ldap.conf for Microsoft Active Directory
12.2 RSA SecurID

RSA SecurID is a token-based authentication method from RSA Security that provides only user authentication. User
authorization must be provided either via parallel local host accounts or from LDAP/NSS. If LDAP/NSS is used, the
configuration files for NSS are as shown in Figure 10. on page 24 through Figure 14. on page 26. The PAM
application for RSA SecurID is not provided on the Communication Manager server. A license for this client must be
purchased from RSA Security and the software loaded onto the server in the field in /lib/security/pam_securid.so,
/etc/sd_pam.conf, and /var/ace/sdconf.rec.This configuration is illustrated in Figure 19. on page 32 and Figure
20. on page 32 with module configuration files shown in Figure 21. on page 33 and Figure 22. on page 33. The default
port for RSA SecurID is 5500 UDP; verify in vendor documentation for your software. See also the notes in Section
3.5 on page 10 regarding parameters for SecurID.
CM Server
PAM PAM
SecurID
/etc/passwd SecurID
pam_securid Server /etc/shadow pam_securid Ntwk Server
/etc/group
Ntwk lacfile
asgfile
pam_ldap
LDAP
Server Each login must have an
NSCD NSS entry in RSA SecurID and in
the local host
CM Server
Each login must have an
Figure 19. RSA SecurID + LDAP entry in LDAP and in RSA Figure 20. RSA SecurID + Local Host
SecurID

auth required /lib/security/pam_asg.so
auth sufficient /lib/security/pam_securid.so
#
account sufficient /lib/security/pam_local_user.so
#account [default=die success=ok user_unknown=ignore service_err=ignore \
authinfo_unavail=ignore] /lib/security/pam_ldap.so
account required /lib/security/pam_radius.so
#
#
Note: LDAP can be used for accounting. If so then, LDAP must be configured as illustrated in
Figures 10 through 14.
Figure 21. /etc/pam.d/mv-auth for RSA SecurID
Note: The sd_pam.conf file will be installed when the software is installed. In addition to this file, a binary file,
#VAR_ACE :: the location where the sdconf.rec, sdstatus.12 and RSA SecurID files will go
VAR_ACE=/var/ace
#ENALE_GROUP_SUPPORT :: 1 to enable; 0 to disable group support

ENABLE_GROUP_SUPPORT=0
#INCL_EXCL_GROUPS :: 1 to always prompt the listed groups for RSA SecurID authentication (include)
# :: 0 to never prompt the listed groups for RSA SecurID authentication (exclude)
INCL_EXCL_GROUPS=0
#LIST_OF_GROUPS :: a list of groups to include or exclude...Example

LIST_OF_GROUPS=other:wheel:eng:othergroupnames
Figure 22. /etc/sd_pam.conf for RSA SecurID
/var/ace/sdconf.rec, must be generated on the RSA SecurID server and copied to the Communication Manager
server. Consult the RSA SecurID documentation for details.

When the Communication Manager server is upgraded, the SecurID software must be re-installed in the new
partition. Prior to the upgrade, edit mv-auth and comment out the use of SecurID. Following the upgrade, after the
system is booted into the new partition, copy the SecurID files from the now off-line partition to the running partition.
If RAMDISK is in use, then
cp /root2/lib/security/pam_securid.so /diskroot/lib/security/pam_securid.so
ln -s /diskroot/lib/security/pam_securid.so /lib/security/pam_securid.so
cp /root2/etc/sd_pam.conf diskroot/etc/sd_pam.conf
ln -s /diskroot/etc/sd_pam.conf /etc/sd_pam.conf
Note that sdconf.rec does not have to be copied because it is in the /var partition which is common to both code
partitions.
If RAMDISK is not in use then:
cp /root2/lib/security/pam_securid.so /lib/security/pam_securid.so
cp /root2/etc/sd_pam.conf /etc/sd_pam.conf
Then edit mv-auth to re-enable use of SecurID. Strictly speaking, mv-auth does not have to be edited as described, but
doing so removes possible problems due to the modules not being present.
If using batch tools such as the upgrade tool to upgrade a number of servers, disable SecurID in mv-auth prior
to invoking the tool, and re-enable after the upgrade.
If using SecurID on a system running IA770 with digital networking, be aware that IA770 uses port 5500 tcp
for message waiting signaling to the IA770 message manager client. The IA770 port cannot be changed. SecurID may
use port 5500 udp by default. This should not be a conflict since IA770 is using TCP and SecurID UDP. However,
if it is desired to avoid the same port all together, it must be changed for SecurID. This is done on the SecurID server.
The sd_pam.conf file must be regenerated and re-installed on the Communication Manager server.
12.3 SafeWord
SafeWord is a token-based authentication method from Secure Computing that provides only for user authentication.
User authorization must be provided either via parallel local host accounts or from LDAP/NSS. If LDAP/NSS is used,
the configuration files for NSS are as shown in Figure 10. on page 24 through Figure 14. on page 26. The PAM
application for SafeWord is not provided on the Communication Manager server. A license for this client must be
purchased from Secure Computing and the software loaded onto the server in the field in /etc/pam_safeword.cfg and
/lib/security/pam_safeword.so.1. These configurations are illustrated in 23 and 24; module configuration files follow.
The sample configuration file contains comments to say that the default port is 7482, but vendor documentation
tested suggested 5030 TCP; verify with vendor documentation for your software.
The safeword files, (pam_safeword.cfg and pam_safeword.so.1) may be distributed on a CD which includes a
JAVA-based installer. Not all Communication Manager servers have a CD drive. This CD must be installed first on a
separate Linux PC and the two files then copied from there to the Communication Manager server.

CM Server
PAM PAM
SafeWord
/etc/passwd
Ntwk SafeWord
pam_safeword Server /etc/shadow pam_safeword
/etc/group
Server
lacfile
Ntwk asgfile
LDAP
LDAP
NSCD NSS Server
CM Server
Figure 23. SafeWord + LDAP Figure 24. SafeWord + Local

Host
Each login must have an entry in SafeWord
Each login must have an entry in LDAP and in and in the local host
SafeWord

auth sufficient /lib/security/pam_safeword.so.1 use_first_pass
#
#
#
Note: LDAP can be used for accounting. If so then LDAP must be configured as illustrated in
Figure 25. /etc/pam.d/mv-auth for SafeWord
A version of the following file, /etc/pam_safeword.cfg, will be installed when the software is installed.
#
# "/etc/pam_safeword.cfg"
#
# SafeWord PAM module Configuration File
# (for use with /usr/lib/security/pam_safeword.so.1)
#
#
# This file determines several operating parameters for "pam_safeword.so.1".
# It may be edited with any text editor. Values are case sensitive.
#
# Lines beginning with a pound sign "#" are treated as comments (the "#"

# MUST be the FIRST character on the line).
#
# Each line in the file has two parts. Everything left of the colon ":"
# is the parameter "Descriptor". The Descriptor MUST include a two character
# ID such as "10" at the beginning of the line followed by a space. The
# remaining text portion of the descriptor is not used by "pam_safeword.so.1"
# and is present only to make the line understandable for humans. To the right
# of the colon ":" is one or more actual "Parameter Values"
# File Id 02: Authentication Server(s)
# This specifies a server to use. There must at least one server
# specified. Additional servers may optionally be specified.
#
# There are four pieces of information needed to specify a server:
# - host name or IP address where the server is located (required)
# - priority weight value used for load balancing. This should be 0
# unless multiple SafeWord servers are used.
# - The maximum number of connections allowed. This value is not used,
# but must be set to 0.
# - service port or socket number (optional) Default is 7482.
#
# The host name may be one of the following:
# (1. Host IP address (e.g. 200.2.2.27).
# (2. Host name. An entry must be made in the /etc/hosts file
# associating the IP address with the host name, or registered
# with your DNS.
#
# At least one server must be configured. Up to 4 servers may be included.
# The PAM client will attempt to connect to the first server in
# the list. If the connection fails, then sid will try the next server
# listed until either a connection fails or it is determined that no
# servers can be utilized and the process aborts with an error.
#
# The service port number (also called socket number) specifies a number
# unique to the authentication server process. This number is only used
# by TCP/IP clients.
#
# The service port number of the service is optional. If omitted or
# set to zero, the default port number will be used. Typically it is
# not required. It should only need to be specified when the default
# port number conflicts with an existing service.
#
# When the port number is zero or not entered in pam_safeword.cfg, then the PAM
# client will look in the /etc/services file for an entry for 'safeword'.
# The entry would look like this:
# safeword 7484/tcp # SafeWord Authentication Server
# If the entry is found, the specified number will be used. If no entry
# is found, then the client will use the default number of 7482.
#
# Note that if you wish to use version 2 EASSP protocol with a
# SafeWord Plus server, the default port is 5030, and you will also
# have to change the EASSP version (Field Id 55, below) to 200.
02 Authen. Server (host weight connects port): 111.222.333.444 0 0 5030
# File Id 09: User ID Source.
# The PAM client can obtain the user's SafeWord ID from either the USER
# himself, in which case the user is prompted for his ID, or it can
# use the user's Unix SYSTEM ID as his SafeWord ID. This setting
# switches between the two identification sources.
#
# Note that, if you obtain the SafeWord ID from the USER, and you are
# only using SafeWord for authentication, then any SafeWord user can
# obtain access to any Unix account. For this reason, it is recommended
# that you stack SafeWord and Unix authentication methods
# (i.e. list both pam_safeword.so.1 and pam_unix.so.1 as 'required') in
# your /etc/pam.conf file in order to assure that SafeWord users are
# authorized to access their selected Unix accounts.
09 User ID Source (USER/SYSTEM): SYSTEM

# File Id 10: Server's System Name.
# This specifies which SafeWord user database is to be used. SafeWord IDUTIL
# can be used to setup and manage multiple user and authenticator databases.
# Each one is given a "System Name". SafeWord comes with the "STANDARD" system
# database already configured. You can continue to use the STANDARD database
# if you wish. Make sure that the Server's System Name is "STANDARD" (or
# matches your custom system name if you wish).
10 Server's System Name: STANDARD
# File Id 13: Data File's Directory
# This specifies the directory where the swec.dat file will reside. This
# file is maintained by pam_safeword.so.1 and contains the encryption
# information needed to keep the link with the SafeWord authentication
# server secure.
13 Data file's dir: /lib/security
# File Id 15: User Status Messages.
# pam_safeword can send error, informational, and status messages to the
# client that is requesting authentications services. Valid entries are:
# NONE - No logging is sent
# ERROR - Error messages are sent
# INFO - Routine informational messages are sent.
# DEBUG - Debugging messages are sent.
# ALL - All message types are sent.
#
# More than one type of message can be specified as in:
# 15 Send Status Messages to User: ERROR INFO
15 Send Status Messages to User: ERROR
# File Id 16: Console Status Messages.
# pam_safeword.so.1 can send error, informational, debug, and status messages
# to the system console. Valid entries are the same as described for
# user status messages. Normally, this value is set to "ERROR".
16 Send Status Messages to Console: NONE
# File Id 17: Log File Messages.
# to the log file (see "Status Message Log Filename). This parameter
# specifies what types of logs are sent to the logfile. Valid entries are the
# same as described for the user status messages. Note that no checking is
# done on the length of the log file and unless monitored, the log file will
# eventually grow to consume all available disk space (unless "NONE" is
# specified).
17 Send Status Messages to Log File: ALL
# File Id 18: Status Message Log Filename.
# to the log file specified here. See "Log File Messages" to determine if
# logging is enabled, and if so, what level.
18 Status Message Log Filename: /var/log/pam_safeword.log
# File Id 23: Status Message Label.
# pam_safeword.so.1 can generate messages. Such messages will be
# identified with the label specified here.
23 Status Message Label: PAM_Safeword
# File Id 27: Client Type.
# This text label can be used to provide authorization that varies
# depending on the access method the user is using. See SafeWord
# documentation for "Services Allowed" pass action for more details.
27 Client Type: PAM
#
# Eassp Version
#
# Should be:
# 100 for SafeWord 5.1.1 and older
# 101 for SafeWord 5.1.2 and new
# 200 for SafeWord Plus
#
55 Eassp Version: 101
#
# Socket timeout in seconds
#

59 Socket timeout: 25
# File Id 1000: Check Pass Action Value
# pam_safeword.so.1 can interpret the user's pass actions as authorization
# values in order to restrict PAM user to selected machines or access points.
# When this line is set to ON, a pass action value of 0 will signify denial
# of authorization, while a non-zero value will grant it. To ignore the
# contents of the pass action field, set this value to OFF, in which case
# all successfully authenticated users will be granted access
# by pam_safeword.so.1. See SafeWord documentation under
# "Services Allowed" pass action for more details.
1000 Check Pass Action Value (ON/OFF): OFF
When the Communication Manager server is upgraded, the SafeWord software must be re-installed in the new
partition. Prior to the upgrade, edit mv-auth and comment out the use of SafeWord. Following the upgrade, after the
system is booted into the new partition, copy the SafeWord files from the now off-line partition to the running
partition.
If RAMDISK is in use, then
cp /root2/lib/security/pam_safeword.so.1 /diskroot/lib/security/pam_safeword.so.1
ln -s /diskroot/lib/security/pam_safeword.so.1 /lib/security/pam_safeword.so.1
cp /root2/etc/pam_safeword.cfg /diskroot/etc/pam_safeword.cfg
ln -s /diskroot/etc/pam_safeword.cfg /etc/pam_safeword.cfg
If RAMDISK is not in use then:

cp /root2/lib/security/pam_safeword.so.1 /lib/security/pam_safeword.so.1
cp /root2/etc/pam_safeword.cfg /etc/pam_safeword.cfg
Then edit mv-auth to re-enable use of SafeWord. Strictly speaking, mv-auth does not have to be edited as described,
but doing so removes possible problems due to the modules not being present.
If using batch tools such as the upgrade tool to upgrade a number of servers, disable SafeWord in mv-auth prior
to invoking the tool, and re-enable after the upgrade.
12.4 RADIUS
RADIUS provides only for user authentication and accounting. User authorization must be provided either via
parallel local host accounts or from LDAP/NSS. If LDAP/NSS is used, the configuration files for NSS are as shown
in Figures 10 on page 24 through 14 on page 26. This configuration is illustrated in Figures 26 on page 39 and 27 on
page 39. The configuration files for RADIUS are shown in Figures 28 on page 39 and 29 on page 40. Note that
RADIUS uses ports 1812 and 1813 (UDP).

CM Server
PAM PAM
RADIUS
/etc/passwd RADIUS
pam_radius Server /etc/shadow pam_radius Ntwk Server
/etc/group
lacfile
LDAP
Ntwk asgfile
LDAP
NSCD NSS Server
CM Server
Figure 26. RADIUS + LDAP Figure 27. RADIUS + Local

Host
Each login must have an entry in RADIUS and
Each login must have an entry in LDAP and in in the local host
RADIUS

auth sufficient /lib/security/pam_radius_auth.so use_first_pass
#
account required /lib/security/pam_radius.so
#
#
Note1: LDAP can be used for accounting. If so then LDAP must be configured as illustrated in
Note2: If the RADIUS server has used an LDAP server for password storage, then it may be
possible to allow the user to change their password from Communication Manager. In this
case the LDAP line in the password section is activated.
Figure 28. /etc/pam.d/mv-auth for RADIUS

# server[:port] shared_secret timeout (s)
172.16.44.6:1812 buyavaya 3
Figure 29. /etc/raddb/server for RADIUS
12.5 Other Configurations

Note that RSA SecurID and SafeWord can be used behind a RADIUS server as illustrated in Figure 30. on page 40
and Figure 31. on page 40. Communication Manager only "sees" the RADIUS server and is not aware that RSA
SecurID/SafeWord are being used. The software for SecurID and/or Safeword is not needed on the Communication
Manager server in this case.
SecurID/ SecurID/
SafeWord
CM Server SafeWord
PAM Server PAM Server
/etc/passwd RADIUS
RADIUS
pam_radius RADIUS /etc/shadow pam_radius Ntwk
/etc/group Server
Server
lacfile
Ntwk asgfile
LDAP
LDAP
NSCD NSS Server
CM Server
Figure 30. RADIUS + LDAP Figure 31. RADIUS + Local

Host
Each login must have an entry in RADIUS and
Each login must have an entry in LDAP and in in the local host
RADIUS
Additionally, external services may use LDAP for storage if they are capable and so enabled. How external services store
their data is transparent to Communication Manager.
13. Other PAM Features

The above sections have focused on support for AAA servers. PAM includes many other capabilities that can be used
in conjunction with any of these configurations, including.
• pam_access • pam_cracklib • pam_issue • pam_lastlog • pam_limits • pam_motd
• pam_tally • pam_time
13.1 pam_access
Pam_access is used to control system access by individual users or groups of users. To use pam_access, it must be
enabled or added to the PAM configuration file (Figure 6. on page 16) and the rules defined in the file
/etc/security/access.conf. Lines in this file have the form:
permission: users: origins
Communication Manager is shipped with a file that contains these lines
# deny all access to the serial port
-:ALL:ttyS0
# block root access everywhere except console ports
-:root:ALL EXCEPT tty0 tty1 tty2 tty3 tty4 tty5 tty6 tty7 tty8
# only members of the group "remote" should be
# allowed to connect via the modem
+:remote:usb/ttyACM0

-:ALL:usb/ttyACM0
13.2 pam_cracklib
Pam_cracklib is a module that can be used to force new passwords to have certain characteristics. For example,
• a new password cannot be a palindrome (a word spelled the same in either direction) such as radar.
• a new password cannot be the old password with just case changes.
• a new password cannot be a rotated version of the old one.
• a minimum length can be enforced.
• a new password cannot be too "close" to the old one. For example, new password equal the old pass-
word with only one character changed.
• a new password can be forced to have a mix of characters (letters, numbers, specials).
• a new password cannot be one that has been recently used. The number of recently used passwords
saved is controlled by the "remember" parameter for pam_unix in the password section of mv-auth.
e.g. password pam_unix remember=10. By default none are saved.
Pam_cracklib is already enabled in the default mv-auth file. There is no configuration file; behavior is controlled
entirely by arguments on the cracklib invocation line. Cracklib parameters are rather obtuse. Hopefully, the following
doesn’t add to the confusion.
Cracklib has two kinds of rules, internal compiled-in rules and rules which may be manipulated via command line
parameters. The internal rules cannot be changed except by recompiling cracklib and include the following.
1. Passwords that are palindromes are never permitted
2. A new password must be different from the old password
3. The difference between the old and new passwords cannot be just a change of case (upper to lower or lower
to upper).
4. A new password cannot be a scramble of the old password or a rotated version of the old one.
5. The password cannot be too simple. For example aaaaaa.
6. The password cannot be a word in a built-in cracklib dictionary of common words stored in
/usr/lib/cracklib_dict. (binary file)
7. The new password cannot be one previously used (stored in /etc/security/opasswd).
8. The password must be a minimum of 6 characters log.
In addition to the built-in rules, cracklib accepts the following parameters on its command line:
Table 6. Cracklib Parameters

Parameter Default Purpose
debug Enables additional messages in syslog. More useful to a developer with source code than to an administrator configuring
cracklib.
type=xxx When cracklib prompts for a password, it uses the string "New UNIX Password:". The word "UNIX" can be replaced with
the string "xxx" from the type=xxx command line parameter.
retry=N 3 The number of times cracklib will allow the user to try to enter a new password that meets cracklib’s criteria before exiting.
Note carefully that this is the number of times a user may try to supply a new password during the password change process;
it is not related to the number of times a user may fail to give the correct password during login.
difok=N 5 This parameter sets the minimum number of characters in the new password that must be different from the old one. How-
ever, there is an exception. If the new password is at least twice as long as the old one, this parameter is ignored.
minlen=L 9 This parameter is used to influence the minimum allowed length of a password. See discussion below.
dcredit=N 1 This parameter is used to influence the number of digit (0-9) characters in a password. See discussion below.
ucredit=N 1 This parameter is used to influence the number of upper case characters in a password. See discussion below.

Table 6. Cracklib Parameters
Parameter Default Purpose
lcredit=N 1 This parameter is used to influence the number of lower case characters in a password. See discussion below.
ocredit=N 1 This parameter is used to influence the number of special characters in a password. See discussion below.
There is a built in rule in cracklib that passwords must be at least 6 characters long. This rule takes precedence over
any other rules regarding password length. The minimum required length can be increased beyond 6 by changes to
the last 5 parameters in Table 6. on page 41. All 5 parameters affect the minimum length together.
The parameter minlen (minimum length) looks to be the minimum length for a password, but it is not. The minimum
acceptable length of a password is also influenced by dcredit, ucredit, lcredit, and ocredit. These parameters can have
either positive or negative values in any combination. Positive values for these parameters reduce the minimum length
requirement. Negative values will be explained shortly. This is best illustrated with a simple example. Consider the
following pam_cracklib configuration:
password required /lib/security/pam_cracklib.so retry=3 minlen=10 dcredit=3 lcredit=0 ucredit=0 ocredit=0
If a user enters a password of 10 random lower case characters, the password will be accepted. However, if the user
enters a password with 4 random lower case letters intermixed with 3 digit characters, the 7-character password is
accepted. That is, dcredit=3 reduces the length required for each digit present in the password up to 3. The password
can have more than 3 digits, but the additional digits will not affect the minimum length requirement. Similar rules
apply for lcredit, ucredit, and ocredit. If cracklib is configured like this,
password required /lib/security/pam_cracklib.so retry=3 minlen=12 dcredit=1 lcredit=1 ucredit=1 ocredit=1
then an 8 character password will be accepted provided it has 1 upper, 1 lower, 1 digit, and 1 special character. It will
obviously have to have more than 1 of at least one type of these characters in order to achieve a length of 8. So the
following password would be accepted
4A3d.wpq
even though minlen=12 and the password is only 8 characters long. Notice that even though there are 2 digits in the
password, it still has to be 8 characters long because dcredit=1. If dcredit had been set to 2, a 7 character password
containing 2 digits would have been acceptable.
Notice that the "credit" parameters did not force the user to have a password with a particular character composition.
The user was simply allowed to choose a shorter password if the specified characters were used.
It is possible to force the password to contain a mix of characters by setting one or more of the "credit" parameters to
a negative value. The following configuration,
password required /lib/security/pam_cracklib.so retry=3 minlen=10 dcredit=-3 lcredit=0 ucredit=0 ocredit=0
will require passwords to be a minimum of 10 characters long and also require 3 of the characters to be digit characters.
The configuration
password required /lib/security/pam_cracklib.so retry=3 minlen=10 dcredit=-3 lcredit=0 ucredit=0 ocredit=2
would require passwords to contain 3 digits. If the password also contains 2 special characters, then the length may be
as short as 8; if no special characters are used, then the length must be 10.
Note: Because there is a built in minimum length of 6, one may encounter unexpected results when setting the
minlen=6 in combination with "credit" values. For example, minlen=6 dcredit=-1 (that’s a minus 1) should allow a
password of kdu8rg but it doesn’t. However, minlen=8 dcredit=-1 will accept a password of kdu8rgbd. This is called a
bug.
13.3 Login Messages (pam_issue and pam_motd)

Linux supports displaying messages at two different times to users logging in. One message, known as the "issue
message" may be displayed as part of the initial login prompt. This message often contains warnings about

unauthorized access. The second message is displayed only after a successful login. This message is called the "Message
of the Day" and is typically used to inform legitimate users about upcoming outages, server status, such as approaching
disk full conditions, or other information of interest to the user.
Prior to the invention of the PAM subsystem, each access service had to display these messages themselves.
Implementation is not consistent across services and each service has its own quirks of operation. Even though all the
services are, at this time, pretty well tied into PAM for user authentication and authorization, display of these messages
has not been fully "pam-ized" and individual services may not cooperate with PAM completely. A description for each
access service will be described shortly, but some words about how to turn on pam_issue and pam_motd.
13.3.1 pam_issue
Pam_issue is intended to display the issue message from the file /etc/issue. To use this feature, one would edit the
desired text into /etc/issue and place a call to its module as the second line in the mv-auth file as follows, noting the
text restrictions described in section 3.5 on page 10. However, pam_issue does not work in all cases and its use is not

auth required /lib/security/pam_issue.so
Figure 32. /etc/pam.d/mv-auth for pam_issue
recommended. Other means for displaying the issue message are described below.
For new system installs, Communication Manager will install a file named /etc/issue.avaya in the active partition and
then copy this file to /etc/issue, again in the active partition. The issue.avaya file contains some default text that may
be used as desired. On an upgrade, a new /etc/issue.avaya will be installed from the distribution. If an /etc/issue file
exists in the current running partition, it will be copied unmodified to the new partition. If it does not exist, then the
/etc/issue.avaya file will be copied to /etc/issue in the new partition. A restore to defaults will copy /etc/issue.avaya
to /etc/issue and overwrite any changes that may have been made there.
Note that the client that is used to access the system can also affect when, how, and if the user sees the issue message.
13.3.2 pam_motd (Message of the Day)
Pam_motd is used in the session section of the PAM configuration file. Pam_motd displays the content of a text file in
/etc/motd to a user AFTER successful login. To use this feature, edit the desired text into /etc/motd and then
uncomment (or add) the pam_motd line in the PAM configuration file. See Figure 6. on page 16. Note also text
restrictions described in section 3.5 on page 10.
13.3.3 SSH
The SSH daemon is configured via the file, /etc/ssh/sshd_config. There are three entries in this file that are of interest
with regard to login message display:
PrintLastLog no
PrintMotd no
Banner /etc/issue
The line PrintLastLog yes, will cause a line of the following form to appear immediately after a successful login:
Last login: Mon Jul 17 11:37:10 2006 from someplace.dr.avaya.com
This line appears regardless of the configuration of pam_lastlog in the PAM configuration files. If the line
session required /etc/security/pam_lastlog never
is added to mv-auth, then two such lines will be displayed on login. The line from pam_lastlog will look similar to this:
Last login: Mon Jul 17 15:04:50 2006 from someplace.dr.avaya.com on pts/2

The two lines are slightly different. The line printed by pam_lastlog occurs first and includes the session identity and
the time corresponds to the time for a preceding login. The line from PrintLastLog yes occurs second, does not contain
the session identity, and the time is the login time of the current session. If pam_lastlog is not present and only
PrintLastLog yes is used, the time is correctly displayed for the prior session.
The line PrintMotd yes, will cause the content of the file /etc/motd to be displayed to the user immediately after the
last login information. There is no option on where the file is located. If at the same time, the line
session required /etc/security/pam_motd
is added to the mv-auth file, the message of the day will be displayed twice. The two mechanisms work independently.
The line, Banner /etc/issue, will cause the content of the file /etc/issue to be displayed. Any file can be specified on
the Banner line. However, SSH will display the content of the /etc/issue file first, followed by whatever file is named,
if it is different from /etc/issue. If the named file is /etc/issue then its is displayed only once. Exactly when this file
is displayed depends on the client but it is usually seen by the user between entering their user name and password.
Placing a call to pam_issue in the mv-auth file has no effect on SSH. i.e. SSH is not integrated with pam_issue.
See also the discussion regarding interactions with pam_tally in section 13.6 on page 45.
13.3.4 Telnet
Telnet is not a "pam-ized" application. As illustrated below, Telnet uses the login process to process user logins. This
PAM Modules
xinet.d in.telnetd login PAM securetty
Module Config
Files
config
Figure 33. Telnet
means that the user experience during login is a combination of the characteristics of the telnet daemon, in.telnetd,
and the login process. The in.telnetd daemon is hard coded to display the content of /etc/issue.net prior to the login
prompt. Additionally, the telnet daemon seems to be incompatible with use of pam_issue entirely. Adding pam_issue
to the mv-auth file prevents a user from logging in via telnet at all. If telnet is to be used, /etc/issue should be copied
to /etc/issue.net, assuming the messages are to be the same, and pam_issue not used.
By default, login will display the time of last login from /var/log/lastlog, and will also display the message of the day
file from /etc/motd. However, if a zero length file named .hushlogin (note first character is a period) is in the user’s
home directory, then login will not display this information.
Additionally, if the following lines are placed in the mv-auth file,
session required /etc/security/pam_lastlog never
session required /etc/security/pam_motd
the user will see the time of last login and message of the day from these entries. That is, if the .hushlogin file is NOT
present, the user would see the time of last login and message of the day twice, once from the login process and again
from the PAM entries. Telnet has the same behavior as SSH regarding display of time of last login when both methods
are employed.
13.3.5 HTTP
The web pages for the Communication Manager server are hard coded to display the content of the /etc/issue file on
the "home" page and display the /etc/motd file after successful login. The only way to remove this display is to remove
the files.

13.3.6 FTP/SFTP
Communication Manager servers support vsftp with an anonymous login only. FTP is disabled by default and must
be enabled before it can be used. FTP does not support display of last login information nor the message of the day.
FTP is also not "pam-ized" and none of the message options in PAM work with FTP. FTP will display the content of
the /etc/issue file if the following line is present in /etc/vsftpd.conf.
banner_file=/etc/issue
13.4 pam_lastlog
Pam_lastlog can be used to display a message to the user at login time to tell the user the time of their last login to this
system. Pam_lastlog keeps track of user logins in the file /var/log/lastlog. To use this feature, uncomment the lastlog
entry or add it to the mv-auth configuration file (Figure 6. on page 16). Pam_lastlog accepts several parameters to
control the message it displays; see the PAM Administrator’s Guide for further details. See also notes about SSH and
telnet in sections 13.3.3 on page 43 and 13.3.4 on page 44. Pam_lastlog is required by the unused_login_audit and for
generating reports regarding login activity.
13.5 pam_limits
Pam_limits is used to restrict resources such as the amount of CPU time, number of open files, number of processes,
etc. that a user may access. These limits are more appropriate to a general purpose computing platform than to the
Communication Manager server because these limits are controlled by the Communication Manager application.
Attempting to change these limits via PAM may cause unexpected behavior. There are, however, two limits that can
be set, maxlogins and maxsyslogins. The first controls the maximum number of sessions that may be active
simultaneously for a particular user and the second controls the maximum number of simultaneous sessions for all
users taken together. To use pam_limits to limit the number of sessions, pam_limits must be enabled in the PAM
configuration (Figure 6. on page 16) and the /etc/security/limits.conf file must be edited to set values for maxlogins
or maxsyslogins.
13.6 pam_tally
Pam_tally is used in both the auth and account section of the PAM configuration file and is used to deny access to a
user after N failed login attempts. To use this feature, it must be configured in the mv-auth file (see Figure 6. on
page 16). There is no additional configuration file. However, there are important parameters on the pam_tally line. In
particular the number of unsuccessful attempts should be explicitly set. e.g. deny=5. After this many failed attempts
the account becomes locked and must be reset by a root user via the program /sbin/pam_tally. (Note that this is a
command and is not the same as the pam module of the same name.) If the parameter, unlock_time = T, is set, then
the account will automatically become enabled again, T seconds after it became locked. e.g. unlock_time=600 causes
the account to automatically unlock 10 minutes after it locks. In the standard implementation of pam_tally, there is
no time limit on the number of failed login attempts. That is, if
pam_tally.so deny=3 unlock_time=600
and a user enters a bad password today, stops trying to login, comes back tomorrow and tries one more time
unsuccessfully, stops and comes back the next day and enters a 3rd bad password, the account becomes locked.
Further, the time T starts over if the user tries again while the account is locked.
Avaya has modified pam_tally to accept a new parameter, unlock_reset. If this parameter is present on the pam_tally
line, then both the attempt count and the time are cleared after unlock_time=T seconds of no activity on the next
attempt. That is, if
pam_tally.so deny=3 unlock_time=600 unlock_reset
and the user enters three bad passwords, stops trying for a period longer than 10 minutes, and then tries a 4th time,
the account is unlocked and the count of attempts is set to 1, corresponding to the current attempt. The reset occurs
on the 4th attempt; there is no audit to perform the reset at the time the timer expires. The user can try bad passwords
forever as long as they don’t try faster than once every 10 minutes. If the user tries faster than once every 10 minutes,

the account will become locked after the third bad attempt and remain locked with the timer being reset to 600 for
each bad attempt.
Notice the position of the pam_tally lines in Figure 6. on page 16. Place the lines as shown. It is not likely to work
otherwise.
A note about deny and unlock_time. These two parameters work together to control how many bad password attempts
are permitted per unit time. This is important because it limits a hacker using an automated program trying multiple
passwords rapidly in order to discover one that works. From a security perspective, it would be desirable to have the
account lock until an administrator is called to unlock it. However, this is operationally expensive and very
undesirable. To avoid this expense, the deny value should be large enough to allow humans to make a reasonable
number of typing errors and recover; the unlock_time should be set small enough so that the legitimate user is
motivated to wait rather than call the help desk for an unlock, but long enough to achieve the desired hacker
impedance. Consider that deny=3 with unlock_time=600 and deny=6 with unlock_time=1200 produce the same rate
limit on bad password attempts (3 per 10 minutes). However, the deny=6 case is much more forgiving of the legitimate
human user. There is likely to be a corporate security policy governing how to set these parameters.
The version of pam_tally provided with CM4.0 will display a message to the user if the user attempts to log in when
their login is locked. The default behavior of pam_tally is to display this message, but if the special parameter, quiet is
add to the pam_tally command line as follows,
pam_tally.so deny=3 unlock_time=600 unlock_reset quiet
then the message is not displayed.The message is

Your account is locked. Maximum amount of failed attempts was reached.
There is an interaction between the configuration of the ssh daemon and the deny setting for pam_tally. The ssh
daemon will, by default, deny access for any given session after 6 invalid attempts to log in, regardless of how pam_tally
is configured. The message (for the login "junk") looks something like this:
This may be changed in /etc/ssh/sshd_config by the addition of the parameter MaxAuthTries. From the man page for
sshd_config:
MaxAuthTries Specifies the maximum number of authentication attempts permitted per connection.
Once the number of failures reaches half this value, additional failures are logged. The
default is 6.
If "pam_tally deny=10" in mv-auth were to be configured and the user attempted to login repeatedly with a bad
password, by default, the ssh daemon would display the above message after 6 failed attempts and terminate the
session. If the user starts another session and continues to try, then after 4 more attempts, pam_tally will lock the
account. If the quiet parameter is present on the pam_tally line, the user will not be aware of this lock and may
continue trying until the 12th attempt, at which point the ssh daemon will display the message and terminate the
session. If the quiet parameter is not present, then the user will see "Account Locked" for each invalid attempt after
10 (in this example).
13.7 pam_time
Pam_time is used to control access based on time of day and day of week. To use pam_time, it must be enabled or
added to the PAM configuration file (Figure 6. on page 16) and the rules defined in the file /etc/security/time.conf.

Lines in this file have the form:
services; ttys; users; times
A line like
all; *; !bigguy; !Wd0000-2400
would deny access to all users on weekends except the login "bigguy". See comments in the time.conf file for details.
© 2006 Avaya Inc. All Rights Reserved. Avaya and the Avaya Logo are trademarks of Avaya Inc. or Avaya ECS Ltd., a wholly owned
subsidiary of Avaya Inc. and may be registered in the US and other jurisdictions. All trademarks identified by ® and TM are registered
trademarks or trademarks, respectively, of their owners.

Appendix A: Certificate Scripts
This appendix contains sample scripts and control files for creating a private root certificate and server certificates.
Consult the openssl documentation for use of the commands listed. For example, Network Security with OpenSSL by
John Viega, Matt Messier and Pravir Chandra, 0Rielly, ISBN: 0-596-00270-X.
These scripts assume a directory structure as follows: The index.txt file must be created as a zero length file to begin.
(i.e. touch index.txt.) The file "serial" must be initialized to 01. (i.e. echo "01" >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 <CertName> "
exit 1
fi
echo ""
echo ""
echo "(1)make a key"
openssl genrsa -out $ServCert.key 1024

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

####################################################################
[ 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 = $dir/serial # The current serial number

RANDFILE = $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 # 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
default_crl_days= 60 # how long before next CRL
default_md = sha1 # which md to use
preserve = no # 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

[ req_distinguished_name ]
# Country
countryName = Country Name (2 letter code)
countryName_default = US
countryName_min =2
countryName_max =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 = Common Name
commonName_default = myldapserver.someplace.com
commonName_max = 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 ]
authorityKeyIdentifier=keyid:always,issuer:always

# 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
certificatePolicies=ia5org,@capol
######################################################
# Extensions for a SA
######################################################
[ v3_sa ]
basicConstraints = CA:false
# Key Usage
keyUsage = digitalSignature
extendedKeyUsage = codeSigning
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
[ engine ]
default = openssl
# rsa = openssl
# dsa = openssl
# dh = openssl

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

Glossary
1
2 AAA Authentication, Authorization and Accounting
3
4 CD Compact Disk
5 CM Communication Manager
6
7 FTP File Transfer Protocol. A non-secure protocol for file transfer (RFC 0959, STD0009)
8 LDAP Lightweight Directory Access Protocol (RFC 2251)
9
10
Local Host Account A user login account for which all AAA information is maintained on the same
11 server the user is logging in to.
12 Microsoft Active Directory A Microsoft implementation of LDAP
13
14 PAM Pluggable Authentication Module
15 PAM Application A software module that has been enhanced to interact directly with the Linux PAM
16 subsystem
17
18 PC Personal Computer
19 PPP Point to Point Protocol
20
21 RADIUS Remote Authentication Dial In User Service (RFC 2865)
22 RFC Request for Comment. An Internet standard
23
24
RSA SecurID® A token based authentication mechanism from RSA Security
25 SASL Simple Authentication and Security Layer (RFC 2222)
26
SAT Communication Manager System Administration Terminal interface
27
28 SSH Secure Shell. A protocol for secure remote login and other secured network services
29 over an insecure network. (RFC 4251)
30
31
SafeWord® A token based authentication mechanism from Secure Computing
32 Sun ONE Sun ONE (Sun Open Net Environment) is a marketing strategy and set of products
33 from Sun Microsystems.
34
35 Telnet A non-secure protocol for interfacing terminal oriented processes to each other (RFC
36 855, STD0008)
37 ASG Access Security Gateway. A one-time-password implementation proprietary to Avaya.
38
39 Cron A process provided by Linux to run jobs periodically
40 NSCD Name Service Caching Daemon. A daemon that provides a cache for user variables
41 obtained via name service requests.
42
43 NSS Name Service Switch. A module to obtain/search-for user authorization variables
44 from an order list of databases.
45
SU Substitute User. A command to allow one to run a shell as another user/group
46
47 SUDO Superuser Do. A command to allow a system administrator to give certain users or
48 groups of users the ability to run some or all commands as root or as another user.
49
50
Tripwire An auditing program that monitors for file changes.
51 VSFTP Very Secure File Transfer Protocol. A secure version of FTP.
52
53
54
55
56
57
58
59

CM Administrator Logins

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CM Administrator Logins

Uploaded by

Copyright:

Available Formats

Communication Manager Administrator Logins

Issue 1.4 Communication Without Boundaries 1

3. The Linux PAM

Issue 1.4 Communication Without Boundaries 2

PAM Application PAM Engine securetty

Issue 1.4 Communication Without Boundaries 3

Figure 2. AAA Structure

3.2 PAM Configuration File Structure

Issue 1.4 Communication Without Boundaries 4

Table 1. PAM Configuration File Sections

Table 2. PAM Configuration File Fields

Issue 1.4 Communication Without Boundaries 5

3.3 PAM Modules

Issue 1.4 Communication Without Boundaries 6

Issue 1.4 Communication Without Boundaries 7

Issue 1.4 Communication Without Boundaries 8

3.4 Related Modules

Issue 1.4 Communication Without Boundaries 9

3.5 PAM Configuration File Content

auth required pam_env

account required pam_unix

password sufficient pam_asg

#session required pam_limits (optional)

Figure 3. Generic PAM Configuration File

Issue 1.4 Communication Without Boundaries 10

Issue 1.4 Communication Without Boundaries 11

If the PAM configuration file is as follows:

Issue 1.4 Communication Without Boundaries 12

However, if the PAM configuration file looks like this:

Issue 1.4 Communication Without Boundaries 13

Issue 1.4 Communication Without Boundaries 14

4. Communication Manager Default PAM Files

PAM Note: In all cases, local host

Figure 5. PAM Configuration File for Login

Issue 1.4 Communication Without Boundaries 15

auth required /lib/security/pam_env.so

Figure 6. Default mv-auth File

5. Configuration file for "su"

Issue 1.4 Communication Without Boundaries 16

account required /lib/security/pam_unix.so

# External AAA uncomment as and when needed

#account sufficient /lib/security/pam_localuser.so

password required /lib/security/pam_stack.so service=mv-auth

Figure 7. PAM Configuration for "su"

Issue 1.4 Communication Without Boundaries 17

Issue 1.4 Communication Without Boundaries 18

9. User Login Characteristics

Table 4. Primary Login Group

Issue 1.4 Communication Without Boundaries 19

10. Home Directories

11. Configuring Multiple Servers

Issue 1.4 Communication Without Boundaries 20

• Disable ramdisk: /opt/ecs/sbin/ramdisk -sf disable

Issue 1.4 Communication Without Boundaries 21

12.1 LDAP / NSS / NSCD

Figure 8. LDAP Accounts

Login requires an entry in LDAP only

Issue 1.4 Communication Without Boundaries 22

Issue 1.4 Communication Without Boundaries 23

Figure 9. /etc/pam.d/mv-auth for LDAP Authentication

server-user nscd passwd: files ldap

Figure 10. /etc/nscd.conf for