1764043 – Support for secure storage in BR*Tools

To improve the security of database connections, SAP Kernel 7.20, Patch Level 100 introduces a new method for the secure saving of the SAP database user or SAP database password. This method stores the data for the connection to the database in a Secure Storage in File System, SSFS. For more information, see SAP Notes 1622837 and 1639578.
Until now, you have used the the BRCONNECT function “chpass” to change the password of the SAP database user. This function changed the password of the ABAP schema simultaneously in the Oracle dictionary and in the SAP database password storage (table SAPUSER). After the introduction of the secure storage, the “chpass” function should be able to change the logon data in this new storage instead of SAPUSER.
The password of the Java schema has always been saved in a separate secure storage. The BRCONNECT function was able to change the Java password in the database only. A relevant update of the Java secure storage was not available and had to be carried out separately using the SAP J2EE configuration tool.

Reason and Prerequisites

This is an advance development.
The prerequisite for the use of the Secure Storage for the ABAP schema is described in the SAP Notes 1622837 and 1639578.
The configuration and maintenance of Secure Storage for Java is explained in the SAP NetWeaver administration documentation in the description of the Config Tool for Java application servers (AS Java).

Solution

The new option “-s|-secstore” has been added to the BRCONNECT function “chpass”. With this option, the specified password is stored to the secure storage.

-s|-secstore abap|abapshd|java|javashd|brtools|none
Where:    abap – for SAP ABAP users (ABAP schema)
abapshd – for SAP ABAP shadow users (ABAP upgrade schema)
java – for SAP Java users (Java schema owners)
javashd – for SAP Java shadow users (Java upgrade schema)
brtools – for BR*Tools users (as a replacement for the OPS$ user)
none – Secure storage is not used (exception)

You can now change the password in the secure storage of the SAP ABAP database user and the Java database user on one server, on which the SAP global directory is located.
Unix: /usr/sap/<SAPSID>/SYS/global
Windows: X:usrsap<SAPSYS>SYSglobal
For Windows, you can also use the “sapmnt” share for the access.
If the “sapmnt” share is not available, set the following environment variable:
set SAPMNT=\<sapglobalhost>usrsap
Alternatively, you can set the SAPGLOBALHOST environment variable:
set SAPGLOBALHOST=<sapglobalhost>
In addition, the executing OS user must have the relevant authorizations to have write access to the secure storage directories or files that are located in the subdirectory “security” of the SAP global directory.
As a default, this action must be started using the OS user <sapsid>adm because this user fulfills these requirements.

1. Changing the password of the SAP ABAP schema
———————————————-
Example of a database server call:
brconnect -u / -c -f chpass -o SAPSR3 -p <password> -s abap
Example of an application server call:
brconnect -u system/<sys_pwd> -c -f chpass -o SAPSR3 -p <sap_pwd> -s abap -RDB
With this call, you change the password for the database user SAPSR3 (ABAP schema) both in the database and in the ABAP secure storage. On an application server, BRCONNECT must connect as DBA (for example, SYSTEM) with the database. In addition, you must set the special option “-RDB” (remote database).
If you do not set the option “-s|-secstore”, the following applies:
– If the table SAPUSER exists in the database, the new database password is changed in the database and in the SAUPUSER table.
– If the table SAPUSER does not exist in the database, the new database password is changed in the database and in the secure storage.
This action must be executed with the OS user <sapsid>adm.

2. Changing the password of the SAP Java schema
———————————————-
Example of a database server call:
brconnect -u / -c -f chpass -o SAPSR3DB -p <password> -s java
Example of an application server call:
brconnect -u system/<sys_pwd> -c -f chpass -o SAPSR3DB -p <sap_pwd> -s java -RDB
With this call, you change the password for the database user SAPSR3DB (Java schema) both in the database and in the Java secure storage. On an application server, BRCONNECT must connect as DBA (for example, SYSTEM) with the database. In addition, you must set the special option “-RDB” (remote database).
If you do not set the option “-s|-secstore”, BRCONNECT still tries to change the password in the Java secure storage for the Java database user SAP<SAPSID>DB.
This action must be executed with the OS user <sapsid>adm.
Note 1:
To change the database password in Java secure storage, the Java application server must be stopped.
Note 2:
A password change for the Java schema is successful only if the following Java jar file exists:
On Unix: /usr/sap/<SAPSID>/SYS/global/sltools/sharedlib/checkKeyPhrase.jar
On Windows: X:usrsap<SAPSID>SYSglobalsltoolssharedlibcheckKeyPhrase.jar
This is normally always the case on Java systems that are based on the following (or higher) SAP NetWeaver versions:
– Release 7.00 Support Package 30
– Release 7.01 Support Package 15
– Release 7.02 Support Package 15
Release 7.10 Support Package 05
– Release 7.20 Support Package 01
– Release 7.3x
– Release 7.4x
Workaround:
In the meantime, you can download the “checkKeyPhrase.jar” file, which is attached to this SAP Note, and copy it to the relevant “sharedlib” directory. However, the Java classes in the “checkKeyPhrase.jar” file require the Java runtime version 5 or higher, which is not in SAP 7.0X systems. On the database server with Oracle 11g, it is automatically included in Oracle Home. On application servers (if you start BRCONNECT there), you must manually install it first. In both cases, set the environment variable BR_JAVA_HOME to the new Java Home before you start BRCONNECT, for example:
setenv BR_JAVA_HOME = $ORACLE_HOME/jdk
In addition, you must set the special option “-OJS” (old Java system) for the BRCONNECT call, for example:
brconnect -u / -c -f chpass -o SAPSR3DB -p <password> -s java -OJS

3. Storage of BR*Tools user/password in secure storage
——————————————————
To be able to completely avoid using the OPS$ database users, you can store the BR*Tools connection data for the database in a BR*Tools-specific secure storage as of Patch 27 for BR*Tools 7.20. The BR*Tools secure storage files are located in the following directories:
$SAPDATA_HOME/security/rsecssfs/data
$SAPDATA_HOME/security/rsecssfs/key
These directories must be created manually before the first BRCONNECT call and must have restrictive authorizations (in accordance with SAP Note 1639578). They belong to the OS user ora<sid> (or Oracle), such as:
> ls -al $SAPDATA_HOME/security/rsecssfs
drwx——  5 oraprd   dba          512 Feb 19 10:52 .
drwx——  3 oraprd   dba          512 Feb 19 10:50 ..
drwx——  2 oraprd   dba          512 Feb 19 10:56 data
drwx——  2 oraprd   dba          512 Feb 19 10:56 key
This also applies to the subdirectories $SAPDATA_HOME/security/rsecssfs and $SAPDATA_HOME/security.
Caution: For Oracle installations using the “oracle” user (SAP Note 1598594), the owner/group “oracle”/”oinstall” are set at this point.
You then create a BR*Tools database user (for example, BRT$ADM) and assign the SAPDBA role to it:
SQL> connect / as sysdba
SQL> create user brt$adm identified by <initial_password>;
SQL> grant sapdba to brt$adm;
Instead of the initial password, you can now set the “correct” password for the BR*Tools user in the database and the secure storage:
On Unix:
brconnect -u / -c -f chpass -o ‘BRT$ADM’ -p <password> -s brtools
You can carry out this call using the <sapsid>adm or the ora<dbsid> OS user on the database server.
On Windows:
brconnect -u / -c -f chpass -o BRT$ADM -p <password> -s brtools
Remark 1:
BR*Tools automatically recognizes database users that have a name starting with “BRT$” as BR*Tools database users. For these, you can omit the option “-s brtools”.
Remark 2:
If BR*Tools cannot be called on the primary database server (for example, on the standby DB server or on the split-mirror side) and the BR*Tools-specific secure storage should be used, you must copy the directory structure “$SAPDATA_HOME/security” together with the files it contains from the primary server to the server where BR*Tools is called.
To prevent the new password from BRT$ADM from expiring, which leads to an oracle error (ORA-28001: the password has expired), we recommend allocating the APUPROF profile to the database user:
SQL> connect / as sysdba
SQL> alter user BRT$ADM profile SAPUPROF;

After you have set up the BR*Tools database users, you can call all BR*Tools executables with the option “-u //” to connect to the database using the data that you have stored in the secure storage.
brconnect -u // -c -f check
You can also use the new connection method for BR*Tools calls in the CCMS transaction DBACOCKPIT/DB13. For this, you must replace the option “-u /” manually (for example with transaction SE16) with the option “-u //” in the SAP table SDBAC in the field PSTRING.
If you switch the SAP system to the new connection method using SSFS and delete the SAPUSER table at the same time, all OPS$ database users may be deleted.
The following Support Packages are required for this change:
SAP Basis Release 7.00:          SAPKB70026
SAP Basis Release 7.01:          SAPKB70111
SAP Basis Release 7.02:          SAPKB70210
SAP Basis Release 7.10:          SAPKB71013
SAP Basis Release 7.11:          SAPKB71108
SAP Basis Release 7.30:          SAPKB73004
SAP Basis Release 7.31:          SAPKB73101
If you want to manage remote databases that are not addressed via an RFC destination (such as Java databases or other non-ABAP databases) with DBACOCKPIT/DB13, you must import the following Support Packages instead:
SAP Basis Release 7.00:          SAPKB70029
SAP Basis Release 7.01:          SAPKB70114
SAP Basis Release 7.02:          SAPKB70214
SAP Basis Release 7.10:          SAPKB71017
SAP Basis Release 7.11:          SAPKB71112
SAP Basis Release 7.30:          SAPKB73009
SAP Basis Release 7.31:          SAPKB73107
Alternatively, you can implement the attached correction instructions.
Lower SAP release levels are not supported here.
Caution: The change in the table SDBAC affects all databases that you manage using DBACOCKPIT/DB13 and that are not addressed via an RFC destination. Therefore, they all must have the BR*Tools-specific secure storage activated.

4. Storage of user/password for Oracle Fail Safe in secure storage
——————————————————————
(as of Patch 29 of BR*Tools 7.20)
Up to now, the user name and the password for Oracle Fail Safe had to be saved in the BRBACKUP environment transparently (see SAP Note 378648). It is now possible to store this sensitive data in the BR*Tools-specific secure storage (see point 3). You call BRCONNECT for this as follows:
brconnect -u / -c -f chpass -o <ofs_user> -p <ofs_pass> -s failsafe
With: <ofs_user> – Oracle Fail Safe User name
<ofs_pass> – Oracle Fail Safe user password
You then change the following BRBACKUP environment variables:
set BR_OFS_USER=SEC$STORE
set BR_OFS_PWD=
The BR_OFS_PWD environment variable is then deleted.
Note: You must first create the directories required for the BR*Tools-specific secure storage manually (see point 3).

5. Role-based storage of BR*Tools user/password in secure storage
———————————————————————
(as of Patch 30 of BR*Tools 7.20)
Comment: This configuration affects mainly Unix platforms.
There are two main roles in the area of the Oracle database management:
– DBA role: Execution of all DBA tasks including restore/recovery
– OPER role: Execution of the routine tasks such as backup and check.
Two Oracle system privileges correspond with these roles:
– SYSDBA for the DBA role
– SYSOPER for the OPER role
and two standard OS groups of which Oracle derives the system privileges:
– “dba” from which the SYSDBA privilege is automatically derived.
– “oper” from which the SYSOPER privilege is automatically derived.

The aim of the role-base storage of BR*Tools user and BR*Tools password in the secure storage is the assignment of the DBA and OPER roles to OS users without the OS users having to belong to the Oracle-relevant OS groups “dba” and/or “oper”. In addition, the OS users that are configured like this must execute the DBA action only with the BR*Tools. Generally, OS users can call all BR programs with the DBA role. OS users with the OPER role can call only BRARCHIVE, BRBACKUP, and BRCONNECT.
Caution: For backups with RMAN, you need the SYSDBA privilege in Oracle 11g. As of Oracle 12c, the SYSBACKUP privilege is sufficient for this purpose.

5.1. Required configuration in the Oracle database
To fulfill the aim described above, the following configuration is required in the Oracle database:

– The Oracle password file must be created and active.
UNIX:
orapwd file=$ORACLE_HOME/dbs/orapw<DBSID> password=<pwd> entries=10
Windows:
orapwd file=%ORACLE_HOME%databasePWD<DBSID>.ORA password=<pwd> entries=10
Note:
For RAC installations, omit <DBSID> from the name of the password file. The file name is restricted to “orpaw” in Unix and to “PWD.ORA” in Windows.

– The following Oracle parameter must be set:
remote_login_passwordfile = exclusive

– Two database users that represent the two roles are created and receive the relevant authorizations. For example the user ORADBA for the DBA role and ORAOPER for the OPER role.
SQL> connect / sysdba
SQL> create user oradba identified by <dbapwd>;
SQL> grant sysdba, sysoper, sapdba to oradba;
SQL> create user oraoper identified by <operpwd>;
SQL> grant sysoper, sapdba to oraoper;And, in addition, as of Oracle 12c:
SQL> grant sysbackup to oraoper;

5.2. Required configuration at OS level (under “root”).
Assumption:
– the OS user “dbauser” is to receive the DBA role and the “operuser” is to receive the OPER role.
– the OS group “dbagroup” represents all OS users with the DBA role.
– the OS group “opergroup” represents all OS users with the OPER role.
– the OS group “dbstaff” represents all OS users with the DBA role and/or the OPER role.
In this case, these users must be configured as follows:
– the OS user “dbauser” is part of the OS groups “dbagroup”, “opergroup”, and “dbstaff”
– the OS user “operuser” is part of the OS groups “opergroup” and “dbstaff”
– these OS users do not belong to the Oracle-relevant OS groups “dba”, “oper”, and “oinstall”
– the BR executables have the following permissions:
-rwsr-xr–   1 ora<sid>   dbstaff   15852744 Feb  4 13:41 brarchive
-rwsr-xr–   1 ora<sid>   dbstaff   16235320 Feb  4 13:41 brbackup
-rwsr-xr–   1 ora<sid>   dbstaff   20176232 Feb  4 13:41 brconnect
-rwsr-xr–   1 ora<sid>   dbstaff   17120056 Feb  4 13:41 brrecover
-rwxr-xr-x   1 <sid>adm   dbstaff   6627408 Feb  4 13:41 brrestore
-rwsr-xr–   1 ora<sid>   dbstaff   21655416 Feb  4 13:41 brspace
-rwxr-xr-x   1 <sid>adm   dbstaff   7828152 Feb  4 13:41 brtoolsFor Oracle installations using the “oracle” user (SAP Note 1598594), the BR*Tools executables must be stored in a separate directory (for example, “brbin”) that has special permissions:
drwxr-x—    1 oracle     dbstaff               64 Feb  4 13:41 brbinThe BR*Tools executables stored there have special permissions, too:
-rwsr-sr-x   1 oracle     oinstall   15852744 Feb  4 13:41 brarchive
-rwsr-sr-x   1 oracle     oinstall   16235320 Feb  4 13:41 brbackup
-rwsr-sr-x   1 oracle     oinstall   20176232 Feb  4 13:41 brconnect
-rwsr-sr-x   1 oracle     oinstall   17120056 Feb  4 13:41 brrecover
-rwxr-xr–   1 oracle     oinstall     6627408 Feb  4 13:41 brrestore
-rwsr-sr-x   1 oracle     oinstall   21655416 Feb  4 13:41 brspace
-rwxr-xr-x   1 oracle     oinstall     7828152 Feb  4 13:41 brtoolsThe OS users “dbauser” and “operuser” must have at least the following Oracle-/BR*Tools-specific environment variables set:
ORACLE_SID – Oracle system ID
ORACLE_HOME – Oracle home directory
SAPDATA_HOME – SAPDATA home directory (/oracle/<DBSID>)
SAPEXE – BR*Tools directory with BR executables
DIR_LIBRARY – SAP directory with libsapsecu.so/libsapcrypto.so
Caution: On the IBM AIX platform, the following environment variable must also be set:
BR_FORK=YES

5.3. Required configuration in the secure storage (with “ora<sid >” or “oracle”)
– delete the old BR*Tools secure storage file, if it exists:
> rm $SAPDATA_HOME/security/rsecssfs/data/*
– store the logon data for the DBA role in secure storage:
> brconnect -u / -c -f chpass -o oradba -p <dbapwd> -s brtools/dbagroup
– store the logon data for the OPER role in secure storage:
> brconnect -u / -c -f chpass -o oraoper -p <operpwd> -s brtools/opergroup

5.4. Call of the BR programs using the OS users “dbauser” and “operuser”.
– The OS user “dbauser” can now call the BR programs as follows:
brarchive -u //dbagroup …
brbackup -u //dbagroup …
brconnect -u //dbagroup …
brrecover -u //dbagroup …
brspace -u //dbagroup …
– The OS user “operuser” can now call the BR programs as follows:
brarchive -u //opergroup …
brbackup -u //opergroup …
brconnect -u //opergroup …
– You can also call these programs using the BRTOOLS/BRGUI menus. In the “Database user/password (user)” menu input field, you enter “//dbagroup” or “//opergroup” accordingly.
– The BRRESTORE program should not be called directly; it should only be called via BRRECOVER.

6. Strict secure storage database connection
———————————————
(as of Patch 30 of BR*Tools 7.20)
Comment: This configuration affects mainly Unix platforms.
The strict secure storage database connection is to ensure that the DBA actions are executed using the BR*Tools only and that the BR*Tools action logs cannot subsequently be manipulated. This configuration is to comply with the strict audit requirements, among other things.

The BR*Tools automatically switch to this operation mode if the following prerequisite is fulfilled:
– the database connection is made via the role-base secure storage entries (see point 5)
– the names of the database users that are stored in secure storage start with the character string “BRT$” (Example: “BRT$DBA”, “BRT$OPER”).
– the BR*Tools profile is located in the directory $ORACLE_HOME/dbs or /oracle/<DBSID>/sapprof – the profile and the underlying directory must have restrictive permissions (for example, -rw——- / -rwx——).
– the BR*Tools log directory (saparch, sapbackup, sapcheck, and sapreorg) are located in /oracle/<DBSID> and must have restrictive permissions (for example -rwx——).

In addition, we recommend to create the directory $SAPDATA_HOME/security/rsecssfs/temp with the restrictive permissions “-rwx——“. In this directory, BR*Tools places temporary files that contain critical logon data.

In addition you can use a new init<DBSID>.sap special parameter “_file_mask” to restrict the permissions to backup files on disks or on new database files. A typical setting could be:
_file_mask = 077
You would restrict the data permissions to “-rw——-” or “-rwx——” (for directories). The leading number “0” is important in this case because the value normally is specified in octal display (corresponds with the UNIX “unmask” command).

7. Storage of user/password for Oracle Fail Safe in secure storage
————————————————————-
(as of Patch 34 of BR*Tools 7.20 and Patch 5 of BR*Tools 7.40)
Until now, the user name and password for the ftp command had to be stored transparently in the init<DBSID>.sap parameter “remote_user”. It is now possible to store this sensitive data in the BR*Tools-specific secure storage (see point 3). You call BRCONNECT for this as follows:
brconnect -u / -c -f chpass -o <ftp_user> -p <ftp_pass> -s ftp
With: <ftp_user> – User name for ftp command
<ftp_pass> – User password for ftp command
Then, set the following init<DBSID>.sap parameter:
remote_user = SEC$STORE
Note: You must first create the directories required for the BR*Tools-specific secure storage manually (see point 3).

=======================================================================

Points 1 and 4: BR*Tools 7.20 Patch 27 and 28 provide an enhancement.
Points 5 and 6: The enhanced functions are provided in BR*Tools 7.20 patch 30.
For more information about downloading patches, see SAP Notes 12741 and 19466.

Leave a Reply