- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
SAML and logs flooded with warnings: AQR and authentication extensions not supported. Or authentication extensions is su
We have enabled Microsoft SAML for Splunk and out splunkd.log seems to be flooded with warnings like this:
WARN UserManagerPro [7456 SchedulerThread] - AQR and authentication extensions not supported. Or authentication extensions is supported but is used for tokens only. user=nobody information not found in cache
Found a few threads on AQR:
- https://community.splunk.com/t5/Monitoring-Splunk/What-is-quot-AQR-quot-and-why-is-it-throwing-warni...
Also the documentation on authentication.conf does not help me much. It seems the only way is to create a low level user (same as mentioned in the error) to suppress the error, which seems doable but I doubt this is the best way and unsure of side effects?
Does any of you know more?
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@wwangsa_splunk Thanks very much for the update, but AFAICT the current release is already 9.3.0 Is it also incorporated in that branch?
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

Hi there,
A quick search of the Splunk Knowledge base find this article:
https://splunk.my.site.com/customer/s/article/AQR-errors-in-internals-logs
Workaround -
I. To find the orphaned Knowledge Objects -
1. Select Settings > All configurations.
2. Click Reassign Knowledge Objects.
3. Click Orphaned to filter out non-orphaned objects from the list.
4. After filtering out the Orphaned KO we have to reassign them to the active users.
II. Reassign knowledge objects to another owner -
1. For the knowledge object that you want to reassign, click Reassign in the Action column.
2. Click Select an owner and select the name of the person that you want to reassign the knowledge object to.
3. Click Save to save your changes.
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That is no relevant to my case since I have no orphaned knowledge base items. Just checked with the instruction from the knowledge base and even with all filters set to 'All' the list turns up empty.
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Were you able to resolve this? I'm having the same issue.
Thanks.
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No, unfortunately not. It is bothering but can be worked around by using Splunk itself to analyze the logs and ignore that message at search time.
This will show all messages w/o INFO and the before mentioned messages:
index="_internal" sourcetype=splunkd NOT INFO NOT "AQR and authentication extensions not supported. Or authentication extensions is supported but is used for tokens only"
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
By now found out that creating the user `nobody` is not allowed by Splunk, it throws the following error when creating such a user:
Create user: The user="nobody" is reserved by the splunk system
- Mark as New
- Bookmark Message
- Subscribe to Message
- Mute Message
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

Hi @jmartens ,
Very sorry for the inconvenience.
Engineering is aware of this (reference: SPL-258019). They have come up with a fix, which excludes the 2 internal users, 'nobody' and 'splunk-system', from the warning message.
The fix will most likely be added to the next 9.1.x version after 9.1.6 and the next 9.2.x version after 9.2.3, respectively.
