Root password is disabling continuously

[csreenivas]

When i tried to connect our server remotely it is showing the below message.
-------------------
login: root
Password:
Account is disabled - see Account Administrator

Wait for login exit: ..
Connection closed by foreign host.
--------------------------------------------
When i tried to connect our server remotely it is showing the below message.
-------------------
login: root
Password:
Account is disabled - see Account Administrator

Wait for login exit: ..
Connection closed by foreign host.
---------------------

# /usr/lbin/modprpw -k root

I am able to enable with the above command with rootb(same as root)but after next day its again disabled.The server is located at some other location.


Can you suggest me the permanent solution.

[Steven E. Protter · Accepted solution]

Shalom,

You have posted to Linux. oops. This is an HP-UX problem.

I'm guessing because my crystal ball is working that you have a trusted system and the number of bad logins to disable the root account is the default, three.

Your root account is being disabled due to bad logins.

lastb

Find the source of the bad logins and stop it.

You may need to use a firewall to stop the bad logins. A console login will re-enable the root account.

SEP

[Tony Berry]

As usual, SEP is completely correct. HP-UX Trusted Mode et. al.

I wanted to respond to make a suggestion. Since we are running all our HP-UX systems in Trusted Mode, I saw this event quite frequently. All though we tracked down various services and such attempting root login, it persisted and was becoming a real problem. If you can't log in as root, you could have a serious problem, especially with a headless system. Our biggest production systems all have consoles and all of our systems have network connected GSP's, so it may not seem like much of an issue. We gave the few administrators SUDO access to the 'modprpw' command, but we ended up turning the "lock after x attempts" off for root user. We have other security provisions in place (firewall (hard and soft), TCP Wrappers, etc.) to keep malicious users at bay. We felt the small risk is worth the larger risk of having root locked out of the system.

[Court Campbell]

Side note:

Trusted systems is being weeded out by HP. You should look into installing SMSE. You need to be running 11iv2 or later in order to install/use the product. It's probably already installed by default on 11iv3. You can download it from http://software.hp.com.

[Steven E. Protter]

Shalom,

It is not unreasonable to set a limit of 3 logins before disabling root.

If its an actual person, then you really don't want to give them extra chances to hack your system. True Trusted system is going away but that is no reason to lower security if you don't want to.

Suspects:
1) Cron scripts from other systems. Should show up in /var/adm/syslog/syslog.log
2) cron scripts on this system from non-root users.
3) Actual users.

Make sure inetd -l is run for enhanced logging.

This commonly occurs in Internet exposed systems. Can you post your lastb output? That might help track this down.

SEP

[skt_skt]

You may increase the the number of bad login atempt to 5. Check for any scripts whihc runs/executes from a remote server(me:-g main/infrastructer server from where we push some thing to all other nodes.

[Court Campbell]

Look at

# lastb -R

this should give you a good idea of where to start looking. You can then know if the logins are local or remote. Also look at /var/adm/sulog. You can see who is trying to su to root. Just a couple of places to start.

[csreenivas]

I didnt see anything special in lastb -R and /var/adm/sulog.
I guess this is because of password expiry and I executed the below command.

/usr/lbin/modprpw -m mintm=0 root

[csreenivas]

Again it is showing as Account disabled.
I didnt see anything in lastb -R
I guess it is not because of failure logins.

Do we get something with the below information?
#/usr/lbin/getprpw root
uid=0, bootpw=YES, audid=0, audflg=1, mintm=0, maxpwln=-1, exptm=-1, lftm=-1, spwchg=Tue May 29 14:53:37 2007, upwchg=-1, acctexp=-1, llog=-1, expwarn=0, usrpick=DFT, syspnpw=DFT, rstrpw=DFT, nullpw=DFT, admnum=-1, syschpw=DFT, sysltpw=DFT, timeod=-1, slogint=Thu Jun 7 05:51:30 2007, ulogint=Thu Jun 7 05:50:44 2007, sloginy=pts/ta, culogin=-1, uloginy=-1, umaxlntr=-1, alock=NO, lockout=0000000

[Steven E. Protter]

Shalom,

I think I have an idea. We had a user in Chicago, my department head whose user kept mysteriously expiring, well before the expiration date.

Seems that the trusted system rules for this user and only this user were wrong.

I had to use same to open up the user and found something stupid like the aging policy was set to 7 days or something like that. I've had similar stuff happen to root because there is a data conversion involving trusted systems and its very good, but not perfect.

Take a look at the root user security setting in sam, you may find something.

SEP