User, Role, and Authentication Management
Users, roles, capabilities
A user is granted one or more roles; each role bundles capabilities such as search, schedule_search, edit_user, delete_by_keyword, or admin_all_objects. Effective permission is the union of all assigned and inherited roles - there are no deny rules, so adding a role can only broaden access. Default roles include admin, power, user, and can_delete; roles may inherit from other roles.
Authentication
Splunk supports its own user store plus LDAP, SAML, Kerberos, proxy SSO, and multi-factor authentication. Settings > Authentication selects the method, with detail in authentication.conf: password policy, failed-login lockout, session timeout, and role mapping from identity-provider attributes. With SAML and LDAP, accounts can be created at first login and mapped to roles.
Traps
- Enabling external authentication and leaving no local break-glass admin account.
- Confusing authentication (identity) with authorization (capabilities and object permissions).
- Expecting a restrictive role to subtract a capability granted by another role.
- Forgetting that token/JWT authentication is a separate mechanism from user passwords.
- Overlooking app/object sharing permissions when a user cannot see a lookup or saved search.
Rule of thumb
| rest /services/authentication/current-context shows the logged-in user's roles and capabilities. From the CLI, splunk list role and splunk edit user <name> -role <role> handle most administration. When someone cannot see an object, check both role capabilities and the object's .meta sharing.