Page 3 of 5
Re: Issues after migrating to a new server
Posted: Mon Feb 21, 2022 9:16 am
by hbouma
FYI, if I change the crypto policy to LEGACY and leave it as LEGACY, the "return code: 66 (EE certificate key too weak)" response and my communication with the AD servers works through openssl. However, I still cannot log in through Nagios.
Re: Issues after migrating to a new server
Posted: Mon Feb 21, 2022 2:15 pm
by pbroste
Hello
@hbouma
Thanks for following up, want to update the trust CA Certificates because the web interface/app adds this to the /etc/openldap/ldap.conf:
- TLS_CACERTDIR /etc/openldap/cacerts
# 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
The fix:
To trust the CA certs system-wide:
Take the CA certs and put them in individual files in this directory:
- NOTE: They must have a .crt extension on the files
Then run these commands:
Then edit your
/etc/openldap/ldap.conf and uncomment this line:
So it looks like this:
Then restart apache/php-fpm and test again and see if that resolves the issue:
Then test the login and the import is a good test as well.
Thanks,
Perry
Re: Issues after migrating to a new server
Posted: Tue Feb 22, 2022 8:51 am
by hbouma
I have made the requested changes.
I can still hit the AD VIP without issue by using echo 'DONE' | openssl s_client -showcerts -connect AD_VIP:636.
However, Nagios does not log in. Instead, it just sits there spinning and trying to log in. I see nothing unusual in the logs.
Re: Issues after migrating to a new server
Posted: Tue Feb 22, 2022 9:06 pm
by pbroste
Going out on a divagation but want to make sure and rule out time/date/timezone synced across within thresholds with your LDAP server.
Code: Select all
date
ls -l /etc/localtime
php -r 'echo date("D M j G:i:s T Y")."\n";'
grep "date.timezone =" /etc/php.ini
grep date.timezone /etc/php.ini
mysql -h 127.0.0.1 -uroot -pnagiosxi -e 'SELECT NOW(); SELECT @@GLOBAL.time_zone, @@SESSION.time_zone;'
Thanks,
Perry
Re: Issues after migrating to a new server
Posted: Wed Feb 23, 2022 8:46 am
by hbouma
Code: Select all
date
ls -l /etc/localtime
php -r 'echo date("D M j G:i:s T Y")."\n";'
grep "date.timezone =" /etc/php.ini
grep date.timezone /etc/php.ini
]mysql -h 127.0.0.1 -uroot -pnagiosxi -e 'SELECT NOW(); SELECT @@GLOBAL.time_zone, @@SESSION.time_zone;'
Code: Select all
[root@SERVERNAME~]# date
Wed Feb 23 08:45:22 EST 2022
[root@SERVERNAME~]# ls -l /etc/localtime
lrwxrwxrwx 1 root root 30 Feb 1 14:08 /etc/localtime -> /usr/share/zoneinfo/US/Eastern
[root@SERVERNAME~]# php -r 'echo date("D M j G:i:s T Y")."\n";'
Wed Feb 23 8:45:22 EST 2022
[root@SERVERNAME~]# grep "date.timezone =" /etc/php.ini
date.timezone = US/Eastern
[root@SERVERNAME~]# grep date.timezone /etc/php.ini
; http://php.net/date.timezone
date.timezone = US/Eastern
[root@SERVERNAME ~]# mysql -h OFFLOADED_DB_SERVER_IP -uroot -pSUPER_SECRET_PASSWORD -e 'SELECT NOW(); SELECT @@GLOBAL.time_zone, @@SESSION.time_zone;'
mysql: [Warning] Using a password on the command line interface can be insecure.
+---------------------+
| NOW() |
+---------------------+
| 2022-02-23 08:45:23 |
+---------------------+
+--------------------+---------------------+
| @@GLOBAL.time_zone | @@SESSION.time_zone |
+--------------------+---------------------+
| SYSTEM | SYSTEM |
+--------------------+---------------------+
Re: Issues after migrating to a new server
Posted: Thu Feb 24, 2022 12:20 pm
by pbroste
Hello
@hbouma
Thanks for verifying that the date/time/timezone are all synced with the LDAP server.
Looking back and going forward, we saw that the 'openssl' command resulted in "verify error:num=66:EE certificate key too weak' so let's verify:
Previously we had you pull the crypto-policies and that results show: FIPS; and want to disable that by: (requires reboot when you get a chance)
Code: Select all
fips-mode-setup --disable && reboot
Then:
Code: Select all
update-crypto-policies --set LEGACY && reboot
After reboot verify:
Thanks,
Perry
Re: Issues after migrating to a new server
Posted: Thu Feb 24, 2022 1:01 pm
by hbouma
Made the requested changes.
Code: Select all
fips-mode-setup --disable && reboot
After reboot, I still cannot log in.
Code: Select all
update-crypto-policies --set LEGACY && reboot
Now, I cannot log in, even with the built in NagiosAdmin account.
Code: Select all
update-crypto-policies --show
LEGACY
Re: Issues after migrating to a new server
Posted: Thu Feb 24, 2022 2:27 pm
by pbroste
Hello
@hbouma
Thanks for following up, let us know what the results:
Code: Select all
echo 'DONE' | openssl s_client -showcerts -connect your.ad_or_ldap.server:636
Please send a copy of the following configs:
Code: Select all
tar -czvf /tmp/sslconfigs.tar.gz /etc/httpd/conf.d/ssl.conf /etc/pki/tls/openssl.cnf
Thanks,
Perry
Re: Issues after migrating to a new server
Posted: Thu Feb 24, 2022 5:01 pm
by hbouma
I will send you the file via PM.
Code: Select all
echo 'DONE' | openssl s_client -showcerts -connect REDACTED:636
CONNECTED(00000003)
depth=3 CN = REDACTED
verify return:1
depth=2 DC = REDACTED
verify return:1
depth=1 DC = REDACTED
verify return:1
depth=0 CN = REDACTED
verify return:1
---
Certificate chain
REDACTED
-----BEGIN CERTIFICATE-----
REDACTED
-----END CERTIFICATE-----
REDACTED
-----BEGIN CERTIFICATE-----
REDACTED
-----END CERTIFICATE-----
REDACTED
-----BEGIN CERTIFICATE-----
REDACTED
-----END CERTIFICATE-----
---
Server certificate
subject=REDACTED
issuer=REDACTED
---
No client certificate CA names sent
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512
Shared Requested Signature Algorithms: RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 5184 bytes and written 475 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: REDACTED
Session-ID-ctx:
Master-Key: REDACTED
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1645739946
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: yes
---
read:errno=104
Re: Issues after migrating to a new server
Posted: Fri Feb 25, 2022 5:27 pm
by pbroste
Hello
@hbouma
Thanks for following up with the info;
read:errno=104 indicates the connection was forcibly closed with a TCP RST. To help determine what is going on let's circle back around and get:
Start tcpdump capture:
Code: Select all
tcpdump -s 0 -i any port <yourldapporthere> -w /tmp/output.pcap
Then run through:
Code: Select all
echo 'DONE' | openssl s_client -showcerts -connect your.ad_or_ldap.server:636
Let's get the curl results from the api:
Code: Select all
curl -k --verbose -XPOST "https://yournagioshostaddresshere/nagiosxi/api/v1/system/authserver?apikey=yourapikeyhere&pretty=1" -d "conn_method=ldap&ldap_host=yourldaphostaddresshere&base_dn=fulldistinguished namehere&security_level=ssl"
Please send over the 'tcpdump' command output found in '/tmp/output.pcap' and let us know how things look. Any chances to see what the LDAP server is looking at in the Eventlogs during the auth attempts?
Thanks,
Perry