Cannot change password on ldap client, need to have 'try_authtok' in the pam config or libpam-cracklib installed

Bug #329067 reported by stephen mulcahy
156
This bug affects 24 people
Affects Status Importance Assigned to Milestone
libpam-ldap (Debian)
Fix Released
Unknown
libpam-ldap (Ubuntu)
Triaged
Undecided
Unassigned

Bug Description

Binary package hint: libpam-ldap

I have a working LDAP client config using libnss-ldapd and libpam-ldap.

I can login to the system using any valid LDAP user.

However, when I attempt to change the password using 'passwd', the following occurs

stemul@dev:~$ passwd
Enter login(LDAP) password:
passwd: password updated successfully
stemul@dev:~$

The command returns without ever giving me the chance to change the password (although it does require the correct password to even get this far).

Some Googling suggested removing use_authtok from vi /etc/pam.d/common-password changing the line

password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass

to

password [success=1 user_unknown=ignore default=die] pam_ldap.so try_first_pass

After doing this, I can now change my password using passwd.

It looks like use_authtok only makes sense in common-password if you have installed libpam-cracklib or similar - is that correct?

Thanks

Revision history for this message
Michael Kofler (michael-kofler) wrote :

I can confirm this bug/problem.

Revision history for this message
Steve Langasek (vorlon) wrote :

Hello,

Can you please post the full content of your /etc/pam.d/common-password on the affected system?

Steve Langasek (vorlon)
Changed in libpam-ldap:
status: New → Incomplete
Revision history for this message
Michael Kofler (michael-kofler) wrote :

Ubuntu 8.10, used pam-auth-update to configure /etc/pam.d/common-*, enabled unix, ldap, consolekit (no kerberos, no cracklib)

resulting common-password:

#
# /etc/pam.d/common-password - password-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define the services to be
# used to change user passwords. The default is pam_unix.

# Explanation of pam_unix options:
#
# The "sha512" option enables salted SHA512 passwords. Without this option,
# the default is Unix crypt. Prior releases used the option "md5".
#
# The "obscure" option replaces the old `OBSCURE_CHECKS_ENAB' option in
# login.defs.
#
# See the pam_unix manpage for other options.

# As of pam 1.0.1-5, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
password [success=2 default=ignore] pam_unix.so obscure sha512
password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass
# here's the fallback if no module succeeds
password requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password required pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config

Revision history for this message
stephen mulcahy (stephen-mulcahy) wrote :

This is my /etc/pam.d/common-password after recently running another "aptitude upgrade", restoring the problematic line to /etc/pam.d/common-password

In this format, if I login as an LDAP user and type passwd, I get the following interaction

stemul@apps:~$ passwd
Enter login(LDAP) password:
passwd: password updated successfully

If I now change the line below

password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass

to

password [success=1 user_unknown=ignore default=die] pam_ldap.so try_first_pass

and then try changing my password again ...

stemul@apps:~$ passwd
Enter login(LDAP) password:
New password:
Re-enter new password:
LDAP password information changed for stemul
passwd: password updated successfully
stemul@apps:~$

#
# /etc/pam.d/common-password - password-related modules common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of modules that define the services to be
# used to change user passwords. The default is pam_unix.

# Explanation of pam_unix options:
#
# The "sha512" option enables salted SHA512 passwords. Without this option,
# the default is Unix crypt. Prior releases used the option "md5".
#
# The "obscure" option replaces the old `OBSCURE_CHECKS_ENAB' option in
# login.defs.
#
# See the pam_unix manpage for other options.

# As of pam 1.0.1-5, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
password [success=2 default=ignore] pam_unix.so obscure sha512
password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass
# here's the fallback if no module succeeds
password requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password required pam_permit.so
# and here are more per-package modules (the "Additional" block)
# end of pam-auth-update config

Changed in libpam-ldap:
status: Incomplete → Confirmed
Revision history for this message
Robert McQueen (robot101) wrote :

I'd like to confirm this bug too with libpam-ldap 184-4.2ubuntu2 on Jaunty. I had the following configuration generated by pam-auth-update:

password [success=2 default=ignore] pam_unix.so obscure sha512
password [success=1 user_unknown=ignore
                  default=die] pam_ldap.so use_authtok try_first_pass
password requisite pam_deny.so
password required pam_permit.so

I believe that pam_unix doesn't recognise the account as it's stored in ldap - it has no shadow entry, so doesn't prompt for an authtok (ie new password), then pam_ldap fails because it's trying to use the authtok which has not been set:

Enter login(LDAP) password:
passwd: Authentication information cannot be recovered
passwd: password unchanged

Removing the use_authtok therefore also fixes it for me, and also explains why pam_cracklib hides the problem - its higher in the stack and sets the authtok after checking it for strength. Ultimately I guess "try_authtok" would be the right semantic to work in both situations.

Revision history for this message
Caeies (caeies) wrote :

I have the exact same problem in Karmic with the package 184-8ubuntu1.

Removing the use_authok does the trick too.

I confirm that using the cracklib module hide the problem.

So is there a way to definitively fix this to avoid much problem during a security upgrade ? (just in case :).

Thanks,

Regards,

Caeies

Revision history for this message
Jamin W. Collins (jcollins) wrote :

This bug is indeed still present in Lucid. With an account only present in LDAP and the default common-password configuration, I get the following when trying to change the password for the user stored in LDAP:

$ sudo passwd testing
passwd: Authentication information cannot be recovered
passwd: password unchanged

Removing only the use_authtok parameter, I get the following:

$ sudo passwd testing
New password:
Re-enter new password:
LDAP password information changed for testing
passwd: password updated successfully

Revision history for this message
Nathan Grennan (ngrennan) wrote :

I also just ran into this bug in Lucid. Please fix it.

Revision history for this message
Jamin W. Collins (jcollins) wrote :

What's more, with libpam-cracklib installed, creation of accounts that should have no password (password disabled accounts) still prompt for a password. The prompting for a password on password disabled account creation should probably be filed as a separate bug report, but I wanted to note it here for anyone affected by this bug.

Revision history for this message
Sakari Maaranen (sam-iki) wrote :

I just confirmed this bug still exists on Maverick, with all the same details described above.

Revision history for this message
Michael Kofler (michael-kofler) wrote :

Still exists in Lucid. Shouldn't be so hard to fix. The simplest (not best) solution would be to add libpam-cracklib to the list of dependencies for libpam-ldap.

Is LDAP really a total non-topic for Ubuntu?

Revision history for this message
Jamin W. Collins (jcollins) wrote :

That's not really a viable solution as it introduces other issues. Once libpam-cracklib is installed and activated, creation of accounts that should not require a password prompt (disable login for example) all of a sudden does prompt for a password.

Revision history for this message
Jamie Brewer (jamie-brewer) wrote :

Requiring libpam-cracklib is unnecessary - all that would really need to happen is change pam-auth-update to write /etc/pam.d/common-password with try_authtok instead of use_authtok when it's enabling ldap. (Wiser and more experienced heads than I should test that for other issues but I haven't found any.) Commenting in hopes this gets bumped up the priority list because I was fighting with this for about a week before I had enough information to narrow down the Google results sufficiently.

Revision history for this message
Thomas Schweikle (tps) wrote :

This is what makes it work. I wasn't really sure if it being the right thing, but as others found it is the right thing if you are stacking various authentication methods.

Changed in libpam-ldap (Debian):
status: Unknown → New
Timo Aaltonen (tjaalton)
Changed in libpam-ldap (Ubuntu):
status: Confirmed → Triaged
summary: - Cannot change password on ldap client unless libpam-cracklib also
- installed
+ Cannot change password on ldap client, need to have 'try_authtok' in the
+ pam config
summary: Cannot change password on ldap client, need to have 'try_authtok' in the
- pam config
+ pam config or libpam-cracklib installed
Revision history for this message
leopardb (leopardb) wrote :

It might be of value to note that the "try_authtok" option for the pam_ldap.so library ist neither documented nor used, producing in the /var/log/auth.log the following line : "illegal option try_authtok". Since illegal options are ignored, it produces exactly the same behaviour as simply removing use_authtok altogether.

Because of this i'd recommend changing the title of the bug to something like : "cannot change user password on a LDAP client when the option use_authtok is used with pam_ldap.so".

Revision history for this message
Florian (florian-ke) wrote :

8 years later this is still an issue in Yakkety.

Revision history for this message
Mauro (mauromol) wrote :

Contrary to what happens in 12.04 (precise) and 14.04 (trusty), if I use the following command in 16.04 (xenial) to configure an LDAP client:
apt-get install ldap-auth-client nscd libnss-ldapd
it seems to install libpam-ldapd instead of libpam-ldap.
What seems to be relevant to this bug report is that on this 16.04 system I don't have try_authtok in my /etc/pam.d/common-password and passwd works fine. However I haven't tried to force the use of libpam-ldap instead of libpam-ldapd to see what happens.

Revision history for this message
Nathan Rennie-Waldock (nathan-renniewaldock) wrote :

Definitely still an issue in yakkety.

Revision history for this message
Mathieu Parent (math-parent) wrote :

Note the similar bug in libpam-winbind: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/570944 (and https://bugs.debian.org/858923).

I propose a new "try_authtok" option to solve this (I'm writing a patch for libpam-winbind).

Changed in libpam-ldap (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.