Softpanorama

May the source be with you, but remember the KISS principle ;-)
Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Authentication token manipulation error

News Authentication and Accounts Security

Recommended Links

Selected PAM Modules strace Reference
Linux PAM Solaris PAM PAM wheel SecurID Humor Etc

This nasty Suse and Red Hat error actually can have different (and sometimes multiple) reasons. It does not prevent successful authentication, but makes changing password via passwd impossible. You still can "implant" password from the other server in /etc/shadow file manually to bypass the error (servers should have identical encryption method set).

Often this error arise due to problems with shadow file. For example shadow password file doesn’t have entry for this user. i.e, /etc/passwd has an entry for this user, but /etc/shadow doesn’t.

The checklist below might help to structure your troubleshooting efforts.

Checklist the "Authentication token manipulation error"

  1. Is this problem for a particular account or all accounts including root.
  2. Are you using something like NIS or LDAP? Try grep passwd /etc/nsswitch.conf

    Running system-config-authentication you can configure the pam settings for the files located in /etc/pam.d.
     

  3. Does the user exists in /etc/passwd and /etc/shadow.
  4. Are attributes of those files correct. Should be:
    	/etc/passwd root.root -rw-r--r-- 
    	/etc/shadow root.root -r--------
  5. Check if the passwd command has the SUID bit enabled and it's owned by root.root. Check integrity of package which contains passwd.
    rpm -qf 
    		passwd
    pwdutils-3.0.7.1-17.24 rpm -V pwdutils
  6. Are records for the user valid (many be accidentally corrupted by manual editing, extra or missing colon is pretty common problem in this case). If passwd and group file were copied from other server, often shadow and gshadow files are not in sync. Try to delete and re-create user records using useradd to make sure that all account records are in sync and valid.
  7. Are permissions on /etc/passwd and /etc/shadow correct
  8. Were PAM configuration changed ?
  9. What are exact messages in /etc/log/messages.
  10. Get strace for the problematic system and strace both for the same user on the system that works OK and has the same PAM configuration. Compare failed and successful straces and find the point at which they diverge.
  11. Add debug option to relevant modules in PAM and see if they will provide any useful additional diagnostics.
  12. Try to simplify PAM excluding modules one by one.
  13. If everything fails restore "pristine PAM configuration from the fresh installation a start anew. 

Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

Authentication Token Manipulation Error when Changing User Passwords in Linux

Mohammedz.com
  1. mohammednv
    February 6, 2008 at 3:50 pm

    Here is another situation where I noticed this error. I was using PAM and the command “chage -d 0 username” to force the user “username” to change his/her password at his first log on. Actually, what I am going to mention here is *not* an error, but a mistake from my side.

    When you use PAM and the above command it will ask for the present password twice. First one as usual, and second time when you are being forced for the password change. When I entered the first one correctly and the second one wrongly, I got this error.

    [abdurahiman@239 ~]$ ssh test1@192.168.1.40
    test1@192.168.1.40‘s password:
    You are required to change your password immediately (root enforced)
    WARNING: Your password has expired.
    You must change your password now and login again!
    Changing password for user test1.
    Changing password for test1
    (current) UNIX password:
    passwd: Authentication token manipulation error
    Connection to 192.168.1.40 closed.
    [abdurahiman@239 ~]$

    You won’t get this error if you enter the password carefully ;).

  1. hi, i am sujit,
    plz check the /etc/pam.d/system-auth there
    only check password lines and that line alos write main word

    “remember=5″ this write after md5 shadow word
    then you can change the password of root or any normal user

SOLVED passwd Authentication token manipulation error

Open Source Web Hosting

SOLVED: passwd: Authentication token manipulation error

Posted on September 14, 2012 by admin


I was migrating a server and rather than add all the users one by one, just copied over /etc/passwd and /etc/group. I totally forgot to get /etc/shadow and when I tried to change a user’s password, I got the error:
passwd: Authentication token manipulation error

To quickly correct this, I was able to run:
/usr/sbin/pwconv
and the /etc/shadow file was created correctly, now I can change user passwords as usual.

passwd Authentication token manipulation error

Long but pretty educational discussion
IT Resource Center forums

Now new and old users alike, can't change their passwords. they get the error message as below

> passwd

passwd: Authentication token manipulation error

here are the relevant PAM files

pam.conf looks like

#
# passwd service entry that does strength checking of
# a proposed password before updating it.
#
passwd password requisite \
/usr/lib/security/pam_cracklib.so retry=3
passwd password required \
/usr/lib/security/pam_unix.so use_authtok
#

other

auth required /lib/security/pam_deny.so
account required /lib/security/pam_deny.so
password required /lib/security/pam_deny.so
session required /lib/security/pam_deny.so

passwd
auth required pam_stack.so service=system-auth
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth

I also deleted some uses the same time as i added new ones. I deleted them
with userdel.

Authentication token manipulation error

Hello,

I've got the following situation: The 6000 accounts of our eMail-server are
stored in /etc/passwd resp. /etc/shadow. To change their passwords, the users
use a ssh-session. The only object of the ssh-session is to change a users
password, therefore the loginshell is /usr/bin/passwd. To avoid attacks on the
ssh-daemon, we only want a seperate web-server with a little php-web-page to
open the ssh-session. I use apache/php with a php-module called php-ssh2 and a
library called libssh2 to establish the ssh-session. This works fine, until it
comes to the point, where the old password is sent to /usr/bin/passwd. I get
the following screen in /var/log/messages:

sshd[]: pam_unix2: pam_sm_authenticate() called
sshd[]: pam_unix2: username=[dummy]
sshd[]: pam_unix2: pam_sm_authenticate: PAM_SUCCESS
sshd[]: pam_unix2: pam_sm_acct_mgmt() called
sshd[]: pam_unix2: username=[dummy]
sshd[]: pam_unix2: expire() returned with 0
sshd[]: Accepted password for dummy from 192.168.136.50 port 6235 ssh2
sshd[]: pam_unix2: session started for user dummy, service sshd
sshd[]: pam_unix2: pam_sm_setcred() called
sshd[]: pam_unix2: username=[dummy]
sshd[]: pam_unix2: pam_sm_setcred: PAM_SUCCES
-passwd[]: pam_unix2: pam_sm_chauthtok() called
-passwd[]: pam_unix2: username=[dummy]
sshd[]: pam_unix2: pam_sm_setcred() called
sshd[]: pam_unix2: username=[dummy]
sshd[]: pam_unix2: pam_sm_setcred: PAM_SUCCESS
sshd[]: pam_unix2: session finished for user dummy, service sshd
-passwd[]: pam_unix2: pam_sm_chauthtok() called
-passwd[]: pam_unix2: username=[dummy]
-passwd[]: User dummy: Authentication token manipulation error
-passwd[]: password change failed, pam error 20 - account=dummy, uid=1000,
by=1000

If I use some other tools like gnu-ssh or putty, it all works very well. Is
there a difference between the two methods gnu-ssh and PHP-script, which
/usr/bin/passwd recognizes, e.g. keyboard-interactive vs. tunneled-cleartext? I
think of this, because I had to change some settings in /etc/ssh/sshd-config,
to enable tunneled-cleartext authentication:

PasswordAuthentication yes

enable or disable following in sshd-config has no effect:

ChallangeResponseAuthentication no
UsePAM yes

What does that mean: 'Authentication token manipulation error'? Is it possible
to use /usr/bin/passwd with a pipe, like libssh2 does?

The PAM configuration is mostly SuSE 10.0 original, except the debug-feature.

/etc/pam.d/sshd:
auth required pam_env.so debug
auth required pam_unix2.so debug
auth required pam_nologin.so
account required pam_unix2.so debug
password required pam_pwcheck.so nullok
password required pam_unix2.so nullok use_first_pass use_authtok debug
session required pam_limits.so
session required pam_unix2.so debug

/etc/pam.d/password:
auth required pam_env.so debug
auth required pam_unix2.so debug
account required pam_unix2.so debug
password required pam_pwcheck.so nullok
password required pam_unix2.so nullok use_first_pass use_authtok debug
session required pam_limits.so
session required pam_unix2.so debug


Versions:

Webserver:
apache2-2.0.54-10
apache2-mod_php4-4.4.0-6.6
php4-4.4.0-6.6
libssh2-0.12
php-ssh2-0.10

eMailserver (on which password has to be changed):
openssh-4.1p1-10
pam-0.80-6
pam-modules-10.0-11.2


Your help is greatly appreciated.
Joerg


"Jetzt Handykosten senken mit klarmobil - 14 Ct./Min.! Hier klicken"
www.klarmobil.de/index.html?pid=73025

Re unable to change root password



Tony wrote:

> Only problem is now I can't change the password for
> root.
> [root ~]# passwd root
> Changing password for user root.
> New UNIX password: 
> Retype new UNIX password: 
> passwd: Authentication failure
> [root ~]# 
> 
> No problems logging in as root or su'ing to root.
> Never had any issues like this before . 
> I also can't change the password for any other user:
> 
...

just a wild guess: probably the (write)-permissions for /etc/shadow and
the like have been set to something unusual? (or whatever backend you
are using for passwords)

and of course you should have a look in auth.log to see anything unusual.

NEOHAPSIS - Peace of Mind Through Integrity and Insight

(RH8) pam_stack considered harmful

From: John M. Taylor Jr. (johntcadence.com)
Date: Wed Apr 09 2003 - 15:49:37 CDT


Here is some interesting behavior I am observing in RH8 that may have
some bearing on both the pam_tally and winbind questions.

Sample pam.d/rlogin:

#(bunch of irrelevant stuff deleted)
#The following line should always fail,
#thus making rlogin auth always fail...right?
auth requisite /lib/security/pam_deny.so

account required /lib/security/pam_stack.so service=system-auth
password required /lib/security/pam_stack.so service=system-auth
session required /lib/security/pam_stack.so service=system-auth

Sample pam.d/system-auth:

#(stock RH8 system-auth file)
#You would think the following 3 lines would not get evaluated,
#since there was no "auth required pam_stack.so service=system-auth"
#in pam.d/rlogin, right?
auth required /lib/security/pam_env.so
auth sufficient /lib/security/pam_unix.so likeauth nullok
auth required /lib/security/pam_deny.so

#if auth failed in the pam.d/rlogin file,
#then none of the rest of this should matter, right?
account required /lib/security/pam_unix.so

password required /lib/security/pam_cracklib.so retry=3 type=
password sufficient /lib/security/pam_unix.so nullok
use_authtok md5 shadow nis
password required /lib/security/pam_deny.so

session required /lib/security/pam_limits.so
session required /lib/security/pam_unix.so

Yet when I try to rlogin to the host with these settings, I get the
following in the /var/log/messages file:

Apr 9 16:15:38 hostfoo rlogind[15198]: PAM authentication failed for
in.rlogind
Apr 9 16:15:43 hostfoo login(pam_unix)[15199]: session opened for user
johnt by (uid=0)
Apr 9 16:15:43 hostfoo login -- johnt[15199]: LOGIN ON pts/11 BY johnt
FROM hostbar

And indeed I can log in after giving the login process my passwd,
because even though I failed the auth section in pam.d/rlogin,
I succeeded in the auth section of pam.d/system-auth.

###

Now if I set things up like this:

Sample pam.d/rlogin:

#(Stock RH8 pam.d/rlogin file,
#except for commented out pam_stack line.
#Since pam_rhosts_auth is "sufficient",
#the missing pam_stack line shouldn't be a problem, right?)
auth required /lib/security/pam_deny.so
auth required /lib/security/pam_nologin.so
auth required /lib/security/pam_securetty.so
auth required /lib/security/pam_env.so
auth sufficient /lib/security/pam_rhosts_auth.so
#auth required /lib/security/pam_stack.so service=system-auth

account required /lib/security/pam_stack.so service=system-auth
password required /lib/security/pam_stack.so service=system-auth
session required /lib/security/pam_stack.so service=system-auth

Sample pam.d/system-auth:

#(stock RH8 system-auth file,
#except for commented out next 2 lines,
#leaving the fall-through pam_deny bare.)
#auth required /lib/security/pam_env.so
#auth sufficient /lib/security/pam_unix.so likeauth nullok
auth required /lib/security/pam_deny.so

#if auth failed in the pam.d/rlogin file,
#then none of the rest of this should matter, right?
account required /lib/security/pam_unix.so

password required /lib/security/pam_cracklib.so retry=3 type=
password sufficient /lib/security/pam_unix.so nullok
use_authtok md5 shadow nis
password required /lib/security/pam_deny.so

session required /lib/security/pam_limits.so
session required /lib/security/pam_unix.so

Which results in the following /var/log/messages entries:

Apr 9 16:32:27 hostfoo login(pam_unix)[15340]: session opened for
user johnt by (uid=0)
Apr 9 16:32:27 hostfoo login[15340]: Authentication service cannot
retrieve user credentials

and I can't log in.
So even though pam.d/rlogin likes me,
since the auth section of pam.d/system-auth denies me,
the login fails.

The bottom line is, no matter what rules you put in the auth section of
your pam.d/rlogin (or other service file), if you use pam_stack then the
previous rules get ignored. And if you use pam_stack for your account,
password, and session sections, then the "service" they check is NOT the
service you would expect, e.g., "rlogin", in my case, but the name of
the service on the pam_stack.so command line, e.g., "service=system-auth".

Conversely, even if the auth lines in your pam.d/rlogin authenticate
you, if the auth lines in your system-auth file don't authenticate you
(my second example), then the account, password, and session lines IN
THE system-auth file may not authenticate you either.

This explains why I have gotten pam_listfiles to work great on Solaris,
but not on Linux. Solaris doesn't use the pam_stack mechanism, and what
you see in your Solaris pam.conf is what you get. This also explains why
users can see themselves being authenticated in the /var/log/messages
file, yet they are getting denied access to the machine.

My question: Does anyone know why pam_stack discards the previous
results of the stack in favor of its own stack? Is this a bug or a feature?

Hope this helps!

best regards,

--johnT

Recommended Links

Softpanorama hot topic of the month

Softpanorama Recommended

password recovery - Authentication token manipulation error - Ask Ubuntu

Getting an Authentication token manipulation error when trying to change my user password - Ask Ubuntu

Fix Ubuntu Passwd Authentication token manipulation error - YouTube

Authentication

Password synchronization

Linuxquestions.org

Authentication Token Manipulation Error when Changing User Passwords in Linux --Mohammedz.com

Fixing “passwd Authentication token manipulation error” when changing passwords Idea Excursion



Etc

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least


Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info

Disclaimer:

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: June, 04, 2016