Support for non-alphanumeric characters in passwords?

[cwscribner]

Hi all.

Does Nagios support passwords with non-alphanumeric passwords at all? I've attempted to monitor a VMWare host but the login fails because the u/p is incorrect. However, the password ends with a '*'. Is this the likely culprit for the failed login? Need some feedback asap...working on a production server...

[mguthrie]

I'm wondering if it's being interpreted by the shell, instead of being passed as a literal character. Can you test this check from the command-line and see if you can pass this password along? It's possible that you may have to escape it with a \ in order for the shell to interpret it literally.

[cwscribner]

No luck. Here's what I have for info.

The check shown in the interface. I've already tried editing the username and password to several different combinations including and escape character ahead of the *

Code: Select all

check_esx3_host!/usr/local/nagiosxi/etc/components/vmware/vkenesxp66_healthone_org_auth.txt!CPU!

The commandline check. Same with this command. I've tried escaping the * but the login still fails. Also tried several different combinations in case of a typo.

Code: Select all

./check_esx3.pl -H <hostname>.org -u Nagios -p password* -l cpu

The commandline output

Code: Select all

ESX3 CRITICAL - Error: Cannot complete login due to an incorrect user name or password.

[mguthrie]

I would check the contents of this file:
vkenesxp66_healthone_org_auth.txt

To see what username and password are getting through. However, if the login failed from the command-line, then the issue is either with the shell or with the perl plugin.

[cwscribner]

The u:p in the file are the same as the ones used on the command line.

A few questions:

1) Nagios does in fact support logging into devices with a u:p located in active directory, correct?

2) How would I go about fixing the problem (if there is one) with the shell or perl script?

I'm double checking with my contact to ensure the u:p are correct as he presented them to me. I may also be able to have the password changed to be only alphnumeric but I'd prefer to not have to do that.

[yancy]

cwscribner,

Some Nagios plugins do support active directory authentication. I'll research this plugin and see how we can get it to authenticate.

Is the ESX server currently tied to active directory using kerberos?

-Yancy

[cwscribner]

Is the WMI plugin one of those that do support active directory auth?

I can only assume the ESX servers are correctly tied. Its for a customer so there's no way for me to be 100%

[cwscribner]

I had an interesting thought a second ago and I'm not sure it applies but maybe it'll help narrow this issue down. I think that the permissions on the customer end may be wrong; here's why...

Right now, all my WMI servers are showing

Code: Select all

ERROR: dcom_create_object.
ERROR: Login to remote object.
NTSTATUS: NT_STATUS_LOGON_FAILURE - Logon failure

My VMWare servers are showing something similar except they just say the user or password is wrong. After experiementing with possible typos on the u:p, the NT status returned on the command line changed from

Code: Select all

NTSTATUS: NT_STATUS_LOGON_FAILURE

to

Code: Select all

NTSTATUS: NT_STATUS_ACCOUNT_LOCKED

In my head, this means that the Nagios can see the server, attempt to login, and would otherwise be successful except there is something at the server level blocking the login. Any thoughts on this?

[yancy]

cwscribner,

DCOM must have remote execution enabled in order for WMI to return information. Also the user must be allowed remote access to the WMI class your accessing.

In general, a member of the administrators group will have these permissions enabled.

If the user is not an administrator:
start > run > DCOMCnfg.exe > COM sercurity > Edit limits > Add the user and check "remote activation" and Remote Launch

to allow access to the WMI class:
start > run > WMImgmt.msc > expand "CIMV2" > click security > add the user and check "enable account" and "Remote Enable"

After making those changes, you should be able to access WMI remotly. Then I would try testing esx3 plugin again once you have verified the U:P are correct and can authenticate.

[cwscribner]

DCOM must have remote execution enabled in order for WMI to return information. Also the user must be allowed remote access to the WMI class your accessing.

In general, a member of the administrators group will have these permissions enabled.

If the user is not an administrator:
start > run > DCOMCnfg.exe > COM sercurity > Edit limits > Add the user and check "remote activation" and Remote Launch

to allow access to the WMI class:
start > run > WMImgmt.msc > expand "CIMV2" > click security > add the user and check "enable account" and "Remote Enable"

These changes don't have to be made on every server, correct? Just on the active directory controller?