Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Anything special about LDAP User Experience Monitor?

So we were using this fine on a previous install on a different server. We changed to a newer OS (server 2016 from 2012r2) and upgraded to the latest versions of NPM (12.3) and SAM (6.7.0) from 12.2 and 6.6.0.

Once we restored the DB from old server to new instance, all appeared OK once fully licensed. The LDAP experience test though no longer works and returns the following message:

Unable to perform search request with given parameters.

Exception message is: The server does not support the control. The control is critical.

The server does not support the control. The control is critical.

We are using the same values as before so not sure why it is failing on the new server. Noteworthy values that we have set are 389, StartTLS, and auth method - Simple. Connections are being made to Fedora 389 DS servers.

Find more posts tagged with

TLS

sam 6.7

ldap

Accepted answers

jvb

As others have noted in this thread, we have identified and resolved this issue. There is a buddy drop available for those

who are currently under active maintenance. If you believe you are affected by this issue please open a ticket with the support team.

The resolution to this issue will also be rolled up in a future hot fix or full release of SAM.

All comments

m_roberts

Did you get an answer to this?

Try changing the Auth method to NTLM or whatever is supported (supportable) by the LDAP target. I am wondering if this is a version issue as, as far as I am aware SAM LDAP monitor supports v2 and not v3, so check your LDAP server will accept v2 requests.

m-milligan

We've had the same problem since we applied the last round of Solarwinds upgrades. I'll be interested to see if a fix is provided.

kelly.ellison

We just upgraded and have encountered the same problem as well. I have tried every Auth method with no success. Nothing changed on the servers or the actual template so I will be reaching out the the LDAP Server team in the morning once they are in to see what version the servers will accept.

dtroworth

Hi,

We recently upgraded to SAM 6.7 and are now having exactly the same issue with the LDAP User Experience Monitor (anonymous bind). Without making any changes to the monitor or to our LDAP environment (LDAP v1), the monitor now no longer works. The bind is fine, but search fails.

Solarwinds logs (C:\ProgramData\Solarwinds\Logs\APM\ApplicationLogs\ on Orion server):

-------------------------------------------------------------------------------------------------------------------

...

2018-11-16 16:23:04,089 [STP SmartThreadPool Thread #10] [C3218] DEBUG SolarWinds.APM.Probes.LdapProbeBase`2 - LdapUserExperienceProbe failed. Unable perform search request '***********' with path '*********' for LDAP server: **********:389. The server does not support the control. The control is critical.

...

Access log on our LDAP server has the following:

--------------------------------------------------------------------

...

[16/Nov/2018:16:23:04 +0000] conn=55156 op=1 msgId=5 - SRCH base="o=********" scope=2 filter="(uid=*******)", unsupported critical extension

...

I've since tested the monitor against a test LDAP v3 Directory Server and the logs have been a little more helpful here, flagging up a couple of LDAP request controls being used by the SAM monitor that I think may be the cause of the issue.

One is the "Simple paged results" Control (OID 1.2.840.113556.1.4.319), which does not appear in the list of supported controls in our LDAP v1 environment - to find supported controls, run the following on your LDAP server: ldapsearch -h localhost -p 389 -b "" -s base "(objectclass=*)" supportedControl

The search also appears to use Control OID 1.2.840.113556.1.4.1340, which is unsupported in both our v1 and v3 environments. Example excerpt from access audit log: "The search request cannot be processed because it contains a critical control with OID 1.2.840.113556.1.4.1340 that is not supported by the Directory Server for this type of operation"

I'm pretty new to LDAP so hope this all makes sense!

I have a webex this week with Solarwinds tech support in relation to this. I'll give an update on the result of that.

hailaeos

Was this issue ever resolved I am experiencing this also.

dtroworth

Hi hailaeos,

I have a ticket still open with Solarwinds. Not resolved yet but they're working on it.

I'm pretty sure it come down to the use of Microsoft controls in the way the monitor is running the search.

m-milligan

I have a case open with Solarwinds for this issue. This morning I heard that it appears to be a bug in Solarwinds and a fix will be made available.

ETA: I got a buddy drop today (13 December 2018) that fixed the problem.

m-milligan

I got a Buddy Drop from Solarwinds this morning. It fixed the problem. Have they given you the BD?

dtroworth

Just to confirm, we applied Solarwinds' buddy drop today and it's resolved the issue.

jvb

As others have noted in this thread, we have identified and resolved this issue. There is a buddy drop available for those

who are currently under active maintenance. If you believe you are affected by this issue please open a ticket with the support team.

The resolution to this issue will also be rolled up in a future hot fix or full release of SAM.