User And Authentication Management practice questions

In authorize.conf under the [role_power] stanza.

Why it fails: authorize.conf defines roles, not mapping logic.

In user-prefs.conf.

Why it fails: user-prefs.conf stores user-specific UI preferences.

In distsearch.conf.

Why it fails: distsearch.conf manages distributed search configurations.

Use a 'blacklist' in authorize.conf for the specific user.

Why it fails: Splunk does not support per-user blacklists for indexes in authorize.conf.

Modify the user's account and set the indexes access to 'none'.

Why it fails: This would remove access to all indexes.

Set the 'allow_index_access' capability to false for the user.

Why it fails: This capability does not exist in Splunk.

The user can still log in using their previous password.

Why it fails: If authentication is via LDAP, the LDAP server must validate the credentials.

The user account is automatically deleted from Splunk.

Why it fails: Splunk does not automatically prune local user objects based on LDAP changes.

The user is automatically promoted to the 'admin' role.

Why it fails: This would be a significant security vulnerability.

limits.conf

Why it fails: limits.conf has global limits, but role-specific limits are in authorize.conf.

server.conf

Why it fails: This relates to instance settings.

authentication.conf

Why it fails: This relates to authentication, not search performance.

user

Why it fails: The base user role does not have this capability.

can_view_settings

Why it fails: This is not a valid capability.

admin

Why it fails: While true for admins, the specific capability is 'edit_settings'.

Review the 'user-prefs.conf' file.

Why it fails: This is for user settings.

Check the 'internal' index for 'User management' events.

Why it fails: Authentication logs are in the 'audit' index.

Use the 'splunk login-history' CLI command.

Why it fails: This command does not exist.

ldap.conf

Why it fails: This file does not exist in the Splunk configuration space.

web.conf

Why it fails: This handles web settings.

authorize.conf

Why it fails: authorize.conf defines the roles themselves.

root

Why it fails: root is the default administrative account on Linux and Unix hosts, not within Splunk Enterprise itself. Splunk's own default privileged account is admin. root is tempting because it is the classic first-login account to secure on any Unix system, which is where the default-password warning genuinely applies.

manager

Why it fails: The manager account is not created by default in Splunk Enterprise; it is a role, not a built-in administrative user, so no default password exists to change. It is tempting because role names resemble accounts. The manager role is what you assign to users needing distributed-management capabilities across search peers.

splunk-system

Why it fails: splunk-system is not a Splunk Enterprise default account; the shipped administrative user is admin, whose password must be changed at first login. The name is tempting because Splunk services run under a system-level identity. splunk-system relates to service execution context, not interactive administrative sign-in.

SAML_Auth

Why it fails: This is a configuration setting.

Modify User.

Why it fails: This is not a capability name.

View Index.

Why it fails: This is not a capability name.

RADIUS

Why it fails: RADIUS is not natively supported for user authentication.

DNS-based auth

Why it fails: This is not a valid authentication method.

SQL database lookup

Why it fails: Splunk does not use SQL databases for authentication.

Deployment server status

Why it fails: Deployment server status is viewed under Settings > Forwarding and receiving, not Access Controls. It is tempting because deployment server management involves client configuration, which Access Controls governs for users, so it would be correct if the question asked about deployment client access.

Index volume settings

Why it fails: Index volume settings live under Settings > Indexes, not Access Controls. It is tempting because index access is controlled through roles, which Access Controls manages, so it would be correct if the question asked about restricting role-based index visibility.

Saved search scheduling

Why it fails: Saved search scheduling sits under Settings > Searches, reports, and alerts, not Access Controls. It is tempting because scheduling relates to search ownership and sharing permissions, which Access Controls does govern, so it would be correct if the question asked about search sharing.

LDAP Bind Password

Why it fails: Used for LDAP, not SAML.

The Splunk license key.

Why it fails: Unrelated to SAML.

It requires the user to be an LDAP admin.

Why it fails: This is a Splunk-specific capability.

It allows a user to delete the Splunk license.

Why it fails: License management is a separate privilege.

user

Why it fails: The user role is the default role for all new accounts and provides basic search capabilities over assigned indexes. It does not include the edit_user capability or any user management permissions. Assigning this role would prevent the junior administrator from performing any account administration tasks, which directly contradicts the requirement to delegate user management.

admin

Why it fails: The admin role contains the edit_user capability, but it also includes many other powerful capabilities such as edit_roles, edit_authentication, and edit_license, which allow changing system-wide configurations. Assigning this role to a junior administrator would grant far more access than necessary, violating the principle of least privilege and potentially allowing accidental or malicious changes to critical authentication or licensing settings.

power

Why it fails: The power role is intended for users who need to create and share searches, alerts, and reports, and it includes the edit_user capability only if explicitly granted. By default, the power role does not include user management capabilities, so it would not allow the junior administrator to create or manage user accounts. It also lacks many administrative permissions, making it unsuitable for this delegation scenario.

The user's LDAP password has expired, causing role mapping to be skipped.

Why it fails: If the password had expired, the user would not be able to authenticate at all. Since the user can log in, password expiration is not the cause. Role mapping occurs after successful authentication and is independent of password validity.

The LDAP strategy is configured to use a bind account that lacks permissions to read group membership attributes.

Why it fails: If the bind account lacked permissions, it would likely affect all users, not just one. Since other users are correctly mapped, the bind account has sufficient permissions. The issue is specific to this user, pointing to a group name mismatch.

The user has not been assigned any roles directly in Splunk, and LDAP group mapping is disabled by default.

Why it fails: LDAP group mapping is not disabled by default; it must be configured. The scenario states that other LDAP users are correctly receiving roles, so group mapping is enabled and working for others. Thus, this is not the cause.

Create two separate LDAP strategies, one for each organizational unit, and assign them to different roles.

Why it fails: Creating two LDAP strategies is unnecessary and complicates management. Splunk supports a single LDAP strategy that can search a broad base DN. Multiple strategies would require separate role mappings and may cause conflicts if a user exists in both OUs. This approach does not directly solve the requirement to authenticate users from both OUs with a single login.

Enable recursive searching and set the User Base DN to dc=example,dc=com.

Why it fails: While setting the base to dc=example,dc=com is correct, enabling recursive searching is not a separate Splunk LDAP setting. LDAP searches from a base DN are recursive by default (subtree scope) unless configured otherwise. The key is the base DN, not a checkbox. This option misleads by implying an extra step that does not exist.

Set the User Base DN to ou=employees,dc=example,dc=com and add a second User Base DN for the contractors OU.

Why it fails: Splunk's LDAP configuration accepts only one User Base DN per strategy. You cannot specify multiple base DNs in a single strategy. To cover both OUs, you must set the base to a common parent. Adding a second User Base DN is not supported and would not result in successful authentication for both groups.

Set 'srchIndexesAllowed' to 'web' and assign the 'share_report' capability.

Why it fails: The 'share_report' capability allows sharing reports, but it does not grant the ability to create reports. The user needs both 'reporting' to create and 'share_report' to share. This option only provides sharing, so the user cannot create new reports. Also, 'srchIndexesAllowed' is correct for index restriction, but the capability set is insufficient.

Set 'srchIndexesAllowed' to 'web' and assign the 'reporting' capability.

Why it fails: The 'reporting' capability allows creating reports, but sharing reports with other users requires the 'share_report' capability. Without 'share_report', the user can create reports but cannot share them. Additionally, 'srchIndexesAllowed' correctly limits index access, but the missing sharing capability makes this option incomplete for the stated requirement.

Set 'srchIndexesAllowed' to 'web' and assign the 'schedule_search' capability.

Why it fails: The 'schedule_search' capability allows scheduling searches, not creating and sharing reports. While 'srchIndexesAllowed' correctly restricts index access, the capability for creating and sharing reports is 'reporting' or 'share_report'? Actually, sharing reports requires 'share_report'? In Splunk, the capability to create reports is 'reporting'? The correct capability for sharing is 'share_report'? However, the question asks for creating and sharing reports, which typically requires 'reporting' and 'share_report'? But 'schedule_search' is for scheduled searches, not reports. So this option fails because it lacks the correct capability for report sharing.

Create a new role that inherits from 'power', set 'srchDiskQuota' to 100,000, and assign it to 'analyst'.

Why it fails: 'srchDiskQuota' limits the amount of disk space a user's searches can consume, not the number of events returned. Setting it to 100,000 would be a very large quota and would not enforce an event limit. Also, creating a new role that inherits from 'power' would not prevent the 'power' role's settings from applying if the user still has the original 'power' role.

Create a new role with the 'srchMaxResults' capability set to 100,000 and assign it to 'analyst' in addition to 'power'.

Why it fails: 'srchMaxResults' is not a valid capability or role setting in Splunk. Capabilities control feature access, not numeric limits. Even if such a setting existed, adding a role would not override the 'power' role's settings unless the new role explicitly restricted them, which is not how role inheritance works. This option invents a setting and misunderstands role precedence.

Edit the 'power' role and set the 'srchJobsQuota' to 100,000.

Why it fails: 'srchJobsQuota' controls the number of concurrently running search jobs, not the number of events returned. Setting it to 100,000 would not limit results and would also affect all users in the 'power' role. This option misidentifies the setting and does not meet the requirement to limit only the 'analyst' user.

user

Why it fails: The user role allows creating and managing one's own saved searches and alerts, but it does not include the capability to share them with other users. Sharing requires the 'share_global' or 'share_user' capabilities, which are not part of the user role by default. Therefore, it does not meet the requirement to share saved searches.

can_delete

Why it fails: The can_delete role is a built-in role that grants the ability to delete objects, but it does not provide the ability to create or manage saved searches. It is typically combined with other roles to allow deletion. It does not address the core requirements of creating, managing, and sharing personal saved searches.

admin

Why it fails: The admin role has broad capabilities, including editing and deleting objects owned by other users. While it meets the creation and sharing requirements, it violates the constraint of preventing the user from editing or deleting others' saved searches. The admin role is too permissive for this scenario.

Create role mappings in Splunk Web under Settings > Authentication > LDAP > Role Mapping.

Why it fails: Role mappings are not configured under Settings > Authentication > LDAP > Role Mapping. In Splunk, group-to-role mapping is typically done via the authentication.conf file or through the LDAP strategy configuration, not a separate Role Mapping page. This option describes a non-existent menu path.

Assign the 'admin' role to all LDAP users by default.

Why it fails: Assigning the 'admin' role by default would grant excessive privileges to all LDAP users, violating least privilege and security best practices. The goal is to map specific groups to specific roles, not to assign a high-privilege role universally. This approach would also bypass the intended group-based mapping.

Set the User Base DN to the same organizational unit as the groups.

Why it fails: The User Base DN defines where user accounts are located, not groups. While users and groups might reside in different OUs, the User Base DN is used for authentication searches. Setting it to the group OU would be incorrect if users are elsewhere; it does not directly affect group-to-role mapping.