Softpanorama
May the source be with you, but remember the KISS principle ;-)

Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Solaris PAM

News Authentication and Accounts Security

Recommended Links

Selected PAM Modules Papers Reference
Linux PAM   PAM wheel SecurID Humor Etc

Pluggable Authentication Modules (PAM) are an integral part of the authentication mechanism for the Solaris. PAM provides system administrators with the ability and flexibility to choose any authentication service available on a system to perform end-user authentication. Other PAM implementations are Linux-PAM and OpenPAM.

By using PAM, applications can perform authentication regardless of what authentication method is defined by the system administrator for the given client.

PAM enables system administrators to deploy the appropriate authentication mechanism for each service throughout the network. System administrators can also select one or multiple authentication technologies without modifying applications or utilities. PAM insulates application developers from evolutionary improvements to authentication technologies, while at the same time allowing deployed applications to use those improvements.

PAM employs run-time pluggable modules to provide authentication for system entry services. PAM offers a number of benefits, including:

This article is part one of a two-part series that offers a technical overview of how the Solaris 9 OE implementation of PAM works, and demonstrates the straightforward way in which it can be configured to accommodate site-specific security policy requirements. This article examines the PAM architecture and the components that make up PAM.

Extending Authentication in the Solaris 9 OE Using PAM: Part II due in the October issue of Sun BluePrintsTM Online details the PAM application programming interface (API) and the PAM service provider interface (SPI). It also details how to write your first PAM module, including annotated examples of how to write pluggable authentication modules.

Part one of this article contains the following information:

Traditional Solaris OE Authentication

Traditional Solaris OE authentication is based on the method developed for early UNIX implementations. This method employs an one-way encryption hashing algorithm called crypt(3c). The encrypted password is stored either in a file or in a Solaris OE naming service, from which it is retrieved during the user login process. The traditional UNIX method of the Solaris OE authentication, using crypt(3c), is very popular and has been enhanced to use an LDAP directory as its data store.

Before proceeding with the details on authentication, you must have a good understanding of what crypt(3c) is. There is some confusion because of a naming conflict with an application named crypt; the latter is a standard tool that ships with the Solaris OE and is a program for encrypting and decrypting the contents of a file. (This program can be found in /usr/bin/crypt.)

However, when the term "crypt" is referred to in authentication, it is normally cited as crypt(3c) and refers to the standard UNIX password hashing algorithm crypt(3c), available to C programmers in the libc.so  library.

A more sophisticated authentication method based on public key technology was introduced with the Network Information System (NIS+) naming service (now rebranded as the Sun OSTM 5.0 Network Information Service). The NIS+ naming service method does not replace crypt(3c), but rather provides an additional security layer by introducing the concept of a network password. When users access network services through the secure remote procedure call (RPC) mechanism, the network password is required.

Originally developed by Sun Microsystems, Inc. and adopted by the Open Software Foundation (OSF) for inclusion in Common Desktop Environment (CDE)/Motif, pluggable authentication modules (PAM) provide a mechanism for dynamic system authentication and related services such as password, account, and session management. Realizing that new authentication models continue to be developed, Sun Microsystems, Inc. created the PAM architecture that allows additional methods to be added without disturbing existing ones. PAM was introduced in the Solaris 2.6 OE to overcome having to recode system entry services such as, login, passwd, dtlogin, telnet, and rlogin  when a new authentication mechanism was developed and introduced.

The PAM architecture and alternatives to traditional Solaris OE authentication are presented in the Section , "Solaris 9 OE PAM Framework," on page 6.

UNIX Passwords

Passwords are created with the Solaris OE passwd  command. This command prompts the user for a (new) password, which the user enters as a text string. In the Solaris OE, this text string is then hashed—or one-way encrypted—using the crypt(3c) algorithm. The result is stored either in /etc/shadow, or in the passwd.byname  and passwd.byuid  NIS maps. If the NIS+ naming service is used, the results are stored in the Passwd  and Cred  table type. The crypt(3c) algorithm is provided with a random seed, known technically as a salt string, so that the result is different each time the passwd  command is run, even if the same text string is used.

When a user logs in, the Solaris OE login  program challenges the user to provide a password. This password is hashed in the same manner as the passwd  command. If the output from this process matches the output that is stored in the password database, the user is authenticated.

The major benefit of crypt(3c) is that it is easy to implement in a closed environment. Authentication takes place on the host that the user logs in to, so an authentication server is not required. In the case of local logins, the clear text passwords are never stored or sent over the network, so there is no reason to be concerned about eavesdroppers intercepting the password. However, when authenticating over a network using telnet  or rlogin, passwords are sent in the clear text.

Because crypt(3c) uses a one-way encryption algorithm, it is difficult to decrypt passwords stored on the server. Only the user knows what the actual password is. This means that there is no way to convert passwords stored in crypt to another format required by a different authentication method.

When the crypt(3c) function is called, it takes the first eight characters and returns its computation. This computation is then injected with a randomly generated value called the salt. In conventional crypt, the salt is stored as the first two characters. This salt value is then added, resulting in a sequence of 13 characters. The result is that the salt is actually an important part of the password string that is stored in the specific naming service.

NOTE

In the future, Sun plans to update the crypt(3c) API in the Solaris 9 OE to allow different algorithms, such as MD5 and Blowfish to be used for encrypting the user's login password.

As CPUs and storage capabilities increase, the crypt(3c) algorithm becomes vulnerable to attack. The crypt(3c) mechanism shipping with the Solaris 9 OE, along with PAM authentication, is exactly the same implementation that has been in the Solaris OE for many years now, and is due to change in a subsequent update release of the Solaris 9 OE.

The Solaris OE crypt(3c) mechanisms work well for authenticating local Solaris OE clients, but they are not the only methods used by applications and services running in the Solaris OE. This can make it difficult for system developers and system administrators, who must work with multiple password systems, and for users who must remember multiple passwords.

The PAM interface in the Solaris 9 OE makes it easier for system administrators to deploy different authentication technologies without modifying administrative commands such as login, telnet, and other administrative commands. Administrators are able to select one or multiple authentication technologies, without modifying applications or utilities. PAM can also be an integral part of a single sign-on system. The PAM APIs provide a flexible mechanism that increases overall system security. The PAM APIs are detailed in Extending Authentication in the Solaris 9 OE Using PAM: Part II due in the October issue of Sun BluePrints Online.

PAM Components

This section details the following components that make up PAM:

Solaris 9 OE PAM Framework

The PAM framework enables new authentication technologies to be plugged in without the need to change commands such as login, dtlogin, rsh, su, ftp, and telnetd. PAM is also used to replace the UNIX login with other security mechanisms, such as Kerberos and LDAP authentication. Mechanisms for account, session, and password management can also be plugged in through this framework.

This framework consists of four specific components:

PAM allows the system administrator to choose any combination of services to provide authentication. These include a flexible configuration policy that enables a per application authentication policy, choice of a default authentication mechanism for non-specified applications, and multiple passwords on high security systems. Another valuable service is the ease of use for the end user that enables no retyping of user passwords if the passwords are the same, and optional parameters passed to the services.

With the introduction of the new PAM framework in the Solaris 9 OE, the LDAP service module for PAM has been extended to support the account service, which checks a user's password and account status by binding to the directory (LDAP) server. The directory server returns the password status to pam_ldap, which in turn maps the status to the PAM error codes. A user might be rejected when logging in with an expired password, or might see a warning message after logging in when the password is about to expire.

The pam_ldap  module has also been updated to support password syntax checking, which is performed through the SunTM Open Net Environment (Sun ONE) Directory Server 5.x (formerly known as the iPlanetTM Directory Server) password policy engine. When changing the password (using the passwd  command), the user might see error messages such as password too short, password in history, and so forth

Pluggable Authentication Service Module Types

The PAM framework currently provides four different types of service modules, which are implemented by dynamic loadable module types to provide authentication related services. These modules are categorized based on the function they perform:

Stacking

PAM enables authentication by multiple methods through stacking. When a user is authenticated through PAM, multiple methods can be selected to fully identify the user. Depending on the configuration, the user can be prompted for passwords for each authentication method. This means that the user need not execute another command to be fully authenticated. The order in which the methods are used is determined through the configuration file, /etc/pam.conf.

NOTE

Stacking might increase the security risk, because the security of each mechanism could be limited by the least secure password method used in the stack. For example, it may not be possible to use the strongest PAM mechanism, such as pam_kerb5  (Kerberos V5 service module for PAM) in the Solaris OE LDAP Client implementation with the directory server, because the currently available directory server does not yet support Kerberos.

Now that some of the PAM basics have been covered, the next section presents an architectural overview of the PAM framework. FIGURE 2 illustrates the PAM framework.

FIGURE 2 PAM Framework Architecture


 

PAM Operation

The PAM software consists of a library, several modules, and a configuration file. The PAM library, /usr/lib/libpam.so, provides the framework to load the appropriate modules and manage stacking. It provides a generic structure for all of the modules to plug into.

FIGURE 3 illustrates the relationship between the applications, the library, and the modules. The applications login, passwd, and su  use the PAM library to access the appropriate module. The pam.conf  file defines which modules are used with each application. Responses from the modules are passed back through the library to the application.

FIGURE 3 PAM and the Relationship Between Applications, Library, and Modules

Pluggable Authentication Service Modules

Each module provides the implementation of a specific mechanism. More than one module type (auth, account, session, or password) can be associated with each module, but each module needs to manage at least one module type. The following is a description of the modules that are part of the Solaris 9 OE.

For security, these files are required to be owned by root  and to have their permissions set so that the files are not writable through group  or other  permissions. If the file is not owned by root, then PAM will not load the module. This requirement on permissions and owner for the modules is not documented anywhere, and might change in future releases.

NOTE

In FIGURE 3, pam_unix  is not layered entirely on the LDAP server. The pam_unix  module sits on the Name Service Switch (NSS) layer and the NSS backends that could be files, NIS, NIS+, or LDAP.

PAM Configuration File Update

The PAM configuration file, /etc/pam.conf, determines what authentication services are used and in what order. Edit this file to select the desired authentication mechanisms for each system entry application.

Configuration File Syntax

The PAM configuration file consists of entries with the following syntax:

service_name module_type control_flag module_path module_options

TABLE 1 explains the functions of the syntax.

TABLE 1 Configuration File Syntax

Syntax Function
service_name Name of the service (for example, ftp, login, telnet)
module_type Module type for the service (auth, account, session, password)
control_flag Determines the continuation or failure semantics for the module (see note below)
module_options Specific options passed to the service modules

 

Comments can be added to the pam.conf  file by starting the line with a pound sign (#). Use white space to delimit the fields.

NOTE

An entry in the PAM configuration file is ignored if one of the following conditions exists: the line has fewer than four fields, an invalid value is given for module_type or control_flag, or the named module is not found.

TABLE 2 summarizes PAM configurations.

TABLE 2 PAM Configurations

Service Name Daemon or Command Module Type
cron /usr/sbin/cron account
dtlogin /usr/dt/bin/dtlogin auth, account, session
ftp /usr/sbin/in.ftpd auth, account, session
init /usr/sbin/init session
login /usr/bin/login auth, account, session, password
passwd /usr/bin/passwd auth, account, password
ppp /usr/bin/pppd auth, account, session
rexecd /usr/sbin/in.rexecd auth, account
rexd /usr/sbin/rpc.rexd account, session
rlogin /usr/sbin/in.rlogind auth, account, session, password
rsh /usr/sbin/in.rshd auth, account
sac /usr/lib/saf/sac session
sshd /usr/lib/ssh/sshd auth, account, session, password
su /usr/bin/su auth, account
telnet /usr/sbin/in.telnetd auth, account, session, password
ttymon /usr/lib/saf/ttymon session
uucp /usr/sbin/in.uucpd auth, account

 

Control Flags

To determine continuation or failure behavior from a module during the authentication process, you must select one of four control flags for each entry. Successful or failed attempts are indicated through control flags. Even though these flags apply to all module types, the following explanation assumes that the flags are being used for authentication modules. The control flags are as follows:

required  — This module must return success  in order to have an overall successful result. If all of the modules are labeled as required, then authentication through all modules must succeed for the user to be authenticated. If some of the modules fail, then an error value from the first failed module is reported. If a failure occurs for a module flagged required, all modules in the stack are still tried but failure is returned. If none of the modules are flagged required, then at least one of the entries for that service must succeed for the user to be authenticated.

requisite  — This module must return success  for additional authentication to occur. If a failure occurs for a module flagged requisite, an error is immediately returned to the application and no additional authentication is done. If the stack does not include prior modules labeled required  that failed, then the error from this module is returned. If a earlier module labeled required  has failed, the error message from the required module is returned.

optional  — If this module fails, the overall result can be successful if another module in this stack returns success. The optional  flag should be used when one success in the stack is enough for a user to be authenticated. This flag should only be used if it is not important for this particular mechanism to succeed. If your users need to have permission associated with a specific mechanism to get their work done, then you should not label it optional.

sufficient  — If this module is successful, skip the remaining modules in the stack, even if they are labeled required. The sufficient  flag indicates that one successful authentication is enough for the user to be granted access. More information about these flags is provided in the next section, which describes the default /etc/pam.conf  file.

NOTE

In Solaris 9 12/02 OE, a NEW control flag has been added to the PAM framework. The control flag binding has a meaning of terminate processing upon success, and report the failure if unsuccessful. This option effectively provides a local account overriding remote (ldap) account functionality.

Generic pam.conf  File

The following is an example of a generic pam.conf  file:

# PAM configuration
# Authentication management
#
login   auth requisite pam_authtok_get.so.1
login   auth sufficient pam_unix_auth.so.1
login   auth required pam_ldap.so.1
#
rlogin  auth sufficient pam_rhosts_auth.so.1
rlogin  auth required   pam_authtok_get.so.1
rlogin  auth sufficient pam_unix_auth.so.1
#
dtlogin auth required   pam_authtok_get.so.1
dtlogin auth required   pam_unix_auth.so.1
#
rsh     auth sufficient pam_rhosts_auth.so.1
rsh     auth required   pam_unix_auth.so.1
#
dtsession auth required pam_authtok_get.so.1
dtsession auth required pam_unix_auth.so.1
#
other   auth required   pam_authtok_get.so.1
other   auth required   pam_unix_auth.so.1
#
# Account management
#
login   account requisite       pam_roles.so.1
login   account required        pam_projects.so.1
login   account required        pam_unix_account.so.1
#
dtlogin account requisite       pam_roles.so.1
dtlogin account required        pam_projects.so.1
dtlogin account required        pam_unix_account.so.1
#
cron    account required        pam_projects.so.1
#
cron    account required        pam_unix_account.so.1
#
other   account requisite       pam_roles.so.1
other   account required        pam_projects.so.1
other   account required        pam_unix_account.so.1
# Session management
#
other   session required        pam_unix_session.so.1
#
# Password management
#
other   password requisite      pam_authtok_get.so.1
other   password requisite      pam_authtok_check.so.1
other   password sufficient     pam_authtok_store.so.1
other   password required       pam_ldap.so.1

This generic pam.conf  file specifies the following behavior:

  1. When running login, authentication must succeed for the pam_authtok_get  module and for either the pam_unix_auth  or the pam_ldap module.
  2. For rlogin, authentication through the pam_authtok_get  and pam_unix_auth modules must succeed if authentication through pam_rhost_auth  fails.
  3. The sufficient  control flag for rlogin's pam_rhost_auth  module indicates that if the authentication performed by the pam_rhost_auth  module is successful, the remainder of the stack is not executed, and a success value is returned.
  4. Most of the other commands requiring authentication require successful authentication through the pam_unix_auth  module.

The other  service name allows a default to be set for any other commands requiring authentication that are not included in the file. The other  option makes it easier to administer the file, since many commands that use the same module can be covered by only one entry. Also, the other  service name, when used as a catchall, can ensure that each access is covered by one module. By convention, the other  entry is included at the bottom of the section for each module type. The rest of the entries are in the file control account management, session management, and password management.

Normally, the entry for the module_path  is root-relative. If the file name entered for module_path  does not begin with a slash (/), the path /usr/lib/security/$ISA  is added to the file name, where $ISA  is expanded by the framework to contain the instruction set architecture of the executing machine (see the isainfo(1) man page for additional information).

A full path name must be used for modules located in directories other than the default. The values for the module_options  can be found in the man pages for the module (for example, pam_unix_auth(5)).

If login  specifies authentication through both pam_unix_auth  and pam_ldap, then the user is prompted to enter a password for each module, for example:

# Authentication management
#
login auth required pam_authtok_get.so.1
login auth sufficient pam_unix_auth.so.1
login auth required pam_ldap.so.1

PAM and LDAP Password Management Extensions

It is important to provide a quick overview to clarify the difference between PAM Password Management Extensions and the new pam_ldap  password management.

PAM Password Management Extensions provide the same functionality as the existing pam_unix  module. The only difference is how the module is packaged. What used to be a single module is now split up into multiple components, known as service modules, each performing a separate function. This modular construction makes implementing custom password management policies easier.

The new pam_ldap  password management facility includes two new account management features: password aging and account expiration. Because the directory server provides its own mechanism for account management, a conflict can occur if you wish pam_ldap  to implement a different password policy than what the directory-wide policy is set for. For example, the directory may force all users to change passwords after 60 days but you might want some special user accounts to be able to keep their current password for a longer period of time.

To support this flexibility, the PAM framework has been enhanced by the addition of a new control flag called binding which instructs pam_ldap  to terminate further process once the password policy criteria has been met and report a failure if it is not. Effectively, this control flag allows you to override the password policy that the directory server enforces.

A server_policy option has been added to instruct pam_unix  to allow users that only have LDAP accounts to be processed by the password policy set on the directory server. This option can be used to instruct the pam_unix_account, pam_unix_auth, and pam_passwd_auth  service modules to ignore the user being authenticated and let the pam_ldap  module stacked below them process the user according to the password policy established in the directory server. This effectively allows you to override the local pam_unix  password policy.

NOTE

The pam_authtok_store  module handles this option differently.

The server_policy option was introduced to solve a problem found when stacking the pam_unix_account  and pam_ldap  modules together. When used, it tells the module to rely on the policy specified on the LDAP server and not to apply a local policy.

Because pam_unix_account  receives incomplete information from the LDAP server, it might inadvertently decide that an active account has expired, or that an expired account is still active. Specifying server_policy in /etc/pam.conf tells pam_unix_account  not to guess an account's status but to leave the decision to the LDAP server. The LDAP server keeps accurate current status of each account and can draw the correct conclusion about its expiration status.

Because this feature enables the pam_ldap  module to fully support the account management, it is reasonable to use the following PAM configuration for account management.

other  account  requisite  pam_roles.so.1
other  account  required   pam_projects.so.1
other  account  binding pam_unix_account.so.1 server_policy
other  account  required   pam_ldap.so.1

NOTE

In this configuration, please note the binding control flag for pam_unix_account.so.1.

This configuration specifies that pam_unix_account  should check the user's local account first. Because of the binding control flag, the stack succeeds or fails depending on the values returned by pam_unix_account. If only the ldap account exists for the user, pam_unix_account  does nothing and allows pam_ldap  determine the stack's success or failure.

Customer feedback indicated that the PAM functionality in the Solaris OE needed some enhancements. The requested changes included improving the mechanism used to validate password structures, adding the ability to change numbers of characters, total password length, and so forth.

In previous versions of the Solaris OE, this functionality was tightly coupled in a single monolithic module (pam_unix) and local extensions could not be incorporated in the module.

Only with a great deal of effort could you extend part of the operations performed by this module. Because of this, the pam_unix(5)  functionality has been replaced with a new set of modular PAM service modules that are listed in this section. The functionality of pam_unix  has been entirely replaced in the Solaris 9 OE. New PAM modules are now provided that replace a specific piece of pam_unix. This makes it easier to customize the PAM behavior by inserting or replacing individual modules. The Solaris 9 OE no longer uses pam_unix  by default. During upgrades any existing instances of pam_unix  in pam.conf  are replaced by the new modules.

In the Solaris 9 OE, the functionality provided by the old pam_unix  module has been split over a number of small modules, each performing a well-defined task, that can be easily extended or replaced by modifying the pam.conf  file.

These new modules are:

You no longer have to replace the pam_authtok_check  module to extend or replace the standard password strength checks. Just list the module in the /etc/pam.conf  file right before, after, or instead of the pam_authtok_check file.

To Add a PAM Module

  1. Determine the control flags and other options to be used.
  2. Become superuser.
  3. Copy the new module to /usr/lib/security.

    NOTE

    If you have a 64-bit version of the module, you should place that version in /usr/lib/security/sparcv9.

  4. Set the permissions so that the module file is owned by root  and the permissions are 755.
  5. Edit the PAM configuration file, /etc/pam.conf, and to add this module to the appropriate services.

To Verify The Configuration

It is essential to do some testing before logging out, in case the configuration file is misconfigured.

  1. Test the modified service or the other configuration.
  2. Run rlogin, su, and telnet  if these services have been changed.

If the service is a daemon spawned only once when the system is booted, it might be necessary to reboot the system before you can verify that the module has been added, however it might be possible to restart the daemon using the appropriate /etc/init.d/  script.

To Disable .rhosts  Access With PAM From Remote Systems

A common use of the .rhosts  file is to simplify remote logins between multiple accounts owned by the same user. For example, if you have multiple accounts on more than one system, you might need to perform specific tasks and using the .rhosts  file is ideal.

However, using the .rhosts  file as an authentication mechanism is a weak form of security and should be avoided.

  1. Remove the rlogin  and rsh  (pam_rhosts_auth.so.1) entries from the PAM configuration file.

This prevents reading the ~/.rhosts  files during an rlogin  session and therefore prevents unauthenticated access to the local system from remote systems. All rlogin  access requires a password, regardless of the presence or contents of any ~/.rhosts  or /etc/hosts.equiv  files.

NOTE

To prevent other unauthenticated access to the ~/.rhosts  files, remember to disable the rsh  service. The best way to disable a service is to remove the service entry from /etc/inetd.conf. The remote shell server, rshd,  and the remote login server, rlogind,  only use PAM, they do not call the ruserok()  function themselves.

PAM Error Reporting

Diagnostic messages generated by the PAM modules or the PAM framework are output using syslog(3c). They are logged to the facility that was specified at the time the application (login, telnet, sshd) called openlog(3c), so the exact location of these messages depends upon whether the application uses PAM.

For example, login  sends its messages to the LOG_AUTH  facility, while rlogind  sends its messages to the LOG_DAEMON  facility. Other daemons might use a configurable facility (sshd,  ftpd,  and so forth) which can be set in the configuration file of the particular service.

Depending on the severity of the diagnostic message, the PAM module directs the message to one of the eight available log priorities.

NOTE

For additional details on the syslog()  function and priorities, see the syslog(3c)  and syslog.conf(4)man pages.

Debug messages are logged with:

syslog(LOG_DEBUG, "...")

Critical messages are logged with:

syslog(LOG_CRIT, "...")

For example, a general error message (LOG_ERR) from PAM, used by login, is directed to auth.crit  and ends up in a logfile as:

Jul 22 22:11:43 host login: [ID 887986 auth.error] ACCOUNT:pam_sm_acct_mgmt: illegal option debuf

To Initiate Diagnostics Reporting for PAM

  1. Backup the syslog.conf  file before editing it.
  2. Determine the syslog  facility used by the application you want to receive diagnostic reports from.
  3. Edit the /etc/syslog.conf  to add a line describing where the message with the intended facility and priority will be logged, for instance:
    auth.debug /var/adm/authlog

    Note that these message levels are part of a hierarchy:

    High -------------------------------------Low
    EMERG ALERT CRIT ERR WARNING NOTICE INFO DEBUG

    Due to this hierarchical ordering, a syslog  channel specified to log debug  messages also logs messages at all higher levels (for example, logs messages with priority debug  and up).

  4. Make sure that the logfile specified in the previous step actually exists. If it doesn't, create it now with
    # touch /var/adm/authlog
  5. Make syslogd  re-read the configuration file by sending it a HUP signal:
    # pkill -HUP syslogd

Initiate PAM Error Reporting

The following example displays all alert messages on the console. Critical messages are mailed to root. Debug messages are added to /var/log/pamlog.

auth.alert /dev/console
auth.crit root
auth.debug /var/log/pamlog

Each line in the logfile contains a timestamp, the name of the system that generated the message, and the message itself. Be aware that a large amount of information may be written to the pamlog  file.

The log format was changed in the Solaris 8 OE and subsequent releases, and now includes a hash-value of the message generating string for example—"user %s not found." It now contains the message facility and severity.

There is another part to diagnostics reporting the debug  option to a module.

  1. Add the debug  flag to a PAM module to enable diagnostics reporting of that module, for example:
    # PAM Module Debugging
    #
    login   auth requisite          pam_authtok_get.so.1
    login   auth required           pam_dhkeys.so.1         debug
    login   auth required           pam_unix_auth.so.1      debug
    login   auth required           pam_dial_auth.so.1

This configuration example enables debugging information from pam_dhkeys.so.1  and pam_unix_auth.so.1.

What gets logged might vary quite a bit, since there is no standard describing the information that needs to be output in response to this option. It is a good practice for module developers to recognize this debug  flag and enable some form of debugging when the flag is specified in /etc/pam.conf.

PAM LDAP Module

The PAM LDAP module (pam_ldap) was introduced in the Solaris 8 OE for use in conjunction with pam_unix  for authentication and password management with an LDAP server. This module was written to support stronger authentication methods such as CRAM-MD5, in addition to the other UNIX authentication capabilities provided by pam_unix.

NOTE

The pam_ldap  module must be used in conjunction with the modules supporting the UNIX authentication, password and account management, as pam_ldap  is designed to be stacked directly below these modules.

Currently, pam_ldap  provides support only for authentication and password management. Support for account management is expected to be provided in the Solaris 9 12/02 OE.

The pam_ldap  module should be stacked directly below the pam_unix  module in the configuration file /etc/pam.conf. If there are other modules that are designed to be stacked in this manner, they could be stacked under the pam_ldap  module. This design must be followed in order for authentication and password management to work when pam_ldap  is used. The following is a sample of /etc/pam.conf  file with pam_ldap  stacked under pam_unix:

# Authentication management for login service is stacked.
# If pam_unix succeeds, pam_ldap is not invoked.
login   auth sufficient /usr/lib/security/pam_unix.so.1
login   auth required /usr/lib/security/pam_ldap.so.1
# Password management
other   password sufficient /usr/lib/security/pam_unix.so.1
other   password required /usr/lib/security/pam_ldap.so.1

It is important to note that the control flag for pam_unix  is sufficient. This flag means that if authentication through pam_unix  succeeds, then pam_ldap  is not invoked. Also, other service types, such as dtlogin, su, telnet, and so forth can substitute for login.  See FIGURE 4.

FIGURE 4 pam_ldap  Structure

The options supported by the pam_ldap  are:

How PAM and LDAP Work

Before discussing the details of how PAM and LDAP work, it is important to provide a quick overview to understand and distinguish between how the password is stored and how the authentication mechanism is used to authenticate to the LDAP server. The password can be stored in a variety of formats in the Sun ONE Directory Server, such as, salted secure hash algorithm (SSHA) secure hash algorithm (SHA), CRYPT, and so forth.

The authentication mechanisms currently used and supported in the Solaris 8 OE LDAP Client, are NONE, SIMPLE, and CRAM-MD5 authentication. SIMPLE authentication requires the client to pass a distinguished name (DN) and password to the server in clear text. Currently, the Sun ONE Directory Server 5.x does not support the authentication mechanism CRAM-MD5, which sends only the digest over the wire. CRAM-MD5 is implemented as a simple authentication and security layer (SASL) mechanism and both the client and server must use it. What happens is the client request authentication is based on SASL/CRAM-MD5 and the server must support this to complete the authentication. In general, very few clients use CRAM-MD5, now that RFC 2831 mandates the use of Digest-MD5, which is intended to be an improvement over CRAM-MD5. With the introduction of the Solaris 8 OE and the LDAP Client, a usable security model is not provided.

With the introduction of the Sun ONE Directory Server 5.x; SASL External and Digest-MD5 are now supported for authentication. With Digest-MD5, a digest is created and sent across the wire to authenticate to the directory server. The directory server then compares the digest that was sent with the digest created by itself with the stored password and returns success if it matches. In this case, the password is not sent in clear text. To address the absence of a security model in the Solaris 8 OE LDAP Client, the Solaris 9 OE now incorporates the Sun ONE Directory Server 5.1 and Solaris 9 OE Secured LDAP Client, addressing the security issues found in the LDAP Client.

There are two LDAP Client libraries available. Currently, the Solaris 8 OE LDAP Client library version provides no support for Secure Socket Layer/Transport Layer Security 1.0 (SSL/TLS 1.0). To address this, a new LDAP library (libldap  (v5)) for the Solaris 9 OE has been developed and it supports both SSL and TLSv1.

NOTE

In the current release of the Solaris 9 OE, the extended startTLS operation is not supported.

The LDAP Client library continues to provide support for the simple page control and the SASL CRAM-MD5 authentication mechanism.

Authentication With pam_unix 

In authentication with pam_unix, the client retrieves the password that is stored in the server by making a call to the getspnam  function. This function binds to the LDAP server with the proxy agent account (the reason the proxy passwd  is sent across the wire in clear text). The proxy agent password is stored in the userPassword  attribute in the directory server. This proxy agent account can reside anywhere in the directory server, but must contain the userPassword  attribute.

Note that the access control instructions (ACIs) of the proxy agent allow this account to have read access to all user passwords. ACIs are instructions that are stored in the directory server itself. Every entry can have a set of rules that define an ACI for that entry. An ACI appears as an attribute in the entry so it can be retrieved by using LDAP search, or it can be added, updated, or deleted with an LDAP modify operation.

An entry may have one ACI, many ACIs, or none. ACIs allow or deny permissions to entries. When the directory server processes an incoming request for that entry, the server uses the ACIs specific to that entry to determine whether or not the LDAP client has permission to perform the requested operation.

NOTE

LDAP stores data as entries. An entry has a distinguished name (DN) to uniquely identify it within the directory server

The encrypted password is sent to the client side and compared with the crypted password supplied by the user at the password prompt. If there is a match, pam_unix  returns success. The following tables illustrate the authentication mechanisms currently used.

TABLE 3 lists the PAM abbreviations used in this section.

TABLE 3 PAM Abbreviations

Abbreviation Description
UP User password
PP Proxy agent password
NP New password
NO* Not applicable (at present)

 

TABLE 4 illustrates if the user password and proxy password are transmitted in the clear during PAM authentications.

TABLE 4 PAM Authentication

Authentication Mechanisms pam_unix pam_ldap
SIMPLE UP-No PP-Yes UP-Yes PP-Yes
DIGEST-MD5 UP-NO* PP-No UP-No PP-No
TLS: SIMPLE UP-No PP-No UP-No PP-No
TLS: DIGEST-MD5 UP-No PP-No UP-No PP-No

 

NOTE

In Tables 4 and 5 the reason for "NO*" as the value of the Digest-MD5 UP column is because the Sun ONE Directory Server version 5.1 requires the passwords be stored in the server in clear text for Digest-MD5 to work.

For updating passwords in pam_unix, the same comparison as for authentication takes place (since the user has to bind as the dn); then, the new password is encrypted and not passed over the wire in clear text (see TABLE 5).

TABLE 5 PAM Update of Password

Authentication Mechanisms pam_unix pam_ldap
SIMPLE UP-No PP-Yes NP-No UP-Yes PP-Yes NP-Yes
Digest-MD5 UP-NO* PP-No NP-NO* UP-No PP-No NP-Yes
TLS: SIMPLE UP-No PP-No NP-No UP-No PP-No NP-No
TLS: Digest-MD5 UP-No PP-No NP-No UP-No PP-No NP-No

 

The matrices are easier to understand when you distinguish between how the password is stored and how the authentication mechanism is used to authenticate to the LDAP server. The password can be stored in a variety of formats, such as SSHA, SHA, crypt, clear text, and so forth. The authentication mechanisms that are currently supported are NONE, SIMPLE, SASL/CRAM-MD5, SASL/Digest-MD5, TLS:NONE, TLS:SIMPLE, TLS:SASL/CRAM-MD5, and TLS:SASL/Digest-MD5.

pam_ldap  Authentication

In authentication that uses pam_ldap, the user password is passed to the server in an auth  structure in clear text, since authentication is being attempted with the user dn  and password. If SIMPLE authentication is used and the password matches, then success  is returned. Using pam_ldap  in the Solaris 9 Secure LDAP client now provides SASL/Digest-MD5 authentication, privacy, and data integrity with SSL/TLS. If you require stronger authentication mechanisms such as Digest-MD5; then you must use pam_ldap. In addition, pam_ldap  is designed to be extended for future authentication mechanisms that will be supported in future Solaris OE releases. One of the benefits of using pam_ldap, is it does not require passwords to be stored in any specific format, so you can store passwords using SSHA, SHA, or CRYPT formats.

For additional information, see the pam_ldap  man page for the correct way to stack the authentication management for login service, and password management modules in the /etc/pam.conf  configuration file.

NOTE

CRAM-MD5 is supported by the Secure LDAP client, but not by the Sun ONE Directory Server. However, Digest-MD5 is supported by both.

The author would like to recognize the following individuals for their contributions to this article:

The SunDocsSM program provides more than 250 manuals from Sun Microsystems, Inc. If you live in the United States, Canada, Europe, or Japan, you can purchase documentation sets or individual manuals through this program.

The docs.sun.com web site enables you to access Sun technical documentation online. You can browse the docs.sun.com archive or search for a specific book title or subject. The URL is http://docs.sun.com/.

To reference Sun BluePrints OnLine articles, visit the Sun BluePrints OnLine Web site at: http://www.sun.com/blueprints/online.html.

 

NEWS CONTENTS

Old News ;-)

PAM in Open Solaris

RBAC - Role Based Access Control at OpenSolaris.org

OpenSolaris UserGroup RBAC presentation

RBAC Best Practices for OpenSolaris developers

The following best practice documents for using RBAC in developing other parts of OpenSolaris can be found in the ARC community:

Why use

PAM were created by Sun and first appeared as a public interface in Solaris 2.6. Previous versions of a very similar framework were in Solaris 2.4 and Solaris 2.5.1. Until Solaris 9 there was only one module, pam_unix.so, that implemented the default UNIX username/password policy. In Solaris 9 we broke up that module in to a number of smaller parts: pam_unix_auth.so, pam_unix_cred.so, pam_authtok_get.so, pam_authtok_check.so, pam_authtok_store.so, pam_dhkeys.so and pam_passwd_auth.so.

Sample Modules


In the files section there are a few sample modules and programs that I (Darren Moffat) have had lying around in my home directory at Sun since I first started playing with PAM before Solaris 2.6 was released.

I originally called this su_cookie.so, and it was one of my earliest PAM modules. I'm not proud of the way it is coded and it is an ugly hack since it uses the xauth(1) program to do its work. However I've always found it very useful, no more xhost + for me :-) I know that some Linux based distros ship with something like this but I'm pretty confident I was the first to implement it and someone else idependently came up with the idea.

This is a simple demo application that calls the PAM APIs that an application would call. I use it as a very simple test application, not really useful for anything else.

This is a PAM implementation of the check that /bin/login has hardcoded for root on the system console.

Basically this is a local file that contains usernames and/or netgroups that should either be allowed or denied access to a given service. The idea for this module came from observing the performance hit that the nsswitch passwd_compat +/- syntax can have on some systems. What most people used that for was invalidating the users shell and/or password so they couldn't login, but still allow the admin to get uid->name translations of the files the users owned on the server. This module has appeared in SunSolve articles in the past. I wrote this version of it in 1999.

 

Re Confounded by PAM and OpenSSH on Solaris 10



Hi,

If anyone can help me understand OpenSSH and PAM and the various
 

 
Which version of OpenSSH? The PAM behaviour has changed
(improved, I hope :-) over time. An overview is in the faq
(http://www.openssh.com/faq.html#3.15) but the details vary with the
version.
 

I apologize. I wanted to provide you with all of the information as
well as write a post that made sense so I edited out the version
information. I am running "OpenSSH_4.3p2, OpenSSL 0.9.8a 11 Oct 2005".

 
user2 is unable to login and instead of calling pam_sm_chauthtok()
OpenSSH calls passwd().
 

 
That happens when you use password authentication and privilege separation
together. When you use password authentication, sshd doesn't have the
ability to interact with the user until very late in the login process
(ie after the pty is allocated) and when privsep is in use, has long
since given up the privilege it would need to call pam_chauthtok (and
have it work, anyway).
 

 
Either use ChallengeResponseAuthentication (preferred) or disable
UsePrivilegeSeparation.
 

I apologize again. I assumed priv sep was disabled by default. I shut
it off and set "ChallengeResponseAuthentication no" and
"PasswordAuthentication yes" and everything seems to work as intended.

 
user1 gets the 'account has expired' message but it does not close the
connection until three attempts are made!
 

 
I think that this no longer happens in 4.3p2.
 

Well I am going to paste some more stuff. Since you say that
ChallengeResponseAuthentication is preferred here are the issues i am
having with it enabled. Here is my configuration:

### START /usr/local/etc/sshd_config ###
[Mon May 01|14:04:59][root@unknown:/]
$ cat /usr/local/etc/sshd_config | grep -v '^#'
Port 2022
Protocol 2
PasswordAuthentication no
ChallengeResponseAuthentication yes
UsePAM yes
UsePrivilegeSeparation no
Subsystem sftp /usr/local/libexec/sftp-server
[Mon May 01|14:05:38][root@unknown:/]
### END /usr/local/etc/sshd_config ###

user1 reports expired and returns PAM_ACCT_EXPIRED. I am not kicked
out.
Here are the dumps!

### START server command ###
$ /usr/local/sbin/sshd -ddd -D > /tmp/sshdebug.txt 2>&1
[Mon May 01|14:15:38][root@unknown:/]
$
### END server command ###

### START client view ###
[Mon May 01|14:05:38][root@unknown:/]
$ ssh -p 2022 -l user1 localhost
Password:
User account has expired!

Password:
User account has expired!

Password:
User account has expired!

Permission denied (publickey,keyboard-interactive).
[Mon May 01|14:15:38][root@unknown:/]
### END client view ###

### START sshd debug ###
$ cat /tmp/sshdebug.txt
debug2: load_server_config: filename /usr/local/etc/sshd_config
debug2: load_server_config: done config len = 265
debug2: parse_server_config: config /usr/local/etc/sshd_config len 265
debug1: sshd version OpenSSH_4.3p2
debug3: Not a RSA1 key file /usr/local/etc/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug3: Not a RSA1 key file /usr/local/etc/ssh_host_dsa_key.
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/local/sbin/sshd'
debug1: rexec_argv[1]='-ddd'
debug1: rexec_argv[2]='-D'
debug2: fd 3 setting O_NONBLOCK
debug1: Bind to port 2022 on ::.
Server listening on :: port 2022.
debug2: fd 4 setting O_NONBLOCK
debug1: Bind to port 2022 on 0.0.0.0.
Server listening on 0.0.0.0 port 2022.
debug1: fd 5 clearing O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 10 config len 265
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 10
debug1: inetd sockets after dupping: 3, 3
Connection from 127.0.0.1 port 32861
debug1: Client protocol version 2.0; client software version
Sun_SSH_1.1
debug1: no match: Sun_SSH_1.1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug2: fd 3 setting O_NONBLOCK
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@xxxxxxxxxxxxxx,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@xxxxxxxxxxxxxx,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@xxxxxxxxxxx,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit:
hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@xxxxxxxxxxx,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@xxxxxxxxxxx
debug2: kex_parse_kexinit: none,zlib@xxxxxxxxxxx
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit:
aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: i-default
debug2: kex_parse_kexinit: i-default
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug2: dh_gen_key: priv key bits set: 137/256
debug2: bits set: 1022/2048
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug2: bits set: 1022/2048
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user user1 service ssh-connection method
none
debug1: attempt 0 failures 0
debug2: input_userauth_request: setting up authctxt for user1
debug1: PAM: initializing for "user1"
debug3: PAM STARTS FROM HERE
debug3: Trying to reverse map address 127.0.0.1.
debug1: PAM: setting PAM_RHOST to "localhost"
debug1: PAM: setting PAM_TTY to "ssh"
debug2: input_userauth_request: try method none
debug3: DOOPIE!#!#!
Failed none for user1 from 127.0.0.1 port 32861 ssh2
debug1: userauth-request for user user1 service ssh-connection method
keyboard-interactive
debug1: attempt 1 failures 1
debug2: input_userauth_request: try method keyboard-interactive
debug1: keyboard-interactive devs
debug1: auth2_challenge: user=user1 devs=
debug1: kbdint_alloc: devices 'pam'
debug2: auth2_challenge_start: devices pam
debug2: kbdint_next_device: devices <empty>
debug1: auth2_challenge_start: trying authentication method 'pam'
debug3: PAM: sshpam_init_ctx entering
debug3: sshpam_thread called!!!!!!!!
debug3: PAM: sshpam_thread_conv entering, 1 messages
debug3: ssh_msg_send: type 1
debug3: ssh_msg_recv entering
debug3: PAM: sshpam_query entering
debug3: ssh_msg_recv entering
debug3: DOOPIE!#!#!
Postponed keyboard-interactive for user1 from 127.0.0.1 port 32861 ssh2
debug2: PAM: sshpam_respond entering, 1 responses
debug3: ssh_msg_send: type 6
debug3: POOPIE!@!@!
debug1: do_pam_account: called
debug3: PAM: sshpam_thread_conv entering, 1 messages
debug3: ssh_msg_send: type 3
debug3: PAM: do_pam_account pam_acct_mgmt = 17 (User account has
expired)
debug3: ssh_msg_send: type 9
debug3: PAM: sshpam_query entering
debug3: ssh_msg_recv entering
debug3: ssh_msg_recv entering
debug3: PAM: PAM_AUTH_ERR
debug3: DOOPIE!#!#!
Postponed keyboard-interactive/pam for user1 from 127.0.0.1 port 32861
ssh2
debug2: PAM: sshpam_respond entering, 0 responses
debug2: auth2_challenge_start: devices <empty>
debug3: PAM: sshpam_free_ctx entering
debug3: PAM: sshpam_thread_cleanup entering
debug3: DOOPIE!#!#!
Failed keyboard-interactive/pam for user1 from 127.0.0.1 port 32861
ssh2
debug1: userauth-request for user user1 service ssh-connection method
keyboard-interactive
debug1: attempt 2 failures 2
debug2: input_userauth_request: try method keyboard-interactive
debug1: keyboard-interactive devs
debug1: auth2_challenge: user=user1 devs=
debug1: kbdint_alloc: devices 'pam'
debug2: auth2_challenge_start: devices pam
debug2: kbdint_next_device: devices <empty>
debug1: auth2_challenge_start: trying authentication method 'pam'
debug3: PAM: sshpam_init_ctx entering
debug3: sshpam_thread called!!!!!!!!
debug3: PAM: sshpam_thread_conv entering, 1 messages
debug3: ssh_msg_send: type 1
debug3: ssh_msg_recv entering
debug3: PAM: sshpam_query entering
debug3: ssh_msg_recv entering
debug3: DOOPIE!#!#!
Postponed keyboard-interactive for user1 from 127.0.0.1 port 32861 ssh2
debug2: PAM: sshpam_respond entering, 1 responses
debug3: ssh_msg_send: type 6
debug3: PAM: sshpam_query entering
debug3: ssh_msg_recv entering
debug3: POOPIE!@!@!
debug1: do_pam_account: called
debug3: PAM: sshpam_thread_conv entering, 1 messages
debug3: ssh_msg_send: type 3
debug3: ssh_msg_recv entering
debug3: PAM: do_pam_account pam_acct_mgmt = 17 (User account has
expired)
debug3: ssh_msg_send: type 9
debug3: PAM: PAM_AUTH_ERR
debug3: DOOPIE!#!#!
Postponed keyboard-interactive/pam for user1 from 127.0.0.1 port 32861
ssh2
debug2: PAM: sshpam_respond entering, 0 responses
debug2: auth2_challenge_start: devices <empty>
debug3: PAM: sshpam_free_ctx entering
debug3: PAM: sshpam_thread_cleanup entering
debug3: DOOPIE!#!#!
Failed keyboard-interactive/pam for user1 from 127.0.0.1 port 32861
ssh2
debug1: userauth-request for user user1 service ssh-connection method
keyboard-interactive
debug1: attempt 3 failures 3
debug2: input_userauth_request: try method keyboard-interactive
debug1: keyboard-interactive devs
debug1: auth2_challenge: user=user1 devs=
debug1: kbdint_alloc: devices 'pam'
debug2: auth2_challenge_start: devices pam
debug2: kbdint_next_device: devices <empty>
debug1: auth2_challenge_start: trying authentication method 'pam'
debug3: PAM: sshpam_init_ctx entering
debug3: sshpam_thread called!!!!!!!!
debug3: PAM: sshpam_query entering
debug3: ssh_msg_recv entering
debug3: PAM: sshpam_thread_conv entering, 1 messages
debug3: ssh_msg_send: type 1
debug3: ssh_msg_recv entering
debug3: DOOPIE!#!#!
Postponed keyboard-interactive for user1 from 127.0.0.1 port 32861 ssh2
debug2: PAM: sshpam_respond entering, 1 responses
debug3: ssh_msg_send: type 6
debug3: PAM: sshpam_query entering
debug3: ssh_msg_recv entering
debug3: POOPIE!@!@!
debug1: do_pam_account: called
debug3: PAM: sshpam_thread_conv entering, 1 messages
debug3: ssh_msg_send: type 3
debug3: PAM: do_pam_account pam_acct_mgmt = 17 (User account has
expired)
debug3: ssh_msg_send: type 9
debug3: ssh_msg_recv entering
debug3: PAM: PAM_AUTH_ERR
debug3: DOOPIE!#!#!
Postponed keyboard-interactive/pam for user1 from 127.0.0.1 port 32861
ssh2
debug2: PAM: sshpam_respond entering, 0 responses
debug2: auth2_challenge_start: devices <empty>
debug3: PAM: sshpam_free_ctx entering
debug3: PAM: sshpam_thread_cleanup entering
debug3: DOOPIE!#!#!
Failed keyboard-interactive/pam for user1 from 127.0.0.1 port 32861
ssh2
Connection closed by 127.0.0.1
debug1: do_cleanup
debug1: PAM: cleanup
debug3: PAM: sshpam_thread_cleanup entering
[Mon May 01|14:18:11][root@unknown:/]
$
### END sshd debug ###

If you look at the sshd debug you will see that my pam module returns
"debug3: PAM: do_pam_account pam_acct_mgmt = 17 (User account has
expired)" however the user is prompted again for a password. I looked
at the code and found that do_pam_account() is called from
sshpam_thread(void *ctxtp). There seems to be no code that kicks the
user out after a bad attempt it just goes through the attempts cycle. I
assume sshd checks the thread's return code this is how it knows
whether or not the authentication was successful so it should be able
to kick the user out.

### START code snippet ###
if (compat20) {
if (!do_pam_account())
goto auth_fail;
if (sshpam_authctxt->force_pwchange) {
sshpam_err = pam_chauthtok(sshpam_handle,
PAM_CHANGE_EXPIRED_AUTHTOK);
if (sshpam_err != PAM_SUCCESS)
goto auth_fail;
sshpam_password_change_required(0);
}
}
auth_fail:
buffer_put_cstring(&buffer,
pam_strerror(sshpam_handle, sshpam_err));
/* XXX - can't do much about an error here */
ssh_msg_send(ctxt->pam_csock, PAM_AUTH_ERR, &buffer);
buffer_free(&buffer);
pthread_exit(NULL);

return (NULL); /* Avoid warning for non-pthread case */
}
### END code snippet ###

If you look at auth2.c in userauth_finish() the code checks for
errors...

### START code snippet ###
#ifdef USE_PAM
debug3( "DOOPIE!#!#!" );
if (options.use_pam && authenticated) {
if (!PRIVSEP(do_pam_account())) {
/* if PAM returned a message, send it to the user */
if (buffer_len(&loginmsg) > 0) {
buffer_append(&loginmsg, "\0", 1);
userauth_send_banner(buffer_ptr(&loginmsg));
packet_write_wait();
}
fatal("Access denied for user %s by PAM account "
"configuration", authctxt->user);
}
}
#endif
### END code snippet ###

Here there is a fatal statement saying that access is denied, which I
assume kicks you
out.


 
SSHD CONFIGURATION #3
Protocol 2
PasswordAuthentication no
ChallengeResponseAuthentication yes
UsePAM yes

user1 now prompts 4 times three times for keyboard-interactive and once
for password.
########################################################
[Fri Apr 28|19:24:50][root@unknown:/]
$ ssh -l user1 localhost
Password:
User account has expired!

Password:
User account has expired!

Password:
User account has expired!

user1@localhost's password:
User account has expired!
 

Are you sure about this one? If PasswordAuthentication is set to no, it
won't even be offered to the client.
 

I wonder if "UsePrivilegeSeparation yes" had anything to do with it?

Elroy

.

 

Solaris SSH - Kerberos 5 Hints

How do you make the Solaris Secure Shell (aka the SSH client that is shipped with Solaris 9) work with Kerberos 5 authentication?
With the release of Solaris 9, Sun has finally started to ship a mostly reasonable SSH client (known by Sun as the Solaris Secure Shell) and server. The server is in /usr/lib/ssh/sshd directory. The sshd daemon included in Solaris 9 will use the PAM (Pluggable Authentication Module) framework that comes with Solaris 9 to do authentication, in addition to the internal public key framework that SSH is capable of using for authentication.

The PAM configuration on Solaris 9 doesn't have any specific configuration for the sshd daemon. Activating the Kerberos 5 configuration lines at the end of the /etc/pam.conf file will not make sshd work with Kerberos 5. This is contrary to the comments in that file about what must be done to make Kerberos 5 authentication work for all the services on the system.

If the following authentication bits are added to the the /etc/pam.conf file, the sshd daemon will just start using Kerberos authentication, and will fall-back to any local password on the machine, if the KDC is unavailable, or the password given doesn't match that stored in the KDC.

#
# sshd authentication order
#
sshd    auth sufficient         pam_krb5.so.1 try_first_pass
sshd    auth required           pam_unix_auth.so.1

No changes are necessary to the /etc/ssh/sshd_config file to make sshd with Kerberos. Of course, the /etc/krb5/krb5.conf file will need to be setup properly, but that's a task outlined in another NSFAQ.

Thanks to Chris Ross for helping to rationalize and debug the configuration.

Back to the page of Not So Frequently Asked Questions.

SUMMARY OpenSSH and Solaris PAM

alexei at soemail.rutgers.edu alexei at soemail.rutgers.edu
Tue Sep 30 10:26:25 EDT 2003

Dear sun managers,

Thanks a lot to those of you who replied to my posting.
The suggestions and ideas were very good.

The winning solution came from Fergus Donohue, who pointed me at
the bug report at http://bugzilla.mindrot.org/show_bug.cgi?id=700

The advice about setting "PasswordAuthentication no" and 
"ChallengeResponseAuthentication yes" in sshd_config made it to work
with PAM and my LDAP users can login now.
 
However, for LDAP to work properly, I had to modify my pam.conf slightly, 
but it is minor change:
sshd   auth requisite          pam_authtok_get.so.1
sshd   auth required           pam_dhkeys.so.1
sshd   auth sufficient         pam_unix_auth.so.1
sshd   auth required           pam_ldap.so.1 try_first_pass
sshd   account required        pam_unix_account.so.1

Regards,
Alexei

pam winbind solaris 10



I have no problem getting pam and winbindd (samba) to play well, though
Solaris 10 has been a real challenge (still is) I am reading the docs
http://docs.sun.com/app/docs/doc/816-4557/6maosrjj0?a=view#pam-36 and
see they have really re-worked pam since Solaris 9.

I am attempting to run winbindd as an auth module but get conflicting
results; it appears the module just is not working, pam, in it's new
implementation does not accept it.

Here is a snip from the system during a ssh login:
Jan 19 10:27:00 testhost2 pam_winbind[17861]: [ID 467601 auth.error]
request failed: No such user, PAM error was 13, NT error was
NT_STATUS_NO_SUCH_USER

So something is happening at the pam_winbind layer.

And the winbindd log:
[2006/01/19 13:46:06, 6] nsswitch/winbindd.c:new_connection(638)
accepted socket 17
[2006/01/19 13:46:06, 3]
nsswitch/winbindd_misc.c:winbindd_interface_version(454)
[ 0]: request interface version
[2006/01/19 13:46:06, 3]
nsswitch/winbindd_misc.c:winbindd_priv_pipe_dir(487)
[ 0]: request location of privileged pipe
[2006/01/19 13:46:06, 6] nsswitch/winbindd.c:new_connection(638)
accepted socket 18
[2006/01/19 13:46:06, 3]
nsswitch/winbindd_user.c:winbindd_getpwnam(336)
[ 0]: getpwnam TESTDOM+testuser
[2006/01/19 13:46:12, 3]
nsswitch/winbindd_user.c:winbindd_getpwnam(336)
[ 0]: getpwnam TESTDOM+testuser
[2006/01/19 13:46:12, 3]
nsswitch/winbindd_user.c:winbindd_getpwnam(336)
[ 0]: getpwnam TESTDOM+testuser
[2006/01/19 13:46:12, 3]
nsswitch/winbindd_user.c:winbindd_getpwnam(336)
[ 0]: getpwnam TESTDOM+testuser

Anyone have some ideas?

I have included a copy of my pam.conf for Solaris 10 as well as a copy
from my 'working' Solaris 9.

========BEGIN pam.conf Solaris 9 ==================
#
#ident "@(#)pam.conf 1.20 02/01/23 SMI"
#
# Copyright 1996-2002 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
#
# PAM configuration
#
# Unless explicitly defined, all services use the modules # defined in
the "other" section.
#
# Modules are defined with relative pathnames, i.e., they are #
relative to /usr/lib/security/$ISA. Absolute path names, as # present
in this file in previous releases are still acceptable.
#
# Authentication management
#
# login service (explicit because of pam_dial_auth) #
login auth requisite pam_authtok_get.so.1
login auth sufficient pam_dhkeys.so.1
login auth sufficient pam_unix_auth.so.1
login auth sufficient pam_dial_auth.so.1
login auth sufficient /usr/lib/security/pam_winbind.so.1
try_first_pass
#
# rlogin service (explicit because of pam_rhost_auth) #
rlogin auth requisite pam_authtok_get.so.1
rlogin auth sufficient pam_dhkeys.so.1
rlogin auth sufficient pam_unix_auth.so.1
rlogin auth sufficient /usr/lib/security/pam_winbind.so.1
try_first_pass
#
# rsh service (explicit because of pam_rhost_auth, # and pam_unix_auth
for meaningful
rsh auth required pam_unix_auth.so.1
#
# PPP service (explicit because of pam_dial_auth) #
ppp auth requisite pam_authtok_get.so.1
ppp auth required pam_dhkeys.so.1
ppp auth required pam_unix_auth.so.1
ppp auth required pam_dial_auth.so.1
#
# Default definitions for Authentication management # Used when service
name is not #explicitly mentioned for authenctication #
other auth requisite pam_authtok_get.so.1
other auth sufficient pam_dhkeys.so.1
other auth sufficient pam_unix_auth.so.1
other auth sufficient /usr/lib/security/pam_winbind.so.1
try_first_pass
#
# passwd command (explicit because of a different authentication
module) #
passwd auth required pam_passwd_auth.so.1
#
# cron service (explicit because of non-usage of pam_roles.so.1) #
cron account required pam_projects.so.1
cron account required pam_unix_account.so.1
#
# Default definition for Account management # Used when service name is
not explicitly mentioned for account management #
other account requisite pam_roles.so.1
other account sufficient pam_projects.so.1
other account sufficient pam_unix_account.so.1
#
# Default definition for Session management # Used when service name is
not explicitly mentioned for session management #
other session required pam_unix_session.so.1
other session sufficient /usr/lib/security/pam_winbind.so.1
#
# Default definition for Password management # Used when service name
is not explicitly mentioned for password management #
other password required pam_dhkeys.so.1
other password requisite pam_authtok_get.so.1
other password requisite pam_authtok_check.so.1
other password required pam_authtok_store.so.1
#
# Support for Kerberos V5 authentication (uncomment to use Kerberos) #
#rlogin auth optional pam_krb5.so.1 try_first_pass
#login auth optional pam_krb5.so.1 try_first_pass
#other auth optional pam_krb5.so.1 try_first_pass
#cron account optional pam_krb5.so.1
#other account optional pam_krb5.so.1
#other session optional pam_krb5.so.1
#other password optional pam_krb5.so.1 try_first_pass
#========END pam.conf Solaris 9 ==================

#========BEGIN pam.conf Solaris 10 ==================
#
#ident "@(#)pam.conf 1.28 04/04/21 SMI"
#
# Copyright 2004 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
#
# PAM configuration
#
# Unless explicitly defined, all services use the modules
# defined in the "other" section.
#
# Modules are defined with relative pathnames, i.e., they are
# relative to /usr/lib/security/$ISA. Absolute path names, as
# present in this file in previous releases are still acceptable.
#
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
login auth requisite pam_authtok_get.so.1
#---- Begin Winbind -----#
#---- Notes: Pass, OK, stacked authtok_get first
login auth binding pam_winbind.so.1 try_first_pass
#---- End Winbind -------#
login auth required pam_dhkeys.so.1
login auth required pam_unix_cred.so.1
login auth required pam_unix_auth.so.1
login auth required pam_dial_auth.so.1
#
# rlogin service (explicit because of pam_rhost_auth)
#
rlogin auth sufficient pam_rhosts_auth.so.1
rlogin auth requisite pam_authtok_get.so.1
#---- Begin Winbind -----#
#---- Notes: OK
rlogin auth required pam_winbind.so.1 try_first_pass
#---- End Winbind -------#
rlogin auth required pam_dhkeys.so.1
rlogin auth required pam_unix_cred.so.1
rlogin auth required pam_unix_auth.so.1
#
# Kerberized rlogin service
#
krlogin auth required pam_unix_cred.so.1
krlogin auth binding pam_krb5.so.1
krlogin auth required pam_unix_auth.so.1
#
# rsh service (explicit because of pam_rhost_auth,
# and pam_unix_auth for meaningful pam_setcred)
#
rsh auth sufficient pam_rhosts_auth.so.1
rsh auth required pam_unix_cred.so.1
#
# Kerberized rsh service
#
krsh auth required pam_unix_cred.so.1
krsh auth binding pam_krb5.so.1
krsh auth required pam_unix_auth.so.1
#
# Kerberized telnet service
#
ktelnet auth required pam_unix_cred.so.1
ktelnet auth binding pam_krb5.so.1
ktelnet auth required pam_unix_auth.so.1
#
# PPP service (explicit because of pam_dial_auth)
#
ppp auth requisite pam_authtok_get.so.1
ppp auth required pam_dhkeys.so.1
ppp auth required pam_unix_cred.so.1
ppp auth required pam_unix_auth.so.1
ppp auth required pam_dial_auth.so.1
#
# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
#
other auth requisite pam_authtok_get.so.1
#---- Begin Winbind -----#
#---- Notes: Pass, OK, but asks for password twice and passes on the
scecond # try without the "try_first_pass"
other auth binding pam_winbind.so.1 try_first_pass debug
#---- End Winbind -------#
other auth required pam_dhkeys.so.1
other auth required pam_unix_cred.so.1
other auth required pam_unix_auth.so.1
other auth required pam_krb5.so.1 use_first_pass
#
# passwd command (explicit because of a different authentication
module)
#
#---- Begin Winbind -----#
#---- Notes: no problem for files users.
passwd auth required pam_winbind.so.1
#---- End Winbind -------#
passwd auth required pam_passwd_auth.so.1
#
# cron service (explicit because of non-usage of pam_roles.so.1)
#
cron account required pam_unix_account.so.1
#
# Default definition for Account management
# Used when service name is not explicitly mentioned for account
management
#
other account requisite pam_roles.so.1
other account required pam_unix_account.so.1
#---- Begin Winbind -----#
#---- Notes: Pass, OK
other account sufficient pam_winbind.so.1
#---- End Winbind -------#
#
# Default definition for Session management
# Used when service name is not explicitly mentioned for session
management
#
#---- Begin Winbind -----#
#---- Notes: Causes
other session required pam_winbind.so.1 try_first_pass
#---- End Winbind -------#
other session required pam_unix_session.so.1
#
# Default definition for Password management
# Used when service name is not explicitly mentioned for password
management
#
other password required pam_dhkeys.so.1
other password requisite pam_authtok_get.so.1
other password requisite pam_authtok_check.so.1
other password required pam_authtok_store.so.1
#---- Begin Winbind -----#
#---- Notes:
other password sufficient pam_winbind.so.1 try_first_pass
#---- End Winbind -----#
#
# Support for Kerberos V5 authentication and example configurations can
# be found in the pam_krb5(5) man page under the "EXAMPLES" section.
#
#========END pam.conf Solaris 10 ==================
thanks

My email is thomas not tom.

Solaris 9 Operating Environment - Features and Benefits Security

The PAM framework has been changed to consist of more modular, smaller shared object files. The PAM API has not been changed. Isolation from naming services is greater. Specifically, the framework has been enhanced to allow customers to concentrate on developing their own solution without needing to manipulate many of the naming service and authentication details.

Re solaris pam vs. padl.org pam for ldap

Our first goal was to install the operating systems and then install openldap to fiddle around and understand how it works. Installing the Solaris OS proved to be quite a challenge in itself as none of us had prior experience working with it. Thus we decided to do a parallel installation and configuration on the Linux platform as well. Much of the documentation on the Internet was done on the Linux platform, thus we can get a comparison between the Solaris and Linux installation and configurations.

On the Linux platform, I used the default RedHat 7.3 distribution with all packages added and then patched them with the up2date program provided by RedHat.The package versions for the main components are as follows:

openssl096-0.9.6-6
db3-3.3.11-6
cyrus-sasl-1.5.24-25
krb5-libs-1.2.4-1
krb5-server-1.2.4-1
openldap12-1.2.13-3

 

 

Recommended Links

Softpanorama Top Visited

Softpanorama Recommended

Sun blueprints

PAM information and experiences some Solaris information

UW-ID-AUTH Solaris PAM Authentication

The UWdir Identification and Authentication service can be used to provide authentication services to PAM aware applications on the Solaris/Unix platform. This note describes how to obtain and configure an xhier package which will allow Solaris systems to authenticate against the Uwaterloo.ca NT4 Domain. A basic configuration allows all PAM aware applications to use the UW/ID-AUTH service; site specific configurations are possible.




Etc

Society

Groupthink : Understanding Micromanagers and Control Freaks : Toxic Managers : BureaucraciesHarvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Two Party System as Polyarchy : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

Skeptical Finance : John Kenneth Galbraith : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Oscar Wilde : Talleyrand : Somerset Maugham : War and Peace : Marcus Aurelius : Eric Hoffer : Kurt Vonnegut : Otto Von Bismarck : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Oscar Wilde : Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 26, No.1 (January, 2013) Object-Oriented Cult : Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks: The efficient markets hypothesis : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

 

The Last but not Least


Copyright © 1996-2014 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Site uses AdSense so you need to be aware of Google privacy policy. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine. This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting hosting of this site with different providers to distribute and speed up access. Currently there are two functional mirrors: softpanorama.info (the fastest) and softpanorama.net.

Disclaimer:

The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: July 18, 2014