The problem lies with the way splunk stores the nameID attribute. This is a case sensitivity issue. When you first login, ADFS sends a login saml response that contains nameID like contoso\PMalcak Splunk then stores it as "/opt/splunk/etc/users/_reserved/contoso_pmalcak.some_guid_here" When you go to logout, splunk has already lost any knowledge of case sensitivity Upon logout, splunk sends ADFS a saml logout request that contains nameID like contoso\pmalcak ADFS uses nameID in case sensitive manner and as such is unable to process the logout request. Until Splunk fixes this bug, this has to be corrected on ADFS side. I am told the following from my ADFS guy who has figured out how to correct this: - can't fix it in ADFS v2 or v3 since in ADFS 2.0 and 3.0 it did not support $_.Tolower() ============================== Potential Fix #1 (did not work for us): 1) Compile a Custom Attribute store .dll per the MS article. https://docs.microsoft.com/en-us/previous-versions/adfs-2.0/hh599320(v=msdn.10) 2) Add the custom attribute store to ADFS Rule 1 use custom Rules for the relying party agreement. Rule 1 take the widnows account name from the pipeline and call the custome attribute store c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] => add(store = "StringProcessing", types = ("http://schema.local/windowsaccountname/lower"), query = "toLower", param = c.Value); Rule 2 Issue lower case windows account name as nameID @RuleTemplate = "MapClaims" @RuleName = "Name_id" c:[Type == "http://schema.local/windowsaccountname/lower"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"); ============================== Potential Fix #2 (did work for us): not proud of and shameful method with out the custom String Processing Attribute Store. Rule 1- 26 Feeding into each other @RuleName = "Convert Upper A to lower" c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] => add(Type = "http://schema.local/windowsaccountname/lower/A", Value = RegExReplace(c.Value, "A", "a")); @RuleName = "Convert Upper B to lower" c:[Type == "http://schema.local/windowsaccountname/lower/A"] => add(Type = "http://schema.local/windowsaccountname/lower/B", Value = RegExReplace(c.Value, "B", "B")); .........Repeat for each letter ....................... Rule 27 @RuleTemplate = "MapClaims" @RuleName = "Name_id " c:[Type == "http://schema.local/windowsaccountname/lower/Z" ] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"); I have no way of validating if any of the above is correct, but... he says that's what he did on his end... and logout now magically started to work, so I wasn't gonna question it. Hopefully this helps some other lost soul banging their head against the wall ... View more

I ran into same limitation myself. The "single capture group" setting is set in stone. You've got 2 options (that I know of): - if possible, use syslog-ng to rewrite your data before it is ingested by splunk (rearrange your event so that all the "junk" data you don't want segmented is at the beginning of your event) - use index-time TRANSFORMS-foo to rewrite your _raw so that your "junk" data is discarded or placed at the beginning of your event I haven't tried the second option, but according to (https://wiki.splunk.com/Community:HowIndexingWorks), index-time segmentation should be happening in annotator processor, which comes after regexreplacement processor , so it should work. ... View more

You were half-way there. The reason why your first approach fails is because [views] stanza functions counter-intuitively to splunk's usual config inheritance. What I mean by that is: [views/my_custom_view] does NOT inherit whatever setting you configured in [views] . Instead... in order for user to be able to access/see a view, he/she needs read access in both [views/my_custom_view] and [views] This behavior is documented at https://docs.splunk.com/Documentation/Splunk/latest/Admin/Defaultmetaconf It states: To access/use an object, users must have read access to: - the app containing the object - the generic category within the app (eg [views]) - the object itself If any layer does not permit read access, the object will not be accessible. ... View more