cancel
Showing results for 
Search instead for 
Did you mean: 

<sapsid>adm has no access to "dba" group

Former Member
0 Kudos

My client, a LARGE telecom company, has 150+ SAP instances and is in the process of moving most of them from PARISC to Itanium HP servers.

As part of the replatforming effort, we have to create <sapsid>adm ids on the new servers. As per SAP installation Manuals, <sapsid>adm should have "sapsys" as primary and "dba" as secondary group. The Basis, DBA and SA support functions are performed by different work groups and due to SOX and other internal security policies, the DBA groups feels it is against "separation of duties", etc, to have someone other than DBAs have access to the "dba" group and is unwilling to approve "dba" as secondary group for <sapsid>adm. The Basis Admins feel that the failure to allow access to "dba" will negatively impact our ability to perform our Basis support activities, For example: unable to start & stop the database when using start|stopsap scripts; inability to perform any activity that uses sapinst (as sapinst checks for existence of <sapsid>adm and its membership of "sapsys" and "dba" groups; probably some of the database related transactions within the SAP gui, etc).

Have any other Basis Admins run across these SOX restrictions? How are they handled in other companies? What other impacts could the failure to have access to the "dba" group have?

Sharing of Any experiences in this area would be greatly appreciated.

Alex

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi...

Check the entries in the file /etc/group

by changing entries against dba, we can manage that,

by default it is

dba::107:<sapsid>adm,ora<sid>

by changing the entries, rotein activities will be effected, but will have good controls.

Cheers

KHS

Former Member
0 Kudos

Hi Alex,

Making the user <SID>adm as part of the group "dba" as secondary is the SAP Standard installation configuration. Indeed sometimes the internal Security policies of the organizations do make some restrictions for the "Segregation of duties" part due to which user configurations need to be different at the OS level. SAP do have a solution for that.

Now there can be 3 scenarios and you have to identify which scenario you want to implement-

1. SAP standard configuration where an operator has full privilege for DB administration.

2. An operator is authorized to backup the DB and also to start/shut down the DB but restricted privileges to modify the data.

3. Only authorized DBA operators are allowed to execute BR*Tools operations. Such users have

no other database access rights.

Please refer to the below link for more details-

http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/9e626b1c-0d01-0010-b2ba-cfa2443c1...

Additonally you can also refer to the SAP note 832662.

Regards

Sourabh Majumdar