splunkd.log UserManagerPro LDAP warning with blank username

[mfrost8]

We use LDAP authentication for users on our Splunk instances. I'm trying to keep an eye on users who no longer exist (orphaned searches, but also user dirs that are 'dead').

Occasionally, I see the following show up in the logs:

03-29-2017 11:27:14.140 -0500 ERROR UserManagerPro - Failed to get LDAP user="" from any configured servers

That is, the user field is blank. I can't see how I could have a blank user in Splunk. Does anyone know how this might happen? I'd like to clean it up if I can.

Thanks!

[brreeves_splunk]

These references come from savedsearches that were previously assigned to a now disabled user. You can track these down by running Splunk in Debug for searches for a bit, then let them run. Next, in the splunkd log you'll see the SID of the search trying to run. That way you can track it back to the search and either re-assign it or delete it.

https://docs.splunk.com/Documentation/Splunk/6.5.2/Troubleshooting/Enabledebuglogging#Enable_debug_l...

[brreeves_splunk]

If you look at the events around that one, does it talk about what search or activity it is trying to complete with that user?

[mfrost8]

Why didn't I think of that? 🙂

Just prior I see

03-29-2017 14:06:11.948 -0500 WARN  HttpListener - Socket error from 1.2.3.4 while idling: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request
03-29-2017 14:06:13.153 -0500 WARN  HttpListener - Socket error from 1.2.3.5 while idling: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request
3-29-2017 14:06:13.543 -0500 ERROR ScopedLDAPConnection - Invalid search filter: Attribute and value must be non-empty. Attempted to constrain attribute="samaccountname" to value=""
03-29-2017 14:06:13.612 -0500 ERROR ScopedLDAPConnection - Invalid search filter: Attribute and value must be non-empty. Attempted to constrain attribute="samaccountname" to value=""
03-29-2017 14:06:13.612 -0500 ERROR UserManagerPro - Failed to get LDAP user="" from any configured servers

I think we have some internal tool that is scanning servers and attempting to break in on any ports it can find. Just to see, I tried going to the web interface and hitting enter without entering a userid or password to see if that would generate this and it did not.

I guess there's something about the way this is hitting the port that is triggering an LDAP search with no user information.