Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 385
  • Last Modified:

See Password History in Fedora 4

We are attempting to oust a sys admin and have asked him to give us the Superuser/root password, as well as all user names and passwords for all users.

Are intent is to reset passwords to prevent unwanted users getting on the box to sabotage data -especially him.

The sys admin responded that there was not a way to see passwords - and he wouldn't give us the superuser/root password.  Is there not a way to see user & password history, as well as a way to see root password or reset it in order to reset other passwords?

We are pure Windows admins and know nothing about Linux.  He did give us this desription of the server and OS:

"The main server on 1st floor is a Linux server running Fedora 4 kernel 2.6.14-1.1656_FC4.  It has 512meg of memory, a 2.6gig processor and 2 raptor disk drives, RAID 0."

Urgent - Any assistance would be appreciated.
0
leishakay
Asked:
leishakay
2 Solutions
 
n664dcCommented:
>>The sys admin responded that there was not a way to see passwords
You can see them, it's just that they're encrypted so it'll do you no good. :D

>>Is there not a way to see user & password history, as well as a way to see root password or reset it in >>order to reset other passwords?
Not that I know of.

I do believe if you have physical acecss to the box, you can use a livecd to reset the root pass but I have never needed to nor done so.

Hopefully someone who has done it before can comment.
0
 
n664dcCommented:
http://www.experts-exchange.com/Security/Linux_Security/Q_22023129.html

This is what I was talking about.  It should work for you as well.
0
 
ygouthamCommented:
apart from the above,  linux also offers a peculiar way of handling such events.  you can read thru the above link to understand how to reset passwords.  

you can do one more thing.  you can copy the line 1 from the /etc/shadow which should ideally start with "root:xxxxxxxxxxxxxx:..." from a machine where you know of the root's password.  

you can paste the same in /etc/shadow- as well for redundancy. and then try logging in as root with the password that you know of and it should still work.

if password is the only point of concern in a sabottage effort then this would help. what if the data is compromised????  having the password is no guarantee to security.  please rethink your strategy.  am voicing my concerns and not trying to advise.  at the end of day it is your call...

goutham
0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
n664dcCommented:
If permissions are set up right, wouldn't the default permissions on /etc/shadow only allow root to edit it?
0
 
ygouthamCommented:
i was suggesting that they login into a single user mode or rescue mode and then carry out the operation.  that ways you are default logged in as root and hence no requirement to know the previous password at all  ;-)

goutham
0
 
Kerem ERSOYPresidentCommented:
Hi,

The thing is Linux encrypts the passwrows using a one-way crypt algorithm. So it i not possible to regain passwords. But this is not a new thing Windows uses a similar algorithm.

If there's  risk of sabootage to your system there are several tools you can use. First of all you may introduce and Identity Manager suite in your IT department. With such a system you can change any'user's password via this system and notfrom the conventional methods. This will give you a consistent log of user Password events such as password changes, resets, unauthorized events etc. It is also possible to change all the passwords without you sys admin acceesess the system and you can escort him to the door if the need should arise :))

There are aosl commercial tools which can limit even the root users abilities over the system. These are called Access-Control products.

and lat but not leastt you need to have  good backup procedures in case he deletes the filesystem in sabottage he would not achieve anything isnce you'd restore and continue from your backups in a short time.

Cheers,
K


0
 
nociSoftware EngineerCommented:
If you want to lock out such a user then
besides the root password, the also check your sudo arangements.
and reset accounts that can gain elevated rights or plainly reset all accounts.

Password histoy files by should only keep encrypted passwords, as all passwords
that are kept in files are encrypted. AFAICT only LDAP allows you to keep unencrypted passwords you can use in unix.
0
 
kyle_in_taiwanCommented:
So, to recap:

A) Change the root password (via noci, the other thread, using my preferred method, although single-user mode is just as effective):

1) boot from a livecd (Knoppix is probably best)
2) mount your root volume on /mnt: $ mount /dev/___ /mnt/___
$ chroot /mnt/___
$ passwd root

and you'll be prompted to change the password.


B) After re-booting into multi-user mode, change all user passwords using the same command:

$ passwd [User1]
$ passwd [User2]
etc.

C) Type:

$ man sudo
and read up on sudo, then edit /etc/sudoers and make damn sure your rogue sysadmin is totally deleted from the system.

D) Investigate what sort of backup systems you have in place, and make sure you've got up-to-date backups;  in this vein, i'd recommend checking to see if you have any old AIDE snapshots to compare the system against -- with root access, it'd be an easy thing for him to install a rootkit and keep access to your box even once you do manage to deny him access via the root account.  Y'all should really think about getting another Linux professional to check out what exactly is on the machine and see if he can guarantee that it's secure.  Such a guarantee may demand a re-installation of the root system, which isn't a terribly difficult thing to do if y'all find someone who knows their way around the system.
0
 
leishakayAuthor Commented:
Thank you kyle_in_taiwan and noci.  We did take remove the servers, physically, from the floor and have them safely secured until we resolve this.   I think kyle is right in that I had better get a Linux pro in here and evaluate and make sure it is secure before we put it back in production.  I'll make sure these instructions are reviewed.  I appreciate all the wise advice and instructions.

0

Featured Post

Vote for the Most Valuable Expert

It’s time to recognize experts that go above and beyond with helpful solutions and engagement on site. Choose from the top experts in the Hall of Fame or on the right rail of your favorite topic page. Look for the blue “Nominate” button on their profile to vote.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now