UEM requests being blocked by SiteMinder
We are using SiteMinder in our environment with the BadCSSChars setting turned on. This setting is for cross-site scripting attacks and blocks characters like <>'. This is causing thousands of User Action Visit requests to be blocked with a 403 error since a lot of the requests contain these characters. The SiteMinder team will not disable this setting due to security concerns. dynaTrace support provided a configuration property (spc) under UEM that is supposed to encode these characters, but Siteminder can detect these characters whether they are encoded or not. Below is an excerpt of how the requests come in (%7C and %3C are the forbidden characters).
a=d%7Ckeypress%20%3CRETURN%3E%20on%20%22claimno%22%7Ckeypress%20%3CRETURN%3E%7C147740757_6
Has anyone else encountered this issue? If so, have you found a workaround?
Thanks,
Ben
Hi Ben
Can I ask what version of Dynatrace you are using?
Thanks
Mike
Great suggestion from Sreerag.
Another thought that comes to my mind is that you can setup a seprate Web Server, e.g: Apache - which you just use to collect the Monitoring Signal.
Andi
Andi, where can I find documentation on the setup you are suggesting? Also, do you know if there are any plans for a workaround? I was told by support to submit an enhancement request.
Thanks,
Ben
Hi Ben,
We have not faced such situation. My guess is that you need the DT agent intercept the /dynatraceMonitor requests before the siteminder.
May we know the technology used by the web servers? The basic idea would be to change the priority of the DT agent higher than siteminder agent so the DT agent can intercept the request before SM agent.
-Sreerag
We also do have siteminder; when i checked our httpd.conf i found that we are loading the siteminder module at the very end.
I think this explains why we never faced this issue.
-Sreerag
We tried placing the Siteminder module further below the dynaTrace webserver module in the httpd.conf file, but that didn't seem to help. We actually didn't realize we had this problem until we began using Splunk to monitor our webserver logs. The 403 errors don't appear in dynaTrace either.
