Page 1 of 1

[SOLVED] root inaccessible even after password change

Posted: 2016/03/09 13:46:24
by warron.french
I have several CentOS-6.x systems for a sensitive network.

I used to be able to access the root account, even through the GUI logon screen, until months ago. Something happened, and I believe it was after a patch update to all of the systems (including my server referenced in my posting from last night).

I do have a GRUB password set to the same value for my 6 workstations and 1 server.
I can only, however, gain access to root on the 6 workstations when in single-user mode; but the server I cannot access through GRUB at all (refer to last night's post for the details).

After gaining access to the GRUB menu, after hitting 'p' and being prompted for and successfully passing the password challenge to use the GRUB menu, I add the value 'single' to the end of the vmlinuz line.
I get root access in single-user mode, and I successfully alter the root password on all 6 workstations (only the workstations) but at the Gnome Desktop, I still cannot gain local access to root.

PLEASE help me, I am in dire straits with this system.

Re: root inaccessible even after password change

Posted: 2016/03/09 13:56:03
by MartinR
When you say you can't log in as root through the GUI screen, do you mean that root is not displayed as a user? If this is what you mean, click on "Other?" and enter root as the username. If, on the other hand, you have already done this, what happens next?

Re: root inaccessible even after password change

Posted: 2016/03/09 15:08:19
by warron.french
MartinR, no, what I am referring to is I provide the root account in the Username entry-field, and then I provide the root account's password in the Password entry-field; the system shows me the little busy icon (looks like the old Blackberry wait icon) and then goes right back to the login page again.

That's all it does,

Re: root inaccessible even after password change

Posted: 2016/03/09 22:11:45
by warron.french
I have found the temporary solution; my AUDIT configuration was breaking Root's access at any runlevel above 1.

It turns out that in my auditd.conf there was a setting that requires the audit daemon start successfully.

If my audit.rules files has inappropriate syntax in it then; then of course my auditd would not properly start.

In my system, the configuration also requires auditd starts successfully before the root account can log into the system at any runlevel greater than 1.

So, my immediate solution was to put back the "factory default files" auditd.conf and audit.rules.

Because I now know that I just need to go back through my audit.rules file and make the necessary adjustments, I am going to close out this issue as [SOLVED].