Hacking the saplogon.ini file

     Posted in BASIS, SAP

hacking-the-saplogon-ini-file-1

I’m sure you know the feeling;
Maybe it’s a Monday morning and you’re busy and want to get started …

Unfortunately there has been a service window in the weekend, and somebody somewhere in a service center far far away has changed the IP address on the development server, meaning you have to hunt down the new IP address.
or…
Maybe you are using another laptop; you start, then find out that the SAP Logon only contains access to the productive system. You might be using a tool to keep track of your SAP logon entries, but then again you might not, meaning you’d need to hunt down the required login information.
Then just after you succeed, you update the SAP logon with the correct information, only to have the system tell you that you are not allowed to update the file

The saplogon.ini file location

hacking-the-saplogon-ini-file-2

I guess that you are quite aware that the entries in your SAP Logon are stored in the saplogon.ini file. This file can be a local file or a central file stored on the company server.
You can find the location of this ini file under “options -> SAP Logon option -> Local configuration files” (in SAP GUI 7.30).
If you are missing a system, or if your entries are not up-to-date, you can maintain this file directly from the SAP Logon.
However, if it’s stored centrally, that may not be a good idea and you may not even be allowed to update it. Luckily, there are several other options.

Using an alternative saplogon.ini file
As for SAP GUI 7.20 for windows, the searching order for the saplogon.ini is as follows:

  1. File name from command line paramater /INI_FILE
  2. File name from the envitoment variable SAP_LOGON_INI_FILE
  3. The saplogon.ini file from the path defined under the Local configuration options
  4. The saplogon.ini file in the SAP GUI installation directory
  5. The saplogon.ini file in the windows directory.

(In the case of scenario 4 & 5, the ini file will be copied to the path defined under the local configuration file)

This means you can easily create your own local SAP Logon version with the entries you need and without having to change the central/protected one. You do this by:

  1. Copy the saplogon.ini file from the directory specified under “local configuration files”
  2. Create a shortcut to SAP Logon on your desktop
  3. Add the parameter /INI_FILE = “c:\your location\saplogon.ini” to the shortcut – and “voila“, you are working with your own version

This will give you a shortcut that looks something like this;

"C:\Program Files (x86)\SAP\FrontEnd\SAPgui\saplogon.exe" /INI_FILE="c:\temp\saplogon.ini"

Starting SAP GUI from the command line
Another shortcut that doesn’t require you to update the ini file is to call the SAP system from the command line.
You do this by simply calling the sapgui.exe with the SAP-Server/IP-address and the system number as parameters, as shown below:

"C:\Program Files (x86)\SAP\FrontEnd\SAPgui\sapgui.exe" 127.0.0.1 00

This command starts the local NSP demo system that I have installed locally.

Calling the system from SM59

hacking-the-saplogon-ini-file-3

Another approach that I have used from time to time is to “piggyback” on the RFC Connections created between systems.
As long as you have access to one of the systems in the landscape and if these connections are up-to-date, you can use the find the required IP address. Furthermore, you could actually do a remote logon from one system to another.
If you’re just after the the IP address for the server, then you can find it in here. You can use the “Connection test” button to check if it’s “alive”.

hacking-the-saplogon-ini-file-4

You can use this RFC connection to gain remote access to the required system, i.e. if it’s created either with a blank set of credentials or with a current user as shown here.
If it has a set of credentials, it is most likely a communication user and should not be used.
Notice that you also have the option to maintain your own credentials directly on the RFC destination, but don’t do that. This is because everybody with access to SM59 would be able to use this connection to get access to the system with your credentials.

A note to the security guy
You can protect your systems from these kinds of backdoors by controlling the access to maintain RFC destinations with the authorization object S_RFC_ADM – this object should only be granted to a few administrators.
You control the access on the receiving system with the object S_RFC.

 

 

Author: