Recently we done the solman 7.1 installation in one server, we created sid adm, dbsid adm are local admin users. system is working fine.
now as per the my organization policy we should nt create the local users in the servers, hence from the OS team we are under the pressure to delete the local admin users.
we already insisted them we cant delete the users, else our installation wont work
But they are stick to the rules requesting to delete the users, please guide us if we delete the sid adm account then my system will work or not?
if not then what is the alternative solution for this situvation, any posiblity to migrate sid adm account to service account. Please advise.
You cannot delete <sid>adm and SAPservice<sid> users as they are SAP admin users.
In order to follow company policy, you can install your solution manager system as domain installation so that all the users will be created on domain.
But there you need to take care of user sapadm (this user is used as host agent). So, if you have any system on domain. So, sapadm user will be existing on domain and you should have credentials of this user to do the installation.
Yes You can delete, But before that create domain User ID's same as Local User ID's . Then go to all the services related the SAP. Then change the log on user for these services to those particular domain users. For Example if your os is Windows then go to services by executing command Services.msc then go to saposcol.exe. Click on to Log on Tab, then select this user and Put Domain\user. Then put the users password. Restart the service. I think it will work.
Since you have mentioned dbsid it looks like it is an Unix installation since dbsid users normally won't exist on Windows (atleast for Oracle & MS-SQL unless explicitily created and used). SO my answer is assuming Unix.
If that is the case and we are not talking of a scenario where these user id in Unix needs to made part of a Windows Company domain (NT domain) (which would involve SAMBA's usage) then I think what your OS colleagues are suggesting is to delete these users ids at local OS level and create it at the organization wide user database for Unix systems. This would give these user ids a new UID (would be a unique UID across systems) plus would also allow the OS admin to enforce company guidelines.
Shouldn't be a massive issue if done sensibly. UID would get changed and hence there will be issues with file permissions. So the OS team needs to ensure that your permissions are reverted to what is required inspite of UID and GID change. This would definitely involve a downtime.Further from your end you need to analyze all the file system (SAP,Oracle,Interface,Home directories) that would be affected. Cronjobs (if any BRTools jobs) also need to be reviewed. I think if Unix folks want the change they must cooperate with you and ensure the status quo is maintained even if the users are re-created.
If it is Windows it is going be a big headache. It drills down at registry level (Example :-> AdmUser key)and often is a painful process.In that case rebuilding with an offline backup would be a sensible option as suggested already by others though if you are good with registry you might be able to pull most of it off. Apart from registry user groups would have be changed and still no guarantees that it would click.SAP services logon user also would have to be changed.