Still an issue in 9.3.2   The concept of "ignore all INFO level" messages doesn't sit with me well as a solution, there are useful messages at that level. ... View more

1. Normally a non-admin user should not have this capability. This is normally used for maintaining credentials which are used for third party integrations (modular inputs, custom alert actions). 2. This works for credentials managed in the official Splunk way. If - for some reason - an addon developer decided to do something "their own way" (for example - decided that for each run of an input, it will pull credentials from a github project; no, that's not a real example but nothing is forbidding an addon author from inventing anything, no matter how stupid), that will most probably not be limited by this capability. 3. Obviously if there are credentials for access stored for use in automated way, you should have additional controls implemented on the destination system mitigating risk of abuse of those credentials. Their use of course should based on the rule of least required privilege and ideally they should be limited per IP. At the very least, if there is no other way, their use in the destination system should be monitored and reviewed regularly. ... View more

Gravedigging for karma / answering questions left unanswered: This would be set in most cases on the receiving indexers props.conf.  And you are very right, in no case should ../default/ be modified. Create a ../local/ or a whole new app if you'd like with a ../local/props.conf If all you do is modify a local props.conf by adding a sourcetype stanza with TZ, there's no requirement to restart splunk, it should detect that change on its own. ... View more