Using SAPControl with Certificate Authentication -
A step up in securing SAP systems
Chapters
Share Article
Let's Talk SAP Security
Have questions about SAP Security? We’re here to help. Contact Us
Introduction
SAP security is critical to business continuity. At SecurityBridge, we understand its challenges – and how to solve them. We are constantly exploring the SAP ecosystem to enhance our platform and ensure robust SAP security for our customers. In this article, we dive into the authentication aspects of quite a specific component in an SAP landscape: the SAP Start Service.
Note of warning: this is a rather technical blog.
SAP Start Service?
This article is about the SAP Start Service (sapstartsrv), which is a component that is normally only known to technical administrators. Common SAP users (should) have nothing to do with it. The sapstartsrv is one of those typical components that is easily overlooked in an SAP landscape. But it can cause very serious security issues if it is not properly secured! All the more reason to have a closer look…
So, what is the SAP Start Service and what’s its function? When an SAP system is installed, this is technically done by installing one or more software units called ‘instances’. For each instance, a sapstartsrv service is installed that can be used for various operational tasks like stopping or starting the instance or the whole system. But also, for getting very detailed information about the SAP System, for reading various log files, and even the execution of commands on the operating system. Moreover, sapstartsrv can be accessed via a SOAP-based web service called SAPControl, turning it into a powerful instrument used by various technical components and administrators to control and maintain SAP landscapes.
Looking at these capabilities, it is a no-brainer that this is a component to handle with care. It should be restricted in terms of access and require proper authentication so that only the intended people or systems can use it. In terms of authentication, the common way is to call SAPControl using basic authentication using the operating system user <sid>adm. This has been the way of working for technical administrators for many years. There is yet another possibility to authenticate: certificate-based authentication.
Basic authentication vs certificate-based authentication
Why would anyone bother about using certificates instead of passwords on sapstartsrv? We name 2 reasons:
- Certificate-based authentication is more secure than using passwords.
- Password policies are getting stricter and stricter over time and require frequent password changes.
The last point is not only a matter of inconvenience. When the password of the <sid>adm user is stored as connection information and the password is not updated consistently, this can lead to the <sid>adm getting locked and the SAP system becoming unavailable. Using a certificate instead of a password can limit these efforts and risks while making use of a more secure authentication method at the same time. These are clear advantages but – to be fair – there is also a downside. As with any integration scenario, setting up certificate authentication is not as easy as using usernames and passwords. This is why we dive deep in this article how it’s done!
Example: basic setup with a single certificate
Let’s 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 configured with a self-signed certificate that holds the name of the installation host (wdisphost). See the below picture.
Out of the box, any remote user or application can use sapstartsrv with basic authentication on both the HTTP or the 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:
- The certificates must be trusted. This can be done by adding the certificates directly to the trust store of the used PSE or by using intermediate or root certificates.
- The certificates must be configured. This is done by specifying the allowed certificate attributes using the parameter service/sso_admin_user_x.
Preparation
For our demo setup, we first configure a separate PSE that is only used by sapstartsrv. By default, sapstartsrv uses the same PSE as the application instance and since we want to make specific changes, it is recommended to separate the two.
In the default location, we create and configure this as follows:
- Create custom PSE SAPSSLS_SAPCONTROL.pse and create a secure login:
- Configure sapstartsrv to use this PSE by setting parameter service/ssl/server_pse:
Next, we create a self-signed certificate that we want to use for the authentication. Any tool can be used, we used openssl and created a certificate with the following attributes:
[email protected], CN=admin.example.domain, O=SecurityBridge, L=Ingolstadt, C=DE
Configuration
Follow these 2 steps to trust and configure the certificate:
1. Import certificate to the PSE:
2. Configure parameter service/sso_admin_user_0. In this case, we simply 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 web service 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:
- A more generic trust can be set up by importing intermediate or root certificates. For example: an internal Certificate Authority (CA) 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.
- 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*.example.domain can also be used. This way, all certificates that comply with the wildcard value will be allowed to authenticate, not just the single certificate.
With these options, certificate authentication can be set up for a certain category of trusted users or applications without the need to import individual certificates all the time!
SecurityBridge – SAP Start Service
In the SecurityBridge platform, the SAP Start Service is a component that is checked for various security settings to safeguard secure operations. Also, SAPControl is used for various connections to agent systems by the SecurityBridge controller system. These connections can be set up with basic authentication but also using certificates, as demonstrated above. Since the SecurityBridge controller runs on an ABAP stack, it is the ABAP system that now acts as a webservice client.
In an ABAP stack, outbound SOAP connections are configured as a so-called consumer proxy and logical port. In short, the authentication with certificates is set up by:
- Creation of an SSL Client PSE in the ABAP system, using the certificate for authentication to sapstartsrv.
- Setup of a logical port and specifying the created SSL Client PSE.
Example:
SSL Client PSE. The same certificate (.p12 file) as above, is now stored in the PSE (called ‘ADMIN’).
In the logical port (transaction soamanager), the PSE is specified instead of a username/password.
Conclusion
In this article, we have shortly demonstrated an option to improve the security of the SAP Start Service component. In a typical SAP landscape, there are many components with a multitude of settings that can either greatly improve or weaken the total security posture. Feel free to contact us for more information about the SecurityBridge platform to safeguard your SAP landscape.
