Page 1 of 2
Support for non-alphanumeric characters in passwords?
Posted: Mon Nov 21, 2011 10:33 am
by 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...
Re: Support for non-alphanumeric characters in passwords?
Posted: Mon Nov 21, 2011 11:28 am
by 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.
Re: Support for non-alphanumeric characters in passwords?
Posted: Mon Nov 21, 2011 11:58 am
by 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.
Re: Support for non-alphanumeric characters in passwords?
Posted: Mon Nov 21, 2011 12:03 pm
by 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.
Re: Support for non-alphanumeric characters in passwords?
Posted: Mon Nov 21, 2011 12:16 pm
by 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.
Re: Support for non-alphanumeric characters in passwords?
Posted: Mon Nov 21, 2011 1:03 pm
by 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
Re: Support for non-alphanumeric characters in passwords?
Posted: Mon Nov 21, 2011 1:15 pm
by 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%
Re: Support for non-alphanumeric characters in passwords?
Posted: Mon Nov 21, 2011 4:21 pm
by 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
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?
Re: Support for non-alphanumeric characters in passwords?
Posted: Tue Nov 22, 2011 11:06 am
by 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.
Re: Support for non-alphanumeric characters in passwords?
Posted: Tue Nov 22, 2011 11:46 am
by cwscribner
yancy wrote:
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?