User Status Detection in Splunk React App with LDAP/SAML Authentication

[sanjai]

Hi Splunk Community,

I’m developing a User Management React application using the Splunk React UI framework, intended to be used inside a custom Splunk App. This app uses the REST API (/services/authentication/users) to fetch user details.

What I’ve Done:
In my local Splunk instance (where users are created manually with Authentication System = Splunk),  for testing the app ,each user object contains a "locked-out" attribute.
I use this attribute to determine account status:

• "locked-out": 0 → User is Active

• "locked-out": 1 → User is Locked

This works as expected in my local environment.

The Issue:
When testing the same app on a development Splunk instance that uses LDAP authentication, I noticed that LDAP user accounts do not contain the locked-out attribute.

Because of this, my app incorrectly assumes the user is locked (my logic defaults to "Locked" if the attribute is missing).

My Questions:

1. Do LDAP or SAML user accounts in Splunk expose any attribute that can be used to determine if the account is locked or active?
   If not, is there any workaround or recommended practice for this scenario?

2. Is there a capability that allows a logged-in user to view their own authentication context or session info?
   I’m aware of the edit_user capability, but that allows users to modify other users, which I want to avoid. ( the below image user does't have the Admin role how can it shows the USER AND AUTH menu)

   

   Table from custom react app(lists only currently logged in user)

   

3. What is the expected behavior when an LDAP or SAML user enters the wrong password multiple times?

   • For Splunk-native users, after several failed login attempts, the "locked-out" attribute is set to 1.

   • For LDAP/SAML users, even after multiple incorrect login attempts, I don’t see any status change or locked-out attribute.

Is this expected? Are externally authenticated users (LDAP/SAML) not "locked" in the same way as Splunk-native accounts?

Scenario Tested:

• Logged in with correct username but incorrect password (more than 5 times).

• Splunk-authenticated user: "locked-out" attribute appears and is set to 1.

• LDAP-authenticated user: no attribute added or updated; no visible change to user status.

Goal:
I want the React app to accurately reflect account status for both Splunk-native and LDAP/SAML users. Looking for best practices or alternative approaches for handling this.

Let me know if you additional details about my question😊

Thanks in advance,
Sanjai😊

[sanjai]

My current understanding of the solution is as follows — please correct me if I’m wrong:

• If the authentication type is SAML or LDAP, the user is always considered active (i.e., the account cannot be locked through Splunk (multiple failed login attempts).

• If the authentication type is Splunk, then the user can be either Active or Locked-out, based on the "locked-out" attribute.

Therefore, I need to update my logic accordingly:

• Check the authentication type of the user first.

• If it's Splunk, then check the "locked-out" attribute.

• If it's LDAP or SAML, assume the user is active by default.

[livehybrid]

Hi @sanjai 

You could use the current-context endpoint (e.g. | rest /services/authentication/current-context) - this does return a locked-out field (see below) however for SSO/SAML/LDAP users this will always be 0 as the locked-out value is only used for native/local Splunk accounts.

It is the authentication provider that determines if the account is locked, e.g. if you fail to login 3 times with LDAP your LDAP provider may temporarily block you, this isnt something you can determine natively from Splunk, you would need some info from LDAP for this.

🌟 Did this answer help you? If so, please consider:

• Adding karma to show it was useful
• Marking it as the solution if it resolved your issue
• Commenting if you need any clarification

Your feedback encourages the volunteers in this community to continue contributing

[sanjai]

Appreciate the insight@livehybrid  — that helps! I’ll be doing a bit more investigation on my end too.

if anyone has any other suggesstions , let me know..😊