Nagios Support Forum

We just upgraded one of our Domains from 2008 to 2012 this past weekend, and now the user I have set up for doing WMI checks no longer works from Nagios. I can use the same credentials from any Windows box, and it works just fine.

The error I get from the WMI check is:
UNKNOWN - The WMI query had problems. You might have your username/password wrong or the user's access level is too low. Wmic error text on the next line.
[librpc/rpc/dcerpc_util.cdcerpc_pipe_auth_recv()] Failed to bind to uuid 4d9f4ab8-7d1c-11cf-861e-0020af6e7c57 - NT_STATUS_NET_WRITE_FAULT
[librpc/rpc/dcerpc_connect.c:790:dcerpc_pipe_connect_b_recv()] failed NT status (c0000022) in dcerpc_pipe_connect_b_recv
[wmi/wmic.c:196:main()] ERROR: Login to remote object.
NTSTATUS: NT_STATUS_ACCESS_DENIED - Access denied

When the DC sees the login coming from Nagios, it rejects it with Event ID 4776.

Any ideas?

I would start off going through this document and making sure the permissions are still in tact.

http://assets.nagios.com/downloads/nagi ... ng_WMI.pdf

Well, I verified everything in that document, and I am getting the same result.

I can set that the issue is not at the Firewall, as there is nothing in the Firewall log to indicate any blocks. Plus, the WMI checks are still working just fine via any Windows box using those same cerdentials. I should also point out that my WMI checks are still working just fine for the other Domains and hosts (I am monitoring two forests, one of which has a subdomain).

I also looked at the Windows Event Log, and what's even weirder, is that the actual status code is listed as 0xC000006A, which appears to be "user name is correct but the password is wrong". I am using the command line to test "check_wmi_plus.pl", and I can see the password plain as day in the string.

Any other ideas?

It seems like this users has a limited permission to access WMI datasources. Check the User Rights Assignment of the Local Group Policy ("Access this computer from the network" option in particular).

Yes, I looked for that one, and confirmed it. I even made it a member of local administrators, who have that right explicitly set in Group Policy. Plus, like I said, I can successfully do WMI checks with that user account from any Windows PC.

At this point I would look at upgrading check_wmi_plus

http://assets.nagios.com/downloads/nagi ... pgrade.pdf

I finally figured it out. It turns out there was a Group Policy set on the new AD that affected how NTLM vs NTLMv2 authentication was being handled.

I compared the Windows successful login messages to the failed logins from Nagios, and saw that the NTLM logins were indeed different.

The issue is with the following settings regarding NTLM vs NTLMv2:

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies/Security Options
Network security: LAN Manager authentication level Send NTLMv2 response only. Refuse LM & NTLM <- Should be set to "Send LM & NTLM responses"
Network security: Minimum session security for NTLM SSP based (including secure RPC) clients Enabled <- should be disabled
Require NTLMv2 session security Enabled <- Uncheck
Require 128-bit encryption Enabled <- Uncheck
Network security: Minimum session security for NTLM SSP based (including secure RPC) servers Enabled <- should be disabled
Require NTLMv2 session security Enabled <- Uncheck
Require 128-bit encryption Enabled <- Uncheck

Turning them off fixes the issue. We now need to make some decisions about how we want to proceed. I am not looking forward to upgrading check_wmi_plus, IF that even is the fix.... Last time I tried to upgrade it broke a bunch of my service checks.

Excellent, thanks for giving the feedback here on how you solved it as it will help others in the future.