Problems with SSO after redirecting login through one SAP WebDispatcher

[ulrich_sander]

Hello

we are already using SNC/SSO2.0 successfully for our ABAP-Systems. Now we wan't to let our users login via a stand alone SAP-WebDispatcher. Let's assume this WebDipsatcher has the hostname "ServerA". We have setup the SAP-WebDispatcher so that the connections to our SAP-System (e.g. C11) works fine, but we have no sso yet. To get this done we have added this new SPN to the existing sso-Service-User.

setspn -S HTTP/ServerA /sap_srv_sso_c11

This was also OK, and we were able to login to C11 via SAP-WebDispatcher on ServerA.

Now we decided to route another SAP system (e.g. S11) via the same SAP-WebDispatcher on ServerA. The integration was done successfully, but again a password pop-up occurs. Now we tried to add the same SPN HTTP/ServerA to th other service user sap_srv_sso_s11.

setspn -S HTTP/ServerA /sap_srv_sso_s11

But this has failed. The error message was:

The operation failed because SPN value provided for addition/modification is not unique forest-wide.

I've tried to set an alias for ServerA (e.g. ServerB). Then I was able to execute the command

setspn -S HTTP/ServerB /sap_srv_sso_s11

but that didn't help for get SSO to be enabled on S11.

What can I do to get multiple Backend-Systems connected via one SAP-WebDispatcher all with SSO enabled?

Rgds

Ulrich Sander

[Colt]

Hi Ulrich,

this issue is mostly non-existent in environments that are using an embedded hub approach but often pops up when having a central SAP web dispatcher in place.

As a common best practice for SAP SSO, it is recommended to have a dedicated AD service account for each SAP system (SID) that normally has SPNs for SAP Logon like SAP/<SID> and HTTP/<FQDN> for browser-based access using SPNEGO.

This way you have a Kerberos key tab on each backend server being able to decrypt Service Tickets or SPNEGO-Tokens for both DIAG/RFC and HTTP connections.

Trying to register your SAP Web Dispatcher's FQDN as an SPN can be done only once as you have learned, that's because SPNs are unique in a AD forest 🙂 And as the client resolves the alias (C-NAME) back to the A-Record via DNS, this approach doesn’t help.

As a possible solution, you could introduce a proper DNS concept and thus make use of an additional DNS domain to expose your SAP applications through the central SAP Web Dispatcher.

1. In your DNS you set up for example saps11-wd.newdomain.int and sapc11-wd.newdomain.int… both are pointing (resolving) to the IP of your SAP WD and, this should be an A-Record.
2. In your AD service account for S11 (sap_srv_sso_s11) you register an additional SPN (http/saps11-wd.newdomain.int) and the same for C11 (http/sapc11-wd.newdomain.int)... This way the SPNs stay unique.
3. Finally, you set up your SAP Web Dispatcher for load distribution and automatic server selection via message server, acting as a central entry point for all HTTP (S) requests, centralize certificate management, provide URL filtering and masking (rewrite rules), perform whitelisting (protection of exposed ICF services) and caching and more…
4. You just need to make sure the DNS resolution works correctly on the SAP WD (maybe by using the IPs of the SAP backends or the hosts file).
5. This way your SAP Web Dispatcher is configured in such a way that it terminates all incoming HTTPS requests at the standard TLS port 443 and forwards the request to the correct SAP application servers ICM ports.
6. Also, you need a signed TLS certificate containing the multiple SANs with all the necessary DNS names (saps11-wd.newdomain.int; sapc11-wd.newdomain.int…) or just a wildcard certificate for *.newdomain.int.
7. Also, I recommend using TLS to secure the whole communication and to re-encrypt the traffic towards your SAP backends.

This could be one possible way and surely there are other ways to solve those requirements.

And BTW: you should really upgrade to SAP SSO 3.0 🙂

Hope that helps a bit.

Cheers Colt

[ulrich_sander]

Hi Carsten,

Thank you for the very profound answer. I've just one little question: Would it be sufficient to create S11001 not as alias of csapqd1wdp48 but a new hostname with the same ip address like csapqd1wdp48?

Rgds

Ulrich

[Colt]

Sounds possible 😉

[ulrich_sander]

OK - this was not successful. So will try your suggestion.

I've created a wdp.de.kostal.int as a subdomain of de.kostal.int.

In this domain is a host s11.wdp.kostal.int that is pointing csapqd1wdp48.de.kostal.int

After that the command

setspn -S HTTP/s11.wdp.de.kostal.int KOSTALROOT\svc_sap_sso_s11

should be executed successfully.

But how do I change my webdispatcher config?

I have two relevant lines:

wdisp/system_6 = SID=S11, EXTSRV=https://csaps11aas03.de.kostal.int:8103, CLIENT=001, SSL_ENCRYPT=1, SRCSRV=s11001:8903

icm/HTTP/redirect_7 = PREFIX=/, FROM=*, FOR=s11001, HOST=s11001, PORT=8903

Which "s1100" must be changed to "s11.wdp.de.kostal.int"? The FOR-part or the HOST-part? I guess the HOST-part because you told me add the new name to the SAN of the certificate.

Rgds

Ulrich

[cris_hansen]

Hi Ulrich,

The commands you shared are Microsoft related.

If SSO is not working, then you should check for what is happening in SAP software, i.e. using the web dispatcher trace (to check what is being sent from the browser to the web dispatcher and from wdp to the backend systems). In the backend system you can check for the ICM trace (like in wdp) and the security trace in the work processes (SM50 logon trace, per SAP Note 495911).

Checking the SAP traces will give you some insights on why SSO is not working for S11.

Regards,

Cris