Debian – pam_unix(sshd:auth): authentication failure

Authentication failure is logged with err=49 - Invalid Credential at default loglevel 256 - (0x100 stats) stats log connections/operations/results:

$ grep 'err=49' -B1 /path/to/ldap.log
slapd[28269]: conn=83767 op=2 BIND dn="cn=x,ou=y,dc=z,dc=t" method=128
slapd[28269]: conn=83767 op=2 RESULT tag=97 err=49 text= 

I do hate to revive a dead question but given that this is the top search result for "dovecot pam authentication failure ldap", let me add this bit of extra knowledge:

The only thing that I've seen in my testing that updates the shadowAccount attributes is the passwd command when you're modifying the password for a user in LDAP... Most other tools don't care much about the shadowAccount class and it's attributes, and won't touch them. However, I only find that shadowAccount classes need to be added to users if they're going to be logging into the host, since that does care. If you're just doing something like email authentication (Dovecot), then it's not much use. I could be wrong here, but I've yet to see anything other than a host login consult the shadowAccount attributes for anything.

Now, if you're having Dovecot authenticate through PAM (which, I assume you probably are, since Dovecot is querying it and you're changing nsswitch), then please bear in mind that while, yes, PAM will pay attention to those extra attributes, you still need the correct tooling to change them... meaning whatever is changing user passwords also needs to go through PAM. Unpopular opinion as it may be, if you're not requiring host logins, just services like Dovecot or others, there's no need to get PAM involved since it's going to be checking a lot more things that are likely going to be irrelevant. (At best it could enforce other things like, yes, password expirations, but personally I would not enforce things like that when the service you login to has no provision to change a password like that) It's likely easier in the long run to have non-host/shell login services check LDAP themselves, allowing for other things like search filters specific to that service.

However assuming you've set up Dovecot to check LDAP itself, and not rely on PAM, at the end of Dovecot's 10-auth.conf are a list of !include lines for different auth mechanisms, like LDAP, SQL, etc. By default, the file auth-system.conf.ext is included before other mechanisms, like LDAP. What this means is that, since, in my testing, Dovecot checks these in the order they're provided, Dovecot will first attempt to authenticate the user with PAM, and then, if that fails, authenticate with LDAP. Ergo, you'll get a PAM error stating, yes, the authentication failure (as well as the first one indicating what failure it is). If you changed this ordering so the method most likely to succeed (LDAP, one would assume) is queried first, then there would be no need to check with PAM, and, therefore, no error thrown by PAM.

To solve this you could comment out the !include auth-system.conf.ext, but this could potentically cause system users (like root or postmaster) to be considered non-existent if you don't have them set up in LDAP.

My personal solution to this one was to cut that line out and paste it at the bottom, like this:

#!include auth-deny.conf.ext
#!include auth-master.conf.ext

!include auth-ldap.conf.ext

#!include auth-sql.conf.ext
#!include auth-passwdfile.conf.ext
#!include auth-checkpassword.conf.ext
#!include auth-vpopmail.conf.ext
#!include auth-static.conf.ext

!include auth-system.conf.ext

This means that Dovecot will first consult LDAP, then consult PAM if LDAP gave no results, as far as my testing has shown.