SSO Broken after Upgrade to 4.3.1

[trutch]

We currently have a proxy set up with an SSO user as deteiled here: http://docs.splunk.com/Documentation/Splunk/latest/Admin/Usesinglesign-onwithSplunk

Some of our application teams use a proxy with SSO to display Splunk dashboards in an iframe on some of their sites. Prior to the 4.3 upgrade, the proxy worked as expected and all elements were displayed. Post upgrade, no search data is displayed but the static content displays properly. Accessing the dashboard without the proxy works fine.

I've looked over the changelog for 4.3 and couldn't find any related changes or issues. The SSO debug page isn't showing errors and I've tried reverting the charts on one of my dashboards to flash to no avail. Can anyone help me out?

[nmistry_splunk]

In 4.2 the default out of the box SSOMode was permissive $SPLUNK_HOME/etc/system/default/web.conf. In 4.3 this default SSOMode is strict. This might cause SSO to break when you upgrade.

If you add SSOMode = permissive under [settings] stanza in $SPLUNK_HOME/etc/system/local/web.conf file. It should make SSO work as expected.

[nmistry_splunk]

Thanks Malcolm.

[malmoore]

Documentation updated.

[johnqwest]

I know this is not the right way to fix this but with tomorrow as my deadline this works until I find a cleaner way.

I set this up today from a clean Splunk 4.3.1 (build 119532) and ran into a similar issue. After some web searching I found this page but no joy. I then grepped the install tree to find the string "have a matching splunk account with the same username" (a generalized excerpt from the error I received in web_service.log) which ended up in the below file:

$SPLUNK_HOME/lib/python2.7/site-packages/splunk/appserver/mrsparkle/lib/decorators.py

It seems at first blush there is a constant (REMOTE_USER_SESSION_KEY) set (line 22) without referencing the override parameter. I set this to:

REMOTE_USER_SESSION_KEY = 'REMOTE-USER'

and it fixed my issue.

Hopefully this helps you. I will submit a bug report or patch once I figure that out.

-John

[fervin]

This hack also isn't working for me on 4.3.3

[ruiaires]

I'm having the exact same problem.
I've tried to do the "hack" you mention but it has not worked. I've tested with both strict and permissive modes.

My original question is also posted here:
http://splunk-base.splunk.com/answers/49156/problems-with-sso-on-windows-cant-search

[johnqwest]

I was able to get a clean debug page by setting the remoteUser option but the login was not satisfied. I just downloaded the Splunk 4.3.2 (build 123586) and extracted this file which is identical to the one in Splunk 4.3.1 (build 119532.) Once I get time I will pursue the "right" fix. After pulling my hair for over an hour I thought I should share what worked for me (hopefully with no side effects.)

-John

[tmeader]

Odd. RSA SecurID's RADIUS server uses the non-standard format of "Remote-User", instead of "REMOTE-USER" for the header variable, and, even since upgrading from 4.2.x to (now 4.3.2), just setting the variable "remoteUser = Remote-User" in web.conf has continued to work fine.

[piebob]

assuming this upgrade was from 4.2.x to 4.3.1 (and not 4.3 to 4.3.1) the only thing i can think of offhand that might be impacting you in this situation is this:

http://docs.splunk.com/Documentation/Splunk/latest/Installation/Aboutupgradingto4.3READTHISFIRST#Spl...

[trutch]

Thanks for the response. The upgrade was from 4.2.3 to 4.3.1. I don't think the link you provided applies, as normal LDAP access works fine and I don't specify anything by IP. I only see the issues when I go through my proxy with SSO (as detailed here: http://docs.splunk.com/Documentation/Splunk/latest/Admin/Usesinglesign-onwithSplunk).

[tmeader · Accepted solution]

Can't find anything offhand, but the following might tangentially apply to SSO (from the known issues):

• Splunk Web modal dialog boxes are not compatible with protected web environments that use proxies and application layer gateways. (SPL-43365)
• The SSOMode=permissive setting does not allow Splunk Web access if the incoming client IP does not have a match in the trustedIP list. (SPL-46047)

For what it's worth, our SSO install appeared to survive the 4.2.5->4.3.1 upgrade unscathed.

[trutch]

I turned off https on one of my search heads and the proxy is functional again. Thanks!