Issue running NW Gateway in DMZ domain

[Former Member]

I am working on an implementation of NW Gateway and have run into an issue which I would think that others have run into and overcome.  The architecture we decided to go with from the beginning is to have Gateway in DMZ with reverse proxy to that system, rather than in the same domain as our backend systems.

For the RFCs from Gateway to backend we did not want to use a single user, which I understand is against SAP license for this purpose anyway, so I set the RFC to use SNC, that way the user connecting to gateway is passed to the backend and authorizations are checked against their user ID.  The SPN for both systems is setup correctly and RFCs work before setting SNC.  My understanding of what is causing this issue is the attempt to use SPNs across domains.  The research that I have been doing tells me that in order for SPNs to be accepted by either system there needs to be domain trust or the systems need to be in the same domain.  We will not setup a trust between DMZ and the domain where SAP lives for obvious reasons and our network security team does not want us to put an Internet facing server in the domain with our other SAP systems.

Because of this issue, I am exploring other options.

For others out there that have used a similar scenario, how do you have Gateway configured to connect to your backend?

For those of you that have an Internet facing Gateway in the same domain as your backend, what do you do to prevent attackers from breaking into your domain?

[Private_Member_12198 · Accepted solution]

Do you need to use SPN? You also can use X509 (certificates) with SNC. The certificates may even be generated by a small local CA, or even only within SAP (STRUST).

Best regards,

Jürgen

[Former Member · Accepted solution]

Hi Jurgen,

Thanks for your reply!  I do know that for client/server SSO X.509 can be used, but my understanding of using SNC from server to server was that I must use SPN.  I will look further into this and try out your suggestion.  That can be a viable solution if it will work.

Thanks,

Derek

[Former Member · Accepted solution]

Thanks again for your reply, Jurgen.  I did a bit of research on this and found that it may be possible to use X.509 for this.  However, we decided to go a much simpler route and move the Gateway to the same domain as our backend systems, which will eliminate this issue, using reverse proxy to send requests to Gateway and filter requests on our load balancer for a bit of added security.