# OpenLDAP: ldap working, but login via PAM not

## adamtheo

Hello, Adam Theo here.

I have been messing with OpenLDAP for weeks now. Seemingly I get it working out of the blue one day, then the next it's back to not working anymore. I'm getting quite sick of OpenLDAP, since it seems there are a gazillion places where a misconfiguration could happen, causing the entire thing to bork, and making it impossible to isolate problems. What's more, the documentation on half the stuff in the configuration files and debug output sucks. But I know that's not the fault of anyone here, just ranting.

Ok, sorry for this crazy long post, but I'm going to post *all* of my LDAP-related config files and debug output, just to make sure the sourse of the problem can be located.

And here's the situation: I can start slapd fine, no errors. I can start it as '/etc/init.d/slapd start' or '/usr/lib/openldap/slapd' with debuging and other flags activated. I see slapd is running as user and group 'ldap' no matter which way I start it.

I can successfully run 'getent' to see the users and groups I have created in LDAP. I have removed all user (but no system, including root) accounts from '/etc/passwd' and '/etc/group' files. So the LDAP directory is obviously working as far as that goes.

When logged in as 'root' (this is not using LDAP since root is a system account) I can 'su' into one of the users in the LDAP directory that I have gived posixAccount and posixGroup access. I have played around as this 'su'ed user, and it works as per the user, as it should (ownership of created files, etc). When I start the slapd in debug mode, I can see lots of activity when I 'su' and 'ls -l'.

I cannot log in remotely as one of the regular users in the directory, even though I can 'su' into them if logged in as root. For example, when I 'ssh' from my desktop over the Internet, I get prompted for my password then denied. Here the last few lines from the server in debug running with the flag '-d 255':

 *Quote:*   

> 
> 
> ====> cache_return_entry_r( 9 ): returned (0)
> 
> send_ldap_search_result 0::
> ...

 

When I run 'ldapsearch -D "cn=root,dc=theoretic,dc=com" -W -d 255' when logged into the computer as root, I get the following output from the client:

 *Quote:*   

> 
> 
> ldap_create
> 
> Enter LDAP Password: 
> ...

 

It is not giving the same result as before during one of those rare times it "just worked" (it was listing all users and groups in the directory before), but it seems to be connecting to the directory fine, just not fetching the info for some reason. I have of course *'ed the password out in the above debug, since it was displaying it in the clear.

Also, when I run the similar command of 'ldapsearch -h new.theoretic.com -D "cn=root,dc=theoretic,dc=com" -W -d 255' from a remote computer on the Internet (my desktop), I get almost identical debug output in the client terminal window (I say almost simply because I skimmed and did not see any notable differences, there very well might be, but I didn't see any).

And again much the same output when I run those commands trying to bind to one of the regular users in the LDAP directory instead of the root account.

Here are my configurations:

The file '/etc/conf.d/slapd' is completely commented out since that's how it came, and the above linked guide leaves it that way, although I've seen some other configurations specify things in it (specifically the new LDAP HOWTO at http://www.gentoo.org/doc/en/ldap-howto.xml which I've also tried with no luck).

The file '/etc/openldap/ldap.conf' is also completely commented out for the same reason as above. Also, is it just me, or does this file seem to serve the same purpose as the below file of '/etc/ldap.conf', merely stripped down? Could I theoretically remove this stripped-down file or replace it with the below file and still get the same functionality? If so, then I might file this as a bug here at gentoo so as to get one of them removed or turned into a link to avoid redundancy and confusion.

The file '/etc/ldap.conf' now. I have included only the uncommented lines from the entire file, so as to not flood. Note that I have tried different variations that I've seen in other guides, such as using 'scope one' and 'pam_password md5' and 'pam_filter objectclass=posixAccount', but they don't make a difference. I have also specified the 'nss_base_***' attributes, since I remembered I had to enable them in one of my previous attempts to get the system working, but that doesn't change the situation anymore.

 *Quote:*   

> 
> 
> host new.theoretic.com
> 
> base dc=theoretic,dc=com
> ...

 

And here is my '/etc/openldap/slapd.conf' file:

 *Quote:*   

> 
> 
> include         /etc/openldap/schema/core.schema
> 
> include         /etc/openldap/schema/cosine.schema
> ...

 

And the files '/etc/nsswitch.conf' and '/etc/pam.d/system-auth' are exactly as per the guide at https://forums.gentoo.org/viewtopic.php?t=72607

I am at a loss. Just let me know what other information you need to debug this, and I'll provide it (short of any root passwords of course  :Smile: . But if it would help if you could authenticate against a regular user account that has posixAccount and posixGroup permissions, try this one:

```

server: new.theoretic.com

user: tester

pass: testing

base: dc=theoretic,dc=com

```

----------

## adamtheo

Just to let everyone know, authentication with Apache through LDAP works. I can go to a restricted page, enter my username and password from LDAP, and it authenticates properly. So it really does seem that the problem is with the PAM part.

Any ideas? Thanks.

----------

## hbp4c

Hi Adam,

I am having similar problems with user auth via ldap lookups.

What I have found that seems most odd to me is if I do a "getent shadow" all the accounts' passwords are "x" locked out.

I would expect this behavior when I do getent passwd:

 *Quote:*   

> 
> 
> geminga root # getent passwd
> 
> root:x:0:0:root:/root:/bin/bash
> ...

 

Which as you can see works.  But, getent shadow shows a very similar output!:

 *Quote:*   

> 
> 
> geminga root # getent shadow
> 
> root:$1$wX4wwe7y$.oNVKH0ZiWMC:12227:0:::::
> ...

 

Now, root above (password has been truncated) is a local account as defined in /etc/passwd and /etc/shadow.  The other daemon accounts like mail, games, etc are also local accounts.  On the hbp4c account is an ldap account in my examples- and it seems locked out!  I have set the password in directory_administrator as well as via passwd (which correctly updates the ldap database according to the debug output) but getent does not reflect this change.  I am able to login as root then su into hbp4c no problem, but I cannot directly login as hbp4c from say, ssh.

So... am I a total noob and chasing the wrong problem?

Thanks,

Howard

----------

## hbp4c

Ah,  I managed to answer my own question.

What I have found in my case is that the ldap lookups for login, and all serviced except ssh are correctly being queried on the server and allowing logins.  It seems that for some reason ssh is the only thing not working correctly.

I have checked my /etc/pam.d/sshd which is still the default version, and it seems that accouting information is handled by the /etc/pam.d/system-auth file instead of itself.  The system-auth seems to work correctly since i am able to log into a console, or into gdm.

So - if anyone can explain to me or give me a hint as to what I can do to get sshd working with pam and ldap then I would love to try them.

Good luck Adam,

h

----------

## jwalcik

i had this very problem myself early last week.  add a line to your sshd_config that says:

UsePAM=yes

then restart sshd.  that was pointed out by someone on this board, and cleared the problem right up for me.

----------

## hbp4c

Thanks, but I tried that and had no more luck with it.  I checked on my server and as I try to login to the client via ssh, i see that it is in fact querying the ldap database for the userid and password.  But for some reason it says that my password is incorrect.

I am starting to wonder if it is a problem with the stored passwords, maybe sshd expects the password to be in {crypt} format vs {md5}.  At this point, I am not even sure what I have it set up to use...

It was a good thought though.

H

----------

## hbp4c

Ok, I seem to have finally flushed out the problem (I believe that it was a bad version of securecrt installed on the pc next to it).  It looks like the /etc/ssh/sshd_config option "UsePam yes" fixed my problem after all.

Thanks very much for your help, jwalcik

H

----------

## Chris W

Adam,

If you can query the directory server then it seems unlikely that it is at fault.

If you suspect that it is a PAM issue then you'll need to post the /etc/pam.d files (system-auth, sshd, su, and login at least) and nsswitch.conf.  Chances are that the problem lies here.

----------

## adamtheo

Hello, I decided to go with a clean slate, uninstalling and removing all LDAP and PAM/NSS files that had been installed. I re-installed and configured soley based on the LDAP-HOWTO at http://www.gentoo.org/doc/en/ldap-howto.xml I have eneded up with a perfectly working LDAP system. I can run the 'ldapsearch' query and get back a list of all entities in the directory, as expected. However, ssh login is still not working, and now 'getent' is not working, either.

I have tried the 'UsePAM yes' option as well just now. It alone did not change the situation, so here are my PAM and SSH-related config files:

/etc/pam.d/system-auth

```

auth       required     /lib/security/pam_env.so

auth       sufficient   /lib/security/pam_unix.so likeauth nullok nodelay

auth       sufficient   /lib/security/pam_ldap.so use_first_pass

auth       required     /lib/security/pam_deny.so

account    required     /lib/security/pam_unix.so

account    sufficient   /lib/security/pam_ldap.so

password   required     /lib/security/pam_cracklib.so retry=3

password   sufficient   /lib/security/pam_unix.so nullok md5 shadow use_authtok

password   sufficient   /lib/security/pam_ldap.so use_authtok

password   required     /lib/security/pam_deny.so

session    required     /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0

session    required     /lib/security/pam_limits.so

session    required     /lib/security/pam_unix.so

session    optional     /lib/security/pam_ldap.so

```

/etc/pam.d/sshd

```

auth       required     pam_stack.so service=system-auth

auth       required     pam_shells.so

auth       required     pam_nologin.so

account    required     pam_stack.so service=system-auth

password   required     pam_stack.so service=system-auth

session    required     pam_stack.so service=system-auth

```

/etc/pam.d/login

```

auth       required     /lib/security/pam_securetty.so

auth       required     /lib/security/pam_stack.so service=system-auth

auth       required     /lib/security/pam_nologin.so

account    required     /lib/security/pam_stack.so service=system-auth

password   required     /lib/security/pam_stack.so service=system-auth

session    required     /lib/security/pam_stack.so service=system-auth

session    optional     /lib/security/pam_console.so

```

/etc/pam.d/su

```

auth       sufficient   /lib/security/pam_rootok.so

auth       required     /lib/security/pam_wheel.so use_uid

auth       required     /lib/security/pam_stack.so service=system-auth

account    required     /lib/security/pam_stack.so service=system-auth

password   required     /lib/security/pam_stack.so service=system-auth

session    required     /lib/security/pam_stack.so service=system-auth

session    optional     /lib/security/pam_xauth.so

```

/etc/pam.d/system-auth-1.1

```

auth       required     /lib/security/pam_env.so

auth       sufficient   /lib/security/pam_unix.so likeauth nullok

auth       required     /lib/security/pam_deny.so

account    required     /lib/security/pam_unix.so

password   required     /lib/security/pam_cracklib.so retry=3

password   sufficient   /lib/security/pam_unix.so nullok md5 shadow use_authtok

password   required     /lib/security/pam_deny.so

session    required     /lib/security/pam_limits.so

session    required     /lib/security/pam_unix.so

```

/etc/ssh/sshd_config

```

UsePAM yes

Subsystem       sftp    /usr/lib/misc/sftp-server

```

/etc/nsswitch.conf

```

passwd:         files ldap

group:          files ldap

```

----------

## Chris W

If your getent command is failing then there's a problem outside of PAM. Have you customised /etc/ldap.conf to point at your directory server and search base DN (base)?  When you run getent does anything register in the OpenLDAP log entries?

----------

## adamtheo

there is no activity with the LDAP directory when I run 'getent'. I did not have the 'host' or 'base' set since the LDAP-HOWTO explicitly said to comment those out and use 'suffix' and 'uri'. I have uncommented 'base' and 'host' and set them to 'dc=theoretic,dc=com' and 'new.theoretic.com', respectively. I have restarted the slapd in debug mode of 255, and still see no activity. My config files are exactly as per the LDAP-DOWTO at http://www.gentoo.org/doc/en/ldap-howto.xml

----------

## adamtheo

OK, I've messed around a little more, and I understand openldap, nss_ldap, and pam_ldap a little better now. I've got a better grasp of what the various config files and their contents are for. But I'm still running up against the same problems.

I have a working LDAP directory, because I can ldapsearch it, binding as the rootdn, and I get back the expected results. However, I am not able to get ldap data from 'getent', nor can I authenticate against it using PAM/NSS (over ssh, I don't have tty access). I have the slapd running in debug mode of -1, and I see absolutely no activity when I run a getent or try to log in over ssh.

I'm thinking now that it's an nsswitch.conf problem? At least since the user listing requests never make it to ldap, and nsswitch controls where queries go, it is stopping at looking in the local /etc/passwd and /etc/group files and not going onto ldap? Thanks.

My ldap directory is organized to have two ou's: Users (for actual user accounts), and Groups (for user account groups).

Here are my config files:

/etc/openldap/slapd.conf

```

include         /etc/openldap/schema/core.schema

include         /etc/openldap/schema/cosine.schema

include         /etc/openldap/schema/nis.schema

include         /etc/openldap/schema/inetorgperson.schema

pidfile         /var/run/openldap/slapd.pid

argsfile        /var/run/openldap/slapd.args

access to dn=".*,dc=theoretic,dc=com" attr=userPassword

        by dn="cn=root,dc=theoretic,dc=com" write

        by self write

        by * auth

access to dn=".*,dc=theoretic,dc=com"

        by users read

defaultaccess none

TLSCertificateFile /site/theoretic/ssl/key.pem

TLSCertificateKeyFile /site/theoretic/ssl/key.pem

TLSCACertificateFile /site/theoretic/ssl/key.pem

TLSCipherSuite HIGH:+MEDIUM:!LOW

TLSVerifyClient never

database        ldbm

suffix          "dc=theoretic,dc=com"

rootdn          "cn=root,dc=theoretic,dc=com"

rootpw          {SSHA}**************

directory       /site/theoretic/ldap

index           objectClass,uid,uidNumber,gidNumber   eq

index           cn,surname,givenname                  eq,subinitial

```

/etc/openldap/ldap.conf

```

BASE    dc=theoretic, dc=com

URI     ldaps://new.theoretic.com:636/

```

/etc/conf.d/slapd

```

OPTS="-h 'ldaps:// ldapi://%2fvar%2frun%2fopenldap%2fslapd.sock'"

```

/etc/ldap.conf

```

host new.theoretic.com

base dc=theoretic,dc=com

ldap_version 3

port 636

scope one

pam_filter objectclass=posixAccount

pam_login_attribute uid

pam_member_attribute gid

pam_password SSHA

nss_base_passwd         ou=Users,dc=theoretic,dc=com?one

nss_base_shadow         ou=Users,dc=theoretic,dc=com?one

nss_base_group          ou=Groups,dc=theoretic,dc=com?one

ssl start_tls

ssl on

```

/etc/nsswitch.conf

```

passwd:         files ldap

shadow:         files ldap

group:          files ldap

```

/etc/pam.d/system-auth

```

auth       sufficient   /lib/security/pam_ldap.so use_first_pass

auth       required     /lib/security/pam_env.so

auth       sufficient   /lib/security/pam_unix.so likeauth nullok nodelay

auth       required     /lib/security/pam_deny.so

account    sufficient   /lib/security/pam_ldap.so

account    required     /lib/security/pam_unix.so

password   sufficient   /lib/security/pam_ldap.so use_authtok

password   required     /lib/security/pam_cracklib.so retry=3

password   sufficient   /lib/security/pam_unix.so nullok md5 shadow use_authtok

password   required     /lib/security/pam_deny.so

session    optional     /lib/security/pam_ldap.so

session    required     /lib/security/pam_mkhomedir.so skel=/etc/skel/ umask=0

session    required     /lib/security/pam_limits.so

session    required     /lib/security/pam_unix.so

```

Any help would be appreciated. Thank you for your time.

----------

## hbp4c

adamtheo,

/etc/ssh/sshd_config:

```

# Set this to 'yes' to enable PAM authentication (via challenge-response)

# and session processing. Depending on your PAM configuration, this may

# bypass the setting of 'PasswordAuthentication'

UsePAM yes

```

Check to make sure this line is uncommented and set to yes.  

Also, I have found that some ssh clients (like vandyke's securecrt) will only work with pam/ldap if you set the client to use "Keyboard Interactive" as its authentication type.  "Password" type just keeps giving me failed password errors in my syslog.  Openssh and even the commercial ssh clients do not have this problem though.  (If anyone has thoughts as to why "password" authentication fails, Id love to hear it).

Hope some of this helps.

H

----------

## adamtheo

Did the above change to /etc/ssh/sshd_config (UsePAM yes), and restarted OpenLDAP and SSHD, but still no results. I still see no activity with OpenLDAP when I run getent. But ldapsearch still produces the correct result, so the problem doesn't lie in OpenLDAP, it seems.

----------

## redog

been a long day I just thought I would add to the confusion...

I had a working pam nss ldap system that stopped working all of a sudden. 

Taking ldap out of nsswitch.conf fixed most of my problems which were not limited to gettys being instakilled, local & remote logins not working, slapd not starting all kind of freaky "stuff just locks up" problems.

Once I could start the system and its services adding ldap back to nsswitch.conf returned the system to its "working" state.

----------

