Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

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

I'm trying to set up an Ubuntu 12.04 server so that users with a valid account in a remote ldap server can login to the ubuntu server.

I've followed this guide closely:

When I try to ssh into that machine, this is what I see in /var/log/auth.log BEFORE entering my password:

Connection from port 36624
Invalid user bentrupk from
input_userauth_request: invalid user bentrupk [preauth]

However, using a packet sniffer, I'm also seeing a successful query to the ldap server using my username that returns my DN in ldap.

Then I enter my password but the packet sniffer shows an ldap bind request with the right DN but with a password of "....INCORRECT".

Obviously, that's not the password what I entered.

I'm assuming it's a problem with 1 or more of my pam.d config files.

I'm wondering if there is a hint from the "Invalid user" in the auth.log? There is clearly a request being made to the ldap server with the username provided by ssh before I enter my password that successfully returns the correct entry.

However, it's unclear to me which happens first: "Invalid user" in the auth.log OR the ldap search seen in the packet sniffer (and just to be clear the ssh user does not have a local account).

What can I do to debug this further or confirm that I have the right configuration?

share|improve this question

I was making an incorrect assumption about what the PAM modules did. I assumed that having an account in LDAP could actually cause a module to create the user on the system (an assumption probably influenced by my webdev background) much like it could also create the home directories (pam_mkhomedir).

Once I created the users locally using:

sudo adduser doej --disabled-password

I was able to login with the doej account in LDAP.

Incidentally, I found a solution using pam_exec that would allow me to dynamically create the users, too.

share|improve this answer
You dont need local acocunts to auth over ldap. That would kind of defat the purpose of central auth. What ldap server are you running? – tomodachi Mar 27 '13 at 23:00
Are you sure?? On the ubuntu machine that I wanted to ssh into, the moment that I created a local account (but with a disabled password) I was then able to authenticate against the remote ldap. As configured, ubuntu would not create a user or allow access to the local machine. Also central auth still has utility even with local accounts. As LDAP is updated, users will still be allowed or denied based on LDAP, not the local system. They can not log on without LDAP. Also see: – Keith Bentrup Mar 29 '13 at 15:46
I'm certain. I have set up ldap auth for ubuntu / debian / mac /freebsd – tomodachi Apr 4 '13 at 12:53
@tomodachi, do you have a suggestion to confirm this? Why if I remove the user system account (but not ldap) does the ldap login stop working? What's wrong with my configuraion? What would further testing could I do? – Keith Bentrup Apr 18 '13 at 11:30
I had this problem until I restarted nscd. – Penz Oct 2 '14 at 21:11

There is no need for local accounts to exist for ldap accounts to be able to log in.

Perhaps when it fails to find the proper user in ldap it falls back to the locally created user accounts.

The invalid user error hints that lookup in your ldap server is not returning the user account you try to authenticate with.

Enable debugging in your ldap server: create a ldiff file with theese lines

dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: stats

and import the ldif file to your ldap server with:

ldapadd -x -W -D 'cn=Manager,dc=pvpsc,dc=com' -f increaseverbosity.ldiff

this will log ldap queries made to your ldap on the the syslog of your server. use the ldapsearch tool to search your ldap server and read out the username of a user. compare the successful log with the one created by the failed auth.

what differs? This is probably where you will find the fault.

share|improve this answer

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.