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

[Court Campbell]

What are you using to connect to the box? SSH?

The alock=NO, lockout=0000000 is telling me that the account is not locked. man getprpw to find out what the lockout fields mean.

[csreenivas]

We used to connect through telnet.

As of now its not locked but it is getting locked within few hours.

[Court Campbell]

next time the account is locked, look at the getprpw command and see what the lockout fields are. What do you mean by you didn't anything with lastb -R?

Also, what did you see in /var/adm/sulog? If the fourth filed is a - (minus sign) then that means someone had an su to a user.

ex.

SU 06/07 09:11 - 0 badboy-root

this tells me that badboy was unsuccessful as su'ing to root at 9:11 today.

[Court Campbell]

Have you thought about setting up HIDS. It's rather easy to implement. It can be setup to log unsuccessful logins and much more. Pluses are that it is a freebie and it's supported by HP.

[csreenivas]

Please find the information when the root password is locked

# /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 07:42:49 2007, sloginy=pts/ta, culogin=7, uloginy=-1, umaxlntr=-1, alock=NO, lockout=0001000

[Court Campbell]

Not that you didn't already know this, but that fourth field set to 1 in lockout means that root has exceeded unsuccessful login attempts. Again you need to look at the sulog and lastb, etc. to see who is causing the issue.

[csreenivas]

please find lastb and sulog. srinu is my userid.



# lastb
sybase pts/ta Fri Jun 1 05:32
sybase pts/ta Fri Jun 1 05:32
sybase pts/ta Fri Jun 1 03:34

/var/adm/sulog
SU 06/05 03:13 - ta srinu-root
SU 06/05 03:13 + ta srinu-rootb
SU 06/05 03:15 + ta srinu-root
SU 06/06 02:59 - ta srinu-root
SU 06/06 02:59 + ta srinu-rootb
SU 06/06 03:00 + ta srinu-root
SU 06/06 05:18 + ta srinu-root
SU 06/07 02:21 - ta srinu-root
SU 06/07 02:22 + ta srinu-rootb
SU 06/07 02:26 + ta srinu-root
SU 06/07 05:50 - ta srinu-root
SU 06/07 05:51 + ta srinu-rootb
SU 06/07 05:51 + ta srinu-root
SU 06/07 07:42 - ta srinu-root
SU 06/07 07:43 + ta srinu-rootb

[csreenivas]

Its getting enabled when I connect from rootb
(same as root) and switch to root

[John Payne_2]

Do you have something like HP SIM set up trying to connect via wbem? If you have that set up, and the wbem root pw is wrong, you would see this sort of thing.

John

[Court Campbell]

Looks like you helped lock the account

getprpw
ulogint=Thu Jun 7 07:42:49 2007

sulog
SU 06/07 07:42 - ta srinu-root

[Court Campbell]

What is your default setting for umaxlntr?

[Court Campbell]

from just 6/7 you had failed to su to root. You may be your own enemy,