Special characters, ex. "#", in service account passwords..

[PhilG]

Hello. Our environment uses complex passwords that most may have some special character in it like a "#". The service account that is used for logging in to our servers for Windows WMI utilization has a special character. My question is:
When will Nagios XI allow special characters to be incorporated in account passwords since our environment will have a complex password global policy in place very soon (which may utilize special characters, too)?

[slansing]

Absolutely, you should be able to use a USERn macro for this, take a look at:

http://nagios.sourceforge.net/docs/3_0/macros.html

You would define the password in:

Code: Select all

/usr/local/nagios/etc/resource.cfg

Under one of the already existing $USERn$ macro's or under a new one you create, then all you need to do is add it to your service template/service configuration/command definition in the CCM where you would normally put the password on the command.

ie:

Code: Select all

$USER1$/check_test $ARG1$ -p $USER5$

[PhilG]

Sounds like we could do that, but, when an Enterprise/Business policy is put into place and are informed to authenticate against LDAP/Active Directory and passwords will use best practices of strong passwords with at least one special character, etc., then this solution is not practical nor acceptable in the eyes of the Directors, etc.

Will Nagios XI start implementing this practice, and if so, when is the timeline to allow that acceptance (allowing passwords with special characters through LDAP/Active Directory authentication)?

Thank you.

[sreinhardt]

I just tested the XI login allowed credentials, which should include although was not explicitly tested against ldap\AD, and all special characters with the exception of \ and '(single quote) pass through and allow valid logins. If there are additional restrictions with AD\ldap I am not presently aware of them, however I can work on getting something setup to test this. Again please note that this is purely for the XI login page and nothing to do with service or host checks and configurations of those objects, I do realize that that has a further restricted subset of allowed characters.

[PhilG]

I just tested the XI login allowed credentials, which should include although was not explicitly tested against ldap\AD, and all special characters with the exception of \ and '(single quote) pass through and allow valid logins. If there are additional restrictions with AD\ldap I am not presently aware of them, however I can work on getting something setup to test this. Again please note that this is purely for the XI login page and nothing to do with service or host checks and configurations of those objects, I do realize that that has a further restricted subset of allowed characters.

So, when I enter a Domain account, ex. <Domain name>\<Domain Admin equivalent account name>, and its corresponding password for a host and/or service check, it does not check that information against the Domain, even though I did enter in the "<Domain name>\" prefix (f.y.i, the account was not locally created)?

[sreinhardt]

Again, I was only referring to the actual XI login page, nothing to do with services and associated accounts. However I would mention depending on the plugin, you may want to try domain/username. Especially with php and perl scripts this is often the case.

[PhilG]

Again, I was only referring to the actual XI login page, nothing to do with services and associated accounts. However I would mention depending on the plugin, you may want to try domain/username. Especially with php and perl scripts this is often the case.

I did a test using the forward slash "/" instead of the back slash "\" and the test appeared to have worked with that test.
I'm doing some more testing in the next week with various things and will report back soon.

[tmcdonald]

Great, let us know how that turns out.