This section includes the following topics:
Identity Manager Fan-Out driver platforms for most UNIX implementations make use of the Pluggable Authentication Module (PAM) framework for system-entry services, such as login. PAM is defined by OSF RFC 86.0.
When a service (login, ftp, user written application, etc.) makes a call to the PAM API, the request is forwarded to the appropriate authentication module based on the specifications you have made in the PAM configuration file, normally /etc/pam.conf. (Some Linux implementations separate the PAM parameters for various services into files in the /etc/pam.d/ directory.) A sample pam.conf file for Platform Services is included in each UNIX platform distribution.
The PAM architecture enables authentication by multiple authentication services through stacking. Stacking service modules can force users to authenticate to several authentication services, possibly using different passwords, or it can allow users the opportunity to authenticate using any one of several methods or some combination of methods.
It is very important to understand certain return codes returned by services in the stack, because these return codes are used in conjunction with the control flag to determine the behavior of the authentication flow within the stack.
Always test the logical flow of your configuration. Some configurations could allow users to log in without passwords, while others could prevent login by anyone, including root. Many service modules, including the Platform Services service module, treat root differently from other users.
For detailed information about PAM, see RFC 86.0, included in each UNIX Platform Services distribution package.
For PAM configuration file information specific to your UNIX implementation, see the man pages, typically man pam.conf.
For Linux-PAM documentation on the Web, see the Linux Kernel site.
An entry in pam.conf has the form:
service module_type control_flag module_path parameters
Service: The name of a service, such as login and ftp. The specification other indicates the module to be used by all other applications not specified in the file.
Module_Type: The type of PAM function.
auth: User authentication
account: Account access, such as expiration and time of day restrictions
session: Session management accounting
password: Password change
Control_flag: Determines continuation or failure behavior of the module. This is especially important if stacking is used.
required: This module must return success in order to have the overall result be successful. If this module fails, stack processing continues and hides where the failure occurred from the user.
requisite: Like required, except stack processing fails immediately if this module fails. Requisite is not used in many versions of PAM.
sufficient: If this module is successful, skip the remaining modules in the stack, even if their control flags indicate they are required. If this module fails, the overall result might be determined by other modules in this stack.
optional: If this module fails, the overall result can be successful if another module in this stack returns success. If this module succeeds, the overall result might be determined by other modules in this stack. If no other modules are required, then a success by an optional module causes success for the stack.
Module_Path: The pathname of the module to be invoked for the function.
The PAM service module for Platform Services, pam_ascauth, checks the user ID to see if it is in the Exclude list or is the user ID root (unless the root_nds PAM parameter is specified). If either condition is met, then pam_ascauth returns PAM_IGNORE, which has the same effect as the Platform Services authentication service not being included in the stack.
Parameters: Command line parameters to be passed to the module. The developer of a module can use these any way desired, but the PAM framework recommends that several parameters always be supported. Among these are use_first_pass (use the same password as that used by the first module that asked for one) and try_first_pass (like use_first_pass, but prompt if it is not valid).
The Platform Services PAM module supports several other parameters. For details about these parameters, see Platform Services PAM Module Parameters.
The following is a fragment from the sample pam.conf file that is provided with Platform Services for Solaris.
login auth sufficient /usr/lib/security/pam_ascauth.so.1 stats login auth required /usr/lib/security/pam_unix.so.1 try_first_pass
This fragment deals with authenticating users of the login service.
The first line specifies the Platform Services PAM module, pam_ascauth.so.1, passing it a parameter of stats, which causes it to write additional statistics records about its processing to syslog. If pam_ascauth.so.1 returns success, the user is granted access to the system. If pam_ascauth.so.1 returns failure, the next module is called.
The second line calls the native Solaris PAM module. It is invoked only if the Platform Services PAM module returns failure. This module first tries the password that was entered by the user and rejected by the driver. If the password is not valid, the user is prompted for the local UNIX system password. If that password is rejected, the user is not granted access to the system. Even if this module returns success, the next module in the stack, if any, is called.
WARNING:You must be familiar with PAM configuration for your particular UNIX implementation before attempting to create your own PAM configuration files. Take extreme care in configuring PAM on your systems. Mistakes here can result in major security exposures.
You can specify the following parameters to the Platform Services PAM module to control its operation:
Table 2-1 Platform Services PAM Module Parameters
For more information about PAM module configuration, see Overview of pam.conf.
Identity Manager Fan-Out driver platforms may also be configured for account redirection using the Name Service Switch and the Platform Services Cache Daemon.When a service requests account information such as uidNumber, gidNumber or homeDirectory, the Name Service Switch redirects these calls to the appropriate library configured by the Name Service Switch configuration file, /etc/nsswitch.conf. If configured to use the Fan-Out Platform Services Cache Daemon, information is retrieved from Event Journal Services memory cache which resides on the local Linux or UNIX system.
Platform Services for UNIX redirects password check and password change requests to eDirectory™.
You can optionally store passwords into the local security system and the Samba password file upon a successful check or change password request. You can also replicate password change information from eDirectory onto your UNIX platform.
Given appropriate security system configuration, maintaining current password information in the local security system allows the user to log in with the eDirectory password if the driver, eDirectory, or the network is not available.
Password redirection for most UNIX systems is accomplished using the Pluggable Authentication Module (PAM) framework. Platform Services for AIX uses the Loadable Authentication Module (LAM) system provided by AIX.
For more information about PAM, see PAM Configuration Notes.
If configured to do so, Platform Services for UNIX stores the user’s password in the local security system and the Samba password file upon a successful check password or change password operation.
To configure Platform Services to store passwords in the local security system, add the UPDATEPASSWORD statement to the platform configuration file. For details about the platform configuration file, see the Platform Services Planning Guide and Reference.
To configure Platform Services to store passwords in the Samba password file, add the UPDATESAMBA statement to the platform configuration file. For details about the platform configuration file, see the Platform Services Planning Guide and Reference.
For details about configuring the local security system for failover, see Configuring PAM for Failover and Configuring AIX for Failover.
If configured to do so, the UNIX Platform Receiver stores password updates from eDirectory into the local security system and the Samba password file.
To configure the core driver to send password information from eDirectory to the platform, use the Web interface to set Permit Password Replication for the Platform object. For details, see the Core Driver Administration Guide. By default, the core driver converts passwords to lowercase before sending them to the Platform Receiver. For more information, see the Maintain Password Case configuration parameter in the Core Driver Administration Guide.
To configure Platform Services to store passwords in the local security system, add the UPDATEPASSWORD statement to the platform configuration file. For details about the platform configuration file, see the Platform Services Planning Guide and Reference.
To configure Platform Services to store passwords in the Samba password file, add the UPDATESAMBA statement to the platform configuration file. For details about the platform configuration file, see the Platform Services Planning Guide and Reference.
For details about configuring the local security system for failover, see Configuring PAM for Failover and Configuring AIX for Failover.
The UNIX Platform Services Cache Daemon can be configured to store account and password updates from eDirectory into a secure local memory cache. This information can be retrieved by local system calls to provide complete account information to your Linux or UNIX system, removing the burden of storing these accounts and other sensitive information in the passwd, shadow and group files of the local /etc directory.To set the core driver to send Posix Account information, be sure your driver filter is configured to allow the posixAccount and posixGroup classes and attributes to flow from eDirectory to the target application. In addition, a Universal Password policy must be configured for the target users and the ability to retrieve the Universal Password from LDAP must be enabled.
The examples in the following sections demonstrate possible PAM configurations.
The first section in the Solaris 2.9 Example Pam Configuration File Fragment represents the auth configuration for service-name “other” in a generic Solaris 2.9 /etc/pam.conf file. The first module prompts for user ID and password. The second module does a keylogin (if needed). The final module does authentication based on the default repository as listed in nsswitch.conf.
The second section in this example, which would replace the first section, authenticates using the Identity Manager Fan-Out driver. If the driver authentication fails, an attempt is made to authenticate the user against the local repository, using the password from the driver prompt.
The other examples show similar PAM configurations for other platforms.
/etc/pam.conf:
#vendor supplied #other auth requisite pam_authtok_get.so.1 #other auth required pam_dhkeys.so.1 #other auth required pam_unix_auth.so.1 #Identity Manager Fan-Out driver variation other auth sufficient /usr/lib/security/pam_ascauth.so.1 stats other auth required pam_unix_auth.so.1 try_first_pass
The following example represents a possible auth configuration for service-name “login” on a FreeBSD* 4.4 platform. This example is designed to authenticate against the Identity Manager Fan-Out driver. If the driver authentication fails for any reason, the same user ID and password combination is used with the standard authentication module.
/etc/pam.conf:
login auth sufficient pam_ascauth.so stats login auth required pam_unix.so try_first_pass
/etc/pam.d/login:
auth sufficient /lib/security/pam_ascauth.so stats debug auth required /lib/security/pam_stack.so service=system-auth
/etc/pam.d/system-auth:
auth sufficient /lib/security/pam_unix.so likeauth nullok try_first_pass
/etc/pam.conf:
# Authentication Management # OTHER auth sufficient /usr/lib/security/libpam_ascauth.1 stats OTHER auth required /usr/lib/security/libpam_unix.1 try_first_pass
If Identity Manager Fan-Out driver authentication fails, an authentication attempt is transparently made against the local authentication mechanism for users whose SYSTEM attribute in /etc/security/user evaluates to the following:
DCE OR DCE[UNAVAIL] AND compat
The Platform Services Process provides Authentication Services and the interface for the AS Client API. It establishes and maintains connections to core drivers and provides load balancing and failover among them.
The Platform Services Process must be running if you plan to use Authentication Services on the platform.
Start the Platform Service Process upon system startup and stop the Platform Service Process during system shutdown.
To start the Platform Services Process, use the following command:
/usr/local/ASAM/bin/PlatformServices/PlatformServicesProcess/asampsp
To stop the Platform Services Process, use the kill command.
NOTE:Optional Startup/Shutdown scripts are provided in the ASAM/data/UnixStartupScripts directory.
Table 2-2 Platform Services Process Command Line Parameters
This involves two types of files.
The Platform Services Process reads the platform configuration file to locate core drivers, to determine which users are authenticated using Authentication Services, and to find other configuration information. For details about the platform configuration file, see the Platform Services Planning Guide and Reference.
The UNIX Platform Services Process writes messages to log files in the SYSLOG facility specified by the SYSLOGFACILITY statement in the platform configuration file. Log messages are documented in the Messages Reference.
The Platform Receiver obtains provisioning events from Event Journal Services and calls the appropriate Receiver script to process the given type of event. For more information about Receiver scripts, see Receiver Scripts.
The Platform Receiver must be running if you plan to use Identity Provisioning on the platform.
Schedule running the Platform Receiver as appropriate for the mode of operation that you have chosen for it. If you are using Persistent Mode or Polling Mode, start the Platform Receiver during system startup and stop the Platform Receiver during system shutdown. If you are using Scheduled Mode, use cron or a similar utility to run the Platform Receiver on a schedule that is appropriate for you. For information about choosing a mode of operation, see the Platform Services Planning Guide and Reference.
To start the Platform Receiver, use the following command:
/usr/local/ASAM/bin/PlatformServices/PlatformReceiver/asamrcvr
To stop the Platform Receiver, use the kill command.
NOTE:Optional Startup/Shutdown scripts are provided in the ASAM/data/UnixStartupScripts directory.
Table 2-3 Platform Receiver Command Line Parameters
The following options determine the mode of operation for the Platform Receiver.: -i, -c, -p, -f, and -r. They are mutually exclusive. If none of them is present, the mode of operation specified by the RUNMODE statement in the platform configuration file is used. If there is no RUNMODE statement, the Platform Receiver uses Persistent Mode.
For details about the Platform Receiver modes of operation, see the Platform Services Planning Guide and Reference.
This involves three types of files.
The Platform Receiver reads the platform configuration file to locate the core driver, to determine which users and groups are managed using provisioning events, and to find other configuration information. For details about the platform configuration file, see the Platform Services Planning Guide and Reference.
Receiver scripts for UNIX platforms are implemented as shell scripts. The Platform Receiver runs the Receiver scripts from ASAM/bin/PlatformServices/PlatformReceiver/scripts. The installation process stores the base scripts in subdirectories of the scripts directory. For information about Receiver scripts, see Receiver Scripts.
The UNIX Platform Receiver writes messages to log files in the SYSLOG facility specified by the SYSLOGFACILITY statement in the platform configuration file. Log messages are documented in the Messages Reference.
The Platform Services Cache Daemon provides Account information for account redirection. It establishes and maintains a connection to the core driver and synchronizes Posix profile and password information from eDirectory to a local memory cache.The Platform Services Cache Daemon must be running if you plan to use Account Redirection through the Name Service Switch on the platform.
Start the Platform Service Cache Daemon upon system startup and stop the Platform Service Process during system shutdown.
To start the Platform Services Cache Daemon, use the following command:
/usr/local/ASAM/bin/PlatformServices/PlatformPS/asamps
To stop the Platform Services Cache Daemon, use the kill command.
NOTE:Optional Startup/Shutdown scripts are provided in the ASAM/data/UnixStartupScripts directory.
This involves three types of files.
The Platform Services Cache Daemon reads the platform configuration file to locate core drivers and to find other configuration information. For details about the platform configuration file, see the Platform Services Planning Guide and Reference.
The UNIX Platform Services Cache Daemon writes messages to log files in the SYSLOG facility specified by the SYSLOGFACILITY statement in the platform configuration file. Log messages are documented in the Messages Reference.
The UNIX Platform Services Cache Daemon writes the memory cache to a protected, encrypted file on the local file system in the /usr/local/ASAM/data/PlatformServices/certs directory. This file is written upon shutdown and read upon startup in order to provide quick retrieval of account information without having to synchronize with eDirectory upon every startup.