6 Replies Latest reply: Mar 20, 2012 10:00 AM by Sunny Pahuja RSS

Os Admin User Account

Jansi Rani Murugesan
Currently Being Moderated

Hello Gurus,

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.

Thanks

Jansi

  • Re: Os Admin User Account
    Sunny Pahuja
    Currently Being Moderated

    Hi,

    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.

    Thanks

    Sunny

  • Re: Os Admin User Account
    Ruchit Khushu
    Currently Being Moderated

    Hello Jansi,

    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.

    Regards.

    Ruchit Khushu. 

Actions