LDAP clients use the PAM modules for user authentication during login. When using the standard UNIX PAM module, the password is read from the server and checked on the client side. This process can fail due to one of the following reasons:
ldap is not associated with the passwd database in the name service switch.
The user's userPassword attribute on the server list is not readable by the proxy agent. You need to allow at least the proxy agent to read the password because the proxy agent returns it to the client for comparison. pam_ldap does not require read access to the password.
The proxy agent might not have the correct password.
The entry does not have the shadowAccount object class.
No password is defined for the user.
When you use ldapaddent, you must use the –p option to ensure that the password is added to the user entry. If you use ldapaddent without the –p option, the user's password is not stored in the directory unless you also add the /etc/shadow file by using ldapaddent.
No LDAP servers are reachable.
Check the status of the servers.
# /usr/lib/ldap/ldap_cachemgr -g
pam.conf is configured incorrectly.
The user is not defined in the LDAP namespace.
NS_LDAP_CREDENTIAL_LEVEL is set to anonymous for the pam_unix_* modules, and userPassword is not available to anonymous users.
The password is not stored in crypt format.
If pam_ldap is configured to support account management, a login failure could be the result of one of the following causes:
The user's password has expired.
The user's account is locked out due to too many failed login attempts.
The user's account has been deactivated by the administrator.
The user tried to log in using a non-password based program, such as ssh or sftp.
If per-user authentication and sasl/GSSAPI are being used, then some component of Kerberos or the pam_krb5 configuration is setup incorrectly. Refer to the Managing Kerberos and Other Authentication Services in Oracle Solaris 11.2 for details on resolving these issues.