The Solaris group is a forum where peers share technical expertise, solve problems, and discuss issues related to the Solaris operating system, including OS-related malfunctions, security issues, and network performance.

Solaris Root Password not Allowing Login

I am running Solaris 10 on a SPARC M3000. The root account was unable to be logged in to either by su or from the console. Since we could not find if anybody changed it, we booted the server into single user mode and it accepted the root password. We then changed it and rebooted the server. The root account was then able to be logged into again. I am trying to research what happened. I did not see anything pointing to a user in the audit logs. The only thing I see appears to be a password utility, passwdutil.so.1. Could this have corrupted the password for some reason? Any help on where I could investigate would be appreciated.

I did check the /var/adm/sulog and saw the last person to su to root, but the audit logs showed them changing their personal password, but not the root password. The last command only showed what I already knew about who logged in.

Doesn't it seem strange that I could not log in through the console with the root password in multi-user mode, but I could in single-user mode?

1) Could not log in as root
2) Shutdown system. I am assuming you power cycled the system
since you could not log in as root to shutdown system.
3) Booted in single user mode and login as root .
4) Change root password and rebooted.
5) Now able to log in as root

If this is the scenario, there should be no difference in the root
password in single user more ( item 3) then multi user mode.

@ gelsies - That is correct. I don't know why there was a difference but there was. I didn't powercyle the machine, just sent a break to the OK prompt and did a boot -s.

At first I tested on another machine booting into failsafe mode, then editing the /etc/shadow file, removing the password for root, then rebooting. It would let me log in at the console as root without a password, then I was able to change the password. On this machine, I tried that first, but when I tried to log in, it still told me invalid login. That was when I went to single user mode and was able to just hit the enter key when asked for the password.

Interesting. Never happened to me. The /etc/shadow file has
parameters for expiration and failed attempts but I think any problem
with that file would stop login in single user mode to. I know that
/etc/pam.conf controls authentication but that was not modified when
you changed passwords. I would like to know the answer to this if
someone figures it out.

Booting into single user mode automatically makes the console root without a password. That is default behavior to protect for lost/corrupt root password.

The sulog is not conclusive. If someone had access to root, they could change the log.

If you have a log showing another user changed their password at the time in question, is it possible they were in the root account and changed the root password erroneously thinking it was their account? Who was that user? Do they have root or console access? Do you leave the console in the server room accessible?

I would take a look at the password utility you found. Doesn't sound familiar. Are their developers writing code on that system that runs with system privileges that could have used that utility? Could they have been writing code to change passwords and messed with the root account?

The other possibility is something that sounds strange, but I've seen it more than once. Was the root password changed recently before the problem occurred? I have seen strange behavior on Solaris 10 where I changed the root password and somehow it reverted back to the previous password. It acts as if it's only affecting a dynamic copy of the shadow file and not writing to disk and reverts back to the old password on reboot (I don't recall if a reboot occurred around the time). I've seen this 2 or 3 times.

You could implement auditing if that box needs to be secure, but you need to send audit files to another secure server or anyone that has root can altered those also.

This happened to us again on the same servers. We cannot su to root or login directly with the root password. We have been told nobody changed the password. We are awaiting an outage to boot the server into single user mode and reset the password. I feel we are going to find the password is the same and we will be able to boot into single user mode. I am still looking for some help on why this could be happening. It doesn't make sense that it will take the password in single user mode, but not in mult user mode. Any help is greatly appreciated.

If you're running Solaris 10 or higher, root may be a role, not a user
account. If it is a role, only user logins designated in
/etc/user_attr as having roles=root... will be able to su to the
super-user role, and you will not be able to login as root on the
console while the system is in multi-user mode. (The user_attr file
will show root::::type=role, among other attributes, as opposed to
type=normal, if this is the case.)