User cannot log in after converting to trusted system

[Kepstein]

Hi All,

I'm trying to convert a HP-UX 11.0 box to a trusted system.

Switching on trusted system mode (which I do from SAM) does not give any errors.

Once it's done though no users (including root from the console) can log in anymore. Users that are currently logged in can continue to work but no new logins are allowed.

If I revert the change back to a non-trusted system everything seems fine again.

Has anyone else had this problem and if so, what was the resolution?

Thanks.

[Calandrello]

Friend
Recommended E that you it makes one make recovery it is always good for preventing against problems. I recommend tambem that you it makes everything for SAM thus reduces the risk of problems.

[Coolmar]

It happened to me before and what the problem was the new restriction on passwords. I can't remember what the max and min characters were by default, but my users passwords didn't comply once it was trusted. I had to then go and change around the password information for all users and everything was fine.

HTH,
S.

[DCE]

one way is to have a second root window open when you do the conversion.

After the conversion use the following command to reactivate an accout (root ID used in the example

/usr/lbin/modprpw -k root

Note trusted system passwords need to 8 characters or less

[Tom Danzig]

If your password is more than 8 characters, use only the first 8 to login to the now trusted system.

untrusted systems only recognize the first 8 and the conversion to trusted will use only these 8.

[Kepstein]

Hi All,

I tried converting to a trusted system again (it's a production system - so I'm limited to when I can give it a try).

I used SAM to do the conversion. First I noticed this message when I attempted to convert.

Note: VxFS file systems do not currently support Access Control Lists (ACLs). If you currently have one or more VxFS file systems in use, these file systems will not contain ACLs after conversion to Trusted Systems.

At that point it asks wether or not I want to continue. If I say yes, it continues and then says that the conversion was successful.

After that I check my account status and I'm not deactivated. Even so - I tried the suggestion above (/usr/lbin/modprpw -k ) the error I get is:

user password file not found:

I checked to see what existed under /tcb and there are a couple subdirectories.

Anyone have any ideas?

Thanks.

[Bill Hassell]

The error that the user's password file was not found would seem to indicate that there is corruption in the original password file. The /tcb directory has many, many subdirectories. To see them all, use:

ls -R /tcb

So, before you switch to a Trusted system, run the commands: pwck and grpck, then fix any problems. NOTE: your system must not already be part of an NIS password system. And make sure your /etc/nsswitch.conf looks like this:

passwd: files
group: files
hosts: files [NOTFOUND=continue UNAVAIL=continue] dns
ipnodes: files [NOTFOUND=return] dns
networks: files
protocols: files
rpc: files
publickey: files
netgroup: files
automount: files
aliases: files
services: files

Then perform the conversion using SAM and see if the passwords are now working.

[Kepstein]

Hi Bill,

I gave pwck and grpck a try. grpck came back with nothing, pwck had 3 issues - all with system account with invalid or no home directories.

The box is not a NIS box.

Any other ideas?

[PVR]

If you have a root session, please execute the command

/usr/lbin/modprpw -k root. Reset the password of root and set a new password.

Also check the status of other users bu executing /usr/lbin/getprpw userid. This shall give lot of details about the user. You can understand from the flags that why the systemis not allowing the user to log in. Please check the man page of getprpw for more details.

You have to look lockout=0000000 option in the output of getprpw command.

Thanks
PVR

[Bill Hassell · Accepted solution]

Make sure your nsswitch.conf file does NOT have the word COMPAT in it. The simplest solution is to copy the sample file provided. Specifically, the lines:

passwd: compat
group: compat

will cause the problem where modprpw fails as described.

[Kepstein]

Bill Hassel,

You're a legend! the problem was with the nswitch.conf
After changing the entries to read "files" rather than "compat" it worked perfectly.

Thanks again!
Kevin

[Kepstein]

Bill Hassel put his finger right on the problem .