Routing SGMAP requests to the SAS OSM servers

[Nigel_Pain]

SAS 9.4M7 on Windows server 2019

Enterprise Guide 8.3 on Windows 10

SAS Studio 3.81 Enterprise Edition

We are having problems enabling users to pull Open Street Map mapping into PROC SGMAP output. By default servers in our environment do not have direct access to the public internet, so we have rules on the proxy servers to allow access by our SAS servers to the SAS OSM servers. This was actually set up to allow geomapping in Visual Analytics (and that works fine). But what we're finding is that this fails for ordinary users, but not for user accounts which are configured for server admin - these are in a different active directory container. I don't have much understanding of how proxies work but here's the analysis from our proxy admins:

When a user attempts to load a map using PROC SGMAP, the map is not rendered in the client. On inspecting the traffic on the SAS server using wireshark during the failure, the following behaviour is noted :-

The SAS server issues DNS lookup requests to its OS configured name servers for opnsta.sas.com and gets a no such name response. The name servers are internal and cannot perform public DNS resolution. This is by design and a security configuration. Hence if an internal resource needs to connect to an internet website, it must use a secure proxy server.

After the first DNS answer, it then performs a DNS query for the server which hosts the PAC file from our internal DNS server and gets a valid response. It downloads the PAC file.

Whilst it is downloading the PAC file it sends two further DNS lookups to internal DNS for opnstc.sas.com and then openstb.sas.com which both return no such name.

It then connects to the proxy server gleaned from the PAC file. However it does not parse these correctly. The PAC file is configured to return back to the requesting application PROXY name.of.our.proxy:portnumber (i.e. use this as a proxy server). But the application appears to receive the PROXY name.of.our.proxy:portnumber returned and then tries to connect to it as a webserver which fails as it isn't one.

It should be noted that the admin users (for whom the functionality works) don't have a PAC file configuration and so calls are directed straight to the proxy server. Has anyone had a similar experience, and did you find a resolution? I haven't had much luck with TS, because they say that there's no configuration options for PROC SGMAP and it just sends a straight call to the internet.

Thanks

[SASKiwi]

How far did this go at Tech Support? The fact that it works in VA but not in Base SAS suggests there is a different mechanism being used and comparing them may help. If TS hasn't escalated the problem, maybe push for that?

Maybe discussing this with an Info Security expert where you work, comparing admin and normal account AD permissions might uncover the reasons.

[Nigel_Pain]

Thanks for the response @SASKiwi .

My understanding from Tech Support was that PROC SGMAP simply sends a request to the SAS OSM servers. The main difference between normal and admin accounts is that normal ones are configured to use a PAC file and this is what's causing the issue. Admin accounts don't have that setting and so they automatically get routed to the proxy. They did say that others had had this issue in the past, so I was wondering if one of them would appear here and say how (if?) they'd managed to fix it.

VA works because there are configuration settings for the JVM which routes requests via a proxy. In the wrapper.conf for the web app server:

wrapper.java.additional.53=-Dhttp.proxyHost=our.proxy.fqdn 
wrapper.java.additional.54=-Dhttp.proxyPort=80
wrapper.java.additional.55=-Dhttp.nonProxyHosts="localhost|127.0.0.1|*.our.domain"

[gwootton]

I wonder if SGMAP would use the HTTP_PROXY/HTTPS_PROXY/NO_PROXY environment variables if set. For example:
options set=HTTP_PROXY "http://our.proxy.fqdn:80";
options set=NO_PROXY "localhost,127.0.0.1,.our.domain";

[Nigel_Pain]

Thanks @gwootton , that was a good thing to try. But sadly it made no difference. 

[Nigel_Pain]

More information on this. The proxy administrator and I had another look at things and it appears that the main issue is that when a user starts a SAS session for the first time a local profile is created for them on the compute server. However, this doesn’t include the important Internet Options covering the PAC file and proxy server (Control Panel, Internet Options, Connections tab, LAN Settings). If a user subsequently logs in to a full user session on the server (eg. using RDP) then the profile gains these settings, and thereafter they can download the maps.

I don’t imagine there’s much we can do about this, as we can’t control what parts of a user profile are created when they are logging on as batch, and only local admins on the compute server can get an RDP session on the server. So it seems we are stuck.

[gwootton]

In looking online you might be able to use runas to get a profile without the user logging on to the host:

runas /env /profile /user:<domain>\<username> cmd.exe

https://merserver.com/index.php/2022/11/01/windows-create-a-user-profile-without-logging-in-as-the-u...

[Nigel_Pain]

That does seem to work (I tried it with my ordinary user account). But I'd need to know the person's password. There's no way I can do that.