openldap-technical

openldap-technical@openldap.org

9897 discussions

Ubuntu ldap client using DNS SRV
by thiago.conrado＠ez-masternodes.com 08 Oct '20

08 Oct '20

Hello everyone, just to share the trick of how to configure openLDAP in Ubuntu. we did config the domain DNS SRV records and ldapsearch -x -LLL -H ldap:///dc%3Dmy-domain%2Cdc%3Dcom works fine... dig shall also return the target server and port with the command "dig SRV _ldap._tcp.my-domain.com." the confusing part is: there are 2 ldap.conf files; a) at /etc/ldap.conf: this one will control the how Ubuntu check user id, feeding PAM via nss_ldap; just keep it with no URI or commented URI entries and DNS SRV will work as expected (DN must be in place); it is possible to test it using the command "id <user>"; journalctl -f and tcpdump port 389 are useful for troubleshoting; b) at /etc/lpad/ldap.conf: it is the param source for tools as ldapsearch; we were not able to make it work without declaring URI, hence, we just pointed to one LDAP server, but you can list it all; another option is to do command aliases as in http://www.rjsystems.nl/en/2100-dns-discovery-openldap.php; a proper configuration should list all the users with ldapsearch -x -LLL; anyway, doing a very small contribution to this great project, as it took us 4 hours to get it going, and we found old mentions that openLDAP do not do resolve SRV records (which was the case in the past), as also, there are some client implementations that do resolve and some that don't. LDAP is very powerful to escalate servers/virtual machines in which credentials sync are required best regards all

1 0

TLS: can't accept: No certificate was found..
by kevhilton＠gmail.com 06 Oct '20

06 Oct '20

Hi - I'm using osixia/openldap docker container. I've created self signed client and server certs. I'm receiving the following error when trying to perform ldapsearch from the Arch linux docker host. Here is a summary of the error: # ldapsearch -x -d1 -b 'dc=ldap,dc=gohilton,dc=com' -D "cn=admin,dc=ldap,dc=gohilton,dc=com" -H ldaps://127.0.0.1:636 -W -LLL d ldap_url_parse_ext(ldaps://127.0.0.1:636) ldap_create ldap_url_parse_ext(ldaps://127.0.0.1:636/??base) Enter LDAP Password: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 127.0.0.1:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 127.0.0.1:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL_connect:SSLv3/TLS read server hello TLS certificate verification: depth: 0, err: 0, subject: /C=US/ST=IL/L=CH/O=domain.com/CN=openldap/emailAddress=user(a)domain.com, issuer: /C=US/ST=IL/L=CH/O=domain.com/CN=Docker OpenLDAP CA/emailAddress=user(a)domain.com TLS trace: SSL_connect:SSLv3/TLS read server certificate TLS trace: SSL_connect:SSLv3/TLS read server key exchange TLS trace: SSL_connect:SSLv3/TLS read server certificate request TLS trace: SSL_connect:SSLv3/TLS read server done TLS trace: SSL_connect:SSLv3/TLS write client certificate TLS trace: SSL_connect:SSLv3/TLS write client key exchange TLS trace: SSL_connect:SSLv3/TLS write change cipher spec TLS trace: SSL_connect:SSLv3/TLS write finished TLS trace: SSL_connect:error in SSLv3/TLS write finished TLS: can't connect: . ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) The server logs the error as the following: f7a7260 conn=1007 fd=12 ACCEPT from IP=172.18.0.1:34350 (IP=0.0.0.0:636) TLS: can't accept: No certificate was found.. 5f7a7260 conn=1007 fd=12 closed (TLS negotiation failure) This error only occurs if on the server I use the following server setting: LDAP_TLS_VERIFY_CLIENT=try Is this possibly a permissions issue? I've verified the chain of trust for client certificate upon creation. Both client and server certificates were signed with same user created CA.

3 5

TLS: during handshake: Peer certificate is not trusted: kSecTrustResultRecoverableTrustFailure
by Siddharth Jain 05 Oct '20

05 Oct '20

(I mistakenly posted this at openldap-its earlier. apologies if anyone saw it there) Hello, We have a LDAP server running with TLS enabled and verified we can connect to it from openssl s_client. This works: $ openssl s_client -connect ldap.foo.com:636 -cert client_tls_cert.pem -key client_tls_key.pem -state -nbio -CAfile ca_chain.pem -showcerts But ldapsearch throws an error: $ ldapsearch -d 1 -x -H ldaps://ldap.foo.com:636 ... -ZZ TLS: during handshake: peer cert is valid, or was ignored if verification disabled (-9841) TLS: during handshake: Peer certificate is not trusted: kSecTrustResultRecoverableTrustFailure We followed the instructions given at https://www.openldap.org/doc/admin24/tls.html#Client%20Configuration. We edited /etc/openldap/ldap.conf like so: TLS_REQCERT demand TLS_CACERT ca_chain.pem TLS_CACERTDIR /path/to/ca/cert TLS_CERT client_tls_cert.pem TLS_KEY client_tls_key.pem The ca_chain.pem file is placed under /path/to/ca/cert. We are running ldapsearch on a Mac. Can anyone help us? Sid PS: we do see following on server: TLS trace: SSL_accept:before SSL initialization TLS trace: SSL_accept:before SSL initialization TLS trace: SSL_accept:SSLv3/TLS read client hello TLS trace: SSL_accept:SSLv3/TLS write server hello TLS trace: SSL_accept:SSLv3/TLS write certificate TLS trace: SSL_accept:SSLv3/TLS write key exchange TLS trace: SSL_accept:SSLv3/TLS write certificate request TLS trace: SSL_accept:SSLv3/TLS write server done

5 9

ACL not behaving as I would expect
by Scott Classen 02 Oct '20

02 Oct '20

Hello, I’m having trouble understanding why I can’t get a service account to reset a userPassword attribute. ACLs are: {0}to attrs=userPassword by self write by anonymous auth by * none {1}to * by self write by users read by dn.base="uid=pwreset,dc=example,dc=com" write by * none But when the password reset utility attempts to modify the password I see the following 50 error, indicating that the ACL is somehow preventing the pwreset account from modifying userPassword Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 fd=22 ACCEPT from IP=192.168.1.104:52888 (IP=0.0.0.0:389) Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=0 STARTTLS Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=0 RESULT oid= err=0 text= Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 fd=22 TLS established tls_ssf=256 ssf=256 Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=1 BIND dn="uid=pwreset,dc=example,dc=com" method=128 Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=1 BIND dn="uid=pwreset,dc=example,dc=com" mech=SIMPLE ssf=0 Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=1 RESULT tag=97 err=0 text= Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=2 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=username))" Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text= Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=3 MOD dn="uid=username,ou=People,dc=example,dc=com" Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=3 MOD attr=userPassword Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=3 RESULT tag=103 err=50 text= Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 op=4 UNBIND Oct 1 14:53:00 bl1231 slapd[10782]: conn=1036 fd=22 closed I’ve also tried with this ACL combination: {0}to attrs=userPassword by self write by anonymous auth by dn.base="uid=pwreset,dc=example,dc=com" write by * none {1}to * by self write by users read by * none Any advice would be greatly appreciated. Scott

3 7

Re: RE24 testing call #1 (OpenLDAP 2.4.54)
by Nick Folino 02 Oct '20

02 Oct '20

No problems noted on Fedora 32. On Thu, Oct 1, 2020 at 12:19 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > This is the first testing call for OpenLDAP 2.4.54. Depending on the > results, this may be the only testing call. > > Generally, get the code for RE24: > > < > https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_4/o… > > > > Extract, configure, and build. > > Execute the test suite (via make test) after it is built. Optionally, cd > tests && make its to run through the regression suite. > > Thanks! > > OpenLDAP 2.4.54 Engineering > Fixed slapd delta-syncrepl to ignore delete ops on deleted entry > (ITS#9342) > Fixed slapd delta-syncrepl to be fully serialized (ITS#9330) > Fixed slapd delta-syncrepl MOD on zero-length context entry (ITS#9352) > Fixed slapd sessionlog to use a TAVL tree (ITS#8486) > Fixed slapd syncrepl to be fully serialized (ITS#8102) > Fixed slapd syncrepl to call check_syncprov on fresh consumer > (ITS#9345) > Fixed slapd syncrepl to propagate errors from overlay_entry_get_ov > (ITS#9355) > Fixed slapd syncrepl to not create empty ADD ops (ITS#9359) > Fixed slapd syncrepl replace usage on single valued attrs (ITS#9295) > Fixed slapd-monitor fix monitor_back_register_database for empty > suffix > DB (ITS#9353) > Fixed slapo-accesslog normalizer for reqStart (ITS#9358) > Fixed slapo-syncprov contextCSN generation with empty suffix (ITS#9015) > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

Re: RE24 testing call #1 (OpenLDAP 2.4.54)
by Nick Folino 01 Oct '20

01 Oct '20

oops. Yes I did. Sorry. Nick On Thu, Oct 1, 2020 at 1:27 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Thursday, October 1, 2020 2:21 PM -0400 Nick Folino <nick(a)folino.us> > wrote: > > > > > --enable-monitor is missing from configure > > > > > > configure: WARNING: unrecognized options: --enable-monitor > > It appears you grabbed openldap trunk and not the RE24 branch. > > Regards, > Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

Re: RE24 testing call #1 (OpenLDAP 2.4.54)
by Nick Folino 01 Oct '20

01 Oct '20

--enable-monitor is missing from configure configure: WARNING: unrecognized options: --enable-monitor Nick On Thu, Oct 1, 2020 at 12:19 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > This is the first testing call for OpenLDAP 2.4.54. Depending on the > results, this may be the only testing call. > > Generally, get the code for RE24: > > < > https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_4/o… > > > > Extract, configure, and build. > > Execute the test suite (via make test) after it is built. Optionally, cd > tests && make its to run through the regression suite. > > Thanks! > > OpenLDAP 2.4.54 Engineering > Fixed slapd delta-syncrepl to ignore delete ops on deleted entry > (ITS#9342) > Fixed slapd delta-syncrepl to be fully serialized (ITS#9330) > Fixed slapd delta-syncrepl MOD on zero-length context entry (ITS#9352) > Fixed slapd sessionlog to use a TAVL tree (ITS#8486) > Fixed slapd syncrepl to be fully serialized (ITS#8102) > Fixed slapd syncrepl to call check_syncprov on fresh consumer > (ITS#9345) > Fixed slapd syncrepl to propagate errors from overlay_entry_get_ov > (ITS#9355) > Fixed slapd syncrepl to not create empty ADD ops (ITS#9359) > Fixed slapd syncrepl replace usage on single valued attrs (ITS#9295) > Fixed slapd-monitor fix monitor_back_register_database for empty > suffix > DB (ITS#9353) > Fixed slapo-accesslog normalizer for reqStart (ITS#9358) > Fixed slapo-syncprov contextCSN generation with empty suffix (ITS#9015) > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

ldap_start_tls: Connect error - self signed certificate in certificate chain
by paul.jc＠yahoo.com 30 Sep '20

30 Sep '20

Hello, I have recently upgraded from openldap 2.4.45 to 2.5.53. I are running into one issue when running ldapsearch wth StartTLS locally on the openldap servers. I get the following error whereas I did not prior to upgrade. Any input/suggestions welcome. $ ldapsearch -ZZ -LLL -H ldap://<uri> -x -D "cn=admin, dc=<test.dc,dc=com" -b "dc=test,dc=com" -w ${pw} ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain) Here is the debug: -------------- TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 3, err: 19, subject: /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority, issuer: /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority TLS certificate verification: Error, self signed certificate in certificate chain TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in error TLS trace: SSL_connect:error in error TLS: can't connect: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain). ldap_err2string ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain) -------------- This does not happen with the same ldapsearch done remotely - TLS works just fine with remote ldapsearch queries. Running ldapsearch without StartTLS locally on the server works just fine as well. Prior to this upgrade, we had built openldap with MozNSS (--with-tls=moznss) but now are using the recommended openssl. With our earlier version, running ldapsearch with StartTLS locally on the openldap servers worked without issue. Our certs are not self signed but it appears tls with ldapsearch is seeing the CA cert from our CA as self signed when running locally on the server. Is this even a problem since remote connectivity with TLS works fine? Since we were running moznss prior, I am not sure what the expected behavior is now but it seems that it should work the same as before. A few more details: ------------------ -Servers are CentOS Linux release 7.5 -We are running Openldap version: OpenSSL 1.0.2k-fips 26 Jan 2017 -We are using the same certs (no changes to the certs as part of the upgrade) -Here is partial output from openssl s_client -connect <hostname-here>:636 (same result with openssl s_client -connect <hostname-here>:389 -starttls ldap): This shows return code of 0 (ok): -------------- New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Verify return code: 0 (ok) -------------- -Ran openssl s_client -verify 3 -connect localhost:636 (and with hostname as well) and openssl s_client -showcerts -connect localhost:636. Both return code 0 (ok): Verify return code: 0 (ok) -Checked the certs: openssl verify -verbose -x509_strict -CAfile ca.crt slapd.crt slapd.crt: OK -Here is our cert config: olcTLSCACertificateFile: /etc/openldap/certs/ca.crt olcTLSCertificateFile: /etc/openldap/certs/slapd.crt olcTLSCertificateKeyFile: /etc/openldap/certs/slapd.key For reference, here is the debug output when running the same ldapsearch command locally on the server on our previous version (2.4.45 with moznss) and the same cert is validated. -------------- TLS: certdb config: configDir='/etc/openldap/certs' tokenDescription='ldap(0)' certPrefix='' keyPrefix='' flags=readOnly TLS: using moznss security dir /etc/openldap/certs prefix . TLS: certificate [CN=*<test-domain-here>,OU=Domain Control Validated] is valid TLS certificate verification: subject: CN=*<test-domain-here>,OU=Domain Control Validated, issuer: CN=Go Daddy Secure Certificate Authority - G2,OU=http://certs.godaddy.com/repository/,O="GoDaddy.com, Inc.",L=Scottsdale,ST=Arizona,C=US, cipher: AES-256-GCM, security level: high, secret key bits: 256, total key bits: 256, cache hits: 0, cache misses: 0, cache not reusable: 0 ldap_sasl_bind -------------- Any suggestions are appreciated. Thanks. Paul

2 3

When will OpenLDAP 2.5 be released officially?
by junc76＠gmail.com 30 Sep '20

30 Sep '20

Out product is planned to support the ldap channel binding required by MS (ADV190023). It seems that the feature has been implemented. https://bugs.openldap.org/show_bug.cgi?id=9189. From the isse description above, the target milestone is 2.5.0. My question is when will the version 2.5.0 be released? Thank you very much.

2 1

What does "slapcat: error writing output" means?
by Dario García Díaz-Miguel 30 Sep '20

30 Sep '20

Hello everyone, I couldn't find an answer or explanation about this error, so I hope somebody could help me over here. I use slapcat with head, grep and awk to retrieve some information and store it into a variable for a shell/bash script. Whenever I use slapcat, the output prompts the following error: - slapcat: error writing output. However, the information looked for is correctly retrieved. What's the reason behind this message? Is there a way to address it or at least, ignore it and hiding it? I can't just redirect that output to /dev/null. Version: Openldap2-2.4.41-18.43.1 Suse 12 SP3 Thank you so much. Kind Regards. Dario Garcia Díaz-Miguel GGCS-SES Unit GGCS SKMF Infrastructure Division GMV C\ de Isaac Newton, 11 28760, Tres Cantos, Madrid España +34 918 07 21 00 +34 918 07 21 99 www.gmv.com P Please consider the environment before printing this e-mail.

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical