Securing Clients in SAP S/4HANA and Netweaver ABAP
The aim of this blog post is to provide recommendations to protect SAP clients. We will go through the role of default clients and the different ways to close a client to prevent undesired modifications. The latter topic is very important because in a production system even a developer user should not able to make modifications. The proper way to modify a client is by transport requests through the entire landscape from development to production system.
Read on to see the settings that must be applied to the system in order to keep it safe from manual modifications, the risk of leaving a production client open and the steps to close it properly.
SAP Default Clients
We recommend securing all the clients present in your SAP system, even the ones that are unused. During the installation of the system, which in certain cases may have been a long time ago, SAP creates two specific clients, 001 and 066, for the following purposes:
Client 001: this is a copy of client 000. It is created to be the production client of the system. In case another client is being used for this role, it is safe to remove it. Keep in mind that an SAP Solution Manager System or an SAP Business Warehouse system usually uses client 001 as the production client.
Client 066: this is a client applicable for all SAP systems based on SAP NetWeaver 7.40 or below and is used to deliver services by SAP Active Global Support. However, it is not used anymore and therefore you can safely remove it (if available). SAP Note #7312 details some more information about this client. Take into account that SAP NetWeaver 7.40 is the last release delivering the client 066 with the installation or upgrade.
Having explained this, SAP recommends to delete these clients if they are not used anymore. Before doing this, it is recommended to check that there are no active users in each client. In addition, it should be checked that no background jobs are scheduled and that they are not classified as production. Both things will be introduced and explained in the following sections.
If any of these clients have been used before, it is required to check SAP Note #934593 for further details.
How to Remove Unused Clients
Bearing in mind the precautions mentioned before and that it might be necessary to set the profile parameter “login/no_automatic_user_sapstar = 0” (for further details, see SAP Note #1749142) to be able to login using built-in user SAP*, these are the steps to delete an unused client:
- Login in to the client to be deleted.
- Execute transaction SCC5.
- Activate the option to remove the entry in table T000. Use the background mode to delete a large client like client 001 (this is not required for client 066). The transaction offers a test-run mode, too.
- To monitor the progress of the client deletion, use transaction SCC3.
- Finally check with transaction SCC4 that there is no entry for the client in table T000 and submit report RSUSR003 to check if no access to this client using standard user SAP* is possible anymore.
Caution
As mentioned before, it is recommended to check there are no active users in the client. This can be done using report RSUSR200 through the User Information System (transaction SUIM) or the Workload Statistics (transaction ST03N) to check if there have been any user activity
It is also recommended to lock all users (except for the user that will execute the deletion) for some time before deleting the client and check if no background job is scheduled within this client. For this last point, use transaction SE16 for table TBTCO or view V_OP with a selection for the client using selection field AUTHCKMAN.
Finally, make sure that the client is not classified as “production” using transaction SCC4. If the client to be deleted has previously been used in production, check note #934593 which describes how to delete all objects of a client from the temporary sequential file (TemSe).
Opened and Closed Clients
Having a client opened means that it is possible to make any cross-client modifications such as changes in the dictionary objects, source code, etc. Having the proper authorization objects associated with the user’s role, it could be possible to modify custom objects with or without including them in transport requests.
On the other hand, if the client is closed it means that no changes to repository and client-independent customizing objects are allowed.
There is a variety of configurations in the middle that suits the different roles an SAP system or client might have in the landscape. They will be described in more detail in the following section.
Usage of SCC4 and SE06 Transactions
Transaction SCC4 is used to maintain all the existing clients in the SAP system. This is how it looks like when trying to edit a client:
In the following section we are going to explain the meaning of each option present in the transaction in order to clear them so it is easier to know how to properly setup each client of the landscape.
For Changes and Transports for Client-Specific Objects, the options are:
- Changes w/o automatic recording: client dependent objects may be changed without being recorded in change requests. Used for tests or training clients.
- Automatic recording of changes: attempts to make client dependent changes will result in a prompt for a change request in which to record the changes. Used for customizing clients.
- No changes allowed: client dependent objects cannot be changed. Used for production, SAP reference clients or test clients in QA.
- No transports allowed: changes are allowed but cannot be transported out of the system. Used for sandbox, pre-config. clients or training client.
For Cross-Client Object Changes, options are:
- Changes to repository and client-ind. Customizing allowed: no restrictions. Used in development clients.
- No changes to client-ind. Customizing objects: Repository objects (programs, table definitions, etc.) can be changed but some customizing that are client independent cannot. Used in ABAP only development clients.
- No changes to repository: Repository objects (programs, table definitions, etc.) cannot be changed but some customizing which are client independent can be done. Used in customizing only development clients.
- No changes to repository and client-independent custom. Obj.: no client independent changes allowed. Used in QA and production clients.
hand, transaction SE06 is mainly used for post-installation actions but it is also used to configure System Change options.
On the other hand, transaction SE06 is mainly used for post-installation actions but it is also used to configure System Change options.
These options provide granularity on what repository and cross-client customizing objects can be modified. This is more of a global setting (regardless of the client) and it is only for client-independent objects. Here, repository objects are further subdivided into different groups (software components and name spaces) so you can set only which group can be changed.
In case the client is set as “Not modifiable” in “Global setting,” it overrides all other settings in both transaction SE06 and SCC4. This means: nothing in this system is changeable except some customizing defined as current setting.
How to Close a Client
After having explained the role of transactions SCC4 and SE06, now we are able to list the conditions required to properly close a production client.
Settings in transaction SCC4
If a client role is defined as in production, it means that it is in fact a production client and there are two options that must be set to keep it closed for changes:
- Changes and Transports for Client-Specific Objects: this option should be No changes allowed to indicate client dependent objects cannot be changed
- Cross-Client Object Changes: this option should be No changes to repository to ensure that objects such as programs, table definitions, etc. won’t be changed – just some customizing which are client independent could be modified
Settings in Transaction SE06
The most significant configuration is the “Global Setting” option in this transaction.
This setting makes all the software components and namespaces in the system, not just a specific client, to be Not Modifiable as well. Different from transaction SCC4, the configuration here affects all the existing clients in the system and cannot be specified for each of them.
It is very important to remark that the setting for both transactions (SCC4 and SE06) should be carried out to be completely sure that the client is closed. Each of them has a different role and checks for different aspects of the system, use them combined to effectively protect your SAP system.
Risks of Having a Production Client Opened
There are some special cases where you have to open the client for some changes. This is a security mechanism to protect the client against unwanted changes from users with powerful authorizations and applications with powerful functions (such as the transport tools). Development systems are open to be modifiable as this is their role, but having a production client open is critical and should be monitored and limited to those special cases. All the changes that are required to be implemented in a production system should be deployed by the implementation of transport requests, following development and QA processes.
There will be specific risks depending on which options are misconfigured in the system. For example, if changes in client specific objects are allowed and users have the proper authorizations assigned, it could be possible for them to change the behaviour of custom code with or without being recorded (according to the selected option). Not even firefighter users are allowed to make changes at source code level.
How Does OSP Help to Monitor these Configurations?
The Onapsis Security Platform (OSP) offers two different functionalities to help customers detect unused default clients and to monitor the changeability of a client.
We are working on a new module for OSP called “Default clients 001 and 066” that will be released soon. This module will detect if either of the clients is present in the SAP system and, therefore, should be removed as explained above.
Another important functionality already present in OSP is a real-time alert to detect attempts of Opening or Closing a client.
Conclusion
Onapsis knows that the security of an SAP system can be a hard task and that is why we want to provide the best recommendations and solutions to help our customers. Our first recommendation in this blogpost relies on that: it is tough enough to be worried about unused clients or, even worse, some do not even know they exist, extending the attack surface.
The second recommendation tries to clarify the different and complementary roles of transactions SCC4 and SE06. Emphasizing the configurations that must be applied in a productive SAP system to prevent undesired and untracked modifications that could compromise the security of the system. It is important to secure all your systems, especially ones in production.
References
