What happens when a user logs on? _audit shows they are "denied" several administrative actions just by logging on..

[lycollicott]

I was trying to audit my user base to find anyone in need of knuckle rapping or public flogging and I was stunned by the apparent number of really bad people. I didn't immediately lose my cool, but it was close. I kept digging and discovered that every time a non-administrator logs in that 27 events are logged for denied actions.

This:

index=_audit host=search_head* user=regular.user@what.com info=denied 
| chart count(info) by user,action useother=false limit=0 
| transpose header_field=user

gives me this summary of those actions:

column                  regular.user@what.com   
change_authentication           2
edit_indexer_cluster            2
edit_modinput_admon             1
edit_modinput_perfmon       1
edit_modinput_winhostmon        1
edit_modinput_winnetmon         1
edit_modinput_winprintmon   1
edit_roles                      3
edit_roles_grantable            3
edit_server                     1
edit_telemetry_settings             2
edit_user                       4
edit_win_eventlogs              1
edit_win_regmon                 1
edit_win_wmiconf                1
license_edit                    1
list_search_head_clustering         1 

Now that sort of defeats the purpose of my little auditing exercise, so what is the Splunk login process doing?

[damiensurat]

I think this splunk answer may help:

https://answers.splunk.com/answers/179911/how-to-audit-config-change-events-in-splunk-i-cant.html

http://docs.splunk.com/Documentation/Splunk/7.0.2/Security/AuditSplunkactivity

[lycollicott]

That link thinks such events are from checking permissions and that may very well be true, but it is not what the documentation actually says:

Audit events are generated from:

    all files in Splunk's configuration directory $SPLUNK_HOME/etc/*
        files are monitored for add/change/delete using the file system change monitor.
    system start and stop.
    users logging in and out.
    adding / removing a new user.
    changing a user's information (password, role, etc).
    execution of any capability in the system.
        capabilities are listed in authorize.conf

So, based on that, audit events are recorded for executions, not checks. If it really is recording checks from logins then that makes it really hard to spot actual denials.

[damiensurat]

I think this splunk answer may help:

https://answers.splunk.com/answers/179911/how-to-audit-config-change-events-in-splunk-i-cant.html