SAPGLOBALHOST - GLCLMPIDEV

Log on to SAPGLOBALHOST in the operating system as the user <sid>adm and execute
the following
commands:

mkdir F:\usr\sap\PID\SYS\global\security
mkdir F:\usr\sap\PID\SYS\global\security\rsecssfs
mkdir F:\usr\sap\PID\SYS\global\security\rsecssfs\data
mkdir F:\usr\sap\PID\SYS\global\security\rsecssfs\key

2) Securing the directories created

In the following, make the directories that were created in step 2.1 accessible
only for the users of the SAP
system <sid>.
On Linux/UNIX, this is the user <sid>adm. On Windows, all relevant users are
grouped together in the
groups SAP_<sid>_LocalAdmin and SAP_<sid>_GlobalAdmin.

All of the other users (in particular <sid>-unspecific SAP users and groups such as
SAP_LocalAdmin) should
not have any authorizations.

Log on to SAPGLOBALHOST as a user with administration authorizations.

Open the explorer and right-click the folder <dir_global>/security/rsecssfs. Choose
"Properties" from
the context menu.

Go to the "Security" tab page and choose "Advanced", and choose "Change
Permissions..." in the
window that is then displayed.

First, deselect the option "Include inheritable permissions from this object's
parent" and choose "Add"
in the warning message that is then displayed to transfer all of the existing
authorizations for this
directory.

Remove all of the entries from the "Permission entries" table, except the
following:
SAP_<sid>_LocalAdmin (only in non-HA installations)
SAP_<sid>_GlobalAdmin
SYSTEM
Administrators

Edit the existing list entries so that there is an entry with the following values
for each of the
aforementioned authorized groups:
Type: "Allow"
Permission: "Full control"
Apply To: "This folder, subfol

3. Maintaining the SSFS profile parameters in the default profile

rsec/ssfs_datapath = $(DIR_GLOBAL)$(DIR_SEP)security$(DIR_SEP)rsecssfs$
(DIR_SEP)data
rsec/ssfs_keypath = $(DIR_GLOBAL)$(DIR_SEP)security$(DIR_SEP)rsecssfs$(DIR_SEP)key
rsdb/ssfs_connect = 1

4) Maintaining the SSFS environment variable

log on to the OS level with the local user <sid>adm.
--> Open a command box and execute the following commands:
setx RSEC_SSFS_DATAPATH F:\usr\sap\PID\SYS\global\security\rsecssfs\data
setx RSEC_SSFS_KEYPATH F:\usr\sap\PID\SYS\global\security\rsecssfs\key

5. Setting up the SSFS data storage and checking the access rights
Log on to SAPGLOBALHOST as the <sid>adm user.
Make sure that the environment variables RSEC_SSFS_DATAPATH and RSEC_SSFS_KEYPATH
are
set.
Use the command line tool of the secure storage rsecssfx from the SAP kernel to add
entries for the
user <name> and the password <pwd> and to add any information about the target
database as
follows:

rsecssfx pf=F:\usr\sap\PID\SYS\profile\DEFAULT.PFL put DB_CONNECT/DEFAULT_DB_USER

SAPSR3 -plain
rsecssfx pf=F:\usr\sap\PID\SYS\profile\DEFAULT.PFL put
DB_CONNECT/DEFAULT_DB_PASSWORD HPs1ngtel

rsecssfx pf=F:\usr\sap\PID\SYS\profile\DEFAULT.PFL list

Check the content of the secure storage as follows:

rsecssfx list

Storage of BR*Tools user/password in secure storage

Symptom

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 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.

Other Terms
BR*Tools, secure storage, Secure Storage in File System, SSFS

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 configuration
tool for Java application servers (AS Java).

Solution

General information

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:\usr\sap\<SAPSYS>\SYS\global

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>\usr\sap

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:\usr\sap\<SAPSID>\SYS\global\sltools\sharedlib\checkKeyPhrase.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 Java Runtime Version 5 or
higher, which is not included 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), it must first be installed manually. In both cases, you
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:

SQL> connect / as sysdba

SQL> create user brt$adm identified by HPs1ngtel;
SQL> grant sapdba, sysdba, sysoper to brt$adm;

brconnect -u / -c -f chpass -o BRT$ADM -p <password> -s brtools

brconnect -u / -c -f chpass -o BRT$ADM -p Sc8anner

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 3:
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. For example:

brconnect -u // -c -f check
You can also use the new connection method for BR*Tools calls in the CCMS
transaction DBACOCKPIT/DB13. To enable this, the option "-u /" must be manually
replaced (for example, with transaction SE16) with the option "-u //" in the SAP
table SDBAC_DATA (SAP_BASIS releases 7.10, 7.11, 7.20, and 7.30) or SDBAC (other
SAP_BASIS releases) in the field PSTRING.
Instead of making the changes manually, you can also run the SQL script
db13secd.sql or db13sec.sql (see attachment):

In SAP_BASIS releases 7.10, 7.11, 7.20, and 7.30:

sqlplus sap<sid>/<pwd> @db13secd

sqlplus sapsr3/HPs1ngtel @db13secd