note 1639578 and 1622837

最近的一个项目，对这两note有加深了印象；具体遇到的问题就不说了.........，    我这里有“故事”，你有酒的话，可以告诉你。。。。。。：-）

1639578 - SSFS as password store for primary database connect

Symptom

This note describes the general steps that are required to use the "Secure Storage in File System (AS ABAP)" (SSFS) for the storage of the password of the ABAP database user. In the following, the "Secure Storage in File System (AS ABAP)" is also referred to as "secure storage". The note also described the availability of the solution for the individual databases.

Currently, the procedure is supported by the following databases. Refer to the relevant notes for details about availabilities and required database-specific configuration steps:

• Sybase ASE: SAP Note 1643080
• Oracle: SAP Note 1622837
• SAP HANA: SAP Note 2154997 (as of SAP Kernel 7.42 PL 101)
• SAP MaxDB: SAP Note 2148115 (as of SAP Kernel 7.42 PL 111/as of SAP Kernel 7.42 PL 20)

If you use Oracle as a database platform, take the following into account:

• All SAP products that can be used only with kernel version < 7.20, exclusively support the standard OPS$ remote connect.

• All SAP products that are used with kernel version > 7.38, as well as all the Oracle databases > Version 11.2, exclusively support the new connect procedure with SSFS that is described here.

The Oracle-specific SAP Note 1622837 describes how you best proceed for SAP or Oracle upgrade projects that lead from one category to another.

Reason and Prerequisites

You are using an SAP product based on AS ABAP in combination with one of the aforementioned database platforms and you are using the 7.20 kernel or higher. In addition, you fulfill the prerequisites mentioned in the relevant platform notes, particularly if you are using the 7.20 kernel in the DCK (downward-compatible kernel) mode.

In this case, you can decide to replace the platform-specific mechanism for storing the password of the ABAP database user with a standardized procedure. To do this, you store user and password information in an encrypted manner in the "Secure Storage in File System". After you make sure that the SAP system and its tools can still connect to the database successfully after the changeover, remove the old password storage. Optionally and to ensure greatest possible security, you can define an external encryption key.

Solution

The steps required for the changeover are described below.

----------------------------------------------------------------------
1. Fulfilling the software prerequisites
----------------------------------------------------------------------
Make sure that your database platform is supported in the SAP Release and database release that you require, and refer to the aforementioned platform notes for the minimum kernel patch level required for this.

The following SAP Notes contain general prerequisites and corrections:

• SAP Note 1611877 (Support for ABAP SSFS during database connect)

• SAP Note 1678336 (RSecSSFs: UTF8 conversion failed with returncode 1)

The secure storage is supported by the ABAP programs RSECKEYGEN and RSECSSFX_ESCAPE. Note 1561615 describes the SAP Releases for which and the Support Package levels with which these are available.


----------------------------------------------------------------------
2. Preparing and securing the file system
----------------------------------------------------------------------
In general, we recommend storing the secure storage in the file system and the optional external encryption key on SAPGLOBALHOST under $(DIR_GLOBAL)/security/rsecssfs/data or $(DIR_GLOBAL)/security/rsecssfs/key, whereby these directories should be secured accordingly.


----------------------------------------------------------------------
2.1 Creating the directories
----------------------------------------------------------------------
Determine the value for DIR_GLOBAL (for example, from transaction AL11) on SAPGLOBALHOST. Replace $(DIR_GLOBAL) in the following description with the determined value <dir_global>. Create the required directories as described below if they do not already exist.

----------------------------------------------------------------------
SAPGLOBALHOST on UNIX or Linux
----------------------------------------------------------------------
Log on to SAPGLOBALHOST to the operating system as user <sid>adm and execute the following commands:

• mkdir <dir_global>/security

• mkdir <dir_global>/security/rsecssfs

• mkdir <dir_global>/security/rsecssfs/data

• mkdir <dir_global>/security/rsecssfs/key

----------------------------------------------------------------------
SAPGLOBALHOST on Windows
----------------------------------------------------------------------
Log on to SAPGLOBALHOST to the operating system as user <sid>adm and open a command box or a powershell. Execute the following commands:

• mkdir <dir_global>security

• mkdir <dir_global>security secssfs

• mkdir <dir_global>security secssfsdata

• mkdir <dir_global>security secssfskey

Alternatively, you can also create the directory structure via the Windows file explorer.

----------------------------------------------------------------------
2.2 Securing the directories created
----------------------------------------------------------------------
In the following, make the directories that were created in step 2.1 available exclusively for the users of the SAP system <sid>.
On Linux and UNIX, this is the user <sid>adm. On Windows, all relevant users are merged into the groups SAP_<sid>_LocalAdmin and SAP_<sid>_GlobalAdmin.
In particular, cross-SAP system users and groups should not have any authorizations in these directories.

The procedure depends on the operating system:

----------------------------------------------------------------------
SAPGLOBALHOST on UNIX or Linux
----------------------------------------------------------------------
If SAPGLOBALHOST runs on Unix or Linux, proceed as follows:

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

• chmod 700 <dir_global>/security

• chmod 700 <dir_global>/security/rsecssfs

• chmod 700 <dir_global>/security/rsecssfs/data

• chmod 700 <dir_global>/security/rsecssfs/key

• Use "ls -al" to check the result. For example:
  
  drwx------ <sid>adm sapsys data
  drwx------ <sid>adm sapsys key

----------------------------------------------------------------------
SAPGLOBALHOST on Windows
----------------------------------------------------------------------
If SAPGLOBALHOST runs on Windows, <sid>-specific users and groups, operating system-specific users and groups, and operating system administrators must have full access. In particular, this concerns the following:

• SAP_<sid>_LocalAdmin (only in non-HA configurations)

• SAP_<sid>_GlobalAdmin

• SYSTEM

• Administrators

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

Proceed as follows:

• 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

• If required, add missing groups.

• 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, subfolder and files"

• Finally, select the option "Replace all child object permissions with inheritable permissions from object".

• Confirm all changes.

----------------------------------------------------------------------
2.3 Heterogeneous installations
----------------------------------------------------------------------
If you operate SAPGLOBALHOST on Linux or UNIX and application servers on Windows in addition to this, you must ensure that, in addition to <sid>adm, all other users from the groups SAP_<sid>_LocalAdmin or SAP_<sid>_GlobalAdmin also have access to the previously created directories on SAPGLOBALHOST. Especially the SAPService<sid> user must have access (that was previously excluded by chmod 700 on UNIX explicitly).

Therefore, check your Samba configuration. The configuration file smb.conf should contain an entry for "username map", for example:
[global]
...
username map = /etc/username.map

The file username.map in turn should contain the following entry for local installations:
<sid>adm = <sid>adm SAPService<sid>

In the case of domain installations, the entry looks as follows:
<sid>adm = <domain>/<sid>adm <domain> /SAPService<sid>

This ensures that the SAPService<sid> user is handled in the same way as <sid>adm when accessing the UNIX file systems that are made visible by Samba.


----------------------------------------------------------------------
3. Maintaining the SSFS profile parameters
----------------------------------------------------------------------
Set the following profile parameters that point to the previously created directories as the location for the secure storage and the external key. We recommend that you add the parameters to the default profile DEFAULT.PFL. Otherwise, you must maintain all of the instance profiles. Add the following entries:
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


----------------------------------------------------------------------
4. Maintaining the SSFS environment variable
----------------------------------------------------------------------
The profile parameters rsec/ssfs_datapath and rsec/ssfs_keypath are interpreted only by the SAP system. The do not apply to the SAP tools R3trans, R3load, and so on. For this, corresponding environment variables must be set in .sapenv.sh, .sapenv.csh, .sapenv_<host name>.csh, and .sapenv_<host name>.sh on each application server, including the central instance. Depending on the operating system, proceed as follows:

----------------------------------------------------------------------
Application server on UNIX and Linux
----------------------------------------------------------------------
For this, first determine the value <dir_global> for DIR_GLOBAL on the relevant application server (for example, using transaction AL11). Then add the following lines to the logon script for <sid>adm on this application server:

• For C shell scripts:
  
  setenv RSEC_SSFS_DATAPATH <dir_global>/security/rsecssfs/data
  setenv RSEC_SSFS_KEYPATH <dir_global>/security/rsecssfs/key

• For Korn shell scripts:
  
  export RSEC_SSFS_DATAPATH=<dir_global>/security/rsecssfs/data
  export RSEC_SSFS_KEYPATH=<dir_global>/security/rsecssfs/key

----------------------------------------------------------------------
Application server on Windows
----------------------------------------------------------------------
If your application server runs on Windows, proceed as follows:

• Determine the value <dir_global> for DIR_GLOBAL on the relevant application server (for example, using transaction AL11).
  
  Note that the specification for SAPGLOBALHOST occurs as a local path with disk drive letters, whereas the specification for other application servers is a UNC path (for example, \$(SAPGLOBALHOST)sapmnt<sid>SYSglobal).

• If you have installed your SAP system in a domain, log onto the operating system as the <domain>/<sid>adm user. Otherwise, log on with the local user <sid>adm.

• Open a command box and execute the following commands:

• setx RSEC_SSFS_DATAPATH <dir_global>security secssfsdata

• setx RSEC_SSFS_KEYPATH <dir_global>security secssfskey

----------------------------------------------------------------------
5. Setting up the SSFS data storage and checking the access rights
----------------------------------------------------------------------

----------------------------------------------------------------------
5.1 Setting up the SSFS storage
----------------------------------------------------------------------
In the following, you must fill the secure storage in the file system with the required access information for the ABAP database user. This information consists of at least the name of the ABAP database user and the password of this user.
In the case of some database types, you must also make specifications about the target database. In all other cases, this information is still derived from the SAP profile.

Note that storage differentiates between uppercase and lowercase characters.

• DB_CONNECT/DEFAULT_DB_USER
  ABAP database connect user (usually "SAPSR3")
  The storage in the secure storage should take place in an unencrypted manner for Support reasons.

• DB_CONNECT/DEFAULT_DB_PASSWORD
  Password of the ABAP database user
  The storage in the secure storage takes place in an encrypted manner.

• DB_CONNECT/DEFAULT_DB_CON_ENV
  Specifications about the ABAP target database
  The storage in the secure storage takes place in an unencrypted manner. This parameter is currently required for the SAP HANA database only.

Refer to the relevant platform note for the name of the database connect user, for the information about whether the parameter DB_CONNECT/DEFAULT_DB_CON_ENV is required, and its exact format, if required.

Proceed as follows:

• 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 put DB_CONNECT/DEFAULT_DB_USER <name> -plain
  rsecssfx put DB_CONNECT/DEFAULT_DB_PASSWORD <pwd>

If required, also use:
rsecssfx put DB_CONNECT/DEFAULT_DB_CON_ENV <con_env> -plain
Note the following: In non-Unicode systems, only characters from the 7-bit ASCII area are permitted.
To avoid code page problems, we generally recommend that you adhere to this rule. If you want to use other characters in Unicode systems, you must convert these using the ABAP report RSECSSFX_ESCAPE into characters that can be used by rsecssfx.

• Check the content of the secure storage as follows:
  
  rsecssfx list

Refer to the command line help for further commands for the administration of the secure storage:

rsecssfx help

----------------------------------------------------------------------
5.2 Setting and checking the authorization of the SSFS data storage
----------------------------------------------------------------------
Due to the first call of "rsecssfx put", the system also creates the data storage of the secure storage. The directory $(DIR_GLOBAL)/security/rsecssfs/data should now contain the file SSFS_<sid>.DAT.

----------------------------------------------------------------------
SAPGLOBALHOST on Windows
----------------------------------------------------------------------
If your SAPGLOBALHOST runs on Windows, no action is required because the access rights are inherited from the directory when the file is created.

----------------------------------------------------------------------
SAPGLOBALHOST on UNIX or Linux
----------------------------------------------------------------------
Otherwise, you must correct the access rights for the file, in the same way as for step 2.2, so that only <sid>adm are authorized.

• chmod 600 <dir_global>/security/rsecssfs/data/SSFS_<sid>.DAT

For security reasons, also check the access rights here using "ls -al":
-rw------- <sid>adm sapsys SSFS_<sid>.DAT


----------------------------------------------------------------------
6. Optional: Creating an external encryption key
----------------------------------------------------------------------

----------------------------------------------------------------------
6.1 Creating the encryption key
----------------------------------------------------------------------
All of the encrypted entries in the secure storage are usually encrypted using a standard encryption key. For additional security, however, you can define an individual external encryption key (24 bytes).

The ABAP report RSECKEYGEN can be used to generate keys from various phrases.

• Log on as <sid>adm.

• Due to the call of the command line tool, the new encryption key <ext_key> is set and the content of the secure storage is encrypted again as a result. <ext_key> is specified in the hexadecimal format (48 characters from the range '0-9' and 'A-F').
  
  rsecssfx changekey <ext_key>

----------------------------------------------------------------------
6.2 Setting and checking the authorization of the SSFS key storage
----------------------------------------------------------------------
If SAPGLOBALHOST runs on Linux or UNIX, carry out step 5.2 for the file <dir_global>/security/rsecssfs/data/SSFS_<sid>.KEY. You do not have to do anything for Windows.


----------------------------------------------------------------------
7. Changing to the new connection method
----------------------------------------------------------------------
----------------------------------------------------------------------
7.1 Setting the required parameters
----------------------------------------------------------------------
If you have executed all of the previous steps correctly, the SAP system should now be able to retrieve the password information that is required for the connection to the primary ABAP database from the secure storage in the file system. However, the conventional password storage is consulted by default.

The changeover to the new method now takes place due to a further profile parameter or a further environment variable. Proceed in the same way as described in step 3 and 4 to set the profile parameter (on SAPGLOBALHOST) and the environment variable (for all of the application servers).

• Profile parameter: rsdb/ssfs_connect = 1

• Environment variable: rsdb_ssfs_connect 1

(To use the conventional storage, you must set the values of the profile parameter and environment variable to the value '0'. This corresponds to the default.)


----------------------------------------------------------------------
7.2 Checking the successful changeover
----------------------------------------------------------------------
Restart the SAP system and check whether the connect was successful. If the changeover was successful, the developer trace (SM50) should contain the following entry:

B ==> connect info for default DB will be read from ssfs

Check this for all of the application servers.

In addition, make sure that the SAP tools are still able to connect to the database. To do this, perform an R3trans testconnect on the application servers as <sid>adm.
R3trans -d

If R3trans was able to connect to the database successfully, the message "R3trans finished (0000)." should be displayed. You must now also check trans.log in the current directory for the following entry:

B ==> connect info for default DB will be read from ssfs

----------------------------------------------------------------------
8. Removing the user data from the platform-specific storage
----------------------------------------------------------------------
After you make sure that the SAP system and its tools are able to retrieve the password information that is required for the initial connect to the ABAP database from the secure storage, you should remove the old platform-specific password storage. Otherwise, you will not benefit from the potential security-relevant improvements in comparison with the old method.

To do this, follow the instructions in the relevant platform notes.

1622837 - Secure connection of AS ABAP to Oracle via SSFS

Symptom

Previously, the connection of the SAP system (Application Server ABAP) and of SAP tools that use the ABAP database interface (R3trans, R3load, and so on) to the database via SQLNet (using the database alias name, for example, TNS) worked in such a way that an OPS$ connection (with the database user OPS$<SID>ADM) that was authorized by the operating system user <sid>adm was created first ("connect /@TNS"). This permitted access to the table OPS$<SID>ADM.SAPUSER, and to this table only. It contains the encrypted password for the actual database connection of the SAP database user (default name SAPSR3).

As of Release 11g, OPS$ remote connect (using the TNS alias name) is no longer supported by future Oracle versions. As of kernel release 7.20, SAP therefore introduces a new method of securely storing the database password and for connecting to the database: "Secure Storage in File System" (SSFS). The encrypted password for the SAP database user is then no longer stored in the database, but in the file system.
With the implementation of Kernel 7.20 (11/2011) as a downward-compatible kernel (DCK for 7.xx), the new method is available in all 7.xx systems (as of SAP 7.00). For security reasons, SAP recommends that you use only the new method as soon as possible.

For backward compatibility, the conventional connect method continues to be supported for all SAP systems up to 7.38 and with Oracle up to Version 11.2.
All SAP systems that use Oracle versions higher than 11g in future can be operated with the new connection method only.
As of SAP Kernel Release 7.40 (irrespective of the Oracle version), only the secure connection (secure connect) is supported via SSFS.

Other Terms

SAPUSER, ops$-User, ops$-Connect, SSFS, data protection, secure storage, Secure Connect

Reason and Prerequisites

The new connect method is supported:
- For Unicode systems: As of kernel 7.20, patch 98 with DBSL patch 102
- For non-Unicode: As of SAP Kernel 7.20 Patch 210, download as individual patches (packages dw, R3trans, R3load and so on) if SAPEXE/SAPEXEDB does not exist

The old connection method is invalid as of Kernel 7.40.
(See point 3.4 about the upgrade)

Solution

1: Setting up the secure storage (SSFS)

The database-independent Note 1639578 describes the individual processes of creating subdirectories and files for a secure storage with the required access authorizations, setting the profile parameters and environment variables, and entering user and password in the secure storage.

Note that the DB user name in the secure storage is case-sensitive.
(Usually, the SAP database user SAPSR3 or SAP<SID> is saved in upper case on the database.)

As an alternative to the method described in SAP Note 1639578 for entering or changing a user and password (in two steps using "sqlplus" in the database and with "rsecssfx" in secure storage), you can do this in one step using "brconnect". The following example for the user "sapsr3" with the new password "<pwd>" changes the password in the database and changes or enters the user and password in the SSFS (if the required subdirectories are set up and environment variables are set) and in the table SAPUSER (if this still exists, see 3.1):

> brconnect -u / -f chpass -o sapsr3 -p <pwd>

2: Switching to the new connection method

If all of the options listed under section 1 have been executed correctly, the system is ready for both connection methods (the standard methods with the table SAPUSER and the new methods with the secure storage).
However, the standard method is always used by default.

The actual switch to the new method occurs with the profile parameter rsdb/ssfs_connect or with the environment variable rsdb_ssfs_connect. For this, refer to the details contained in the database-independent Note 1639578.
Pay attention to lowercase/uppercase letters here: rsdb_ssfs_connect.


3: Oracle database-specific postprocessing and BR* tools

3.1: Excluding the standard SAP connect method

If you use only the new database connection method, you should delete the table SAPUSER:

> sqlplus
SQL> connect system/<pwd>
SQL> drop table ops$<sid>adm.sapuser;

Caution with the upgrade, see below: 3.4., point (3)

The Oracle user ops$<sid>adm is then no longer required for the SAP connect. However, it is not allowed to be deleted immediately, since it can still be used by default by BR*Tools for the local database connection (see 3.3 in this SAP Note).
To make BR*Tools independent of the ops$ user, too, and thus enable the full deletion of the latter, please proceed as per point 3 of SAP Note 1764043.


3.2: Excluding the Oracle remote OPS$ connect

The remote OPS$ connect is deactivated by default in all Oracle versions. However, you can activate it up to Oracle 11.2, which is also required for the conventional SAP connect method. For this, the Oracle initialization parameter REMOTE_OS_AUTHENT must be set to TRUE.
If the parameter REMOTE_OS_AUTHENT is set to TRUE in Oracle 11g, the system issues the following information message when starting the database:
"ORA-32004: obsolete and/or deprecated parameter(s) specified".

After the changeover to the new SAP connect method with the secure storage, you should remove the parameter REMOTE_OS_AUTHENT. Only with this setting does the new advantage in relation to security take full effect:

SQL> alter system reset remote_os_authent [scope=spfile];
(The addition scope=spfile is required up to Oracle 10g only.)

In future Oracle versions after 11g, the remote OPS$ connect ("connect /@TNS") will no longer be possible.


3.3: Local OPS$ connect for BR* Tools

Regardless of the old or new SAP connect method described in this SAP Note, the BR* database administration tools from SAP continue to use the local OPS$ connect ("connect /") for the operating system user <sid>adm with the database user ops$<sid>adm by default. In UNIX systems, the same also applies to ora<sid> or ops$ora<sid>. After 3.1., these database users no longer have any data segments in the database, but they retain the authorization of the role "SAPDBA".
The local OPS$ connect is also still possible in future Oracle releases after 11g and is not influenced by the parameter REMOTE_OS_AUTHENT. This does not affect the issue of security in the SAP system.
If, despite this, you want to end the local use of OPS$ users for BR*Tools, too, and completely delete OPS$ users, please proceed as per point 3 of SAP Note 1764043.

Password changes, in particular, the encrypted entry in the table SAPUSER, were made for the old connect method using brconnect. When you use only the new method (that is, after 3.1.), the entry in the table SAPUSER is no longer required. The database password can still be changed with brconnect.

Support for the new connect method with BR*Tools is described in detail in SAP Note 1764043.

Important:
After the Oracle parameter REMOTE_OS_AUTHENT has been removed, you sould use transaction DB17 to change the relevant BRCONNECT check condition that monitors its setting: The check value and the check operator are deleted or removed.
In this case, an alert is triggered if the parameter REMOTE_OS_AUTHENT is specified in the Oracle Spfile.


4: Information about the upgrade

The upgrade of SAP systems that are based on Oracle databases takes place using a shadow user that you can recognize from the suffix SHD (for example, SAPSR3SHD). This user is used only for the upgrade.

The upgrade proceeds in the same way as with the previous method except that, instead of the shadow user and password being entered in the table SAPUSER, the corresponding entries are now made in the secure store.
In the standard system, the same secure store is used for this as for the default user. Accordingly, the key words read (see SAP Note 1639578):
DB_CONNECT/SHADOW_DB_USER
DB_CONNECT/SHADOW_DB_PASSWORD
DB_CONNECT/SHADOW_DB_CON_ENV

As of the following kernel patches, you can also perform the SAP upgrade with the new connect method via secure store (SSFS):
7.20: As of patch >= 318
7.21: As of patch >= 27
and as of kernel 7.38 in general. (As of 7.40, only SSFS applies (see above)).

Note the following for the upgrade:
(1)
The entire SAP Kernel 7.2x must be patched and not just the DBSL.

(2)
For the BR* tools, at least version 7.20 patch 28 is required.

(3)
The table SAPUSER can only be deleted after the completion of the full upgrade because during the upgrade the old system still connects to the DB.

(4)
The Secure Store paths are generally set in the SAP profile: Parameters rsec/ssfs_datapath and rsec/ssfs_keypath. However, these are by default defined using the variables $DIR_GLOBAL, which leads to different paths during the upgrade. As a consequence, these parameters must also be set as environment variables during the upgrade. Also the other R3 tools (R3trans,and so on), and the BR* tools require these environment variables:
RSEC_SSFS_DATAPATH = /usr/sap/<SID>/SYS/global/security/rsecssfs/data
RSEC_SSFS_KEYPATH = /usr/sap/<SID>/SYS/global/security/rsecssfs/key
rsdb_ssfs_connect = 1
(The paths in this example correspond to the standard.)


(5)
for the upgrade to 7.40

5.1 start release < 7.00:

The upgrade (SUM) stops during the extraction phase with a DB connect error. Install SSFS with the 7.40 kernel that is already unpacked at this time. Then continue the upgrade, that is, terminate the SUM process and restart with the new environment variables (log on as OS user if necessary).

5.2 source release = 7.0x and 7.1x as well as older 7.2x patches (see above):

There are two options:
a)
Kernel exchange (replace the old 7.xx Kernel with the current, backward compatible Kernel 7.2x), implement SSFS, carry out the upgrade.
b)
Start the upgrade (SUM) with the old 7.xx Kernel. It will stop with a DB connect error during the extraction phase. Install SSFS with the 7.40 kernel that is already unpacked at this time. Then continue the upgrade, that is, terminate the SUM process and restart with the new environment variables (log on as OS user if necessary).

5.3 source release >= 7.2x (SSFS-compatible patch, see above prerequisites):

First set up Secure Store if you have not yet done this.
Then, perform the upgrade.