Unable to change root password succesfully

[Nick Wickens]

I can't get any searches on the forums to work so sorry if this has been done before. This morning I converted an 11i installation to "trusted" status and changed some system security policies. Since then I have been unable to login as root via telnet or console. Fortunatly I have still got an X windows session logged in so I have disabled all of the security settings to no avail. I have also changed the root password but still I can't login and I am of course very loathe to logout of the Windows session. There is no securetty file in exitence so its not that.

[David_246]

Hi,

Please look at the /var/adm/syslog/syslog.log and for the /var/adm/wtmp and btmp(last and lastb commands) Did root actualy log in ??

Look at the structure of /tcb/files/auth, did root join in the migration ??

run a telnet from remote, after that a "ps -ef | grep telnet" on the local machine. And then a tusc -p .
Ones logging in you should get all C-calls so the error should be resolvable.

Regs David

[Pete Randall]

Nick,

Try this:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xa75535a43b46d71190080090279cd0f9,00.html
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x5bfd5f260cafd4118fef0090279cd0f9,00.html

(search works on this side of the pond!?)


Pete

Forgive me if this is a duplicate, the first attempt 404'd on me.

[Michael Elleby III_1]

Hello-

This one is easy if you have a recent backup of your 'trusted' system. On all my trusted systems I try to keep a recent backup of the root file system which includes the /tcb directory.

In addition, on my all of my systems (trusted or non-trusted), I have a unix workstation on my desk where I maintain a root login for just this occasion, as well as other administrative tasks.

Restore the file /tcb/files/auth/r/root from backup and your root account is restored. Voila! Well, hopefully you remember what the root password was when the backup was completed.

Mike-

[S.K. Chan · Accepted solution]

My suspicion is the /etc/nsswitch.conf file especially the "passwd" line. It should look like this ..
passwd: files
If it's not, change it ..

[Michael Elleby III_1]

Hello, disregard my last answer, I re-read your initial post...

I would suggest you first try to untrust your system by running tsconvert -r...

If this does not work, then reboot you system to single user mode, run tsconvert -r and reset your system password, then retrust (tsconvert) and reboot the server once more..

Mike-

[Darren Prior]

Hi Nick,

An authck -pv will verify the health of your /tcb structure and /etc/passwd. Can you post the /tcb/files/auth/r/root file so we can see if there's still anything strange in there - we can also decode the login times.

Is there anything unusual in /tcb/files/devassign or /tcb/files/ttys?

regards,

Darren.

[Stuart Abramson_2]

Bring up sam and check the status of the root passwd. It may have become "deactivated". If so, reactivate it.

You can also vi /tcb/auth/files/r/root entry to set an encoded password field (one you know) and a status, and expiration field, etc. It's tricky/dangerous, but you're already in trouble here.

[Zigor Buruaga]

Hi,

Maybe a problem in the passwd length?
If you have changed that option in Security Policies, try using the first 8 characters of your root passwd.
If this not helps, use SAM to view the Security Policies of root user, maybe you can find something wrong.
Or unconvert the system, change the passwd ( only 8 characters ), reconvert again the trusted system and try again.
Is there any other user with the same problem?

Regards,
Zigor

[Nick Wickens]

Thanks people !!

S K Chan got nearest - This system was initially set up as a NIS client which was then backed out but the /etc/nsswitch entry was still trying to point to the non-existent NIS master.

Turning off the "trusted" side of things then got me back in.

Much appreciated.