Home / server / Questions / 536066
In Process
NinjaCat
Asked: 2013-09-04 14:44:34 +0800 CST

PAM: auth: pam_unix(dovecot:auth): authentication failure;

  • 772

We have opnldap setup on our ubuntu server, and were getting this message for a user:

 auth: pam_unix(dovecot:account): account has expired (account expired)
Sep  3 19:05:03  auth: pam_unix(dovecot:auth): authentication failure; logname= uid=0 euid=0 tty=dovecot ruser=XXXX rhost=::1  user=XXXX

I changed the password with ldappasswd successfully, but still the error persists. Doing some research it seems that shadowLastChange is not getting updated.

How can we resolve this?

/usr/share/slapd/slapd.conf

access to attrs=userPassword,shadowLastChange
        by dn="@ADMIN@" write
        by anonymous auth
        by self write
        by * none
access to dn.base="" by * read

# The admin dn has full write access, everyone else
# can read everything.
access to *
        by dn="@ADMIN@" write
        by * read

OK - this seems to be a PAM issue.

If I edit /etc/nsswitch.conf to :

shadow: compat

I don't get the message that the account is expired.

If I change it to:

shadow: files ldap

I do. But in either case, I still get the dovecot error.

ldap

2 Answers

  1. 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.

    • 1

  2. Never really answered my own question before, but I wanted to share in case anyone else ever comes across this. It had to do with saslauthd not installed, configured, and running. Once I did that, error went away.

    • 0