Strange Occurance after Full System Restore...

[Christina Martin]

We restored a full system backup. After the backup was restored, we can not log onto the machine remotely. The message we get is that the account is disabled. However, if we log in at the console, everything is fine. If we are watching the console while logging in at a remote PC, the console shows that the user is NOT disabled. Any ideas on how to fix this or what has caused this problem?

Thanks in advance.
Lisa Taylor

[Mel Burslan]

If your backup is old enough, and the system is trusted, at the login time, login procedure makes a date comparison between the last password change date and today's date. And depending on your password aging policies, if you have exceeded the allocated available time for a password change, it will lock out the account not letting you login.

This restriction is only valid for network access. At the console, it won't hold, hence you can gain access at the console.

[A. Clay Stephenson]

I'll assume this is a trusted system. Execute /usr/lbin/getprpw user for a non-root user that is not able to login (other than on the console. Examine the "lockout" value; each non-zero digit in the lockout display has a specific meaning. Man getprpw for details. My best guess is that you have expired passwords because it has been too long since these users have logged in since the tcb database was restored from backup. You can do a /usr/lbin/modprpw -k user to reenable these accounts although this is begging for a script because you only want to reenable those account which are locked out because of expired passwords. Man modprpw for details. The script will be duck soup using a bit of awk or Perl.

[Pat Lieberg]

I'm guessing you have a trusted system and the passwd file is older than the accepted expiration period. You can reset the root password at the console, which should allow you to fix the other accounts. See the modprpw command.

[Christina Martin]

Have attempted to change the password, fix the password aging, and even untrusted the system (it's a development system) all with no effect, as I still get the 'account disabled' when trying to log in remotely.

[A. Clay Stephenson]

It's just possible that all this is caused by a stale pwgrd. Do a ps -e | grep pwgrd and kill that PID. The pwgrd daemon is not necessary. I suspect that when you untrusted the system, you had passwords longer than 8 characters. I would untrust the system again, set a users password, and try to login remotely. In an untrusted world, the ONLY way that an account is disabled is if an impossible passwd hash is in the passwd entry (by convention, a '*' is used but essentially any other non-null charactter(s) will work.)

[A. Clay Stephenson]

One other whackball thought (that applies only to trusted systems) is that /tcb/files/ttys entries no longer "fit" your existing system; ie, your pseudoterminal device nodes have changed.

[Christina Martin]

None of these solutions are working for us. We've deleted the user, added the user back and still receive the Account Deactivated notification when we try to log in. We've untrusted the system, given the user an 8 character password after killing the pwgrd service.

We're stumped.

Lisa

[Raj D.]

Hi Christina ,

Which tools are you using for remote connection to the server.

Check the proper service is enabled in /etc/inetd.conf , Do provide some more info...

Check for /etc/nologin , it will not allow ssh to login if the file is there..

cheers,
Raj.

[Christina Martin]

We are using netterm. We do not have SSH installed on this server.

securetty is not on the system.

This all started after we restored a full system backup...it did not happen when we restored the backup before this one, I just don't know what happened. Worse come to worst we're getting a new Ignite tape and backup on Thursday morning, and can restore from there, but we'd like to get this issue resolved today.

Another point. When I restored this backup, I did't have to change the identity. Meaning this backup came from a system in Louisianna...I should have had to change at a minimum the IP address and the gateway, and I didn't....so what's going on here?

Lisa

[Christina Martin]

I went ahead and submitted a call to HP for Software support and this is what the CE responded back with:

even on the same system it is not recommended to restore everything, the fbackup is used to restore the data but to reinstall a system the way to proceed is to use CORE/OS media or an ignite tape or network image, then after you restore the missing data, not the configuration files and stuff like that.


Unfortunately the option for you is to reinstall again, but this time in a proper and supported way.


Is this a true statement? This is a full system back up, taken from the exact same system that is on our machine right this moment. We are providing COOP Services for the System in Baton Rouge at the moment, they send up their backup tapes (fbackup) and we restore them onto our machine. It worked great twice...this is the only time we've had a problem.

HELP PLEASE!

Lisa

[A. Clay Stephenson]

This was actually my thought (that you did not use Ignite) but when you mentioned Ignite I thought that you were always using it. You are fortunate in that your hardware configuration was close enough that this actually produced a bootable machine. In any event, what you did is a big no-no and the only reliable way to get you back to a stable system is an Ignite. Your prior restores were working by accident.

However, you should be able to untrust your system and leave it untrusted. For a user with a known password, try to login. If that fails then explicitly set his password again. You should only see the account disabled (at least using a standard login) is there is a '*' in the password hash of this user -- or more accurately if his hash is '*'.