I'm a "backup" sysadmin for a small team, and the primary sysadmin is unavailable. The lab setup is a little bit new to me, and I'm not familiar with everything about how it's setup yet (and my Linux sysadmin skills are probably a little out of date). I was asked to reset a password for a user, and I thought "great, that's just passwd -e username". Unfortunately, this gives me:
# /usr/bin/passwd jdoe
Changing password for user jdoe.
Password reset by root is not supported.
passwd: Authentication token manipulation error
At first I thought I just need to use ldappasswd
instead, but apparently it's not using LDAP (/usr/bin/ldappasswd
does not exist and the command is not found on the system). Finally, I checked /etc/nsswitch.conf
, and saw this:
passwd: files sss
shadow: files sss
group: files sss
Additional info: This system (and most of my lab network) is running on CentOS release 6.6.
Ok, I guess my Linux skills are a little bit inadequate or rusty. What is "sss"? And how do I accomplish a simple password reset on this system?
Updated Information:
I am attempting to reset the password as the root user (yeah, not the best security setup that we have root login enabled and not sudo for the lab admins, but I'm just the backup guy…I can only try to influence). What appear to be the relevant lines from /etc/sssd/sssd.conf
are (best guess, as I said, I'm rusty on some things, like IPA):
ipa_domain = sub.domain.mycompany.com
id_provider = ipa
auth_provider = ipa
ldap_autofs_entry_object_class = automount
access_provider = ipa
ipa_hostname = node6.sub.domain.mycompany.com
chpass_provider = ipa
ldap_autofs_entry_key = automountKey
ipa_server = ipa1.sub.domain.mycompany.com, ipa2.sub.domain.mycompany.com
Best Answer
The clues start with knowing that the
/etc/nsswitch.conf
file on the system is used to configure the Name Service Switch facility in Linux. From wikipedia:This line from the
/etc/nsswitch.conf
file lets us know that the Linux "System Security Services" (sss) is the provider for user passwords and related functions.The next clue comes from the contents of
/etc/sssd/sssd.conf
. The man page for this configuration file tells us about thechpass_provider
entry, and for me that is ipa:And this line lets us know what server(s) are responsible for running the ipa services:
Finally, I just had to log on to
ipa1.sub.domain.mycompany.com
, where I see thatipa
is indeed installed, as well as LDAP. A couple judicious internet searches led me to this Redhat page pertaining to managing passwords via IPA, that gave me these helpful steps:Voila, done! Lesson learned: My lab system is kind of a hodge-podge of servers configured in a (perhaps) non-standard way, but a couple knowledgeable people can give you some clues to point you in the right direction, and following the bread crumbs and doing some Internet searches will hopefully reveal the answer.