openldap-technical

openldap-technical@openldap.org

5 participants
9899 discussions

ldap_start_tls_s fails
by James Gordon 25 Feb '22

25 Feb '22

Hi, I have just installed symas openldap v2.6. Everything seems to be running ok, except that I cannot get C interface ldap_start_tls_s() to work. If I do something like this the program works fine: ldap_initialize(&ld, HOST)); rc = ldap_simple_bind_s(ld, BASEDN, BASEPWD); ldap_unbind(ld); However, if I do something like this the program fails with ldap error string "local error": ldap_initialize(&ld, HOST)); ldap_set_option(ld, LDAP_OPT_X_TLS_CACERTFILE); ldap_start_tls_s(ld, NULL, NULL); rc = ldap_simple_bind_s(ld, BASEDN, BASEPWD); ldap_unbind(ld); From the command line, TLS seems to work fine: The following works ok: ldapsearch -H ldap://ldap.domain.com:389 -D "cn=admin,dc=domain,dc=com" -w secret -b “ou=users,dc=domain,dc=com” -ZZ This also works ok from a different server openssl s_client -verify 10 -starttls ldap -showcerts -connect ldap.domain.com:389 -CApath /etc/ssl/certs (verification = ok): However, if I omit the CApath it fails, not sure if that is a clue to the problem: openssl s_client -verify 10 -starttls ldap -showcerts -connect ldap.domain.com:389 (Verification error: unable to get local issuer certificate). Any help would be appreciated. If this is the wrong list, let me know. ldapsearch -H ldap://ldap.red0rb.com:389 -D "cn=admin,dc=red0rb,dc=com" -w MdKlUIGYm0o63HxQ0RWYuKWkRkgr3Ohy -b “ou=users,dc=red0rb,dc=com” -ZZ

1 0

Re: 2.5 Quick-Start guide roadblock: ldap_bind: Confidentiality required (13)
by Ben Poliakoff 24 Feb '22

24 Feb '22

> > Steps 1-7 involve building the software, which I would not expect you to > be > doing if you're using Symas' packages? > You are, of course, correct about my having not compiled slapd, I misspoke. > In any case, I have no idea what changes you made to the original LDIF. I > have no such issue doing only the changes advised in the quickstart guide: > I sorted out what was happening. I was using the ldapadd command syntax from the Quick-Start guide, which doesn't use the '-H ldap:///' parameter, so ldapadd was picking up defaults from /etc/ldap/ldap.conf and happily talking to our existing production slapd, running on a different server (which of course does require secure binds). However, when I added '-H ldap:///' to the ldapadd command, ensuring that the ldap traffic was now going to the correct server (headpalm), the command fails with "ldap_bind: Invalid credentials (49)". At this point the olcRootPW in my slapd.ldif is the default ("secret"), and I can see that the base64 encoded olcRootPW in "slapd.d/cn=config/olcDatabase={1}mdb.ldif" is "olcRootPW:: c2VjcmV0" (which is, in fact the base64 encoding for "secret"). Does anyone have debugging approaches that might help me sort out why slapd isn't happy with the password? Also with regard to this mailing list's protocol, would it be better to ask this question in a separate thread? (It's humbling to be asking such phenomenally basic questions, having built and managed our existing openldap servers for many many years.) Ben

2 1

Is there a way to expose SLDAP Server Metrics to Prometheus?
by vtejaswini1＠gmail.com 24 Feb '22

24 Feb '22

It would be interesting if there were any official Prometheus exporter to monitor LDAP metrics. If we have one such exporter, does it authenticate LDAP Server to aggregate/formulate/capture metrics? Thanks, Teja

3 4

Unable to change ssl version on openldap 2.6.0
by Frédéric Goudal 24 Feb '22

24 Feb '22

Hello, For a legacy application we need to drop the ssl version available on our openldap server. Currently it supports TLSv1.2, checked with nmap --script ssl-enum-ciphers -p 636 host What ever value I put on olcTLSProtocolmin the ssl version does not change… I have tried 3.0 3.1 3.2… What do I miss ? Or is it a feature ? Thanks in advance f.g. — Frédéric Goudal Ingénieur Système, DSI Bordeaux-INP +33 556 84 23 11

2 6

Is there a way to silence or redirect BIND Operation Logs in SLDAP?
by vtejaswini1＠gmail.com 23 Feb '22

23 Feb '22

Hi, For each LDAP BIND Operation, SLDAP Server logs a significant amount of logs (> 10 Log Lines). Is there a way to silence or redirect or configure these logs or BIND Operation itself? Thanks, Teja

2 5

2.5 Quick-Start guide roadblock: ldap_bind: Confidentiality required (13)
by Ben Poliakoff 23 Feb '22

23 Feb '22

I've been using the Symas OpenLDAP debian packages, and following the Quick-Start guide for 2.5: https://www.openldap.org/doc/admin25/quickstart.html Following steps 1 - 10 has been straight forward, but when I get to step 11 (Add initial entries to your directory), I run into trouble when running the ldapadd command: root@openldap-x:/opt/symas/etc/openldap# ldapadd -x -D "cn=Manager,dc=example,dc=com" -W -f bootstrap.ldif Enter LDAP Password: ldap_bind: Confidentiality required (13) additional info: confidentiality required root@openldap-x:/opt/symas/etc/openldap# I used the provided slapd.ldif.default to seed the cn=config (updating it with the appropriate domain components), as per the instructions in the Quick-Start, so slapd isn't yet configured to run with ssl or starttls. Is there a default SSF factor that I should adjust to get past this bootstrapping failure? I don't see anything like that explicitly set in the configs that were rendered into /opt/symas/etc/openldap/slapd.d, from my slapd.ldif. I'm not new to openldap, but this is the first time I've used the Symas packages and also the first time trying to use olc instead of a slapd.conf based configuration. Ben

2 1

OpenLdap on Rocky 8 -- suggestions?
by Aaron Bennett 23 Feb '22

23 Feb '22

Hi, I'm migrating a small two-node OpenLDAP cluster from CentOS 7 to Rocky 8. I've been maintaining my own openldap rpms forked off of the RHEL 7 srpms, edited to link against OpenSSL instead of the never-to-be-sufficiently-d*mned GnuTLS. Now that there is no official openldap build from RedHat, I'm evaluating my choices. Essentially it comes down to these: 1. Build from source every time. Not difficult and I'm comfortable with it, but I prefer when possible to not drop non-rpm packaged files into production 2. Package it myself. If we still used it super extensively like we did in the past, I would do this, but it's a lot of work. 3. Look for third-party packages that are frequently updated. My preference is 3, which of course leads me to Symas OpenLdap. Looking at the symas page, it looks like there are two branches, the LTS 2.5 branch and the 2.6 branch. If this is accurate and the 2.5 branch is updated with security backports, etc, and is still gratis, that's the direction I'm looking to go. Any gotchas, or am I totally missing something obvious? Best, Aaron Bennett --- Aaron Bennett Manager of Systems Administration Clark University ITS

2 1

Re: log analysis tools
by Clément OUDOT 22 Feb '22

22 Feb '22

Le sam. 5 févr. 2022 à 20:57, Quanah Gibson-Mount <quanah(a)fast-mail.org> a écrit : > > > --On Friday, February 4, 2022 10:12 PM -0500 Dave Macias <davama(a)gmail.com> > > wrote: > > > > > > > https://www.ltb-project.org/documentation/ldap-stats.html > > Is that the one I used to help maintain? I don't believe it's been updated > for 2.5 and later, unless it was forked and someone else has started > working on it. > Hello Quanah, this is indeed a fork done inside LTB project, there was no git repo for this script (or I did not found it). Of course if there are changes in 2.5 log format, we can update the script. Clément.

4 8

str2entry: invalid value for attributeType objectClass #1 (syntax 1.3.6.1.4.1.1466.115.121.1.38)
by gpaz＠iter.es 21 Feb '22

21 Feb '22

````` [root@ldap ~]# slapcat The first database does not allow slapcat; using the first available one (2) dn: dc=ldap,dc=test objectClass: top objectClass: dcObject objectClass: organization dc: ldap o: ldap_test_iter description: ldap_test_iter structuralObjectClass: organization entryUUID: 4a04a984-1dfc-103c-8835-d781e468857b creatorsName: cn=Manager,dc=ldap,dc=test createTimestamp: 20220209135948Z entryCSN: 20220209135948.842285Z#000000#000#000000 modifiersName: cn=Manager,dc=ldap,dc=test modifyTimestamp: 20220209135948Z dn: ou=users,dc=ldap,dc=test objectClass: organizationalUnit ou: users structuralObjectClass: organizationalUnit entryUUID: 4a09e624-1dfc-103c-8836-d781e468857b creatorsName: cn=Manager,dc=ldap,dc=test createTimestamp: 20220209135948Z entryCSN: 20220209135948.876561Z#000000#000#000000 modifiersName: cn=Manager,dc=ldap,dc=test modifyTimestamp: 20220209135948Z dn: ou=groups,dc=ldap,dc=test objectClass: organizationalUnit ou: groups structuralObjectClass: organizationalUnit entryUUID: 4a0dc5fa-1dfc-103c-8837-d781e468857b creatorsName: cn=Manager,dc=ldap,dc=test createTimestamp: 20220209135948Z entryCSN: 20220209135948.901999Z#000000#000#000000 modifiersName: cn=Manager,dc=ldap,dc=test modifyTimestamp: 20220209135948Z dn: uid=pedro,ou=users,dc=ldap,dc=test uid: pedro cn: pedro sn: pedro objectClass: top objectClass: posixAccount objectClass: inetOrgPerson loginShell: /bin/bash uidNumber: 500 gidNumber: 500 mail: pedro(a)example.com gecos: pedro user homeDirectory: /home/pedro structuralObjectClass: inetOrgPerson entryUUID: 908089be-1dfc-103c-8838-d781e468857b creatorsName: cn=Manager,dc=ldap,dc=test createTimestamp: 20220209140147Z userPassword:: e1NTSEF9eWdWaGZSMFhKY3N3blpLREdMbm9TU0VlanVWK01jL0s= entryCSN: 20220217123622.452494Z#000000#000#000000 modifiersName: uid=pedro,ou=users,dc=ldap,dc=test modifyTimestamp: 20220217123622Z dn: cn=pedro,ou=groups,dc=ldap,dc=test objectClass: posixGroup objectClass: top cn: pedro userPassword:: e2NyeXB0fXg= gidNumber: 500 memberUid: uid=pedro structuralObjectClass: posixGroup entryUUID: 9096c90e-1dfc-103c-8839-d781e468857b creatorsName: cn=Manager,dc=ldap,dc=test createTimestamp: 20220209140147Z entryCSN: 20220209140147.240435Z#000000#000#000000 modifiersName: cn=Manager,dc=ldap,dc=test modifyTimestamp: 20220209140147Z dn: cn=module,dc=ldap,dc=test cn: module objectClass: top objectClass: olcModuleList olcModuleLoad: ppolicy.la olcModulePath: /usr/lib64/openldap structuralObjectClass: olcModuleList entryUUID: 8ffa80b4-243f-103c-809a-d143605cbb0e creatorsName: cn=Manager,dc=ldap,dc=test createTimestamp: 20220217131629Z entryCSN: 20220217131629.473761Z#000000#000#000000 modifiersName: cn=Manager,dc=ldap,dc=test modifyTimestamp: 20220217131629Z dn: ou=ppolicy,dc=ldap,dc=test objectClass: organizationalUnit ou: ppolicy structuralObjectClass: organizationalUnit entryUUID: aeeed796-2443-103c-9d36-4f3e029afe7a creatorsName: cn=Manager,dc=ldap,dc=test createTimestamp: 20220217134559Z entryCSN: 20220217134559.393630Z#000000#000#000000 modifiersName: cn=Manager,dc=ldap,dc=test modifyTimestamp: 20220217134559Z ````` When I try enable the modulo I obtain the next error: ````` [root@ldap ldap]# slapadd -n2 -l 2.2_ppolicy-bdb-ldap.test.ldif str2entry: invalid value for attributeType objectClass #1 (syntax 1.3.6.1.4.1.1466.115.121.1.38) slapadd: could not parse entry (line=1) _#################### 100.00% eta none elapsed none fast! Closing DB... ````` File 2.2_ppolicy-bdb-ldap.test.ldif: ````` [root@ldap ldap]# cat 2.2_ppolicy-bdb-ldap.test.ldif dn: olcOverlay=ppolicy,olcDatabase={2}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: ppolicy olcPPolicyDefault: cn=default,ou=ppolicy,dc=ldap,dc=test olcPPolicyUseLockout: TRUE olcPPolicyHashCleartext: TRUE ````` Could anyone help me?

2 3

slapcat truncates slapd.log
by Jose Garcia 21 Feb '22

21 Feb '22

Hello, openldap.org community! This is my first thread here, in the hopes of finding a better understanding of a problem I'm having with OpenLDAP after several hours of unsuccessful troubleshooting. I'm in no way an expert on the matter so maybe someone more experienced here could help me get things a bit clearer. I recently found this issue in two Ubuntu 18.04 servers I'm running with OpenLDAP 2.4 and bdb backend for their databases. I want to export my LDAP database to an LDIF file by running: # slapcat -l database.ldif This works just fine. However, I realized every time I run such slapcat command, my slapd.log file gets truncated (i.e. all previous log entries are deleted). This happens on both servers, no matter if the slapd daemon is running or not. I don't know if this is normal or expected behavior, but it is weird to me that slapcat is wiping the log files. From what I understood slapd is in charge of the logging, so why is slapcat messing with that? Is this just normal/expected behavior, or am I experiencing some kind of weird issue here?

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