|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
| News | Authentication and Accounts Security | 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 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.
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.
This section details the following components that make up PAM:
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
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:
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
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
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.
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.
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.
| 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.
| 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 |
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.
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:
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
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.
NOTE
If you have a 64-bit version of the module, you should place that version in /usr/lib/security/sparcv9.
It is essential to do some testing before logging out, in case the configuration file is misconfigured.
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.
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.
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.
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
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).
# touch /var/adm/authlog
# pkill -HUP syslogd
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.
# 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.
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.
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.
| 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.
| 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).
| 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.
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.
 |
 |
 |
RBAC - Role Based Access Control at OpenSolaris.org
OpenSolaris UserGroup RBAC presentationRBAC 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:
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.
|
|
|
- From: "elroy.deng@xxxxxxxxx" <elroy.deng@xxxxxxxxx>
- Date: 1 May 2006 19:52:05 -0700
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 yesuser1 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
.
|
|
|
- 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/sshddirectory. 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.conffile 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.conffile, 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.1No changes are necessary to the
/etc/ssh/sshd_configfile to make sshd with Kerberos. Of course, the/etc/krb5/krb5.conffile 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.
|
|
|
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
|
|
|
- From: tom@xxxxxxxxxxxxxxxx
- Date: 19 Jan 2006 11:13:55 -0800
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_USERSo 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+testuserAnyone 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 ==================
thanksMy email is thomas not tom.
|
|
|
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.
|
|
|
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
Google matched content |
Part one, Extending Authentication in the Solaris 9 Operating Environment Using Pluggable Authentication Modules (PAM): Part I, was published in the September 2002 issue of Sun BluePrints Online.
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.
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : 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.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 DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting 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-Month : How 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 Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
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 to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: March 12, 2019
