Database Security

Make sure that you take all relevant security precautions for your Oracle database. For more information on Oracle database security with your SAP system, see: Oracle Under UNIX Oracle Under Windows

You also need to take security precautions at operating system level. For more information, see: SAP documentation on operating system security with the SAP system: SAP System Security Under UNIX/LINUX SAP System Security Under Windows

The documentation provided by your operating system vendor For example, for more information about operating system security on Microsoft Windows, see: www.microsoft.com/security

Oracle Under UNIX

Here we describe the measures that you need to take on UNIX when your database is Oracle. Protecting the Database Standard Users The OPS$ Mechanism Under UNIX Protecting the SAP Database User Changing the Passwords for <sapsid>adm and ora<dbsid> Access Privileges for Database-Related Resources Setting Access Privileges for Files and Directories Access Privileges for BR*Tools Additional Information on Oracle with UNIX

Protecting the Database Standard Users

The table below shows the users for which you should change passwords and how to do it. Changing the Passwords for Oracle Standard Users User <sapsid>adm ora<dbsid> SYS (internal) SYSTEM SAPR3 / SAP<SAPSID> Type Operating system user Operating system user Database user Database user Database user (SAP System) How to Change the Password UNIX command passwd UNIX command passwd BRCONNECT, SQLPLUS BRCONNECT, SQLPLUS BRCONNECT or the OPS$ mechanism

For more information about how to protect these users, see the following topics:

The OPS$ Mechanism Under UNIX Protecting the SAP Database User Changing Password for Database Users Using BRCONNECT Changing the Passwords for <sapsid>adm and ora<dbsid>

The OPS$ Mechanism Under UNIX

For the database, the SAP System is a single user, SAPR3 / SAP<SAPSID>, whose password is stored in the table SAPUSER. Therefore, to access the database, the SAP System uses a mechanism called the OPS$ mechanism, which works as follows:
...

1.

When the system accesses the database, it first logs on to the database as the user OPS$<operating_system_user>, for example,OPS$<SAPSID>adm. (The OPS$ user that corresponds to the operating system user must be defined in the database and identified as externally.) It retrieves the password for SAPR3from the SAPUSER table. It then logs on to the database as the user SAPR3.

2. 3.

Protecting the SAP Database User

Take the following precautions to protect SAPR3 / SAP<SAPSID> and prevent unauthorized access to the database: The password for SAPR3 / SAP<SAPSID> is stored in the SAPUSER table. Therefore, you should protect access to this table by changing the password for<sapsid>adm regularly. To prevent someone from working around the OPS$ mechanism by using an .rhosts file, deactivate the UNIX service rlogin in the inetd.conf file.

In a distributed system, the client is responsible for the authorization checks for the operating system user <sapsid>adm. Therefore, make sure that only authorized persons have access to PC clients that directly access the database server.

Do not change the value of the Oracle parameter REMOTE_OS_AUTHENT to FALSE. The OPS$ mechanism needs to be able to work from remote clients for example, SAP System work processes need to be able to log on to the application servers as the user OPS$<sapsid>adm. Therefore, keep this parameter set to TRUE. With the Oracle network protocol SQL*Net, you can also use the file sqlnet.ora to restrict access to the database using IP addresses. In this file, you specify invited and excluded IP addresses. For example: tcp.validnode_checking = yes tcp.invited_nodes = (139.185.5.73, ...) or: tcp.excluded_nodes = (139.185.6.71, ...) In this way, you can make sure that only specific hosts (for example, only the application server host) are capable of accessing the database.

Changing Passwords for Database Users with BRCONNECT

Use
You can use BRCONNECT to change the passwords for the database users SAP<SCHEMAID> or SYSTEM. By using BRCONNECT, you will have the password for SAP<SCHEMAID> encrypted before storing it in the database.

Procedure
Use one of the following methods to change the passwords with BRCONNECT:

Changing the Password with BRCONNECT Interactively

...

1. 2.

Start BRCONNECT with the command: brconnect [-u system/<system_password>] f chpass u <user_name> Enter the new password twice for confirmation.

When you change the password interactively, on some platforms you can enter the new password hidden, as long as it is no longer than eight characters.

Changing the Password by Using the Command Line

Enter the following command: brconnect [-u system/<system_password>] c f chpass u <user_name> p <new_password> Where: <system_password> is the password of the SYSTEM database user. You can use another user with DBA privileges. <user_name> is the database user for which the password should be changed (for example, SAP<SCHEMAID>). <new_password> is the new password for the user.

If you omit the -u option, then the logon occurs using SYSTEM with its default password.

Changing the Passwords for <sapsid>adm and ora<dbsid>

To change the passwords for <sapsid>adm and ora<dbsid>:
...

1. 2.

Log on as user <sapsid>adm. Enter the passwd command at the UNIX prompt.

3. Enter the old and new passwords. Repeat steps 1 to 3 for the user ora<dbsid>.

If you use Network Information Service (NIS), you should also refer to the NIS guide and the operating system documentation. (Changing the password with an activated NIS may be different from changing it with passwd.)

Access Privileges for Database-Related Resources

We recommend that you restrict the UNIX file and directory access privileges as shown in the table below. For more information, see Setting Access Privileges for Files and Directories.

The access rights as shown in the table below are automatically set in the installation procedures. Setting Access Privileges for Oracle Directories and Files Oracle Directory or File Access Privilege in Octal Form 4.x 755 755 640 755 640 755 755 755 755 755 755 755 755 640 755 640 755 640 Owner Group Comment

/oracle/<DBSID>/sapdata* /oracle/<DBSID>/sapdata*/* /oracle/<DBSID>/sapdata*/*/* /oracle/<DBSID>/oraarch /oracle/<DBSID>/oraarch/* /oracle/<DBSID>/saparch /oracle/<DBSID>/sapreorg /oracle/<DBSID>/sapbackup /oracle/<DBSID>/dbs /oracle/<DBSID>/sapcheck /oracle/<DBSID>/sapstat /oracle/<DBSID>/saptrace /oracle/<DBSID>/saptrace/* /oracle/<DBSID>/saptrace/*/* /oracle/<DBSID>/origlog* /oracle/<DBSID>/origlog*/* /oracle/<DBSID>/mirrlog* /oracle/<DBSID>/mirrlog*/*

ora<dbsid> ora<dbsid> ora<dbsid> ora<dbsid> ora<dbsid> ora<dbsid> ora<dbsid> ora<dbsid> ora<dbsid> ora<dbsid> ora<dbsid> ora<dbsid> ora<dbsid> ora<dbsid> ora<dbsid> ora<dbsid> ora<dbsid> ora<dbsid>

dba dba dba dba dba dba dba dba dba dba dba dba dba dba dba dba dba dba Redo log directories Redo log files Redo log directories Redo log files Archive files Data files

Setting Access Privileges for Files and Directories

Saving Current Settings
Before changing the access privileges, we advise you to save your current settings. Enter the following commands: cd /oracle/<DBSID> ls -lR > oracle_perm.txt cd /usr/sap ls -lR > sap_perm.txt cd /sapmnt ls -lR > sap_sw.txt

Setting Access Privileges

To change the access privileges for a file or directory use the chmod command as shown below:

Do not use chmod recursively. It is very easy to make unintended changes to authorizations when doing so. chmod <access privileges in octal> <file or directory>

chmod 755 /oracle/<DBSID>/sapdata* chmod 755 /oracle/<DBSID>/sapdata*/* chmod 640 /oracle/<DBSID>/sapdata*/*/* .

Access Privileges for BR*Tools

If you use the DBA Planning Calendar in the Computing Center Management System (CCMS), which uses the BR*Tools, then note the following: Assign ora<dbsid> and <sapsid>adm to the groups dba and oper. BRBACKUP then logs on with connect / as sysoper. The group oper (DB role: SYSOPER) is an administrator group that is restricted to operator operations. oper can start or shut down the database, perform backups, and so on, but has no read or write authorizations. BRBACKUP and BRARCHIVE must also have full access to the SAP tables SDBAD, SDBAH and tables defined in the XDB interface. These access rights are contained in the database role SAPDBA. BRCONNECT only executes from CCMS when the database is open. Thereby, the appropriate database privileges are necessary for the following BRCONNECT operations: -f stats, -f next, -f cleantup, -f check BRCONNECT must have write permissions to the following tables: SDBAD, SDBAH, DBSTATC, DBSTATTORA, DBSTATHORA, DBSTATIORA, DBSTAIHORA, and other DBA* tables. These access rights are also contained in the SAPDBA role. In addition, BRBACKUP, BRARCHIVE, BRCONNECT, and BRTOOLS need to run under the user ora<dbsid>. If you start these tools from the SAP System (or over the command line with the user <sapsid>adm), then you must first set the SUID bit for these programs. This

allows <sapsid>adm to run the programs using the rights from ora<dbsid>. Make sure the owner of these programs is ora<dbsid> and set their access rights to 4775. (See SAP Note 8523.)

The owner for BRRESTORE, BRRECOVER, and BRSPACE is <dbsid>adm and its access rights are 755.

Additional Information on Oracle Under UNIX

SAP Database Guide: Oracle for database administration with an SAP system on SAP Service Marketplace at: service.sap.com/dbaora Media Library General SAP Notes on SAP Service Marketplace at service.sap.com/notes:

8523: DB backups using CCMS do not work 27928: Consequences in transport during password change 319211: Problems with CHDPASS under Oracle >= 8.0.6

Installation documentation <SAP Component> on UNIX: Oracle on SAP Service Marketplace at: service.sap.com/instguides <SAP Component> Release

Oracle on Windows
The following list provides an overview of the sections that describe the security measures to take on Windows when your database is Oracle: Protecting the Database Standard Users The OPS$ Mechanism on Windows Protecting the SAP Database User Changing Passwords for SAP Database Users with BRCONNECT Apply Security Settings for Database-Related File System Resources Access Privileges for BR*Tools

For general information about Windows operating system security, see http://www.microsoft.com/security For additional information about the Oracle database administration, see the database administration guide SAP Database Guide: Oracle on SDN: http:// www.sdn.sap.com/irj/sdn/ora

Protecting the Database Standard Users

The table below shows the standard users for which you should change passwords and the method used. Oracle Standard Users and Method to Change Passwords User Type Method Used to Change the Password

<sapsid>adm OPS$<domain>\<sapsid>adm OPS$<computer>\<sapsid>adm SAPService<SAPSID> OPS$<domain>\SAPService<SAPSID> OPS$<computer>\SAPService<SAPSID> SYSTEM SAP<SCHEMAID> or SAPR3

Operating system user Database user Operating system user Database user Database user Database user (SAP ABAP system) Database user (SAP Java system)

Standard Windows method OPS$ mechanism Standard Windows method OPS$ mechanism BRCONNECT, SQLPLUS BRCONNECT, SQLPLUS

SAP<SCHEMAID>DB

BRCONNECT, SQLPLUS for database user configtool for secure store

With SAP releases prior to 4.6C the database user SAPR3 was used instead of SAP<SAPSID>. Upgrades to current SAP releases do not change the database user name.

Note that if you change the passwords for <sapsid>adm and SAPService<SAPSID>, you also have to change the passwords of all services and batch jobs started with the Windows Scheduler that use these users. For more information about how to protect these users, see the following sections: The OPS$ Mechanism on Windows Protecting the SAP Database User Changing Passwords for SAP Database Users with BRCONNECT

The OPS$ Mechanism on Windows

For the database, the SAP system is a single user, SAP<SAPSCHEMAID>, or SAPR3 whose password is stored in the table SAPUSER. Therefore, to access the database, the SAP system uses a mechanism called the OPS$ mechanism, which works as follows:
...

1.

When the SAP system accesses the database, it first logs on to the database as user OPS$<operating_system_user>, for example, OPS$<domain>\<sapsid>adm. (The OPS$ user that corresponds to the operating system user must be defined in the database and identified as externally.)

SAP does not support changes of the Oracle parameter os_authent_prefix whose default value is OPS$. The os_authent_prefix is automatically set to O$ if the resulting string (OPS$<osusername> has more than 30 characters). 2. 3. It retrieves the password for SAP<SAPSCHEMAID> or SAPR3 from the SAPUSER table. It then logs on to the database as the user SAP<SAPSCHEMAID> or SAPR3.

Protecting the SAP Database User

To protect access to the SAPUSER table and the SAP database user SAP<SAPSID>, or SAPR3 you must do the following: Change the passwords for SAP<SAPSID> or SAPR3, and <sapsid>adm regularly. Only define OPS$ users for the Windows users that are necessary for operating the SAP system. These are typically the users SAPService<SAPSID> and<sapsid>adm; however, you may assign them other names. (In this guide, we refer to SAPService<SAPSID> and <sapsid>adm.) For more information about creating OPS$ users on Windows, see SAP Note 50088. With the Oracle network protocol SQL*Net, you can also use the file sqlnet.ora to restrict access to the database using IP addresses. In this file, you specify invited and excluded IP addresses. In this way, you can make sure that only specific hosts (for example, only the application server host) can access the database. Example: tcp.validnode_checking = yes tcp.invited_nodes = (139.185.5.73, ...) or: tcp.excluded_nodes = (139.185.6.71, ...) See also: Changing Passwords for Database Users with BRCONNECT

Changing Passwords for Database Users with BRCONNECT

Use
You can use BRCONNECT to change the passwords for the database users SAP<SCHEMAID> or SYSTEM. By using BRCONNECT, you will have the password for SAP<SCHEMAID> encrypted before storing it in the database.

Procedure
Use one of the following methods to change the passwords with BRCONNECT:

Changing the Password with BRCONNECT Interactively

...

1. 2.

Start BRCONNECT with the command: brconnect [-u system/<system_password>] f chpass u <user_name> Enter the new password twice for confirmation.

When you change the password interactively, on some platforms you can enter the new password hidden, as long as it is no longer than eight characters.

Changing the Password by Using the Command Line

Enter the following command: brconnect [-u system/<system_password>] c f chpass u <user_name> p <new_password>

Where: <system_password> is the password of the SYSTEM database user. You can use another user with DBA privileges. <user_name> is the database user for which the password should be changed (for example, SAP<SCHEMAID>). <new_password> is the new password for the user.

If you omit the -u option, then the logon occurs using SYSTEM with its default password.

Apply Security Settings for Database-Related File System Resources

Use
On Windows, you should protect all data files, all executable files, all Oracle files, and all SAP system files. The following table below shows the Oracle files and the corresponding access rights: Access Privileges for Oracle Directories and Files Oracle Directories %ORACLE_HOME% Access Privilege Full Control For User or Group SYSTEM, Administrators, SAP_<SAPSID>_GlobalAdmin (domain installation), SAP_<SAPSID>_LocalAdmin (local installation) <drive>:\oracle\<dbsid> Full Control SYSTEM, Administrators, SAP_<SAPSID>_GlobalAdmin (domain installation), SAP_<SAPSID>_LocalAdmin (local installation)

Procedure
For all Oracle directories and the ORACLE_HOME set the security settings for the built-in accounts and groups SYSTEM, Administrators,SAP_<SAPSID>_GlobalAdmin (domain installation), and SAP_<SAPSID>_LocalAdmin (local installation) as follows:
...

1. 2. 3. 4.

In the Windows Explorer, right-click the Oracle root directory and choose Properties. On the Security tab, choose Advanced. Deselect Allow inheritable permissions from the paren t... In the upcoming dialog, choose Copy, to copy the permission entries that were previously applied from the parent to this object. 5. Choose OK.

6.

Set the permissions for the above-mentioned accounts SYSTEM, Administrators, SAP_<DBSID>_GlobalAdmin, or SAP_<DBSID>_LocalAdminto Full Control. Delete all other accounts.

7.

Access Privileges for BR*Tools

If you use the DBA Planning Calendar, which uses the BR*Tools, the following applies: Assign <sapsid>admand SAPService<SAPSID> to the local groups ORA_<DBSID>_DBAand ORA_<DBSID>_OPER. BRBACKUP then logs on usingconnect / as sysoper. The group ORA_<DBSID>_OPER(DB role: SYSOPER) is an administrator group that is restricted to operator operations. ORA_<DBSID>_OPERcan start or shut down the database, perform backups, etc., but has no read or write authorizations. BRBACKUP and BRARCHIVE must also have full access to the SAP tables SDBAD, SDBAH and tables defined in the XDB interface. These access rights are contained in the database role SAPDBA. BRCONNECT only executes from CCMS when the database is open. Appropriate database privileges are necessary for the following BRCONNECT operations: -f stats, -f next, -f cleanup, -f check BRCONNECT must have write permissions to the following tables: SDBAD, SDBAH, DBSTATC, DBSTATTORA, DBSTATHORA, DBSTATIORA, DBSTAIHORA, and other DBA* tables. These access rights are also contained inSAPDBA role. If database backup and archive log backups are to run directly to locally attached tape drives (not using 3rd party backup solutions) the userSAPService<SAPSID> must be a member of the local Backup Operators group.

SAP System Security Under UNIX/LINUX

In the following topics, we cover the aspects pertaining to security under the UNIX or LINUX operating systems. When appropriate, we include our recommendations and any measures that you need to take. Protecting Specific Properties, Files and Services Protected SAP System Directory Structures Under UNIX/LINUX Setting Access Privileges for SAP System Directories Under UNIX/LINUX Additional Information on UNIX/LINUX Security

The most important recommendation for securing your system at the operating system level is to keep your operating system up to date! Stay informed and install any securityrelated patches that are released by your operating system vendor.

Protecting Specific Properties, Files and Services

There are certain precautions to take when using any of the following properties, files or services: SUID/SGID programs The SUID/SGID property gives programs extended privileges that exceed the privileges possessed by the caller. Every UNIX system contains a large number of these programs for administrative purposes. These programs may contain known errors that unauthorized users may be able to take advantage of in order to assign new access rights to themselves. For example, the SENDMAILprogram is such a SUID program. We suggest that you only use versions of SENDMAIL (or similar SUID programs) in which known errors have been corrected. Password file (passwd) Although UNIX hashes passwords before storing them in this file, a user could use a dictionaryattack program to discover password information contained in this file. You can improve security by using a shadow password file that allows only the user root to access the password information. BSD services rlogin and remsh/rsh, These services permit remote access to UNIX machines. At logon, the files /etc/host.equiv and $HOME/.rhosts are checked. If either of these files contains the hostname or the IP address of the connection originator or a wildcard character (+), then the user can log on without having to supply a password. You should be aware that the UNIX services for rlogin and remsh/rsh are especially dangerous in regard to security. We recommend you deactivate these services in the inetd.conffile unless you need them for specific purposes. Services such as Network Information System (NIS) or Network File System (NFS) You can use the Network Information System (NIS) to manage user data and passwords centrally. This service allows every UNIX machine in a local area network to read the password file using the ypcat passwd command, including shadow password files. Another service is the Network File System (NFS) service. This service makes directories available across the network. It is a service that is also frequently used in the SAP System environment to make transport and work directories accessible over the network.

There are certain security risks involved when using these services and you should take special precautions. For example, when using NFS, you should be cautious when determining which directories should be made available. Do not export directories that contain SAP data to arbitrary recipients using NFS. Export to known and "trustworthy" systems only. Be cautious when assigning write authorization for NFS paths and avoid distributing the home directories of users across NFS. X Windows There are security issues involved with the use of X Windows. Therefore, for an SAP Web AS installation, you should check and see if you need to have the corresponding X server running on an SAP application server. If not, then disable this service. Otherwise, take precautions according to your vendor to protect this service. Summary To summarize the precautions that you should take, especially pertaining to NIS, NFS and the BSD remote services, adhere to the following guidelines: Disable any services that you do not need. To ensure a safe environment when using any of these services, follow the instructions of your OS vendor. Also use tools for monitoring activities to help you detect potential misuse of these services. If you do use these services, then use them only within a secure LAN. Do not export directories that contain SAP data to arbitrary recipients using NFS. Export to "trustworthy" systems only. Protect the following users: root, <sid>adm and <db><sid>. These should be the only users that exist on your application servers and your main instance at the operating system level. After installation, you should lock <db><sid> on your application servers. For critical users, empty the .rhosts files and assign it the access rights "000". Either delete the file /etc/hosts.equiv or make sure that it is empty. Keep your operating system up to date regarding security-related patches that are released by your operating system vendor!

Protected SAP System Directory Structures Under UNIX/LINUX

For security reasons, the SAP System together with the user data is stored in a special directory structure in the operating system and is protected with defined access authorizations. The graphic below shows how the SAP System directory structure is established in the UNIX/LINUX file system: SAP System Directory Structure Under UNIX/LINUX

Setting Access Privileges for SAP System Directories Under UNIX/LINUX

We recommend that you restrict the file and directory access privileges as shown in the table below.

The access rights shown in the table below are automatically set in the installation procedures. Setting Access Privileges for SAP System Directories and Files SAP Directory or Files /sapmnt/<SID>/exe /sapmnt/<SID>/exe/saposcol /sapmnt/<SID>/global Access Privilege in Octal Form 775 4755 700 Owner <sid>adm root <sid>adm Group sapsys sapsys sapsys

/sapmnt/<SID>/profile /usr/sap/<SID> /usr/sap/<SID>/<Instance ID> /usr/sap/<SID>/<Instance ID>/* /usr/sap/<SID>/<Instance ID>/sec /usr/sap/<SID>/SYS /usr/sap/<SID>/SYS/* /usr/sap/trans /usr/sap/trans/* /usr/sap/trans/.sapconf <home directory of <sid>adm> <home directory of <sid>adm>/*

755 751 755 750 700 755 755 775 770 775 700 700 <sid>adm <sid>adm <sid>adm <sid>adm <sid>adm <sid>adm <sid>adm <sid>adm <sid>adm sapsys sapsys sapsys sapsys sapsys sapsys sapsys sapsys sapsys

UMASK
Newly created files have rights determined by UMASK definitions. An UMASK is a four digit octal number that specifies those access rights that are not to be given to newly created files. You can define UMASKS in any of several files, to include: .login .cshrc .profile /etc/profile

As with UNIX access rights, the corresponding octal positions represent user, group, and world access, and the value of the digit represents which access privileges should be removed (remove none = 0, remove write = 2, remove all = 7). You can use the UMASK to automatically restrict permissions for newly created files. For example, by defining a UMASK of 0027, you specify that all newly created files have the access rights 750.

Additional Information on UNIX/LINUX Security

Type Internet Title Cipher: Electronic Newsletter of the Technical Committee on Security and Privacy:http://www.ieeesecurity.org/cipher.html Computer Emergency Response Team (CERT):http://www.cert.org Linux security: http://www.linuxsecurity.com/

SAP System Security on Windows

The Windows security concept grant specific rights to users and groups to allow them access to administration tasks and operating system resources. For more information, see: http:// www.microsoft.com/security Windows distinguishes between local and users and groups that exist locally on a computer, and domain users and groups that exist in a domain. A domain is a group of several computers that share a common account database, which contains all information about users and computers belonging to this domain. Domains can also be organized hierarchically, which is also known as domain tree. Within each domain, you create and administer your users and groups. The following sections explain how SAP systems protect their resources: Windows Groups and Users in an SAP System Environment Protecting the Operating System Users Used in an SAP System SAP Systems in the Windows Domain Concept Security Measures When Using Windows Trusted Domains Protecting SAP System Resources Protecting Data Relevant to the SAP System Defining Start and Stop Permissions Protecting Shared Memory Protection for Dynamically-Created Files (Files Created by ABAP) Protecting Database Files Setting Rights for an Installation with Several SAP Systems

Windows Groups and Users in an SAP System Environment

Windows distinguishes between the following groups: Domain groups In a Windows domain there are domain local, domain global and universal groups. Domain groups are valid within a Windows domain, not only on one server. Therefore, we recommend that you bundle the domain users into different activity groups, depending on their tasks. The domain administrator can export these activity groups to other domains, so the respective user can access all resources needed to administer the SAP system. Although you can choose the name of the group, the standard domain global group for SAP system administrators is defined asSAP_<SAPSID>_GlobalAdmin. For more information, see the installation guide for your SAP product on Windows, which you can find on SAP Service Marketplace athttp://service.sap.com/instguides <SAP product <Release>. Local Groups Local user groups, as well as local users, exist locally on one server.

During the installation of an SAP system, user rights are assigned to local users instead of groups. For example, the user <sapsid>adm gets the user right Log on as a service. However, to simplify user administration, we recommend that you assign server resources to local groups instead of single users. You can then assign the appropriate domain users and domain groups to the local group.

Be careful when using domain controllers. If you define a local group of users, or a single local user on a domain controller, the group or user is known on all domain controllers within the domain. Therefore we do not support installing SAP systems on a domain controller. The following relationships exist between users, local groups and domain groups: A local user can only be a member of the local group. A domain user can be a member of both a local group and a domain group.

A domain group can be included in a local group. You may also export a domain group to another Windows domain. If several users need the same rights for a certain set of resources, you can create a group. You do not need to assign individual user rights to each of the files. Instead, you assign the rights to a group. Thereby, all users in the group automatically receive the rights of the group. The same applies to the users in a domain group that is itself the member of a local group. To simplify your administrative tasks, we recommend adding all Windows users to user groups that are granted the appropriate rights at the operating system level.

Protecting the Operating System Users Used in an SAP System

This section informs about the users that exist or are needed in an SAP system on Windows. It also describes some security measures to take for them.

Overview of SAP System-Related Users

User type Windows built-in users User Administrator Guest Function and Rights The local super user who has unlimited access to all local resources. A local guest account who has guest access to all local resources. The guest account is disabled on a standard Windows 2003 installation. The SAP system administrator who has unlimited access to all local resources related to SAP systems. A special user who runs the Windows services related to SAP systems. One or more special users who run database-specific Windows services or access the database resources with utility programs. Some databases also need certain users at the operating system level.

SAP system users

<sapsid>adm

SAPService<SAPSID> Database users <DBservice>

<DBuser>

Note the following: Windows automatically creates the users Administrator and Guest during the installation. You do not need them for SAP system operations. You must enable the guest account to grant non-authenticated users (that have not specified a valid user name or password) access to resources on a computer. The Windows built-in group Everyone includes authenticated users and guests. However, non-authenticated guest users only have access to resources that are secured with Everyone, if the guest account is enabled. SAP strongly recommends to keep the guest account disabled. The database users <DBservice and <DBuser> are database-specific. Their name and availability depend on the database you use.

Protecting Administrator
The Windows built-in super user Administrator has unlimited access to all Windows resources. However, the built-in user Administrator cannot access resources that are located on other computers, except when this user already exists and has the same password on these computers. The user Administrator can do the following: Create, manage, and become the owner of all data files, hard disks, and file shares. Create and manage local users and their rights.

Create and manage peripherals, kernel services, and user services. Change the user name and hide its password. Create other users for administrative tasks and limit their rights to those tasks for which they are used (for example, user administrators, backup operators or server operators).

Protecting <sapsid>adm
The <sapsid>adm user is the Windows super user for SAP system administration. This user is created during the SAP system installation process, normally as a domain user for the SAP system. This user can therefore log on to all Windows machines in the domain. The <sapsid>adm user also needs full access to all instance-specific resources for the SAP system such as files, shares, peripheral devices (for example, tape drives or printers), and network resources (for example, the SAProuter service). <sapsid>adm has an SAP instance-specific environment (variables, registry settings, group membership) that allows this user to administer the SAP system in a proper manner. Furtheron, the user is a member of the local Administrators group and has sufficient privileges during special tasks such as upgrading and administrating an SAP instance. Customer-specific created users might not have this complete environment and are therefore not supported for SAP system administration tasks. To protect this user from unauthorized access, take the following precautions: Change the password regularly. Restrict the access rights to instance-specific resources for the SAP system only. Although <sapsid>adm can access SAP system files, a different user runs the SAP system itself, namely SAPService<SAPSID>.

Protecting SAPService<SAPSID>
SAPService<SID> is also created during the SAP system installation. It is usually created as a domain user to run the SAP system and to manage database resources. This user can log on locally on all Windows machines in the domain. Since the SAP system must run even if no user is logged onto the local Windows machine, the SAP system runs as a Windows service. Therefore, during the installation, the user SAPService<SAPSID> receives the right to Log on as a service on the local machine. SAPService<SAPSID> also administers the SAP system and database resources within the Computing Center Management System (CCMS). Therefore, it needs full access to all instance-specific and database-specific resources such as files, shares, peripheral devices, and network resources.

It is rather difficult to change the password of this user. To change the password for a Windows service user, you must stop the service, edit its start-up properties, and restart it. Therefore, to change the password of this user, you need to stop the SAP system. To protect SAPService<SAPSID>, take the following precautions: Cancel the users right to Log on locally. Restrict its access rights to instance-specific and database-specific resources only.

In addition, prevent this special service user from logging on to the system interactively. This prevents misuse by users who try to access the system from the presentation servers. You then do not have to set an expiration date for the password and you can disable the setting change passwd at logon.

Protecting <DBservice> and <DBuser>

As with the SAP system itself, the database must also run even if no user is logged on to the Windows machine. Therefore, the database must run as a service. During the database installation process, the user <DBservice> receives the right to Log on as a service on the local machine.

Overview of Database-Related Users

In addition, the various databases use various operating system users for their administration. To protect these users, we recommend that you change their passwords. For more information, see the corresponding sections under Database Oracle Database Access Protection. Function Runs all Oracle services User for SAP system and database administration Runs the SAP system Runs all MS SQL Server services User for SAP system and database administration User for database administration Runs all MaxDB services User for SAP system and database administration

Operating System User Local System Account <sapsid>adm SAPService<SAPSID>

MS SQL Server

Local System Account <sapsid>adm SAPService<SAPSID>

MaxDB

Local System Account <sapsid>adm

Database

Operating System User SAPService<SAPSID>

Function Runs the SAP system SAP system administrator SAP service account Database administrator User for SAP system database objects

IBM DB2 for Linux, UNIX, and Windows

<sapsid>adm SAPService<SAPSID> db2<dbsid> Connect user: sap<sapsid>db (Java) sap<sapsid> (ABAP)

The user SYSTEM is a virtual user without password. (You cannot log on as user SYSTEM.) However, this user has complete access to the local Windows system.

SAP Systems in the Windows Domain Concept

In large systems, we recommend creating two separate domains for your company domain and your SAP system domain. Between the two domains you can have trusted relationships which is useful for single sign-on functionality. In the company domain, you set up your domain users (to include your SAP system users) and your company domain administrator. In the SAP domain, you set up your SAP system servers, services and administrators, including:

SAP system application and database servers SAP system or database services SAP system administrators Windows administrators SAPdomain administrator

SAP System Security When Using Windows Trusted Domains

In the standard installation procedures, especially in large system configurations, we recommend that you establish separate domains for your company data and your SAP system. We also recommend that you use the Windows trusted domain concept as certain SAP-specific features and Windows-specific services require trusted relationships between domains. There are certain services that require a uni-directional trust relationship only (for example, network printing with the Print Manager or file transfer batches with operating system commands such as xcopy or move). There are also services that require a bi-directional trust relationship, for example, Single Sign-On using Microsoft's LAN Manager Security Service Provider Interface (NTLMSSPI). When installing the SAP system, the installation tool SAPinst, automatically performs all steps that are relevant for protecting the system against unauthorized access. For example, it creates the required user accounts and groups and protects the most important directories. SAPinst creates the following domain users: <sapsid>adm

This is the SAP system administrator account that enables interactive administration of the system. It is a member of the local administrators group. SAPService<SAPSID>

This is the virtual user account that is required to start the SAP system. It has the local user right to log on as a service. SAPinst creates the domain group SAP_<SAPSID>_GlobalAdmin SAPinst creates the local group SAP_<SAPSID>_LocalAdmin and includes the domain group SAP_<SAPSID>_GlobalAdmin SAPinst creates the local administrator group SAP_<SAPSID>_LocalAdmin on the transport host. Members of the group have full control over the transport directory \usr\sap\trans that allows transports to take place between systems. The SAP_<SAPSID>_GlobalAdmin group is added to theSAP_LocalAdmingroup. SAPinst protects the SAP directories \usr, \usr\sap, \usr\sap\trans, \usr\sap\<sapsid> and its sub-directories by only granting Full controlaccess rights for the Administrators and SAP_<SAPSID>_LocalAdmin groups. Eliminate any Full control rights for Everyone to shares on the SAP system servers. For additional protection, you can eliminate the dynamically-created Windows root shares on the SAP system server. The server can then only be accessed from the network over manually created shares. If you have installed other software on the application server, make sure that the access rights for their directories and files are also set properly. These rights apply specifically for SAP system resources. For details applying to the database files and directories, see the security instructions from your database supplier.

Protecting SAP System Resources

In the following sections we describe the security measures for protecting the SAP system: Protecting Data Relevant to the SAP System Defining Start and Stop Permissions Protecting Shared Memory Protection for Dynamically-Created Files (Files Created by ABAP) Protecting Database Files

Protecting Data Relevant to the SAP System

The following applies to the Windows domain concept and the installation of your SAP system: Regardless of whether the SAP system is installed centrally or as a distributed system, we recommend to set up one domain that contains the SAP system application and database servers. We strongly recommend that you set up all your SAP system servers in one Windows domain. For short-term test installations or demonstration purposes only, you might install a central SAP system that is not located in a Windows domain. However, we recommend this setup for limited use only. It is difficult to introduce the domain concept to a system that is already in use. In a central installation on a server in a domain, all SAP system administrators are members of the local group SAP_<SAPSID>_LocalAdmin. In a distributed installation with several server machines in the domain, a global group is set up for the SAP system (SAP_<SAPSID>_GlobalAdmin). This global group itself is a member of the server's local groups and contains the SAP system administrators. This also simplifies the

administration in the client or server environment, since new users who need SAP system administration rights only need to become members of the global group.

Defining Start and Stop Permissions

The permissions for starting and stopping an SAP instance are defined in the sapstartsrv.exe file. To change the start and stop permissions, you can do one of the following: Use the Microsoft Management Console with the SAP Systems Manager snap-in which was developed at SAP and is integrated in the Microsoft Management Console (MMC). Right-click on the SAP instance for which you want to change the start permissions and choose Properties to adjust the permissions. In the Windows Explorer right-click on the sapstart.exe file and choose Properties to adjust the permissions.

Protecting Shared Memory

The shared memory is used by the SAP system dispatcher and the work processes for certain activities, such as buffering (ABAP programs, database data) and sharing interprocess information. These processes use the Access Control List (ACL) of their executable (dispatcher: disp+work.exe) to protect the shared memory segments they are creating or attaching. Therefore, users who have only Read, List Content and Execute permissions on the executable cannot start programs that create the SAP shared memory segments, or write to them.

Protection for Dynamically-Created Files (Files Created by ABAP)

Because SAP systems use ANSI stream file I/O, a file created by ABAP inherits the access rights from the folder in which it was created. Only the owner of the files or the administrator can change the access rights. When ABAP statements create these files, they are owned by the SAP system (<sapsid>adm orSAPService<SAPSID>).

Protecting Database Files

The database provider or the database administrator is responsible for protecting the data at the database level. You should therefore consult the documentation supplied by the database vendor on the subject of data protection and security. For specifics pertaining to SAP systems, see the appropriate section in Access Protection. Database

Setting Rights for an Installation with Several SAP Systems

If there are several SAP systems on the server(s), it is possible to perform the administration tasks separately using different local and global groups. Assign the access rights appropriately for the files in the directory (to include sub-directories) \usr\sap. You can distinguish between the administrators and groups by using the names of the SAP systems (for example, <SAPSID1>, and <SAPSID2>). All administrators should have access to the two directories at the \usr\sap top level. If there are several SAP systems installed on a single server, then an additional area of shared memory exists. This memory is created by saposcol.exe and is used jointly by the OS Collector and all SAP

systems. Therefore, give Full Control access rights to the SAP_<SAPSID>_LocalAdmin local groups for the executable file saposcol.exe. To avoid access conflicts here, start saposcol.exe before starting the SAP system.