Using SAPControl with certificate authentication

A step-up in securing SAP systems 

Introduction 

In today’s digital world, ensuring robust security measures is of paramount importance. At Protect4S we understand this like no other. Authentication, the process of verifying the identity of users or systems, plays a crucial role in protecting sensitive information and preventing unauthorized access. Many system components in an SAP system require authentication and need proper setup for a secure configuration. In this technical blog post we dive into authentication on the SAP Start Service using certificates, a feature that we recently made available to use in our products Vulnerability Management (VM) and Threat Detection (TD). 

SAP Start Service? 

Most users of SAP systems are probably unaware of the SAP Start Service (sapstartsrv) because it is not used for common SAP functionality. But technical administrators do know it or at least they should! Sapstartsrv is a service installed on operating system level for many components (instances) in an SAP landscape. It provides management and monitoring capabilities, like starting and stopping of SAP instances but also functionalities for configuring system parameters, handling of log files etc. Moreover, sapstartsrv can be accessed via a SOAP based webservice called SAPControl, turning it into a powerful instrument used by various technical components and administrators to control and maintain SAP landscapes. 

Looking at its capabilities, it seems a no-brainer that this is a component to handle with care. Historically though, the service was poorly secured by its default settings at first and only after various updates this has improved. And today still, the sapstartsrv is a component that is still often overlooked from a security perspective. Which is a pity, because there are definitively some interesting features that can be applied. One of these is the use of certificates for authentication to the service, instead of using passwords.  

Basic authentication vs certificates 

But why would anyone bother about switching from using passwords to certificates for sapstartsrv? We don’t mean to give a full comparison here between basic authentication (using a username and password combination) and certificate based authentication. But in summary: basic authentication is generally considered less secure because of several drawbacks. As a counter measure, password policies have been getting more strict nowadays and require password changes more frequently. Making managing passwords more and more a high maintenance task. 

Looking at the effect of this on the use of sapstartsrv, it is important to note that the service uses a specific operating system user. In the past, it was more or less general practice in many organizations that passwords of these users were never or seldomly changed after installation. But over time, organizations have been applying stricter password policies for all types of users, including these. This is not only a high maintenance burden but also quite a hassle for applications that use the OS users for sapstartsrv and have its passwords stored, because these need to be updated every time. Using a certificate instead of a password for authentication can limit the efforts needed, while making use of a more secure method at the same time. Sounds like win-win right? 

Example: basic setup with a single certificate 

First lets demonstrate the use of certificates with a basic example. We use a single SAP web dispatcher instance running on a Linux OS that runs without any configuration changes after installation. This means the sapstartsrv is running by default with an active HTTP and HTTPS port that is configured with a self-signed certificate. See below picture. 

Out of the box, any remote user or application can use sapstartsrv with basic authentication on both the HTTP or HTTPS port (blue line). It simply requires the username and password and that’s it. Although plain HTTP should be avoided for obvious reasons…  

To authenticate with certificates (green line), the following is needed: 

1. The certificates must be trusted. This can be done by adding the certificates directly to the trust store of the used SAPSSLS.pse or by using intermediate or root certificates. 

2. The certificates to use must be configured. This is done by specifying the allowed certificate attributes using parameter ‘service/sso_admin_user_x’. 

For this demo setup we have created a self-signed certificate with the following attributes: 

EMAIL=admin@p4stest.com, CN=admin.protect4s.tst, OU=IT, O=Protect4S, L=Wageningen, SP=Some-State, C=NL 

Following the steps above: 

1. Import certificate to SAPSSL.pse: 

2. Configure parameter service/sso_admin_user_0. In this case we simple trust the single test certificate by adding it to the default profile of the instance: 

All it takes now is a restart of the sapstartsrv and the configuration is ready for certificate authentication! This can be tested with any webservice tool like SOAPUI for example.  

The configuration above is a basic setup for a single certificate but this can be extended easily to support more complex scenarios: 

1. A more generic trust can be setup by importing intermediate or root certificates. For example of an internal Certificate Authority (CA) that is used within a company or an internal division. These certificates are often valid for a longer time and this prevents frequent changes. All certificates signed by the imported CA certs are trusted in this case. 

2. Multiple service/sso_admin_user_x parameters can be configured AND the values may contain wildcards. So instead of the single certificate example, a value like ‘CN=admin*.protect4s.tst can also be used. This way, all certificates that comply to the wildcard value will be allowed to authenticate, not just a single certificate.  

With these options, certificate authentication can be setup for a certain category of trusted users or applications, without the need to import individual certificates all the time! 

Certificate authentication on Protect4S VM and TD 

As said, our products Vulnerability Management and Threat Detection also make use of the SAPControl webservice and can be configured to use certificates to a client system. In summary, the configuration comes down to: 

1. Setup of the certificate authentication on the client system (like the basic example). 

2. Configuration of an ‘SSL client’ PSE in the P4S system that holds the certificate to use.  

3. Configuration of the connection with the created SSL client identity. 

Wit the right preparations made, configuration of the connection basically comes down to selecting the PSE to use for a connection and test it: 

Select PSE: 

Test: 

See the following blog about SAP Start Service here. 

Conclusion 

In the realm of authentication, security is of paramount importance. Basic authentication has its known drawbacks and maintenance challenges that come with it. Certificate-based authentication, although not maintenance free, offers enhanced security and trust by utilizing digital certificates, encryption, and the verification of identities using trusted Certificate Authorities. This is a step-up in security and we are happy to offer this enhancement as a feature to use in our products VM and TD.  

Like to know more about how Protect4S can help to increase security of your SAP landscape? We are happy to tell you more about our SAP Vulnerability Management and SAP Threat Detection capabilities. For more SAP security-related news, articles, and whitepapers, please follow us on LinkedIn!