Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Gateway Security: reginfo, secinfo, gw/acl_mode - how to set?

j_bayrhammer
Participant
0 Kudos

Hello,

our EWA complained Gateway Security Settings.

Gateway Access Control List (reg_info/sec_info) contains trivial entries

Parameter gw/acl_mode can be set to 1. SAP recommends setting gw/acl_mode to 1


So we set parameter gw/acl_mode to 1 which had the effect that default for files reginfo and secinfo got more restricted.


If gw/acl_mode=0 default is:

reginfo:

P TP=*

secinfo:

P TP=* USER=* USER-HOST=* HOST=*


If gw_acl_mode=1 default is:

reginfo:

P TP=* HOST=local

P TP=* HOST=internal

secinfo:

P TP=* USER=* USER-HOST=local HOST=local

P TP=* USER=* USER-HOST=internal HOST=internal


With these settings all is rejected so that created own files, that are less restrictive:

reginfo:

P TP=* HOST=local ACCESS=local,x.xx.*.*,%%RFCSERVER%%

P TP=* HOST=internal ACCESS=local,x.xx.*.*,%%RFCSERVER%%

secinfo:

P TP=* USER=* HOST=local,x.xx.*.*,%%RFCSERVER%% USER-HOST=local,x.xx.*.*,%%RFCSERVER%%

P TP=* USER=* HOST=internal,x.xx.*.*,%%RFCSERVER%% USER-HOST=internal,x.xx.*.*,%%RFCSERVER%%

All hosts from our network should have access.

But still we get reject messages in gateway log:

V Mon Aug 25 2014 20:01:17:721 created convid=52867721 (conn=11, act=23)

C Mon Aug 25 2014 20:01:17:721 client INIT (convid=52867721, lu=hostname.domain, tp=sapgw00, type=R3_CLIENT)

O Mon Aug 25 2014 20:01:17:721 open client connection (lu=%%RFCSERVER%%, tp=IGS.SID, type=R3_CLIENT)

R Mon Aug 25 2014 20:01:17:721 reject client: TP=IGS.SID not registered

Or:

V Fri Aug 22 2014 16:34:50:803 created convid=73395803 (conn=2, act=3)

C Fri Aug 22 2014 16:34:50:803 client INIT (convid=73395803, lu=hostname.domain, tp=sapgw00, type=R3_CLIENT)

O Fri Aug 22 2014 16:34:50:803 open client connection (lu=%%RFCSERVER%%, tp=WEBADMIN, type=R3_CLIENT)

R Fri Aug 22 2014 16:34:50:803 reject client: TP=WEBADMIN not registered

O Fri Aug 22 2014 16:34:50:803 open client connection (lu=hostname.domain, addr=x.xx.xxx.xxxx, tp=sapgw00, type=R3_CLIENT)

C Fri Aug 22 2014 16:34:50:803 STATISTIC (convid=73395803), bytes sent 0

C Fri Aug 22 2014 16:34:50:803 STATISTIC (convid=73395803), client sent 0 bytes in 0 packages

C Fri Aug 22 2014 16:34:50:803 STATISTIC (convid=73395803), server sent 0 bytes in 0 packages

V Fri Aug 22 2014 16:34:50:803 removed convid=73395803 (conn=2, act=2)

What does this mean? I maintained both files and added "%%RFCSERVER%%", but this didn't help.

Typically access works like this:

V Mon Aug 25 2014 20:01:17:453 created convid=52865453 (conn=23, act=22)

C Mon Aug 25 2014 20:01:17:453 client INIT (convid=52865453, lu=hostname.domain, tp=sapgw00, type=R3_CLIENT)

O Mon Aug 25 2014 20:01:17:453 open client connection (lu=hostname, addr=x.xx.xxx.xxxx, tp=sapdp00, type=R3_CLIENT)

C Mon Aug 25 2014 20:01:17:453 client ALLC (convid=52865453)

C Mon Aug 25 2014 20:01:17:453 client SEND (convid=52865453, length=28000)

C Mon Aug 25 2014 20:01:17:453 client SEND (convid=52865453, length=28000)

C Mon Aug 25 2014 20:01:17:453 send data to server (convid=52865453, length=28000, req_length=32000)

O Mon Aug 25 2014 20:01:17:453 open server connection (lu=hostname, addr=x.xx.xxx.xxxx, tp=sapdp00, type=R3_CLIENT)

But in rejected case there comes no "addr=...", just lu.

How do I have to maintain reginfo and secinfo to get this work?

Regards,

Julia

1 ACCEPTED SOLUTION

Former Member

Hi Julia,

This complaint in the EWA is in my opinion not correct.

See SAP Note 1480644. The same is achieved by setting the gw/no_reg_conn_info to a value greater than 1 and you should do that anyway. It forces you to have your own correct files in place as the local and internal defaults are insufficient.

Ideal is first create full access files. Then switch the gw/no_reg_conn_info to an acceptable level for you but at least to 1, then use the gw/sim_mode to simulate failures for a while and maintain the files. Then consolidate all files from the same network zone into 1 set of files and aggregate it and relax the constraints for TP programs which are acceptable and not a security threat. Park those files on a central server which SAP can only read from and locally change the gw/sec_info parameters to read the central file and not the local one anymore.

The syntax with %%RFCSERVER%% is also not correct. If an entry contains syntactically incorrect tags, then it is no longer evaluated  - so it does not work. I also see that you are using tabulators between the tags - this is a bit unreliable, rather use semi-colon.

Cheers,

Julius

16 REPLIES 16

Former Member

Hi Julia,

This complaint in the EWA is in my opinion not correct.

See SAP Note 1480644. The same is achieved by setting the gw/no_reg_conn_info to a value greater than 1 and you should do that anyway. It forces you to have your own correct files in place as the local and internal defaults are insufficient.

Ideal is first create full access files. Then switch the gw/no_reg_conn_info to an acceptable level for you but at least to 1, then use the gw/sim_mode to simulate failures for a while and maintain the files. Then consolidate all files from the same network zone into 1 set of files and aggregate it and relax the constraints for TP programs which are acceptable and not a security threat. Park those files on a central server which SAP can only read from and locally change the gw/sec_info parameters to read the central file and not the local one anymore.

The syntax with %%RFCSERVER%% is also not correct. If an entry contains syntactically incorrect tags, then it is no longer evaluated  - so it does not work. I also see that you are using tabulators between the tags - this is a bit unreliable, rather use semi-colon.

Cheers,

Julius

0 Kudos

Hello Julius,

thank you for your answer and your hints.

I maintained reginfo and secinfo after the reject messages with %%RFCSERVER%%-Entries. Now I removed them because there are still thes reject messages.

Between the tags there is no tabulator, just space. This is as SAP standard supposed.

But how do I have to maintain files that Requests from %%RFCSERVER%% will go through? At the moment they are rejected, because they come without "addr=...". TP are all open!

Thank you for the hint with the parameter gw/sim_mode - I could not remember this parameter was mentioned anywhere...

Regards,

Julia

0 Kudos

My recommendation would be to use the gw/sim_mode after setting the gw/reg_no_conn_info correctly. You will get the exact syntax for the tags from the gateway security trace, and not other noise from conversation IDs and other requests.

Believe me, semi-colons is a better option. Tabulators and spaces are unreliable in my experience and latest they produce problems when the external program or user name contains a space in it, which they can.

Regarding the gw/acl_mode, perhaps it makes sense to attract 's attention to this in the EWA and perhaps have it removed or made dependent on the gw/reg_no_conn_info at least?

Cheers,

Julius

0 Kudos

Hello Julius,

we will test this parameter gw/sim_mode and check if we get more information about "reject"-entries. Because parameter isn't already set we net a restart of SAP. After that I hope parameter is dynamically switable as announced in parameter documentation. RZ10 does not know this parameter although RZ11 shows documentation.

In notes 1480644, 1444282 I read, it is the same setting gw/acl_mode=1 like setting gw/reg_no_conn=16. So I think this should be for the beginning. But your're right - it's better to increase gw/reg_no_conn step by step.

Reginfo / secinfo should look like this?

reginfo:

P TP=*;HOST=local;ACCESS=local,x.xx.*.*

P TP=*;HOST=internal;ACCESS=local,x.xx.*.*

secinfo:

P TP=*;USER=*;HOST=local,x.xx.*.*;USER-HOST=local,x.xx.*.*

P TP=*;USER=*;HOST=internal,x.xx.*.*;USER-HOST=internal,x.xx.*.*

Regards,

Julia

0 Kudos

That syntax looks ok.

But you will have to add more TP tags still in which you relax the USER-HOST restraints, as several SAP scenarios do start and register specific programs from SOLMAN, BEX, own integration developments, etc.. Only those settings will not be enough.

Cheers,

Julius

0 Kudos

Hello Julius,

I thought these current settings in reginfo and secinfo open all possibilities for all servers from network x.xx.*.*?!

If TP=* all TP's can register - they can't?

At the moment we don't get any rejected entries in gatewaylog. It's not sufficient to check the gw_log* entries? Are there other logs I have to look in?

Confused regards,

Julia

0 Kudos

Ahha, now I know what xxx is... (it is normally also used as the netiquette for "hugs and kisses" so good that we clarified that... :-))

Well, if that is the network domain for the SAP servers then you have effectively isolated the servers to be able to communicate freely amongst each but block everything else.

You must however still consider that some clients accessing the gateway might be outside of the SAP server zone. This is often the case for BEX analyzer and some 3rd party software for mass processing which should not impact the SAP server (PDF generation, mass printing queues, etc).

If the clients and other communication servers are also all in this xxx network domain, then you will be fine but do have a very pragmatic gateway ACL approach. The EWA will however not complain about it as long as the parameters are set and the files exist.

Cheers,

Julius

0 Kudos

xoxo is normally used for hugs and kisses.

0 Kudos

Ahha, now I know what xxx is... (it is normally also used as the netiquette for "hugs and kisses" so good that we clarified that... :-))

I find it amsuing that for a technical security question you reactived with hugs and kisses instead of field masking. LOL!

0 Kudos

I actually was not aware that the gateway ACL files permitted a syntax of having multiple host names per record line separated by comma. I always thought a record per host name was needed.

So I thought Julia was just being friendly. Sorry for the confusion...  😉

Cheers,

Julius

0 Kudos

Hello Julius,

no worries - next time I will use xx and yy or mask it with faked network digits 🙂

Thank you for removing my confusion, so that these files work and for pointing to the servers standing outside of our network. I have to keep that in mind with the other servers.

Regards,

Julia

0 Kudos

Seems to work now.

After restart parameter gw/sim_mode is dynamically switchable.

Probably the last recected entries were triggered by restart of the machine.

From SAP I got a link for correct syntax in reg/secinfo:

Gateway Security Files secinfo and reginfo - Security Settings in the SAP Gateway - SAP Library

In Version #1 ',' (comma) or ' ' (space) are used as separators.

In Version #2 ',' (comma) or ' ' (space) are used as separators.

If the TP name itself contains spaces, you have to use commas instead.

Thanks for your help,

Regards,

Julia

0 Kudos

Hello Julia,

Can you please let us know how do we change the HOST=* to actual hostname in secinfo and reginfo files in SMGW t-code. Also after changing the parameters do we need a system bounce for this? how will it affect the environment?

Thanks,

Akshay Joglekar

0 Kudos

Hello Akshay Joglekar,

you can use HOST=local or/and HOST=internal.

I don't remember the difference, but I think you will find some about that.

After changes an in reginfo/secinfo and reread  you should restart Gateway (SMGW - Goto - Expert functions - hard/soft shutdown)  - a restart of whole system is not needed.

If you change parameters like gw/logging oder gw/sim_mode a restart of whole system is needed.

Impact of environment is that only systems registered in reginfo/secinfo will have access to the server.

Regards,

Julia

0 Kudos

Hi Julia,

So Changing HOST for secinfo and reginfo won't affect any performance issue in any components like BI/ECC.

Regards,

Akshay Joglekar

0 Kudos

Hello Akshay Joglekar,

I can't tell you that. Check this on your test system landscape.

We had miscellaneous problems after activating security gateway environment, but we tried first in test system.

Regards,

Julia