If you have not changed the pam.conf(4) file, pam_unix functionality is enabled by default.
The pam_unix module has been removed and is no longer supported with Solaris. A set of other service modules provides equivalent or greater functionality. Therefore, in this guide, pam_unix refers to the equivalent functionality, not to the pam_unix module itself.
Following is a list of the modules that provide the equivalent pam_unix functionality.
pam_unix follows the traditional model of UNIX authentication, as described in the following list.
The client retrieves the user's encrypted password from the name service.
The user is prompted for the user's password.
The user's password is encrypted.
The client compares the two encrypted passwords to determine whether the user should be authenticated.
Additionally, there are two restrictions when using pam_unix.
The password must be stored in UNIX crypt format and not in any other encryption methods, including clear.
The userPassword attribute must be readable by the name service.
For example, if you set the credential level to anonymous, then anyone must be able to read the userPassword attribute. Similarly, if you set the credential level to proxy, then the proxy user must be able to read the userPassword attribute.
pam_unix is not compatible with the sasl authentication method digest-MD5, since Sun Java System Directory Server requires passwords to be stored in the clear in order to use digest-MD5. pam_unix requires the password be stored in crypt format.
Starting in the Solaris 10 10/09 release, pam_unix supports account management when the enableShadowUpdate switch is set to true. The controls for a remote LDAP user account are applied just as the controls are applied to a local user account that is defined in the passwd and shadow files. In enableShadowUpdate mode, for the LDAP account, the system updates and uses the shadow data on the LDAP server for password aging and account locking. Of course, the shadow data of the local account only applies to the local client system, whereas the shadow data of an LDAP user account applies to the user on all client systems.
Password history checking is only supported for the local client, not for an LDAP user account.