operating system user other than <sid>adm

When, for some reason, the default <sid>adm OS user cannot be used, the following alternatives are possible. Alternative A is best here, because a cloned user can be protected using a no-login shell and is in all aspects equivalent to the <sid>adm user. However: Alternative A is not available for the Windows operating system. For Windows, only the (sub-optimal) Alternative B can be used.

You should only consider alternative B when there is really no other option available, because some Protect4S checks on operating system level (the ones that need the OSExecute function of SAPControl) will not work.

A) Clone the <sid>adm user

1. Copy the <sid>adm user record in /etc/passwd and /etc/shadow to a new user

Copy the <sid>adm user record in both the /etc/passwd en /etc/shadow files to a new user.

2. In the /etc/passwd file, change the login shell for the new user into: /sbin/nologin and save

Cloned User

In the example above, the smdadm user record was copied to a new user called smcadm and the login shell was changed to: /sbin/nologin.

3. Change the password for the newly created user

(as root): set a new password:

> passwd <new user>

and use this new user and password to create the SAPControl connections in Protect4S.

There is no equivalent option to clone a user in Windows.

B) Use a newly created OS user

Procedure for Linux / UNIX:

1. Create new os-user

(root):

> useradd -d /home/<os-user> -g <sapsys GID> -G sapinst <os-user>

2. Set initial password

(root):

> passwd <os-user:

Set initial passwd

3. Set final passwd

(root):

> su - <os-user>

> passwd

Enter initial password first then set final password twice

4. set default shell as csh

(root):

> vi /etc/passwd

Change shell for <os-user> from /bin/bash to /bin/csh

5. Create home directory

(root):

> mkdir /home/<os-user>

> chown <os-user>:sapsys /home/<os-user>

> chmod 755 /home/<os-user>

6. Copy <sid>adm env to <os-user>

(os-user):

> cd > cp /home/<sid>adm/.* . Logout and login and check environment

7. Check & set correct permissions on sapuxuserchk executable

(root):

> cd /sapmnt/<SID>/exe/uc/linuxx86_64

> chown root:sapsys sapuxuserchk

> chmod u+s,o-rwx sapuxuserchk

Also on all local instance exe directories (DVEBMGSxx, Dxx and ASCSxx):

(root):

> cd /usr/sap/<SID>/<instance>/exe

> chown root:sapsys sapuxuserchk

> chmod u+s,o-rwx sapuxuserchk

8. Add the following 2 lines to the DEFAULT.PFL of the SAP satellite system service/protectedwebmethods = SDEFAULT

service/admin_users = <os-user>

  • On Unix : service/admin_users = user1 user2

  • On Windows: service/admin_users = domain\user1 domain\user2

and restart the SAP satellite system on a suitable moment to activate these settings

9. Re-Start SAP Control service for all instances (DVEBMGSxx, Dxx, (A)SCSxx)

(official sap-user):

> sapcontrol -nr <instance# xx> -function RestartService

10. (Re)create the SAPControl connections using the Systems menu

(Re)create the SAPControl connections in the Systems menu for the SAP satellite system in question and wait several minutes after doing so. The connection will not turn green (as is the case with the <sid>adm user), but yellow instead. This is OK. When you hover your cursor over the yellow icon it will show as:

SAPControl connection using alternative OS-user

11. Verify that SAP Control works ok

In the Systems menu for the SAP satellite system concerned, go to the System Context, and inspect the SAP Control context. It should now be filled for all instances:

SAP Control context

Procedure for Windows:

For Windows you must create a user as a member of the Groups: SAP_LocalAdmin and Users :

Windows Roles required for Protect4S satellite OS user

Next: Follow step 8-11 from the above procedure for non-windows systems.