cancel
Showing results for 
Search instead for 
Did you mean: 

EHPI PREP_INPUT/INSTANCELIST_PRE fails on SIDADM Password

Former Member
0 Kudos

PREP_INPUT/INSTANCELIST_PRE fails with

>>>> Required system passwords <<<<

The system is running in a distributed environment. To be able to proceed, the

<SID>adm user will be utilized. Enter the password for the <SID>adm user. In

case you are using a Windows domain user, please enter the domain user

password.

SIDADM PASSWORD: ********

>>>> Required system passwords <<<<

The password is correct. Can SSH to all servers with sidadm and password entered but still fails.

Have manually typed the pwd, cut an pasted the password, tested all on each server in environment.

This is a DPF environment with partitions on multiple nodes. Also has 2 app servers as well. sidadm connects to all servers as said before both with and without password (RSA Key enabled).

Accepted Solutions (1)

Accepted Solutions (1)

sunny_pahuja2
Active Contributor
0 Kudos

Hi,

Please mention your operating system release. Your problem is documented in SAP note 1140980.

Thanks

Sunny

Former Member
0 Kudos

Currently at 5.3 but upgrading to 6.1 at the same time looking at recommendations in this note. Will see if this resolves the issue.

Thanks.

Former Member
0 Kudos

Upgrading to AIX 6.1 resolved the problem. Would have resorted to instructions in note, though, if needed.

Understood my particular problem was AIX specific. Not sure if any of this is applicable to SUN OS.

Answers (5)

Answers (5)

0 Kudos

I'm having exactly same issue when upgrading using SUM tool on Windows 2008 R2 OS. I have entered correct password but it keeps erroring out

"Error message:

OS user password does not work, please reenter: System error: Logon failure: unknown user name or bad password."

Please help,

Thanks

0 Kudos

how you solve your issue?

Former Member
0 Kudos

Thanks all for your comments,

we have resolved the issue on SunOS 5.10 with the SAP Note 992907.

The issue was caused because of the lack of read permission to the file "/etc/shadow"

Solution: execute als root the following command

setfacl -m user:adm:r,mask:r /etc/shadow

Best Regards,

José

Former Member
0 Kudos

Setting permissions on "/etc/shaddow" also resolved the issue in our environment.

SUSE Linux Enterprise Server 11 (x86_64)

VERSION = 11

PATCHLEVEL = 1

setfacl -m user:<SID>adm:r--,mask:r-- /etc/shadow

Thanks

Former Member
0 Kudos

Hi Thomas,

did you solve the problem?

We are facing exactly the same issue with an EHP4 installation but on SunOS 5.10.

We are using the lastest EHP Installer 7.0 availabe:

Patch level 58 - released today 01.02.2011

Can you give us some hints?

Thanks in advance!

Best Regards,

Jose

markus_doehr2
Active Contributor
0 Kudos

> We are facing exactly the same issue with an EHP4 installation but on SunOS 5.10.

> We are using the lastest EHP Installer 7.0 availabe:

> Patch level 58 - released today 01.02.2011

>

> Can you give us some hints?

Solaris stores passwords in /etc/shadow - which is only readable by root. Since EHPI is started by <sid>adm and there is no option to read that file and compare it with your given password. Solaris has RBAC you can create a role and add a permission for <sid>adm to read the file. An example how to do that is here: http://www.kernelthread.com/publications/security/solaris.html (check the 'ppriv' section). That would be the same as the first part of the note for AIX.

For point two you can change the permissions as stated in the note for the runtime of EHPI and change it back.

I'm sure that this issue is either because of a new Solaris release (check /etc/release) or because the method of how SAPehpi checks the password changed. I've done quite a bunch of upgrades on Solaris 10 and I've not had that problem.

Markus

Former Member
0 Kudos

Has the password got any special characters in it? EHPI doesn't like @ appearing in the password - it might be the same for others?

markus_doehr2
Active Contributor
0 Kudos

If you have checked all the latest logfiles and the OS logs (/var/log/, /var/adm/) I suggest you open an OSS call.

Markus