LDAP-UX Client Services B.05.01 Administrator Guide for HP directory servers and Windows ADS

For more information on how to configure access rules in the access policy configuration file, set
global policy access permissions, and configure the pam.conf file for security policy enforcement
when using ssh key pair or r-commands, see Section 7.4.10 (page 210).
7.4.3.1 Authentication using PAM
The PAM framework is pluggable, the backend support for PAM authentication, account
management, session management, and password management services can be directed to
alternate repositories, such as a directory server or Kerberos KDC. When the authentication functions
are invoked, the UNIX identity is translated into an ID that represents that user in the backend
repository (such as a distinguished name in a directory server or a principal in a Kerberos KDC).
If the backend authentication operation succeeds, then the PAM backend authentication function
will return success to the PAM authentication subsystem.
With LDAP (PAM_LDAP) or Kerberos (PAM_KERBEROS), when authentication occurs, not only is
the user authenticated, but security policy verification also occurs. If the account is locked or a
password has expired, the directory server or KDC will return an error to the PAM authentication
subsystem. However, the design of PAM is such that authentication and policy enforcement are
handled by two different functions, authentication and account management functions, respectively.
However, in some cases, services such as ssh and rlogin can authenticate users without calling
the PAM authentication function. But those services might still call the PAM account management
function to determine if the account is disabled or if a password has expired. In this case, backend
PAM modules such as PAM_LDAP and PAM_KERBEROS might not be able to perform security
policy verification, since that verification is done in the authentication function. You can use
PAM_AUTHZ to supplement security policy verification that is not performed by PAM_LDAP or
PAM_KERBEROS, if the security policy information can be found in the directory server.
For more information about pam.conf configuration and sample files, see “Sample PAM
configuration (pam.conf) files ” (page 420).
7.4.3.2 Authentication with secure shell (ssh) and r-commands
For LDAP-UX B.04.00 and previous releases, a user defined in an LDAP directory who tries to log
on to a UNIX system using ssh key pair or the rhost enabled r-command will always be able to
log in even if this user’s account has been locked or password has expired. These applications
and commands do not need to call the PAM (Pluggable Authentication Module) authentication
functions, but perform their own authentication instead. When this occurs, the LDAP bind or Kerberos
authentication operation is never performed. Thus, the directory server or KDC is never given the
opportunity to perform security policy enforcement.
LDAP-UX Client Services B.04.10 or later provides PAM_AUTHZ features to support enforcement
of account and password policies, stored in an LDAP directory server, for applications/commands
(such as ssh or r-command) where authentication is not performed by the PAM subsystem, but is
performed by the command itself.
7.4.4 Policy file
The system administrator can define a local access policy that can be stored in an access policy
file. The default access policy file is /etc/opt/ldapux/pam_authz.policy, but you can store
the local access policy in an alternate location by setting the policy option in pam.conf. The
PAM_AUTHZ service module uses this local policy file to process the access rules and to control
the login authorization. Any service that loads the libpam_authz.1 library will also load this
file. The access policy file location is set per-service in pam.conf, so access rules can be customized
for each service . For example:
login auth required libpam_authz.so.1 policy=/etc/opt/ldapux/login.policy
ftp auth required libpam_authz.so.1 policy=/etc/opt/ldapux/ftp.policy
202 Administering LDAP-UX Client Services