Changing the UNIX user UID for the SAP Users sidadm and orasid

SAP System Administrator Unix User Accounts <sid>adm and ora<sid>

You may find it necessary to change the the UID of the sidadm and orasid accounts on your SAP server. The process is not difficult but there are a number of steps that must be followed for it to work correctly. The following is an outline of steps that I have followed in that past on AIX running oracle. Please note you should always test this on a test server to develop a proper procedure for your specific OS and installation. You should also confirm that you have a current backup just in case.
Lets Review The High Level Steps

  • Confirm backups are in place and current. Validate the restore procedure.
  • Review the current SAP UNIX user setup and develop list of required changes.
  • Backup the current passwd file.
  • Create a backup list of files owned by the user being changed.
  • Stop SAP System and processes owned by <sid>adm.
  • Stop Oracle and processes owned by ora<sid>.
  • Restart the server.
  • Change user UID mapping.
  • Change file ownership to new UID mapping.
  • Restart the server.
  • Restart SAP and Validate server started correctly.

Reviewing UNIX Users and Outlining Changes
First let’s review the setup of the user accounts on the server. You will find the UNIX user accounts and their corresponding UID’s in the passwd file in the /etc/ directory. Let’s review the entries for <sid>adm and ora<sid>

dx1adm:!:207:203:SAP System Administrator:/home/dx1adm:/bin/csh

oradx1:!:208:204:SAP Database Administrator:/oracle/DX1:/bin/csh

So on the DX1 instance of SAP we see the following users are setup as follows dx1adm has a UID of 207 and oradx1 has a UID of 208. In this example let say we need to change dx1adm to 307 and oradx1 to 308.
Backup the Current passwd File

# cd /etc

# cp passwd /home/xd1adm/passwd.bak

Create a Backup List of Files
In this case I am going to create 5 lists just to be safe. These lists are a snapshot of file and directory ownership before we make any change. All of the examples below are run from any directory. The backup lists are written to the /home/xd1adm.

Create a list for: /usr/sap

# ls -ltraR /usr/sap > /home/xd1adm/usr_sap_list.txt

Create a list for: /sapmnt

# ls -ltraR /sapmnt > /home/xd1adm/sapmnt_list.txt

Create a list for all files owned by: xd1adm

# find / -user 207 -exec ls -altr {} \; > /home/xd1adm/xd1adm_list.txt

/oracle/XD1 (you need to su to oraxd1)

# ls -ltraR /oracle/XD1 > /oracle/XD1/oracle_XD1_list.txt

(To put this file in the /home/xd1adm/ directory you will need to copy it there and then delete it from oraxd1 home)

Create a list for all files owned by: oraxd1

# find / -user 208 -exec ls -altr {} \; > /oracle/XD1/xd1adm_list.txt

(To put this file in the /home/xd1adm/ directory you will need to copy it there and then delete it from oraxd1 home)
Stop SAP and Processes
Now we need to stop SAP and Oracle. We need to make sure that we stop all of the processes owned by <sid>adm and ora<sid>.

To stop SAP issue the following command as <sid>adm

# stopsap

To stop the SAP OS collector issue the following command as <sid>adm

# saposcol -k

To stop the Oracle listener issue the following command as ora<sid>

# lsnrctl stop

Restart The Server
This is just to be safe. (Please make sure that you don’t have SAP and Oracle setup to automatically start in your start scripts)
Change The UID for <sid>adm and ora<sid>
In this example we will use smitty to make this change. You will want to be root on the server.

# smitty

200907282002.jpg

200907282002.jpg

200907282003.jpg

In this case we will select the <sid>adm account

200907282003.jpg

200907282004.jpg

Change the User ID field from 207 to 307 and save your change. Repeat this process for the ora<sid> account.
Change File Ownership to New UID’s for <sid>adm and ora<sid>
In order to run this next command you will need to be root on the server.

Change the <sid>adm file ownership to the new UID

The following command will change the owner of all files that are owned by UID 207, the old <sid>adm UID, on a server to the new <sid>adm UID 307.

# find /! (proc | backup) -user 207 -exec chown 307 {} \;

The following command will change the owner of all the symbolic links that are owned by UID 207, the old <sid>adm UID, on a server to the new <sid>adm UID 307.

# find /! (proc | backup) -user 207 -exec chown -h 307 {} \;

You can verify that the ownership on all the files has been changed from 207 to 307 by running the following command. It should not return any results.

# find / -user 207 -exec ls -altr {} \; > /home/xd1adm/xd1adm_list.txt

Change the ora<sid> file ownership to the new UID
The following command will change the owner of all files that are owned by UID 208, the old ora<sid> UID, on a server to the new ora<sid> UID 308.

# find /! (proc | backup) -user 208 -exec chown 308 {} \;

The following command will change the owner of all the symbolic links that are owned by UID 208, the old ora<sid> UID, on a server to the new ora<sid> UID 308.

# find /! (proc | backup) -user 208 -exec chown -h 308 {} \;

You can verify that the ownership on all the files has been changed from 208 to 308 by running the following command. It should not return any results.

# find / -user 208 -exec ls -altr {} \; > /home/xd1adm/xd1adm_list.txt

Restart The Server
This is just to be safe.
Restart SAP Instance
Restart the Oracle Listener issue the following command as ora<sid>

# lsnrctl stop

Restart SAP issue the following command as <sid>adm

# startsap

Confirm you SAP instance has started correctly. I would also check the SAP startup log as well as transaction SM21 to see if there where any issues with starting the instance after making these changes. If you have issues with restarting you instance you can troubleshoot the issue from the startup logs and you also have the backup lists of the directories that show what the system looked like before you made any changes. Again make sure you test this procedure for your environment in a system it like a sandbox, before you implement on any productive instances.

About Tim Yates

Tim is the Co-Founder and CEO of DataXstream, LLC, a U.S. headquartered, multi-million dollar SAP consulting firm that specializes in delivering solutions for SAP Retail, Virtualization, Project Management, Integration and Infrastructure Technology, and SAP-related Third Party Product Development.

Tim is also one of DataXstream's senior SAP consultants, specializing in SAP Project Management and Systems Architecture. Tim has over 15 years SAP system design, development, configuration, architecture, and project management experience. He has a broad range of hands on experience in SAP with the ability to do the detailed technical, functional work, lead a team, or program.

Tim has had significant exposure to multiple industry verticles, working on successful SAP projects for companies such as Lumber Liquidators, Siemens Automotive, Lumber Liquidators, PSS World Medical, ICW, United Launch Alliance, Mercury Marine, SAP America, Eli Lilly & Company, and Verizon.

Add Comment Register



Speak Your Mind

*