Nagios Support Forum

I found many cases on this subject and spent most of today going through each one, only to have it appear to work OK on the CLI, but never in Nagiosxi gui. When attempting to connect to add users, I get the (unable to get local issuer certificate) error.

So far I have added the host certificate and ADPKI root certificate to /etc/pki/ca-trust/source/anchors per another thread for the same issue.

Ran openssl s_client -showcerts -connect adserver01.domain.com:636 before and after adding the certs to /etc/pki

BEFORE
openssl s_client -showcerts -connect adserver01.domain.com:636
CONNECTED(00000003)
depth=0 CN = adserver01.domain.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = adserver01.domain.com
verify error:num=21:unable to verify the first certificate
verify return:1

AFTER

openssl s_client -showcerts -connect adserver01.domain.com:636
CONNECTED(00000003)
depth=1 C = US, ST = st, L = town, OU = this place, O = our job, CN = Company Root CA SHA2 2012
verify return:1
depth=0 CN = adserver01.domain.com
verify return:1

So it appears the server itself can find it, but after restarting the server just to be sure, reran the openssl to verify and then added the server and both certificates to the gui, I get the same error.

If I tell openldap to never request a cert it fails with a completely different error as I would expect since our AD is TLS only.

Now I 'm not sure if this is anything, but I did spot this in the output of openssl, issuer=C = US, ST = , since I don't have anything to compare to, and is probably nothing. just thought I would mention it.

I don't know it this is helpful or not either

[root@nagiosxi anchors]# ll /etc/openldap/cacerts
total 0
lrwxrwxrwx. 1 apache apache 37 May 20 16:47 60a6d8f26a05f.0 -> /etc/openldap/certs/60a6d8f26a05f.pem
lrwxrwxrwx. 1 apache apache 37 May 20 16:50 60a6d9b6547df.0 -> /etc/openldap/certs/60a6d9b6547df.pem
[root@nagiosxi anchors]# ll /etc/openldap/certs
total 28
-rw-r--r--. 1 apache apache 3134 May 20 16:47 60a6d8f26a05f.crt
-rw-r--r--. 1 apache apache 8755 May 20 16:47 60a6d8f26a05f.pem
-rw-r--r--. 1 apache apache 2208 May 20 16:50 60a6d9b6547df.crt
-rw-r--r--. 1 apache apache 7607 May 20 16:50 60a6d9b6547df.pem


This is a new install of NagiosXI version 5.8.3 running on RHEL 8.3 with the latest patches as of May 5th.

We are attempting to connect to Active Directory on a Windows 2012 server.

If it helps any

php-json-7.2.24-1.module+el8.2.0+4601+7c76a223.x86_64
php-cli-7.2.24-1.module+el8.2.0+4601+7c76a223.x86_64
php-mbstring-7.2.24-1.module+el8.2.0+4601+7c76a223.x86_64
php-pdo-7.2.24-1.module+el8.2.0+4601+7c76a223.x86_64
php-process-7.2.24-1.module+el8.2.0+4601+7c76a223.x86_64
php-7.2.24-1.module+el8.2.0+4601+7c76a223.x86_64
php-snmp-7.2.24-1.module+el8.2.0+4601+7c76a223.x86_64
php-odbc-7.2.24-1.module+el8.2.0+4601+7c76a223.x86_64
php-pgsql-7.2.24-1.module+el8.2.0+4601+7c76a223.x86_64
php-ldap-7.2.24-1.module+el8.2.0+4601+7c76a223.x86_64
php-xml-7.2.24-1.module+el8.2.0+4601+7c76a223.x86_64
php-fpm-7.2.24-1.module+el8.2.0+4601+7c76a223.x86_64
php-gd-7.2.24-1.module+el8.2.0+4601+7c76a223.x86_64
php-imap-7.2.11-1.el8.x86_64
php-devel-7.2.24-1.module+el8.2.0+4601+7c76a223.x86_64
php-pear-1.10.5-9.module+el8.1.0+3202+af5476b9.noarch
php-common-7.2.24-1.module+el8.2.0+4601+7c76a223.x86_64
php-pecl-ssh2-1.2-2.el8.x86_64
php-mysqlnd-7.2.24-1.module+el8.2.0+4601+7c76a223.x86_64

Try this, take the CA certs and put them in individual files in this directory:
Then run these commands:
Then test it again.

If that still doesn't work, take the CA files, put them into this file (just one on top of the other in the file):
Then add this to your /etc/openldap/ldap.conf:
Then restart apache and try again:

Thanks for the response. The first one I had tried before that tested OK at the CLI, but not through NagiosXI, but tried it again just to be sure, same result. I tried the second one, and now have a different error,

80090308: LdapErr: DSID-0C09044E, comment: AcceptSecurityContext error, data 52f, v2580

Are you entering domain admin credentials when typing in the credentials for the import? Additionally, you only need to type the username not the domain\user or [email protected] formats.

ssax wrote:Are you entering domain admin credentials when typing in the credentials for the import? Additionally, you only need to type the username not the domain\user or [email protected] formats.

Yes, have an account set up specifically for AD admin, however I just tested my server admin account which is not supposed to have AD access and was able to connect and pull up the AD orgs. So looks like it is working now after doing the above fixes. I think that last one adding to the ldap config did the trick.

Thanks, now to go find out why my ad admin account isn't working correctly.

One other thing, where can I view logs for the logging in? It's a 50/50 chance of a user logging in for some reason, I have two who can log in, and two who cannot, so is there a log I can view?

You can check Admin > Audit Log.

Usually, I'd be able to have you enable debug logging for them via this KB article:

https://support.nagios.com/kb/article/a ... n-600.html

But there is something stopping that from working on EL8 (I spent hours trying to get it to log and was unsuccessful).

Check to make sure the AD Username matches what they use to login into AD with in Admin > Manage Users when editing their user.

What error do they get when they try to login?

Is there a chance they have a different account suffix? (@someotherthing.com)

ssax wrote:You can check Admin > Audit Log.

Usually, I'd be able to have you enable debug logging for them via this KB article:

https://support.nagios.com/kb/article/a ... n-600.html

But there is something stopping that from working on EL8 (I spent hours trying to get it to log and was unsuccessful).

Check to make sure the AD Username matches what they use to login into AD with in Admin > Manage Users when editing their user.

What error do they get when they try to login?

Is there a chance they have a different account suffix? (@someotherthing.com)

Layer 8 issue

Turns out he was using IP instead of hostname for the URL. All is working good now, appreciate the help.

Nice catch! Let us know when we're okay to lock this up and mark this as resolved.