Operating system user other than <sid>adm
Last updated
Last updated
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 VM checks on operating system level (the ones that need the OSExecute function of SAPControl) will not work.
Copy the <sid>adm user record in both the /etc/passwd and /etc/shadow files to a new 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 (to prevent user logon).
(as root): set a new password:
> passwd <new user>
Next: Follow step 8-11 from the below procedure and use this new user and password to create the SAPControl connections in the Protect4S system.
There is no equivalent option to clone a user in Windows.
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.
(root):
> vi /etc/passwd
Change shell for <os-user> from /bin/bash to /bin/csh to allow user logon.
Change shell for <os-user> from /bin/bash to /sbin/nologin to prevent user logon.
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 and 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
For SAP HANA Databases also do the above for the HDB executable directory (e.g. /usr/sap/<HANA SID>/SYS/exe/hdb).
Documentation from SAP can be found in SAP note 927637.
**** 8. Add the following 2 lines to the DEFAULT.PFL of the SAP satellite system (and also for the ASCS instance profile and HANA DB instance if applicable)
service/protectedwebmethods = SDEFAULT
service/admin_users = <os-user>
On Unix : service/admin_users = **<**user1> <user2>
On Windows: service/admin_users = domain\<user1> domain\<user2>
where <user1> is the normal <sid>adm user and <user2> is the user that was created, separated by space.
For HANA Databases do the above in the DEFAULT.PFL in directory /usr/sap/<HANA SID>/SYS/profile
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:
11. Verify that SAPControl works ok
In the Systems menu for the SAP satellite system concerned, go to the System Context, and inspect the SAPControl context. It should now be filled for all instances:
Procedure for Windows:
For Windows you must create a user as a member of the Groups: SAP_LocalAdmin and Users:
Next: Follow step 8-11 from the above procedure for non-windows systems.
