I am trying to run OpenLDAP (2.4.44 on RedHat 7.6) as a client against an existing LDAP server with TLS. This is working well - too well, actually. It looks to me as if OpenLDAP accepts any server certificate, instead of validating it against the CAs I provided.
Here is my ldap.conf file:
TLS_CACERT /etc/openldap/cacerts/ldap-2019.pem
TLS_REQCERT demand
URI ldaps://ldap.mydomain.com/
BASE ou=people,dc=mydomain,dc=com
# Some optimizations suggested by
# https://sourceforge.net/p/xcat/wiki/Setting_up_LDAP_in_xCAT/
set_cachesize 0 268435456 1
set_lg_regionmax 262144
set_lg_bsize 2097152
What I want to accomplish is of course that OpenLDAP validates the certificate for ldaps://ldap.mydomain.com against the list of CAs in TLS_CACERT.
But in reality, no matter what I put into the TLS_CACERT file, openldap seems to connect successfully, just as long as it is a valid PEM file.
What am I missing? Is there a second list of CAs that OpenLDAP consults? I also removed the CAs in /etc/pki/tls, just in case.
More details:
ldapsearch -x -uid=somename fails if I delete the file I specified in TLS_CACERT. It also fails if TLS_CACERT is not a valid PEM file. This is of course expected behavior when the client cannot validate a TLS certificate:
ldapsearch -x uid=somename
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
But if I put a completely nonsensical certificate into the TLS_CACERT file, ldapsearch will return a result as if the server's certificate was valid.
ldapsearch -x uid=somename
# extended LDIF
#
# LDAPv3
# base <ou=people,dc=mydomain,dc=com> (default) with scope subtree
# filter: uid=somename
# requesting: ALL
#
# somename, People, mydomain.com
dn: uid=somename,ou=People,dc=mydomain,dc=com
...
For example, I tried using a certificate for www.google.com as a TLS_CACERT. I would have expected this connection to fail with the same "Can't contact LDAP server" error.
Update:
I found the cause but not the solution. OpenLDAP uses the certificate bundle in /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem . Renaming this file causes ldapsearch to behave as I expected, but of course that is not an acceptable solution since this is a systemwide file, not just for OpenLDAP.
So my new question is: how do I prevent OpenLDAP from using this file?
Update 2:
For clarification, this is on RedHat 7.6, and OpenLDAP 2.4.44. I assume that using the systemwide CA bundle is a RedHat modification to the stock OpenLDAP.
Related
i have configured ldap client (ubuntu 20.04) with nss_ldap to connect on ldap server and accept users in a specific group, it seems that everything is working fine, the client can access the ldap server and ldap users can access the client machine. however i am receiving the following error message when the client connects to ldap server:
systemd-logind: nss_ldap: failed to bind to LDAP server ldap://[IP address]: Can't contact LDAP server
systemd-logind: nss_ldap: reconnecting to LDAP server...
systemd-logind: nss_ldap: could not connect to any LDAP server as cn=admin,dc=example,dc=com - Can't contact LDAP server
systemd-logind: nss_ldap: could not search LDAP server - Server is unavailable
and here is my configuration files:
/etc/ldap.conf
regarding that parameter (nss_initgroups_ignoreusers) is auto-generated.
# The distinguished name of the search base.
base dc=example,dc=com
# Another way to specify your LDAP server is to provide an
uri ldap://[IP address]
# The LDAP version to use (defaults to 3
# if supported by client library)
ldap_version 3
# The distinguished name to bind to the server with
# if the effective user ID is root. Password is
# stored in /etc/ldap.secret (mode 600)
rootbinddn cn=admin,dc=example,dc=com
# Do not hash the password at all; presume
# the directory server will do it, if
# necessary. This is the default.
pam_password md5
nss_initgroups_ignoreusers _apt,backup,bin,clamav,daemon,fwupd-refresh,games,gnats,irc,landscape,list,lp,lxd,mail,man,messagebus,mysql,news,pollinate,proxy,root,sshd,sync,sys,syslog,systemd-coredump,systemd-network,systemd-resolve,systemd-timesync,tcpdump,tss,uucp,uuidd,www-data
/etc/ldap.secret --> contain the password.
/etc/nsswitch.conf
passwd: files ldap systemd
group: files ldap systemd
shadow: files ldap
gshadow: files
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
/etc/pam.d/common-session
# here are the per-package modules (the "Primary" block)
session [default=1] pam_permit.so
# here's the fallback if no module succeeds
session requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
session required pam_permit.so
# The pam_umask module will set the umask according to the system default in
# /etc/login.defs and user settings, solving the problem of different
# umask settings with different shells, display managers, remote sessions etc.
# See "man pam_umask".
session optional pam_umask.so
# and here are more per-package modules (the "Additional" block)
session required pam_unix.so
session optional pam_ldap.so
session optional pam_systemd.so
session required pam_mkhomedir.so skel=/etc/skel umask=0022
/etc/security/access.conf
added this line [ -:ALL EXCEPT root khloud (ldap-group) (admin) ubuntu:ALL EXCEPT LOCAL ]
/etc/pam.d/sshd --> uncomment the following line:
account required pam_access.so
Note:
i tested the connection also with ldapsearch and it works.
i tried to change in nsswitch.conf file or reinstalling nss_ldap client again but i still receiving the same error while everything is working right.
I am using devise, devise_ldap_authenticatable module to do simple ldap authentication.
But if I try to authenticate on ssl (689 port), I have this error:
Net::LDAP::Error (hostname "x.x.x.x" does not match the server certificate):
So, I need to ignore this verification.
I tried to google, but I have no result :(
How I can do it?
Per the devise_ldap_authenticatable documentation
If you're using a test LDAP server running a self-signed SSL certificate, make sure the appropriate root certificate is installed on your system. Alternately, you may temporarily disable certificate checking for SSL by modifying your system LDAP configuration (e.g., /etc/openldap/ldap.conf or /etc/ldap/ldap.conf) to read TLS_REQCERT never.
I enabled TLS in NiFi by running the below command,
nifi-toolkit/nifi-toolkit-assembly/target/nifi-toolkit-1.4.0-SNAPSHOT-bin/nifi-toolkit-1.4.0-SNAPSHOT/bin/tls-toolkit.sh standalone -n "{my-ip},localhost" -C 'CN={my-ip}' -C 'CN=localhost' -o ./certs
This created the files required for TLS under the directory certs.
I moved the files under the directory certs into the conf folder of the deployment in my machine.
Installed the certificate to my machine's Keychain Access.
Now started the server using bin/nifi.sh start. My server starts, I am able to hit the server, But my request is not authorized.
I am getting the below error,
Not authorized for the requested resource. Contact the system
administrator.
Once TLS is enabled in Apache NiFi, anonymous access is no longer enabled by default. You will need to authenticate as a user in order to access the UI/API. There are three authentication mechanisms available -- client certificates, LDAP, or Kerberos. Once you configure an Initial Admin Identity in $NIFI_HOME/conf/authorizers.xml (this would be the exact CN of the client certificate you issued in the TLS Toolkit command), that user can authenticate and use the user management tools in NiFi to add additional users.
You can find more information in the NiFi Admin Guide. Bryan Bende has also written a detailed walkthrough of the process.
One note about the command you posted above -- I am not sure what your desired output is, but the command is issuing a server certificate for my-ip and another for hostname, but then two client certificates with those DNs as well. In general, you want a server certificate for hostname (possibly with a SAN entry for my-ip), and a client certificate with a DN like CN=alopresto, OU=Apache NiFi.
For example:
./bin/tls-toolkit.sh standalone
-n 'nifi.nifi.apache.org'
--subjectAlternativeNames '123.234.234.123'
-C 'CN=alopresto, OU=Apache NiFi'
-P password
-S password
-B password
-f ...conf/nifi.properties
-o ...conf/
I'm trying to start my TURN server with TLS enabled. I use the following line to start the server:
daemon --user=$USER $TURN $OPTIONS --tls-listening-port 3478 --cert /root/cert_2014_11/my_domain_nl.crt --pkey /root/cert_2014_11/my_domain_nl.key --CA-file /root/cert_2014_11/PositiveSSLCA2.crt
The environment variables in there are set in the config file. The server works fine without TLS using the same startup line, but if I add the three SSL related arguments, the server still isn't reachable over TLS. I tried setting a different port for SLL instead of the standard port, but it still didn't work. Whatever I do, I can reach the server without SLL, but over TLS I can't reach it. The certificate chain I use if fine, I use it for our website as well.
I've run into this exact problem before. Have a look at the documentation for the --CA-file argument:
--CA-file <filename> CA file in OpenSSL format.
Forces TURN server to verify the client SSL certificates.
By default, no CA is set and no client certificate check is performed.
This argument is needed only when you will be verifying client certificates. It's not for the certificate chain for your server certificate.
Drop the --CA-file argument, keeping the --cert and --pkey arguments.
EDIT: FYI, the certificate file you give to the --cert option can contain the entire certificate chain (yours and your CA's).
I've got problems connecting secure (SSL) to an IBM LDAP server using an openLDAP client.
A connection like the following, which is not using SSL works fine:
ldapsearch -h <LDAP server host name> -D <bind dn> -w ? -b <base dn> <filter>
But when I add the -Z option to use a secure LDAP connection (SSL) like shown in the following ldapsearch an error occours:
ldapsearch -h <LDAP server host name> -Z -D <bind dn> -w ? -b <base dn> <filter>
The error says:
ldap_simple_bind: Can't contact LDAP server
Attempted communication over SSL.
The extended error is 116.
Here I found out that I have to add ssl start_tls to the clients configuration file (ldap.conf) to enable SSL in openLDAP: http://www.openldap.org/faq/data/cache/185.html
After reading the description above I'm not sure if the author is dealing with an openLDAP client and an openLDAP server and if this is the only change that have to be made to make the connection work.
Does anybody here know if it is possible to connect from an openLDAP client to an IBM LDAP server using an SSL connection?
Does anybody have experience with this topic?
Thanks a lot!
As far as I know, OpenSSL no longer provides CA signer certificates in its trust store (i.e., CA cert file). Therefore, you will have to configure OpenLDAP's ldapsearch through the file .ldaprc or ldap.conf to specify the location of the trust store that has the signer certificates for your LDAP server. Something like this:
TLS_CACERT /usr/ssl/certs/my.ldapserver.certs.pem
# TLS_CACERTDIR /usr/ssl/certs/
TLS_REQCERT never|allow||try|demand|hard
See
http://www.openldap.org/software/man.cgi?query=ldap.conf&format=html
http://www.openldap.org/faq/data/cache/185.html
for more details.
IBM's website has a discussion of this error.
A number of possibilities, mostly server side, about keys not being in the keystore, expired, or not using port 636. So you can look at this and see if it helps you.