Splunk Support for Active Directory: Why are non-admin users getting ldapsearch error "You do not have permission to perform this operation (requires capability: admin_all_objects)."?

[glancaster]

Hi all,

Installed SA-ldapsearch and it works perfectly for my account. I told the users to go ahead and start using it but they are returned the following red banner message:

External search command 'ldapsearch' returned error code 1. Script output = " ERROR "HTTPError at ""/apps/splunk/etc/apps/SA-ldapsearch/bin/packages/splunklib/binding.py"", line 1108 : HTTP 403 Forbidden -- In handler 'passwords': You (user=testuser) do not have permission to perform this operation (requires capability: admin_all_objects)." "

I have adjusted the app permissions to allow read and write permissions to all users. I have looked through the scripts to the best of my ability but am unable to locate the parameter to requires admin_all_objects to execute. Anyone have an idea of where I can find the config and what I need to change it to - to allow all users to be able to execute the SA-ldapsearch commands?

Thanks in advance,
George

[dineshraj9]

Is this issue resolved in the later versions of SA-ldapsearch app?

[glancaster]

Not that I am aware of, I did open an enhancement request to allow us to assign roles outside of admin_all_objects to control access to this feature.

[David_Noble_at_]

I opened a bug to update the documentation. That change will be made soon.

[David_Noble_at_ · Accepted solution]

We use Splunk's storage passwords endpoint to read/write passwords. This endpoint cannot be accessed by users without admin_all_objects capability. You might wish to create a new role for this. You might, for example, create an "SA-ldapsearch user" role that inherits from user and adds the admin_all_objects capability.

The admin_all_objects capability grants users significant access rights:

• A role with this capability has access to objects in the system (user objects, search jobs, etc.).
• This bypasses any ACL restrictions (similar to root access in a *nix environment).
• We check this capability when accessing manager pages and objects.

See the authorize.conf spec for additional information.

We are considering developing an alternative to the storage password endpoint for securely storing credentials in a future release of the Splunk Support Add-on for Active Directory; one that would not require admin_all_objects capability. Please stay tuned.

[afret2007]

It has been just short of three years since glancaster first received an answer from Splunk that an alternative was being looked into so that a standard Splunk user would be able to run ldapsearch without being given VERY dangerous admin_all_objects capability. AS I write this out organization has just come up against this same problem recently and yet NO solution been given even after enhancement tickets have been opened over the past three years. Very disappointing.

[worshamn]

@afret2007 see ontkanin's answer which I believe to be the true workaround without admin_all_objects

[afret2007]

If I am reading ontkanin's workaround correctly , the problem is moved off of Splunk and on to the LDAP server. Not in giving every Splunk user admin capability which is mmuch much worse but in giving all Splunk users capability to run an LDAP search. We only want certain Splunk users by role the ability to run an LDAP search. Working within a high security facility and network, we are limited to what a user can and cannot execute. We cannot give everyone on Splunk the capability, just those whose job requires it. The best solution is still to have Splunk team to give LDAP search capability as a role attribute with no other capability/attribute required to be given that gives more privileges than they should have. Ontkanin's solution is great if you do not have limitations as we do on what regular users can be given permissions to.

[worshamn]

Actually you can take away the ability for any user to run ldap search by taking about the capability "list_settings" from their role. Though maybe that might have other consequences that won't work for you...

[afret2007]

That may work. Will see if we can get that to work for us. Thanks to you and ontkanin!

[jhedgpeth]

we just upgraded, which led me here. there are no scenarios where we would throw away security like suggested here. breaking the code to do it ourselves is more likely.

[sander980]

I see the same error as @benic mentions in an answer below.

This manifests in the Splunk App for Windows INfra meaning that a lot of the AD dashboards that rely on LDAP do not work.

I am not keen on any of the workarounds above. It would be good for Splunk to address this as the Windows Infra app is one that a lot of customers wish to use.

[ontkanin]

We are considering developing an alternative to the storage password endpoint for securely storing credentials in a future release of the Splunk Support Add-on for Active Directory; one that would not require admin_all_objects capability. Please stay tuned.

Any update about fixing this?

[jaxjohnny2000]

We are considering developing an alternative to the storage password endpoint for securely storing credentials in a future release of the Splunk Support Add-on for Active Directory; one that would not require admin_all_objects capability. Please stay tuned.

Is this corrected?

[afret2007]

jaxjohnny2000,

It has been not. Splunk only gave it lip service but have done nothing about it in the 5 years the problem was first brought up. In secure environments such as I work in now and in the past the "workarounds" proposed by others are not allowed. It is one reason why we have been looking to drop Splunk as our main tool on our 3 major networks.

[rkantamaneni_sp]

@jaxjohnny2000 @afret2007, This capability is obviously not ideal (or secure) to casually give to users, I've engaged the product team to review this. Please do talk to your Splunk Account team (Sales Rep/Engineers) and reference this Splunk Answer asking for a solution.

Just in case it helps, I did post the most recent workarounds for this in this answer: https://answers.splunk.com/answers/189732/splunk-support-for-active-directory-why-are-non-ad.html#an...

[johnsjm]

Great app but I can't allow my users to use it... will this ever be fixed?

[glancaster]

See my response below.

[Lucas_K]

Has anyone found a way around this requirement? This is a seriously bad design choice. Fix a potential security issue by allowing everyone the equivalent of root access?

Hashed local password storage for your ldap servers were much better than having users changing/deleting whatever they like across your platform just to access a custom command 😕

We just has a user reconfigure a heap of server level options on our clustered search heads. It was only when they said "why doesn't X" work did we find out that they'd believed they were changing options just for themselves.

[glancaster]

Thank you for the response, I understand the limitations and hope that Splunk is able to work around this, In our situation we use a read-only account to query LDAP and need a wide range of users to be able to execute these commands in Splunk - a range of users that we wouldn't want to give admin_all_objects capabilities to.

Would we be able to get someone to update the documentation and add this to the "About" section or maybe the release notes? Reading this before I tested and deployed would have saved me and others some time.

Thanks for the assistance,
George

[glancaster]

Forgot to mention, running version 2.0.0