All Apps and Add-ons

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)."?

Path Finder

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

1 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.

View solution in original post

Engager

I was able to get this working by adding both the list_settings and list_storage_passwords capabilities to the role.,I was able to get this working by adding the list_settings and list_storage_passwords capabilities to the role.

Path Finder

This works for me. I am using the LDAP authentication on SH cluster, so adding a user role is complicated.

0 Karma

SplunkTrust
SplunkTrust

Ah, now after posting my answer I found this one.. seems like I missed it. I'll convert my answer to a comment.

It's enough to enable list_storage_passwords as the other capability can be improted from the user role.

Skalli

Splunk Employee
Splunk Employee

https://docs.splunk.com/Documentation/SA-LdapSearch/2.2.0/User/UseSA-ldapsearchtotroubleshootproblem...

Authentication fails despite a successful connectivity test after configuration

If you encounter a problem where queries with SA-LDAPsearch fail despite successfully testing a connection that you set up on the configuration page, make sure that the user that you log into Splunk Enterprise as has the admin_all_objects capability. This capability must be present because the configuration page saves passwords as storage passwords, and only this capability allows users to read storage passwords.

If you cannot grant the admin_all_objects capability, as a workaround, you can use a clear-text password and obfuscate that password with base-64 encoding. In this case, however, you can not use the configuration page to save the password nor can you test the connection. This is because the configuration page moves any clear-text passwords to storage passwords when you save the configuration.

You must edit ldap.conf with a text editor and save the password(s) that way, and then use the ldaptestconnection command to test the configuration.

Otherwise, like others have suggested, you can create a Scheduled Saved Search or lookup that makes data available to users to search/query off of.

0 Karma

Path Finder

Same problem with 2.1.4 but I get another Error:

External search command 'ldaptestconnection' returned error code 1. First 1000 (of 2868) bytes of script output: " ERROR " # host: X.X.X.X: Could not access the directory service at ldaps://X.X.X.X:636: 000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1 # host: X.X.X.X: Could not access the directory service at ldaps://X.X.X.X:636: 000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1

0 Karma

Contributor

for me it worked after i gave the user list_storage_passwords capability. use it with caution!

Regards,

Andreas

0 Karma

Path Finder

I believe I have found a solution without hacking the Python script code 🙂 I actually got inspired by @howyagoin

The (much) older version of this SA-ldapsearch had the password stored in the ldap.conf file

I looked into bin/packages/app/configuration.py file and I saw this:

if password is None:
    password = self._get_value(settings, 'password', default='')
    if password.startswith('{64}'):
        password = b64decode(password[4:])
    pass

which pretty much means "if password cannot be read from password storage, then as a last resort try to read it from ldap.conf file."

So just open local/ldap.conf and add the following line into a proper stanza (in case you have multiple ADs, then add proper password to its respective stanza):

password = BINDDN_PASSWORD

We have tested it here and it works.

Communicator

We were able to get this working without changing anything in ldap.conf. We just had to add the list_settings capability. We are running Splunk 6.0.2 on linux with app version 2.1.4. Thanks for the workaround suggestion, it got us going in the right direction.

0 Karma

Explorer

Just adding 'list_settings" to users did not fix it for us unfortunately.
We are on Splunk 6.6.5 on windows, with app v.2.1.6.
Back to the drawing board for something that should have been there in the first place.

0 Karma

Contributor

I was using this workaround but just upgraded from 6.5.3 to 6.6.1 and seems to no longer work. @ontkanin know if this workaround still works in 6.6?

0 Karma

Motivator

Yeah it still works in 6.6. This issue is related to the app version, not the Splunk version 🙂

0 Karma

Contributor

Thanks, I did get it working again in 6.6 still using this workaround but I had to give the users a capability that they previously did not have--"list_settings". Before I gave them that they were getting the error "External search command 'ldapsearch' returned error code 1. Script output = " ERROR "HTTPError at ""/opt/splunk/etc/apps/SA-ldapsearch/bin/packages/splunklib/binding.py"", line 1111 : HTTP 403 Forbidden – insufficient permission to access this resource" ". Glad it is working though.

Explorer

@worshamn thank you for the tip

had to give the users a capability that they previously did not have--"list_settings"
I had the issue in 6.6.4

Contributor

Just ran into this issue as well - the solution of adding admin_all_objects to all users is simply not acceptable. The (much) older version of this SA-ldapsearch had the password stored in the ldap.conf file; whilst that's not ideal, for a read-only LDAP user this was far, far better than the proposed solution.

I do NOT recommend doing what I just did, but it got me working:

You can modify the .py files and embed the password directly rather than using the password storage routines. This means that your LDAP/AD password would be readable at the filesystem level by whomever has access to that, but, if you're like me, that's probably a lot more palatable than giving all Splunk users the required permission.

I modified:

  • ldapsearch.py
  • ./packages/app/connection_pool.py
  • Possibly ./packages/app/configuration.py

Point is, I looked for the Python functions which were waiting for the results of the storage routines to return the password and just inserted password='whatever-the-password-was' instead.

Really, really bad idea, but, it's a far less bad idea than the current permissions requirement.

0 Karma

Path Finder

Hi @howyagoin,
Thanks for the reply but, I have 2 domains configured so not sure which passwords are we talking about here. for both these domains there's a different password, which one should i use. I tried one but its giving me an error.

0 Karma

Path Finder

@rahul_jasrotia, please see my solution below; it works with multiple domains.

0 Karma

Path Finder

Thanks @ontkanin, it sure works.

0 Karma

Path Finder

Is there a solution to this now? I need to make a dashboard for people to take work on and i can't give admin access to them all.

Please help?

0 Karma

Path Finder

For a cheap work around you can export the results you need from an admin account out to a lookup table and let normal users query against that. I have some high level queries set on daily cron.

Also, please open an enhancement request for the fix like I did to let them know we need this changed.

Builder

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

0 Karma