Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Problem Overview

Solaris 11 has been configured to use pam_ldap to authenticate users against an LDAP v3-compliant directory server. The Solaris host is only configured to use LDAP for authentication; it is not configured to use LDAP as a naming service.

When a valid user attempts to ssh to the Solaris host, the pam_ldap module submits a BIND request to the LDAP server and gets a response of success. However, Solaris still denies the user access.

Problem to solve: How can I complete my PAM configuration to allow users to authenticate to the Solaris host via ssh by using their LDAP identities?

The user is a valid user that exists both on the host (in the /etc/passwd and /etc/shadow files,) and on LDAP. The account is not locked on LDAP, and the user can properly authentication (BIND) to LDAP:

$ldapsearch -h <REMOVED> -p 389 -b ou=people,o=som,dc=com -D "uid=testuser,ou=people,o=som,dc=com" -W uid=testuser LDAP Password:

dn: uid=testuser,ou=People,o=som,dc=com
uid: testuser
cn: Test User
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
shadowInactive: 7
loginShell: /bin/bash
uidNumber: 1176
homeDirectory: /home/testuser
gecos: Test User
gidnumber: 501
shadowmax: 91
shadowmin: 7
shadowwarning: 28
userpassword:: <REMOVED>
shadowflag: 22352
shadowlastchange: 16115

Debugging Information

From the LDAP Server, you can see the user successfully authenticated:

Search--bindDN: cn=proxyAgent,ou=Profile,o=som,dc=com--client: <REMOVED>:59874--connectionID: 88496--received: 2014-02-17-10:53:02.324-5:00--Success
    base: ou=people,o=som,dc=com
    scope: singleLevel
    derefAliases: derefAlways
    typesOnly: false
    filter: (&(objectclass=SOLARISUSERATTR)(uid=testuser))
    attributes: uid, SolarisUserQualifier, SolarisAttrReserved1, SolarisAttrReserved2, SolarisAttrKeyValue
    numberOfEntriesReturned: 0
    AuditV3--2014-02-17-10:53:02.332-5:00--V3 Bind--bindDN: cn=proxyAgent,ou=Profile,o=som,dc=com--client: <REMOVED>:22262--connectionID: 103359--received:     2014-02-17-10:53:02.332-5:00--Success
    name: cn=proxyAgent,ou=Profile,o=som,dc=com
    authenticationChoice: simple

Search--bindDN: cn=proxyAgent,ou=Profile,o=som,dc=com--client: <REMOVED>:22262--connectionID: 103359--received: 2014-02-17-10:53:02.333-5:00--Success
    base: ou=people,o=som,dc=com
    scope: singleLevel
    derefAliases: derefAlways
    typesOnly: false
    filter: (&(objectclass=POSIXACCOUNT)(uid=testuser))
    numberOfEntriesReturned: 1

**Bind--bindDN: uid=testuser,ou=People,o=som,dc=com--client: <REMOVED>:12241--connectionID: 103360--received: 2014-02-17-10:53:02.335-5:00--Success
    name: uid=testuser,ou=People,o=som,dc=com
    authenticationChoice: simple**

Search--bindDN: cn=proxyAgent,ou=Profile,o=som,dc=com--client: <REMOVED>:59874--connectionID: 88496--received: 2014-02-17-10:53:02.985-5:00--Success
    base: ou=people,o=som,dc=com
    scope: singleLevel
    derefAliases: derefAlways
    typesOnly: false
    filter: (&(objectclass=POSIXACCOUNT)(uidnumber=10011))
    attributes: cn, uid, uidNumber, gidNumber, gecos, description, homeDirectory, loginShell
    numberOfEntriesReturned: 1

Logging on the Solaris host client shows that the PAM LDAP module submitted the user's credentials. Yet, while the LDAP server returned a success on the BIND operation, Solaris reports authentication failed. Note the use of sshd-kbdinit:

 [] reprocess config line 160: ignoring RhostsRSAAuthentication option value. SSHv1     protocol is no longer supported in the server, please remove the option.
 [] reprocess config line 167: ignoring RSAAuthentication option value. SSHv1 protocol is no longer supported in the server, please remove the option.
 [auth.notice] Failed none for test user from <REMOVED> port 54650 ssh2
 [auth.debug] ldap pam_sm_authenticate(sshd-kbdint testuser), flags = 1 
 [] Keyboard-interactive (PAM) userauth failed[9] while authenticating: Authentication failed
 [auth.notice] Failed keyboard-interactive for test user from <REMOVED> port 54650 ssh2
 [] Connection closed by <REMOVED>

Configuration Details

Solaris Host Client


Protocol 2
Port 22
ListenAddress ::
AllowTcpForwarding no
GatewayPorts no
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
MaxStartups 30:60:120
Banner /etc/issue
PrintMotd no
KeepAlive yes
ClientAliveInterval 120
ClientAliveCountMax 60
SyslogFacility auth
LogLevel info
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
ServerKeyBits 768
KeyRegenerationInterval 3600
StrictModes yes
LoginGraceTime 600
MaxAuthTries    3
MaxAuthTriesLog 0
PermitEmptyPasswords no
PasswordAuthentication yes
PAMAuthenticationViaKBDInt yes
PermitRootLogin yes
Subsystem       sftp    /usr/lib/ssh/sftp-server
IgnoreRhosts yes
RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes
KbdInteractiveAuthentication yes

ldapclient utilizes an ldapclient profile from the server.

$ldapclient list

NS_LDAP_BINDDN= cn=proxyAgent,ou=Profile,o=som,dc=com
NS_LDAP_AUTH= simple
NS_LDAP_SERVICE_SEARCH_DESC= passwd:ou=people,o=som,dc=com
NS_LDAP_SERVICE_SEARCH_DESC= shadow:ou=people,o=som,dc=com
NS_LDAP_SERVICE_SEARCH_DESC= group:ou=group,o=som,dc=com?sub
NS_LDAP_ATTRIBUTEMAP= group:gidnumber=gidNumber
NS_LDAP_ATTRIBUTEMAP= passwd:gidnumber=gidNumber
NS_LDAP_ATTRIBUTEMAP= passwd:uidnumber=uidNumber
NS_LDAP_ATTRIBUTEMAP= passwd:homedirectory=homeDirectory
NS_LDAP_ATTRIBUTEMAP= passwd:loginshell=loginShell
NS_LDAP_ATTRIBUTEMAP= shadow:userpassword=userPassword
NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=posixAccount
NS_LDAP_OBJECTCLASSMAP= passwd:posixAccount=posixaccount
NS_LDAP_OBJECTCLASSMAP= group:posixGroup=posixgroup

pam.conf and pam.d/service

/etc/pam.conf (Only the relevant parts are shown)

login   auth requisite
login   auth required 
login   auth required 
login   auth binding   server_policy
login   auth required  debug
login   auth required 

other   auth requisite
other   auth required 
other   auth required 
other   auth binding   server_policy
other   auth required  debug

/etc/pam.d/login (Only the relevant parts are shown)

auth requisite
auth required 
auth required 
auth binding   server_policy
auth required  debug
auth required 

/etc/pam.d/other (Only the relevant parts are shown)

auth requisite
auth required 
auth required 
auth binding   server_policy
auth required  debug

nsswitch.conf (nsswitch.conf was modified by using svccfg, resulting in the following nsswitch.conf file)

passwd: files ldap
group:  files ldap
hosts:  files [SUCCESS=return] dns
ipnodes:        files [SUCCESS=return] dns
networks:       files
protocols:      files
rpc:    files
ethers: files
netmasks:       files
bootparams:     files
publickey:      files
netgroup:       files
automount:      files
aliases:        files
services:       files
printers:       user files
project:        files
auth_attr:      files
prof_attr:      files
tnrhtp: files
tnrhdb: files
sudoers:        files

LDAP Server

This host acts as a client to a Tivoli Directory Server v 6.3 (ITDS). Assume all proper schema modifications have been made. (I've added all necessary RFC2307bis, NIS and Solaris schema elements to ITDS.)

share|improve this question
up vote 0 down vote accepted

As it turns out, the issue is with the 'binding' control_type keyword used in the /etc/pam.conf and **/etc/pam.d/ *files.

By replacing all instances of 'binding' with 'sufficient' for the lines in the files, authentication now works. As an example:

login   auth binding   server_policy
login   auth required  debug

should become

login   auth sufficient server_policy
login   auth required  debug

Be sure to do this wherever you want to use LDAP authentication.

share|improve this answer
thank you very much, your advice about "sufficient" keyword really works, some hours ago, following this ...... "did the trick", after several days of test, NOW we have LDAP authentication in solaris box to IBM Security Directory server 6.3.1 remains to refine some details. but the principal authentication function is working ... =) XD – user278111 Mar 25 '15 at 2:23

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.