Issues after migrating to a new server

[pbroste]

Hello @hbouma

Thanks for following up, want to get an updated System Profile on this so we can see what it has been logging:

But first, let's capture a LDAP auth attempt:

Code: Select all

tcpdump -s 0 -i any port <yourldapporthere> -w /tmp/output.pcap

To send us your system profile.

• Login to the Nagios XI GUI using a web browser.
• Click the "Admin" > "System Profile" Menu
• Click the "Download Profile" button
• Save the profile.zip file and share (/tmp/output.pcap)

Thanks,
Perry

[hbouma]

Information sent via PM.

[pbroste]

Hello @hbouma

Thanks for sending over the info, we are continuing to look at the pcap on the ldap interface and will follow up on that.

Want to hit on the continued error messages that surround the NPCD service. We see that you are using the 'nagiosramdisk' for "swap". Verify the 'ramdisk.service' is running:

Code: Select all

systemctl status ramdisk.service

Review this support article to verify that all the configs are in place:
https://assets.nagios.com/downloads/nagiosxi/docs/Utilizing_A_RAM_Disk_In_NagiosXI.pdf

Thanks,
Perry

[hbouma]

RAMDisk is running, I restarted it to get the full output as my journalctl info had rotated and the output was not full.

Code: Select all

systemctl status ramdisk
● ramdisk.service - Ramdisk
   Loaded: loaded (/usr/lib/systemd/system/ramdisk.service; enabled; vendor preset: disabled)
   Active: active (exited) since Mon 2022-02-14 08:09:41 EST; 2s ago
  Process: 1933026 ExecStart=/usr/bin/chown -R nagios:nagios /var/nagiosramdisk (code=exited, status=0/SUCCESS)
  Process: 1933025 ExecStartPre=/usr/bin/mkdir -p -m 775 /var/nagiosramdisk /var/nagiosramdisk/tmp /var/nagiosramdisk/spool /var/nagiosramdisk/spool/checkresults /var/nagiosramdisk/spoo>
  Process: 1933022 ExecStartPre=/usr/bin/mount -t tmpfs -o size=500m tmpfs /var/nagiosramdisk (code=exited, status=0/SUCCESS)
  Process: 1933021 ExecStartPre=/usr/bin/mkdir -p -m 775 /var/nagiosramdisk /var/nagiosramdisk/tmp /var/nagiosramdisk/spool /var/nagiosramdisk/spool/checkresults /var/nagiosramdisk/spoo>
Main PID: 1933026 (code=exited, status=0/SUCCESS)

Feb 14 08:09:41 SERVER_NAME systemd[1]: Stopping Ramdisk...
Feb 14 08:09:41 SERVER_NAME systemd[1]: Starting Ramdisk...
Feb 14 08:09:41 SERVER_NAME systemd[1]: Started Ramdisk.


I have gone through the provided link and verified all the steps under the manual install and everything was present (FYI, we did use the automated install step, but verified it all using the manual steps).

[pbroste]

Hello @hbouma

Thanks for following up, please send over an updated System Profile so we can see what it looks like now.

Regards,
Perry

[hbouma]

Profile sent.

[pbroste]

Hello @hbouma

Thanks for sending over the updated System Profile. Appears that you will need all CA certificates that complete the LDAP/AD server certificate's CA signer certificate chain for the new LDAP/AD server's certificate. For example, if a subordinate CA issued the LDAP/AD certificate you would still need the Root CA's signer certificate that signed the subordinate CA's signer certificate to complete the chain. The instructions I crafted below tries to be generic to hit both situations (single vs multiple CA certificates in the chain):

Take the CA certs and put them in individual files in this directory:
- NOTE: They must have a .crt extension on the files

Code: Select all

/etc/pki/ca-trust/source/anchors/

Then run these commands:

Code: Select all

update-ca-trust extract
systemctl restart httpd php-fpm

Then test it again.


If your XI server OS version is Ubuntu/Debian:

Take the CA certs and put them in individual files in this directory:
- NOTE: They must have a .crt extension on the files

Code: Select all

/usr/local/share/ca-certificates/

Then run these commands:

Code: Select all

sudo update-ca-certificates
systemctl restart apache2

Then test it again.


If that still doesn't resolve it (it should), please PM the full output of this command:
- Change your.ad_or_ldap.server before running

Code: Select all

echo 'DONE' | openssl s_client -showcerts -connect your.ad_or_ldap.server:636

And attach or PM this file:

Code: Select all

/etc/openldap/ldap.conf

Thanks,
Perry

[hbouma]

The Root CA and intermediary for our internal certificate authority is already trusted by this server and in the /etc/pki/ca-trust/source/anchors/ location.

Here is the output of the command:

Code: Select all

echo 'DONE' | openssl s_client -showcerts -connect REMOVED_FOR_SECURITY_PURPOSES
CONNECTED(00000003)
depth=0 CN = REMOVED_FOR_SECURITY_PURPOSESm
verify error:num=66:EE certificate key too weak
verify return:1
depth=3 CN = REMOVED_FOR_SECURITY_PURPOSES
verify return:1
depth=2 DC = REMOVED_FOR_SECURITY_PURPOSES
verify return:1
depth=1 DC = REMOVED_FOR_SECURITY_PURPOSES
verify return:1
depth=0 CN = REMOVED_FOR_SECURITY_PURPOSES
verify return:1
---
Certificate chain
0 s:CN = REMOVED_FOR_SECURITY_PURPOSES
   i:DC = REMOVED_FOR_SECURITY_PURPOSES
-----BEGIN CERTIFICATE-----
REMOVED_FOR_SECURITY_PURPOSES
-----END CERTIFICATE-----
1 s:DC = REMOVED_FOR_SECURITY_PURPOSES
   i:DC =REMOVED_FOR_SECURITY_PURPOSES
-----BEGIN CERTIFICATE-----
REMOVED_FOR_SECURITY_PURPOSES
-----END CERTIFICATE-----
2 s:DC = REMOVED_FOR_SECURITY_PURPOSES
   i:CN =REMOVED_FOR_SECURITY_PURPOSES
-----BEGIN CERTIFICATE-----
REMOVED_FOR_SECURITY_PURPOSES
-----END CERTIFICATE-----
---
Server certificate
subject=REMOVED_FOR_SECURITY_PURPOSES

issuer=REMOVED_FOR_SECURITY_PURPOSES

---
No client certificate CA names sent
Client Certificate Types: REMOVED_FOR_SECURITY_PURPOSES
Requested Signature Algorithms: REMOVED_FOR_SECURITY_PURPOSES
Shared Requested Signature Algorithms: REMOVED_FOR_SECURITY_PURPOSES
Peer signing digest: REMOVED_FOR_SECURITY_PURPOSES
Peer signature type: REMOVED_FOR_SECURITY_PURPOSES
Server Temp Key: REMOVED_FOR_SECURITY_PURPOSES
---
SSL handshake has read 5184 bytes and written 407 bytes
Verification error: EE certificate key too weak
---
New, TLSv1.2, Cipher is REMOVED_FOR_SECURITY_PURPOSES
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : REMOVED_FOR_SECURITY_PURPOSES
    Session-ID: REMOVED_FOR_SECURITY_PURPOSES
    Session-ID-ctx:
    Master-Key: REMOVED_FOR_SECURITY_PURPOSES
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1645034939
    Timeout   : 7200 (sec)
    Verify return code: 66 (EE certificate key too weak)
    Extended master secret: yes
---
DONE


contents of /etc/openldap/ldap.conf

Code: Select all

#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

#BASE   dc=example,dc=com
#URI    ldap://ldap.example.com ldap://ldap-master.example.com:666

#SIZELIMIT      12
#TIMELIMIT      15
#DEREF          never

# When no CA certificates are specified the Shared System Certificates
# are in use. In order to have these available along with the ones specified
# by #TLS_CACERTDIR one has to include them explicitly:
#TLS_CACERT     /etc/pki/tls/cert.pem

# System-wide Crypto Policies provide up to date cipher suite which should
# be used unless one needs a finer grinded selection of ciphers. Hence, the
# PROFILE=SYSTEM value represents the default behavior which is in place
# when no explicit setting is used. (see openssl-ciphers(1) for more info)
#TLS_CIPHER_SUITE PROFILE=SYSTEM

# Turning this off breaks GSSAPI used with krb5 when rdns = false
SASL_NOCANON    on

TLS_CACERTDIR /etc/openldap/cacerts


/etc/openldap/cacerts has symlinks to each of the files in /etc/openldap/certs.
In /etc/openldap/certs/ I see the Root and Intermediary CA certs for our environment.

As I go into the Nagios XI GUI, I go to Admin -> LDAP/AD Integration, I see all the same certificates under the Certificate Authority Management that we have on our other working Nagios XI servers. I also see the same setup for our AD integration, which works fine on the other servers.

However, those servers are RHEL 7.9 with Nagios XI 5.8.6. The new server is RHEL 8.5 with Nagios XI 5.8.7

[pbroste]

Hello @hbouma

Thanks for following up, lets verify the encryption:

Add this to: /etc/openldap/ldap.conf:

# When no CA certificates are specified the Shared System Certificates
# are in use. In order to have these available along with the ones specified
# by TLS_CACERTDIR one has to include them explicitly:
TLS_CACERT /etc/pki/tls/cert.pem

Then run these commands:

Code: Select all

systemctl restart httpd php-fpm

Verify the output on this:

Code: Select all

echo 'DONE' | openssl s_client -showcerts -connect your.ad_or_ldap.server:636

Do you receive return code: 66 (EE certificate key too weak)?

To view which crypto-policy is being used and how to change it.

# Show and change crypto-policies

Code: Select all

update-crypto-policies  --show

Code: Select all

update-crypto-policies --set LEGACY

Code: Select all

reboot

# To Set back to default

update-crypto-policies --set DEFAULT

reboot

Thanks,
Perry

[hbouma]

After the changes requested, I run the command to our AD server and I still see "Verify return code: 66 (EE certificate key too weak)".

Code: Select all

update-crypto-policies  --show
FIPS

Code: Select all

update-crypto-policies --set LEGACY
Setting system policy to LEGACY
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.

Rebooted.

Code: Select all

update-crypto-policies --set DEFAULT
Setting system policy to DEFAULT
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.

Rebooted.

Still cannot log in.