If you are still managing an SAP system with an Oracle database. If so, understanding how to configure BRTOOLS SSFS (Secure Storage in File System) is crucial. SSFS provides a secure way to store sensitive data such as database passwords. Let’s dive into the key steps:
Avoid using OPS$ mechanism, locking/deleting OPS$ users
Reference –
1764043 – Support for secure storage in BR*Tools
1622837 – Secure connection of AS ABAP to Oracle via SSFS
Click for SAP Help Portal
Validation before performing any change(BRTOOLS SSFS) with existing setup(OPS$) –
Validate SAP – DB13 jobs should be running fine.
Trigger below command should be getting completed without any error.
ora
OPS$ users in DB –
OPS$ORA
OPS$
OPS$SAPSERVICE
Login to OS level via ora
create below directories via ora
mkdir -p $SAPDATA_HOME/security/rsecssfs/data
mkdir -p $SAPDATA_HOME/security/rsecssfs/key
mkdir -p $SAPDATA_HOME/security/rsecssfs/log
mkdir -p $SAPDATA_HOME/security/rsecssfs/temp
Connect to Oracle
SQL> connect / as sysdba
SQL> create user brt$adm identified by
SQL> grant sapdba, sysdba, sysoper to brt$adm;
Updating the password in Secure Storage for BRTOOLS SSFS –
Run below command to set the temporary variable for this present session.
setenv RSEC_SSFS_DATAPATH /oracle/
setenv RSEC_SSFS_KEYPATH /oracle/
Run below command –
brconnect -u / -c -f chpass -o ‘BRT$ADM’ -p
this will generate below file at OS level and set the key also.
To stop the new password from BRT$ADM expiring, which leads to an oracle error (ORA-28001: the password has expired), we recommend allocating the SAPUPROF profile to the database user:
SQL> connect / as sysdba
SQL> alter user BRT$ADM profile SAPUPROF;
Validate the new configuration is working fine –
brconnect -u // -c -f stats -t all
the above command should be completed successfully without any error. If it’s working then now it’s not using OPS$ mechanism and working with brt$adm user(created in oracle).
Note – above environment variable are temporary for configuration. Post configuration, there is no requirement of temporary environment variables hence log out and login again to ora
brconnect -u // -c -f stats -t all
Locking the OPS$ users in Oracle post BRTOOLS SSFS Configuration
sqlplus / as sysdba
alter user OPS$ORA
alter user OPS$
alter user OPS$SAPSERVICE
Post locking these users command – brconnect -u / -c -f stats -t all will start failing with error “Account is Locked”.
As we now change from OPS$ to SSFS brconnect -u // -c -f stats -t all should be running fine without any error hence it means our configuration is successfully completed.
These users can be deleted post configuration changes and validations at SAP level.
Changes in SAP Systems to run successfully DB13 jobs
(Take table backup of both tables before performing any changes)
New connection method for BR*Tools calls in the CCMS transaction DBACOCKPIT/DB13. To do this, the content of the SAP table SDBAC_DATA (SAP_BASIS Releases 7.10, 7.11, 7.20, and 7.30) or SDBAC (other SAP_BASIS releases) must be modified. Use the SQL script db13secd.sql or db13sec.sql for this see attachment of note 1764043.
In SAP_BASIS releases 7.10, 7.11, 7.20, and 7.30:
sqlplus / as sysdba
Run the script
In other SAP_BASIS releases:
sqlplus / as sysdba
Run the script
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.
Download the respective file and run on the system, as
Trigger the file with below command –
sqlplus / as sysdba
/tmp/db13.sql
Validate SDBAC table in SAP system.
Now // entry is there in the table.
Schedule DB13 jobs in SAP post above changes to validate, it should be getting completed.
Difference of OPS$ and User mechanism working –
Ans – By Default any brtools library run command as below when OPS$ mechanism is configured.
brconnect -u / -c -f stats -t all
But once you configured user mechanism to avoid OPS$ by locking or deleting the database which is a secure method. You need to run command as below –
brconnect -u // -c -f stats -t all
// means – it’s now running with SSFS method avoiding OPS$ mechanism.
Running BRTOOLS post above configuration –
There is a slight change for running brtools after above user configuration(avoid OPS$ mechanism), as BRTOOLS is configured with OPS$ user with (/), it will start failing hence need to change (/) to (//) in the command as below –
For example – Default Value of /
New Change Value – Database user/password (user ) ……………….. [//]
Click to Read – Oracle 19c Automatic Indexing
Commvault Configuration post BRTOOLS SSFS Changes
As Commvault use the default behavior while running the Oracle DB and Log backup by using / function hence this also need to be updated at Commvault side.
Login to Commvault Configuration and select the impacted Oracle Database and select SSFS Connectivity.
Recommendations
For Cluster Databases
Directory structure should be copied $SAPDATA_HOME/security together with the files it contains from the primary server to secondary and DR server where BR*Tools is called.
Caution 5
If SAP Host Agent is active for the affected system. following the deletion of the OPS$ database users, it will attempt to connect to the database with the SYSDBA authorization. This can result in the extremely frequent creation of Oracle audit trace files (see SAP Note 2146596). These audit trace files are deleted by the BRCONNECT function “cleanup”. This should be executed regularly (for example, once a week) in this case. However, if you want to generally avoid the creation of Oracle audit trace files, the OPS$ database users should not be deleted.