passwd : gives "Authentication token manipulation error"

[gmoore777]

Binary package hint: samba

 `passwd` for ActiveDirectory account gives "Authentication token manipulation error"

I have latest and greatest of LucidLynx updates.

    winbind 2:3.4.7~dfsg-1ubuntu3
    samba 2:3.4.7~dfsg-1ubuntu3

I have ActiveDirectory integration with Samba/Winbind. (not Likewise-Open)
Logging into Console window or `ssh`-ing into machine works fine using
DOMAIN\first.last account names.

Trying to change password with the `passwd` program:

$ passwd
Changing password for DOMAIN\first.last
(current) NT password:
passwd: Authentication token manipulation error
passwd: password unchanged
$

In the /var/log/auth.log file I get this output in conjunction with the above passwd attempt:

pam_unix(passwd:chauthtok): user "DOMAIN\first.last" does not exist in /etc/passwd
passwd[16109]: pam_winbind(passwd:chauthtok): getting password (0x0000002a)

passwd[16109]: pam_winbind(passwd:chauthtok): user 'DOMAIN\first.last' granted access
passwd[16109]: pam_unix(passwd:chauthtok): user "DOMAIN\first.last" does not exist in /etc/passwd
passwd[16109]: pam_winbind(passwd:chauthtok): getting password (0x00000012)

I don't see anything particularly wrong with that output, other
than it seems to stop prematurely.

This is my default-created /etc/pam.d/common-password file:

password [success=2 default=ignore] pam_unix.so obscure sha512
password [success=1 default=ignore] pam_winbind.so use_authtok try_first_pass
password requisite pam_deny.so
password required pam_permit.so
password optional pam_gnome_keyring.so

I've Googled for "Authentication token manipulation error", but most
cases involve local Linux accounts or other uninteresting problems.

I don't think any entries in smb.conf have an effect on passwd, but here's a snippet of entries with the word "pass" or "encrypt" in them:

password server = machine.domain.com
encrypt passwords = true
passdb backend = tdbsam
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = yes
encrypt passwords = true

I can successfully change password, using `passwd` for a local Linux account.

$ passwd
Changing password for localAccount.
(current) UNIX password:
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
$

[Thierry Carrez (ttx)]

Thanks for your input. Did it ever work on previous releases ?

[gmoore777 (guy-moore)]

Yes it works on HardyHeron.
I used likewise-open to faciitate the ActiveDirectory integration on HardyHeron,
rather than just the native samba/winbind integration on LucidLynx.
But that may have nothing to do with it, but is worthy of mentioning.

[Thierry Carrez (ttx)]

So it works with likewise-open on Hardy, and fails with winbind on lucid ? Or did you also successfully use winbind on hardy ?

[gmoore777 (guy-moore)]

Correct, `passwd` works with likewise-open on hardy, and fails with winbind on lucid.
I do not know what the outcome of `passwd` is on hardy without likewise-open, nor
the outcome of `passwd` on lucid with likewise-open.
I will ask this on the Lucid forum at http://ubuntuforums.org/showthread.php?t=1459309

[Thierry Carrez (ttx)]

Probably an issue with the winbind configuration... Any reason why you're not using likewise-open in lucid as well ?

[gmoore777 (guy-moore)]

i am not using likewise-open on Lucid cause likewise-open no longer supports setting up Samba shares with ActiveDirectory integration.
Meaning from a Windows machine, I cannot access \\linuxmachinename\sharename and this
is important to our Windows/Linux workplace.

(And I no longer see the advantage or point to using likewise-open. It only adds another mysterious layer
 to the whole samba/winbind realm.)

[Thierry Carrez (ttx)]

Note that likewise 5.x doesn't add another layer on top of samba/winbind, it's a complete reimplementation. It's also simpler to set up, and since in your case something must be wrong with the winbind setup, it might help you...

Could you attach your winbind configuration ?

[gmoore777 (guy-moore)]

Is this what you need?

$ cd /etc/pam.d
$ cat common-auth common-session-noninteractive common-session common-password common-account | grep -v "^#"

auth [success=2 default=ignore] pam_unix.so nullok_secure
auth [success=1 default=ignore] pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass
auth requisite pam_deny.so
auth required pam_permit.so

session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session required pam_unix.so
session optional pam_winbind.so

session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session required pam_mkhomedir.so skel=/etc/skel/ umask=0027
session required pam_unix.so
session optional pam_winbind.so
session optional pam_ck_connector.so nox11

password [success=2 default=ignore] pam_unix.so obscure sha512
password [success=1 default=ignore] pam_winbind.so use_authtok try_first_pass
password requisite pam_deny.so
password required pam_permit.so
password optional pam_gnome_keyring.so

account [success=2 new_authtok_reqd=done default=ignore] pam_unix.so
account [success=1 new_authtok_reqd=done default=ignore] pam_winbind.so
account requisite pam_deny.so
account required pam_permit.so

Here is the smb.conf, with comments removed and substituted in
<shortDOMAINname>, <MACHINEX>, <DOMAIN> where appropriate.

[global]
workgroup = <shortDOMAINname>
security = ADS
password server = <MACHINE1>.<DOMAIN>.com, <MACHINE2>.<DOMAIN>.com
realm = <DOMAIN>.COM
server string = %h server (Samba, Ubuntu)
dns proxy = no
log file = /var/log/samba/log.%m
max log size = 1000
syslog = 0
panic action = /usr/share/samba/panic-action %d
encrypt passwords = true
passdb backend = tdbsam
obey pam restrictions = yes
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = yes
map to guest = bad user
idmap backend = idmap_rid:<DOMAIN>=50-9999999999
idmap uid = 50-9999999999
idmap gid = 50-9999999999
allow trusted domains = no
winbind offline logon = true
template shell = /bin/bash
template homedir = /home/%D/%U
winbind normalize names = yes
winbind use default domain = yes
usershare allow guests = yes

[gmoore777 (guy-moore)]

FYI:
I can get `passwd` to work if I change the line in common-password
From:
  password [success=1 default=ignore] pam_winbind.so use_authtok try_first_pass
To:
  password sufficient pam_winbind.so

I'm not sure if I'm creating other problems with the above edit, since
I'm not PAM savvy.

I have to wait one day to change my password again,
but I will try a more minimal change of:
   password [success=1 default=ignore] pam_winbind.so try_first_pass
Meaning, I will just remove the "use_authtok" to see if that is the problem.

[gmoore777 (guy-moore)]

FYI:
I can get `passwd` to work if I change one line in common-password

From the winbind default-configured line of:

  password [success=1 default=ignore] pam_winbind.so use_authtok try_first_pass

To:
  password [success=1 default=ignore] pam_winbind.so try_first_pass

So looks like just the "use_authtok" parameter is misbehaving.

(not sure what that really means or with whom the problem lies)

[Thierry Carrez (ttx)]

Interesting. Short explanation of the parameters: the pam passwd stack asks for two passwords, one to authenticate and one as the new password.

try_first_pass makes pam_winbind try to use the authentication password provided to the previous module (pam_unix). If it fails, it will prompt for a new authentication password.

use_authtok makes pam_winbind use the new password as set by the previous module. If there is none, it will prompt for a new password to use.

Looks like the latter is failing: you don't get prompted for a new password ever if "use_authtok" is present.

Could you post the output and logs you get when changing winbind password and using "password [success=1 default=ignore] pam_winbind.so try_first_pass" ? I'll try to compare it with the output and logs you posted in Description.

[gmoore777 (guy-moore)]

I have interleaved the information, removed the timestamps and substituted DOMAIN\first.last for the actual:

$ passwd
Changing password for DOMAIN\first.last

        passwd[30381]: pam_unix(passwd:chauthtok): user "DOMAIN\first.last" does not exist in /etc/passwd
        passwd[30381]: pam_winbind(passwd:chauthtok): getting password (0x00000028)

(current) NT password:
        passwd[30381]: pam_winbind(passwd:chauthtok): user 'DOMAIN\first.last' granted access
        passwd[30381]: pam_unix(passwd:chauthtok): user "DOMAIN\first.last" does not exist in /etc/passwd
        passwd[30381]: pam_winbind(passwd:chauthtok): getting password (0x00000000)
Enter new NT password:
Retype new NT password:
passwd: password updated successfully
         passwd[30381]: pam_winbind(passwd:chauthtok): user 'DOMAIN\first.last' OK
         passwd[30381]: pam_winbind(passwd:chauthtok): user 'DOMAIN\first.last' password changed
         passwd[30381]: pam_winbind(passwd:chauthtok): user 'DOMAIN\first.last' granted access
         gnome-keyring-daemon[30390]: gp11_module_get_slots: assertion `data->funcs' failed
         gnome-keyring-daemon[30390]: lookup_login_session: assertion `slot' failed
         gnome-keyring-daemon[30390]: lookup_login_keyring: assertion `GP11_IS_SESSION (session)' failed
         gnome-keyring-daemon[30390]: create_credential: assertion `GP11_IS_SESSION (session)' failed
         gnome-keyring-daemon[30390]: egg_error_message: assertion `error' failed
         gnome-keyring-daemon[30390]: couldn't create new login credential: (unknown)
         passwd[30381]: gkr-pam: couldn't change password for the login keyring: the passwords didn't match.
$

and the password has changed via a test of `ssh`-ing into any Linux machine.

[Thierry Carrez (ttx)]

OK, I misread use_authtok. It will *not* prompt for a new password if none has been set by the previous module in stack. Since pam_unix doesn't prompt for a new password (due to "user "DOMAIN\first.last" does not exist in /etc/passwd"), pam_winbind has nothing to use and fails.

Looks like we should just drop use_authtok here.

[Thierry Carrez (ttx)]

I'd like a second pair of PAM eyes before making that change.

[Steve Langasek (vorlon)]

This is a tricky one. Dropping use_authtok does solve the problem of pam_unix not prompting for the password, but it also changes the behavior in the case that you have a password strength checking module stacked first, such as pam_cracklib. If pam_cracklib is configured, we don't want pam_winbind to prompt for a different password after we've gone to all the trouble of checking the strength of the first one entered!

This problem affects other combinations of stacked modules as well (e.g., pam_krb5+pam_unix), and needs to be solved generally. Currently the best solution I can offer is for PAM modules to always prompt for passwords even when they don't need them, in order to ensure correct usage of use_authtok. Alternatively, we could fix modules that accept use_authtok to recognize the lack of a password token as valid and prompt for it after all, or we could introduce a new common module option with "use_authtok_if_available" semantics. In any event, we don't want to lose the current behavior that modules *must* use the existing password if provided rather than prompting separately, and any solution we implement needs to be done systemically; so please don't change the winbind pam profile without us first having a larger conversation about how to make this work.

[Thierry Carrez (ttx)]

Right. We clearly don't want to introduce new failures when we fix a specific combination :)
In the mean time, users affected by this issue can workaround it by following comment 10.

[urusha (urusha)]

Here is my solution:
1) copy "winbind" "winbind-noauthtok" "unix-noauthtok" files from attachments to /usr/share/pam-configs/ (with overwrite)
2) copy "pam_winbind.conf" from attachment to /etc/security/
3) run pam-auth-update and check "Unix authentication (no use_authtok)" & "Winbind NT/Active Directory authentication (no use_authtok)", also uncheck "Unix authentication" & "Winbind NT/Active Directory authentication"
4) use it

What it is:
1) new configs.
  1. winbind - is the same as default winbind (you need to overwrite it) but:
    a) without krb5_*, cached_login options, I think these should be placed in special config file /etc/security/pam_winbind.conf - this is much more customizable way to configure pam_winbind without any involving of pam-auth-update. Also this solves bug about not getting krb ticket and ccache when changing expired password on login (pam_winbind passwd section should contain krb5_* options too, but it doesn't)
    b) increased "Priority", it's to solve buggy changing expired password on login. Winbind should be before unix (like pam_krb5 does)
  2. winbind-noauthtok, unix-noauthtok - is the same as winbind and unix, but without use_authtok option. These configs conflicts with winbind, unix and cracklib, so you can't install winbind-noauthtok with winbind or cracklib
2) see 1-1-a
3) just changing configs in /etc/pam.d/ "the right" way
4) this solution has the next advantages:
  1. customizable - you may choose: use cracklib or not, pam-auth-update suggests different ways
  2. solves some existing bugs: allows you to change unix, wb password via passwd command (or any other graphical tools); allows to change expired unix, wb password on login; gets krb ticket and ccache after wb expired password has been changed; maybe some others...

To packages supporters:
  Why not to implement this in all pam modules packages (add unix, unix-noauthtok in libpam-runtime for example), while thinking about upgrading whole pam system?
  It would be really nice to add function of detecting if use use_authtok or not to pam-auth-update (just read configs of higher priority modules).

Some offtopic (to pam-auth-update supporters):
  Even if I use pam_winbind.conf option "mkhomedir = yes" it doesn't copy skel directory to new user home. So I'm forced to use pam_mkhomedir. But if I create config for it in /usr/share/pam-configs, it adds lines about making home derictories to /etc/pam.d/common-session-noninteractive too, and this is really BAD behavior. So the right way is to implement "Session-noninteractive:" section in config files, I think.

Thanks for attantion.

[urusha (urusha)]

Oh, about offtopic - forget about it. Now I see - there is "Session-Interactive-Only: yes" option.

[Luca Lorenzetto (lorenzetto-luca)]

As suggested by gmoore777 removing use_authtok allowed me to go on with password changing

[Luca Lorenzetto (lorenzetto-luca)]

I forgot to say i'm on precise with latest updates

[Filippe LeMarchand (gasinvein)]

6 years passed, and the bug introduced by maintainers, confirmed and easly fixable, is still present. Shame on you, Canonical.

[Nish Aravamudan (nacc)]

@gsainvein, thanks for your input, but as mentioned in c#15, this is not "easily fixable". The workaround mentioned in c#10 is possibly fine in some situations, but will break others.

[Mathieu Parent (math-parent)]

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

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

[Launchpad Janitor (janitor)]

This bug was fixed in the package samba - 2:4.9.2+dfsg-2ubuntu2

---------------
samba (2:4.9.2+dfsg-2ubuntu2) disco; urgency=medium

  * d/p/smbd-startup-with-winbind.patch: ignore create_builtin_guests()
    failing without a valid idmap configuration. This fixes the smbd startup
    on a standalone server where winbind is available and running. Thanks to
    Stefan Metzmacher <email address hidden>. (LP: #1806035)

 -- Andreas Hasenack <email address hidden> Fri, 21 Dec 2018 10:39:23 -0200

[Andreas Hasenack (ahasenack)]

I don't know why that samba upload closed this bug: #570944 is nowhere in d/changelog.

[Mathieu Parent (math-parent)]

It is. Closed by me:

 samba (2:4.9.1+dfsg-2) unstable; urgency=medium
 [ Mathieu Parent ]
 * Allow one to change password via passwd in default config
- third_party: Update pam_wrapper to version 1.0.7
- third_party: Add pam_set_items.so from pam_wrapper
- nsswitch: Add try_authtok option to pam_winbind
 - tests: Check pam_winbind pw change with different options
- Patch for previous 4 commits
 - debian/winbind.pam-config: Use the new try_authtok option allowing password change while preserving current behavior with password strength modules (Closes: #858923, LP: #570944)

[Andreas Hasenack (ahasenack)]

Ah, thank you, I missed that

On Wed, Jan 9, 2019, 18:34 Mathieu Parent <<email address hidden> wrote:

> It is. Closed by me:
>
> samba (2:4.9.1+dfsg-2) unstable; urgency=medium
> [ Mathieu Parent ]
> * Allow one to change password via passwd in default config
> - third_party: Update pam_wrapper to version 1.0.7
> - third_party: Add pam_set_items.so from pam_wrapper
> - nsswitch: Add try_authtok option to pam_winbind
> - tests: Check pam_winbind pw change with different options
> - Patch for previous 4 commits
> - debian/winbind.pam-config: Use the new try_authtok option allowing
> password change while preserving current behavior with password strength
> modules (Closes: #858923, LP: #570944)
>
> --
> You received this bug notification because you are subscribed to samba
> in Ubuntu.
> https://bugs.launchpad.net/bugs/570944
>
> Title:
> passwd : gives "Authentication token manipulation error"
>
> Status in samba package in Ubuntu:
> Triaged
>
> Bug description:
> Binary package hint: samba
>
> `passwd` for ActiveDirectory account gives "Authentication token
> manipulation error"
>
> I have latest and greatest of LucidLynx updates.
>
> winbind 2:3.4.7~dfsg-1ubuntu3
> samba 2:3.4.7~dfsg-1ubuntu3
>
> I have ActiveDirectory integration with Samba/Winbind. (not
> Likewise-Open)
> Logging into Console window or `ssh`-ing into machine works fine using
> DOMAIN\first.last account names.
>
> Trying to change password with the `passwd` program:
>
> $ passwd
> Changing password for DOMAIN\first.last
> (current) NT password:
> passwd: Authentication token manipulation error
> passwd: password unchanged
> $
>
> In the /var/log/auth.log file I get this output in conjunction with
> the above passwd attempt:
>
> pam_unix(passwd:chauthtok): user "DOMAIN\first.last" does not exist in
> /etc/passwd
> passwd[16109]: pam_winbind(passwd:chauthtok): getting password
> (0x0000002a)
>
> passwd[16109]: pam_winbind(passwd:chauthtok): user 'DOMAIN\first.last'
> granted access
> passwd[16109]: pam_unix(passwd:chauthtok): user "DOMAIN\first.last" does
> not exist in /etc/passwd
> passwd[16109]: pam_winbind(passwd:chauthtok): getting password
> (0x00000012)
>
> I don't see anything particularly wrong with that output, other
> than it seems to stop prematurely.
>
> This is my default-created /etc/pam.d/common-password file:
>
> password [success=2 default=ignore] pam_unix.so obscure sha512
> password [success=1 default=ignore] pam_winbind.so use_authtok
> try_first_pass
> password requisite pam_deny.so
> password required pam_permit.so
> password optional pam_gnome_keyring.so
>
> I've Googled for "Authentication token manipulation error", but most
> cases involve local Linux accounts or other uninteresting problems.
>
> I don't think any entries in smb.conf have an effect on passwd, but
> here's a snippet of entries with the word "pass" or "encrypt" in them:
>
> password server = machine.domain.com
> encrypt passwords = true
> passdb backend = tdbsam
> unix password sync = yes
> passwd program = /usr/bin/passwd %u
> passwd chat = *Enter\snew\s*\spassword:* %n\n
> ...