Skip to end of metadata
Go to start of metadata


Help with the understanding of the Gateway ACLs (Access Control Lists) and the Simulation Mode, in order to help prepare production systems to have these security features enabled without disruptions.


This page contains information about the Gateway ACLs (reginfo and secinfo files), the Simulation Mode, as well as the workflow showing how the Gateway works with regards to the ACLs versus the Simulation Mode.

Additional ACLs are discussed at this WIKI page. This is for clarity purposes.

Observation: in emergency situations, follow these steps in order to disable the gateway security.

Gateway ACLs (reginfo and secinfo)

This section contains information about the Gateway ACLs, and examples of landscapes and rules.

The reginfo file have ACLs (rules) related to the registration of external programs (systems) to the local SAP instance. For example: an SAP SLD system registering the SLD_UC and SLD_NUC programs at an ABAP system.

The secinfo file has rules related to the start of programs by the local SAP instance. In other words, the SAP instance would run an operating system level command. For example: the RFC destination (transaction SM59) “CALL_TP_<operating system>” starts the “tp” program, which is used by the SAP Transport System (transaction STMS).

Before jumping to the ACLs themselves, here are a few general tips:

  • The very first line of the reginfo/secinfo file must be "#VERSION=2";
  • Each line must be a complete rule (you cannot break the rule into two or more lines);
  • The gateway will apply the rules in the same order as they appear in the file, and only the first matching rule will be used (similar to the behavior of a network firewall). All subsequent rules are not even checked. This means that the order of the rules is very important, especially when general definitions are being used (“TP=*”);
  • Each instance should have its own security files, with their own rules, as the rules are applied by the Gateway process of the local instance. However, if in your scenario the same rules apply to all instances of the system, you can use a central file (see the SAP note 1425765);
  • The first letter of the rule can be either P (for Permit) or D (for Deny). You don’t need to define a “deny all” rule at the end, as this is already implicit (if there is no matching Permit rule, and the Gateway already checked all the rules, the result will be Deny – except when the Simulation Mode is active, see below).

    The syntax of the rules is documented at the SAP note 1408081. There are other SAP notes that help to understand the syntax (refer to the “Related notes” section below).

A general reginfo rule definition would be (note that the rule was split into multiple lines for explanation purposes, so it is more easily understood):

P TP=<program name>
  HOST=<comma separated list of hosts that can register the program>
  ACCESS=<comma separated list of hosts that can communicate with the program>
  CANCEL=<comma separated list of hosts that can cancel this registration>


Usually, ACCESS is a list with at least all SAP servers from this SAP system. This can be replaced by the keyword "internal" (see examples below, at the "reginfo" section). It might be needed to add additional servers from other systems (for an SLD program – SLD_UC, SLD_NUC, for example).

CANCEL is usually a list with all SAP servers from this system (or the keyword "internal"), and also the same servers as in HOSTS (as you must allow the program to de-register itself).

A general secinfo rule definition would be (note that the rule was split into multiple lines for explanation purposes, so it is more easily understood):


P USER=<username that is allowed to start the program>
/* read the explanation for USER at the SAP note 614971 for more details */
  USER-HOST=<comma separated list of hosts from where the users can start the program>
  HOST=<comma separated list of hosts where the program can be started>
  TP=<program name>


Go to Secinfo section

Go to Simulation Mode section

Reginfo – Landscape and Example

You have a Solution Manager system (dual-stack) that you will use as the SLD system. The Solution Manager (“SolMan”) system has only one instance, running at the host “sapsmci”.

You have configured the SLD at the Java-stack of the SolMan system, using the Gateway of the SolMan’s ABAP-stack.

There is an SAP PI system that needs to communicate with the SLD. The PI system has one Central Instance (CI) running at the server “sappici”, and one application instance (running at the server “sappiapp1”). The RFC destination “SLD_UC” looks like the following, at the PI system:



No reginfo file from the PI system is relevant. Since the SLD programs are being registered at the SolMan’s CI, only the reginfo file from the SolMan’s CI is relevant, and it would look like the following:

P TP=SLD_UC HOST=local ACCESS=internal,sappici,sappiapp1 CANCEL=local
# This must always be the last rule on the file – see SAP note 1408081
P TP=* HOST=internal,local CANCEL=internal,local ACCESS=internal,local


The keyword “local” means “the local server”. The keyword “internal” means “all servers that are part of this SAP system” (in this case, the SolMan system). Notice that the keyword "internal" is available at a Standalone Gateway (like the Gateway process that runs at an SCS or ASCS instance) only after a certain SAP kernel version. Refer to the SAP Notes 2379350 and 2575406 for the details.

Another example: you have a non-SAP tax system that will register a program at the CI of an SAP ECC system. The name of the registered program will be “TAXSYS”. The tax system is running on the server “taxserver”. The reginfo rule from the ECC’s CI would be:

P TP=TAXSYS HOST=taxserver ACCESS=internal CANCEL=local,taxserver


The rule above allows any instance from the ECC system to communicate with the tax system. If other SAP systems also need to communicate with it, using the ECC system, the rule need to be adjusted, adding the hostnames from the other systems to the ACCESS option. For example:


P TP=TAXSYS HOST=taxserver ACCESS=internal,host1,host2 CANCEL=local,taxserver


The SAP KBAs 1850230 and 2075799 might be helpful. They also have a video (the same video on both KBAs) illustrating how the reginfo rules work.

Changes to the reginfo rules

Changes to the reginfo rules are not immediately effective, even after having reloaded the file (transaction SMGW, menu Goto -> Expert functions -> External security -> Reread / Read again).

After reloading the file, it is necessary to de-register all registrations of the affected program, and re-register it again. This is required because the Gateway copies the related rule to the memory area of the specific registration. If you have a program registered twice, and you restart only one of the registrations, one of the registrations will continue to run with the old rule (the one that was not restarted after the changes), and another will be running with the current rule (the recently restarted registration). This would cause "odd behaviors" with regards to the particular RFC destination.

For example: you have changed to the rule related to the SLD_UC program, allowing a new server to communicate with it (you added the new server to the ACCESS option). You have already reloaded the reginfo file. However, you still receive the "Access to registered program denied" / "return code 748" error. The solution is to stop the SLD program, and start it again (in other words, de-register the program, and re-register it).

Go to the top of the page

Secinfo – Landscape and Example

You have a non-SAP tax system that needs to be integrated with SAP. Such third party system is to be started on demand by the SAP system.

Only the (SAP level) user IDs “BOB” and “JOHN” can start this program, and they will be logged on to one of the instances from this SAP system.

You have an RFC destination named “TAX_SYSTEM”. It is configured to start the tax calculation program at the CI of the SAP system, as the tax system is installed only there. The RFC destination would look like:



The secinfo files from the application instances are not relevant. Only the secinfo from the CI is applicable, as it is the Gateway from the CI that will be used to start the program (check the “Gateway Options” at the screenshot above).

Note: depending on the system’s settings, it will not be the Gateway itself that will start the program. However, the Gateway would still be involved, and it would still be the process to enforce the security rules.

The secinfo file from the CI would look like the below:

P USER=BOB USER-HOST=internal HOST=local TP=/usr/taxsys/taxcalc
P USER=JOHN USER-HOST=internal HOST=local TP=/usr/taxsys/taxcalc
# This must always be the last rule on the file – see SAP note 1408081
P USER=* USER-HOST=internal,local HOST=internal,local TP=*

In case you don’t want to use the keywords “local” and “internal”, you’ll have to manually specify the hostnames. For example: the system has the CI (hostname “sapci”) and two application instances (hostnames “appsrv1” and “appsrv2”). The rules would be:


P USER=BOB USER-HOST=sapci,appsrv1,appsrv2 HOST=sapci TP=/usr/taxsys/taxcalc
P USER=JOHN USER-HOST=sapci,appsrv1,appsrv2 HOST=sapci TP=/usr/taxsys/taxcalc

Another example: let’s say that the tax system is installed / available on all servers from this SAP system, the RFC destination is set to “Start on application server”, and the “Gateway options” are blank. This way, each instance will use the locally available tax system.

In this case, the secinfo from all instances is relevant as the system will use the local Gateway of the instance the user is logged on to start the tax program. The secinfo file would look like:

P USER=BOB USER-HOST=local HOST=local TP=/usr/taxsys/taxcalc
P USER=JOHN USER-HOST=local HOST=local TP=/usr/taxsys/taxcalc
# This must always be the last rule on the file – see SAP note 1408081
P USER=* USER-HOST=internal,local HOST=internal,local TP=*


The usage of the keyword “local” helps to copy the rule to all secinfo files, as it means “the local server”. In case you don’t want to use the keyword, each instance would need a specific rule. Here are some examples:

  • At the application server #1, with hostname “appsrv1”:

    P USER=BOB USER-HOST=appsrv1 HOST= appsrv1 TP=/usr/taxsys/taxcalc
    P USER=JOHN USER-HOST=appsrv1 HOST= appsrv1 TP=/usr/taxsys/taxcalc
  • At the application server #2, with hostname “appsrv2”:

    P USER=BOB USER-HOST=appsrv2 HOST= appsrv2 TP=/usr/taxsys/taxcalc
    P USER=JOHN USER-HOST=appsrv2 HOST= appsrv2 TP=/usr/taxsys/taxcalc

The SAP KBA 2145145 has a video illustrating how the secinfo rules work.

Go to the top of the page

Simulation Mode

To avoid disruptions when applying the ACLs on production systems, the Gateway has a Simulation Mode. The SAP note 1689663 has the information about this topic.

In summary, if the Simulation Mode is deactivated (parameter “gw/sim_mode = 0”; default value), the last implicit rule from the gateway will be “Deny all” as mentioned above, at the “Gateway ACLs (reginfo and secinfo)” section.

If the Simulation Mode is active (parameter “gw/sim_mode = 1”), the last implicit rule will be changed to “Allow all”. In addition, the Gateway logging (see the SAP note 910919) can be used to log that an external program was registered, but no “Permit” rule existed.

It is important to mention that the Simulation Mode applies to the registration action only. After the external program was registered, the ACCESS and CANCEL options will be followed as defined in the rule, if a rule existed.

In addition, the existing rules on the reginfo/secinfo file will be applied, even on Simulation Mode. Thus, if an explicit Deny rule exists and it matches the request being analyzed by the Gateway, the Gateway will deny the request.

Gateway behavior versus Gateway parameters

There are two parameters that control the behavior of the gateway with regards to the security rules. They are:

  • gw/acl_mode: this parameter controls the value of the default internal rules that the Gateway will use, in case the reginfo/secinfo file is not maintained. In case the files are maintained, the value of this parameter is irrelevant;
  • gw/sim_mode: activates/deactivates the simulation mode (see the previous section of this WIKI page).

The diagram below shows the workflow of how the Gateway works with the security rules and the involved parameters, like the Simulation Mode.



Related Content

Related Documents

SAP Gateway Security Files secinfo and reginfo

Configuring Connections between Gateway and External Programs Securely

Gateway security settings - extra information regarding SAP note 1444282

Additional Access Control Lists (Gateway)

Disabling gateway security

Reloading the reginfo - secinfo at a Standalone Gateway

Related Notes

SAP note 1689663: GW: Simulation mode for reg_info and sec_info

SAP note 1444282: gw/reg_no_conn_info settings

SAP note 1408081: Basic settings for reg_info and sec_info

SAP note 1425765: Generating sec_info reg_info

SAP note 1069911: GW: Changes to the ACL list of the gateway (reginfo)

SAP note 614971: GW: Changes to the ACL list of the gateway (secinfo)

SAP note 910919: Setting up Gateway logging

SAP KBA 1850230: GW: "Registration of tp <program ID> not allowed"

SAP KBA 2075799: ERROR: Error (Msg EGW 748 not found)

SAP KBA 2145145: User is not authorized to start an external program

SAP KBA 2605523: [WEBINAR] Gateway Security Features

SAP Note 2379350: Support keyword internal for standalone gateway

SAP Note 2575406: GW: keyword internal on gwrd 749

SAP Note 2375682: GW: keyword internal lacks localhost as of 740


  1. ooohhh my god, (It could not have been more complicated -obviously the sequence of lines is important): 


    why the simple comment

    "# This must always be the last rule on the file – see SAP note 1408081" + next line content 

    is not included as comment within the default-delivered reginfo file or secinfo file (after installation) -

    this would save a lot of wasted life time

    (sad)   (shaking my head in disbelief)



    gw/acl_mode:      ( looks like to enable/disable the complete gw-security config, but )

    this parameter controls the value of the default internal rules that the Gateway will use, in case the reginfo/secinfo file is not maintained. In case the files are maintained, the value of this parameter is irrelevant;

    (sad)   (shaking my head in disbelief)



    and with parm gw/reg_no_conn_info, all other sec-checks can be disabled => SAP note 1444282 

    obviously this parm default is set to 1 ( if not set in profile file ) in kernel-773

    (sad)   (shaking my head in disbelief)


    I wasted a whole day unsuccessfully trying to configure the (GW-Sec) in a new system

    sorry for my bad mood. (any helpful wiki is very welcome, many thanks to Isaias Freitas)

    where ist the hint or wiki to configure a well runing gw-security ?


  2. Obviously, if the server is unavailable, an error message appears, which might be better only just a warning,

    some entries in reginfo and logfile dev_rd shows (if the server is noch reachable) 


    NiHLGetNodeAddr: to get 'NBDxxx' failed in 5006ms (tl=2000ms; MT; UC)
    *** ERROR => NiHLGetNodeAddr: NiPGetHostByName failed (rc=-1) [nixxhl.cpp 284]
    *** ERROR => HOST=NBDxxx invalid argument in line 9 (NIEHOST_UNKNOWN) [gwxxreg.c 2897]


    if the server is available again, this as error declared message is obsolete. so for me it should only be a warning/info-message.

    1. Hello Christoph,

      About item #1, I will forward your suggestion to Development Support. Thank you!

      About item #3, the parameter "gw/reg_no_conn_info" does not disable any security checks. If you set it to zero (highly not recommended), the rules in the reginfo/secinfo/proxy info files will still be applied. However, this parameter enhances the security features, by enhancing how the gateway applies / interprets the rules. Giving more details is not possible, unfortunately, due to security reasons.

      About the second comment and the error messages, those are messages related to DNS lookup.
      I believe that these are raised as errors because they have occurred during the parsing of the reginfo file. Thus, part of your reginfo might not be active.
      The gateway is logging an error while performing name resolution.
      The operating system / DNS took 5 seconds to reply - 5006ms per the error message you posted; and the response was "host unknown".
      If the "HOST" argument on the reginfo rule from line 9 has only one host, then the whole rule is ignored as the Gateway could not determine the IP address of the server.
      Kind regards,