- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've tried to implement Splunk 6.2 SSO using Windows 2012R2 IIS Server. But when i try to access splunk via proxy the site does not load properly. I only get:
splunk>
Loading...
My Network consists of one Windows 2012R2 Server with Splunk 6.2/ IIS / ARR 3.0 / Helicon ISAPI_Rewrite 3.1 Lite. I've been following instructions from #Conf2014 "Passwords Are For Chumps: Using Single Sign-on" Video and slidedeck is available on http://conf.splunk.com/sessions/2014?r=conf_topnav_keynotessessions_2014sessions.
Everything looks fine with /debug/sso
Remote User HTTP Header REMOTE-USER
Value of REMOTE-USER erik
My ISAPI Config:
Helicon ISAPI_Rewrite configuration file
Version 3.1.0.104
RewriteHeader REMOTE_USER: .* $1
RewriteMap user int:tolower
RewriteCond %{REMOTE_USER} .\([^\]+)
RewriteHeader Remote-User: . ${user:%1}
RewriteBase /
What wrong with my setup ?
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We had issues with a apache proxy setup, trying to use SSO on 6.2, which worked perfectly on 6.1
"fix" was to run in legacy mode by adding appServerPorts = 0 to web.conf
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

SPL-92698 was fixed in 6.2.1
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
Just an update, our splunk was upgraded to 6.2.3 recently and it broke our SSO.
we had to use appServerPorts = 0 option for time being.
Thank you
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We had issues with a apache proxy setup, trying to use SSO on 6.2, which worked perfectly on 6.1
"fix" was to run in legacy mode by adding appServerPorts = 0 to web.conf
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

Please don't use appServerPorts=0 as a final fix, Legacy mode can be used as an interim workaround to minimize intruption to your service but the main underlying issue needs to be investigated and addressed.
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
How do we find the underlying issue so we don't need to use Legacy mode?
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
http://docs.splunk.com/Documentation/Splunk/6.2.1/ReleaseNotes/6.2.1
2014-10-28 PL-92730 Splunk 6.2 appears to break reverse proxy., SPL-92730
I have ticket open (199508), but no fix yet.
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Our problem has been fixed after receiving some tips from splunk support, we use a php script in combination with mod_rewrite to proxy.
It seems cookie handling has changed between 6.1 & 6.2
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
// Added for new splunk version to work.
curl_setopt($ch, CURLOPT_COOKIEFILE, '/tmp/splunk-cookie-'. session_id());
curl_setopt($ch, CURLOPT_COOKIEJAR, '/tmp/splunk-cookie-'. session_id());
//
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Unfortunately, we are using IIS and am not sure how to adapt this to work in our environment. I tried to search for IIS option for this, but came up empty handed.
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The issue appears to be with SSL, as going to http://iporservername:8000 works fine after the header has been rewritten, but not with https://iporservername. Hopefully, they will get this fixed soon as it is a bit of a pain.
