openldap-technical

openldap-technical@openldap.org

10 participants
9969 discussions

Slapd unexpectedly shutdown
by Kevin Olbrich 06 Apr '20

06 Apr '20

Hi! I'm experiencing an issue with Slapd 2.4.49 on Debian Buster. I use Slapd as a proxy / lb with two AD nodes behind it. If I reboot one of the AD nodes, everything is fine. As soon as I reboot the seconds one (while the first is back and available), OpenLDAP shuts down immediately: Apr 06 22:03:33 ldap-lb1.ldap.example.com slapd[22140]: Stopping OpenLDAP: slapd. Apr 06 22:03:33 ldap-lb1.ldap.example.com systemd[1]: slapd.service: Succeeded. There is no traffic during this time and it matches the exact time when node two is down. Debian still uses an init script for slapd but I did not find anything interesting in it. Is there a config setting that I missed in the docs that explains this behavior? As it's not crashing, HA in systemd won't catch this issue. Kind regards Kevin

1 0

Re: NetworkRadius CentOS pkg uses openldap-ltb which conflict with symas-openldap
by Dave Macias 02 Apr '20

02 Apr '20

On Thu, Mar 26, 2020 at 3:44 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > Try it and see? I can't find any concrete documentation one way or the > other, although it seems BuildRequires generally follows what Requires > does. You may need to ask the people who maintain RPM. > > There are other issues in the spec file, however, like: > > --with-libfreeradius-ldap-include-dir=/usr/local/openldap/include \ > --with-libfreeradius-ldap-lib-dir=/usr/local/openldap/lib64 \ > > are specific to LTB, might want to do something like they did around line > 447 to only do this if the LTB openldap is in use. > Awesome! Thank you very much for the input! Will report how things go -Dave

2 2

Multiple OpenLDAP client instances with the c library
by Lasa Martxel 02 Apr '20

02 Apr '20

Hello, I'm using the openldap c client library (2.4.45). I would like to somehow have two client instances (not necessarily simultaneously) within the same application, but I'm having issues with the second instance I create. I have not found a way to clear the global options so the new ones (different ca cerficiate, different client certificate) can be used with the second instance. With the second ldap_initialize, global options are already initialized. Same with the TLS context, it's initialized too. I have seen that the function that destroys the global options is called only when the program exits, or the dyn library is unloaded. Is this correct? Is this somehow a limitation of the library? Thank you, Martxel

2 4

AD proxy / CAPITAL letters in attributes
by Kevin Olbrich 31 Mar '20

31 Mar '20

Hi! How can I disable the behavior of CAPITAL letters when OpenLDAP proxies an AD? I know they should be case insensitive but I had to debug Rocketchat for two hours to find, they use sAMAccountName (case sensitive) and the app crashed because mine was named SAMACCOUNTNAME. (I will open a bug there but I bet there is a lot of broken SW). Kind regards Kevin

3 6

NetworkRadius CentOS pkg uses openldap-ltb which conflict with symas-openldap
by Dave Macias 26 Mar '20

26 Mar '20

Good day Everyone, Back Story: We wanted to install the latest release of Freeradius from NetworkRadius and got a conflict. See post: http://lists.freeradius.org/pipermail/freeradius-users/2020-March/097718.ht… Their response was of course, figure it out and fix it yourself, which I have no problem with. I personally never compiled a rpm file before but i think i have an idea of what needs to be adjusted on their specs file. Wanted to run my changes by you guys, if you could please kindly review.... https://github.com/davama/freeradius-server/commit/7fa0f49e25de874bb5034584… https://github.com/davama/freeradius-server/commit/dab208186d440196c297821f… Not too sure if "BuildRequires" uses the same syntax but "Requires" does, at least what it says here: https://rpm.org/user_doc/boolean_dependencies.html Hope it's clear. Please let me know, if you need any info from me. Any input is much appreciated! Thank you, Dave

3 3

OpenLDAP-Proxy in front of AD - Non-DN bind
by Kevin Olbrich 26 Mar '20

26 Mar '20

Hi! I'm new to OpenLDAP / Slapd and try to integrate it into our AD setup. I followed this howto: https://wiki.samba.org/index.php/OpenLDAP_as_proxy_to_AD ... and ended up with this config: https://bitbucket.org/code-orange/django-cdstack-tpl-openldap-proxy/src/mas… Proxy mode works fine, I can bind with DN and password. So far so good. TLS works perfectly. On AD, I can bind using either domain\username or username(a)example.com. Can I enable this again for my proxy? Atm this does not work: Invalid DN-Syntax, invalid DN. I try to provide a secure way to connect a remove machine to our AD to read the contacts (a pbx). Using the DN worked for some devices but some have issues because of the length. If the DN is several OUs deep, the string is to long. Thats why I would like to allow the sAMAccountName as username (or USN, etc.). How can I solve this? Do I need SASL for this? Thank you very much! Kind regards Kevin

1 0

issues while modifying the LDAP on Production
by Guni Hanchate 25 Mar '20

25 Mar '20

Hi, we are getting some issues while modifying the LDAP on Production. We restarted LDAP instance but same issue persist. I request you to suggest on this . Let us know if you need any further information . I can read an entry From Cricetid via the VirtIP [u5356968@cricetid ~]$ldapsearch -x -LLL -h 192.168.154.33 -b "o=mobistar.be" "uid=u5356968" cn dn: uid=u5356968,ou=Techmahindra,ou=Partners,o=mobistar.be cn: DEMOULIN Philippe From Mousedeer to Mousedeer u5356968@mousedeer # ldapsearch -x -LLL -p 3898 -h 192.168.154.97 -b "o=mobistar.be" "uid=u5356968" cn dn: uid=u5356968,ou=Techmahindra,ou=Partners,o=mobistar.be cn: DEMOULIN Philippe But we cannot modify the entry. u5356968@mousedeer # ldapmodify -p 3898 -h 192.168.154.97 -D"cn=directory manager, o=mobistar.be" -w8ZQ7HUJS dn: uid=013tes3477,ou=Dealer Users,ou=Partners,o=mobistar.be changetype: add add: mail mail: 013test.test_osp_fr_hq(a)orange.be adding new entry "uid=013tes3477,ou=Dealer Users,ou=Partners,o=mobistar.be" ldap_add: Undefined attribute type (17) additional info: add: attribute type undefined This is the error I get: Error while executing LDIF - [LDAP: error code 17 - Undefined Attribute Type] java.lang.Exception: [LDAP: error code 17 - Undefined Attribute Type] at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.checkResponse(DirectoryApiConnectionWrapper.java:1280) at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.access$600(DirectoryApiConnectionWrapper.java:109) at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper$4.run(DirectoryApiConnectionWrapper.java:726) at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.runAndMonitor(DirectoryApiConnectionWrapper.java:1175) at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.checkConnectionAndRunAndMonitor(DirectoryApiConnectionWrapper.java:1109) at org.apache.directory.studio.connection.core.io.api.DirectoryApiConnectionWrapper.modifyEntry(DirectoryApiConnectionWrapper.java:748) at org.apache.directory.studio.ldapbrowser.core.jobs.ImportLdifRunnable.importLdifRecord(ImportLdifRunnable.java:514) at org.apache.directory.studio.ldapbrowser.core.jobs.ImportLdifRunnable.importLdif(ImportLdifRunnable.java:272) at org.apache.directory.studio.ldapbrowser.core.jobs.ExecuteLdifRunnable.executeLdif(ExecuteLdifRunnable.java:157) at org.apache.directory.studio.ldapbrowser.core.jobs.ExecuteLdifRunnable.run(ExecuteLdifRunnable.java:123) at org.apache.directory.studio.ldapbrowser.core.jobs.UpdateEntryRunnable.run(UpdateEntryRunnable.java:59) at org.apache.directory.studio.connection.ui.RunnableContextRunner$1.run(RunnableContextRunner.java:112) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) [LDAP: error code 17 - Undefined Attribute Type]

3 4

logging through systemd-journald is bottleneck
by Markus.Storm＠t-systems.com 20 Mar '20

20 Mar '20

Dear all, we're currently testing performance of OpenLDAP on Oracle/RedHat Linux and quite unexpected actually hit systemd-journald to be a bottleneck. While OpenLDAP happily makes use of all available CPUs, that one is single threaded, braking everything. The only way around I have found is to set olcLoglevel to 0, speeding up my test run by a factor of 6(!). That now of course is not an option to use in production. I'd happily directly write to a file as I did in the old days but I cannot get olcLogfile to work. And even if I was able to get there, how do I stop OpenLDAP from logging to syslogd (which is inevitably forwarding everything to system-journald ....) ? Can anyone give advice how to handle this ? Any hint appreciated (short of "get a decent OS" - that is not an option). Thanks, Markus

3 3

Antw: [EXT] Re: logging through systemd-journald is bottleneck
by Ulrich Windl 19 Mar '20

19 Mar '20

>>> Dieter Klünter <dieter(a)dkluenter.de> schrieb am 18.03.2020 um 19:57 in Nachricht <30206_1584557842_5E726F12_30206_1570_1_20200318195706.1d992aa0(a)pink.fritz.box>: > Am Wed, 18 Mar 2020 17:16:53 +0000 > schrieb <Markus.Storm(a)t-systems.com>: > >> Dear all, >> >> we're currently testing performance of OpenLDAP on Oracle/RedHat >> Linux and quite unexpected actually hit systemd-journald to be a >> bottleneck. While OpenLDAP happily makes use of all available CPUs, >> that one is single threaded, braking everything. The only way around >> I have found is to set olcLoglevel to 0, speeding up my test run by a >> factor of 6(!). That now of course is not an option to use in >> production. I'd happily directly write to a file as I did in the old >> days but I cannot get olcLogfile to work. And even if I was able to >> get there, how do I stop OpenLDAP from logging to syslogd (which is >> inevitably forwarding everything to system-journald ....) ? Can >> anyone give advice how to handle this ? Any hint appreciated (short >> of "get a decent OS" - that is not an option). > > I support Qanah's advice! > Beside this, consider a logging strategy based on required information > and neglected information, as well as min. and max. server load. > > Based on my experience I would disable logging as default, but enable > logging for a short given time, just a modify operation on atribute > olcLogLevel. > With regard to journald I advice to define filters, see man > journalctl(1). > If syslog is a requirement, change to rsyslog. Don't make use of > logstash! Can't openLDAP simply log to a different port than the default syslog port? If so, just set up some alternate local syslog server. Or, in case an external syslog server is supported, just use one that isn't using systemd-journald. Sorry, I neved had the need to use a different syslog mechanism... > > -Dieter > > -- > Dieter Klünter | Systemberatung > http://sys4.de > GPG Key ID: E9ED159B > 53°37'09,95"N > 10°08'02,42"E

4 3

write ACL
by Thomas Elsäßer 18 Mar '20

18 Mar '20

Hi ACL Gurus i would like following ACL , but i'm to stupid. cn=app1,ou=application,dc=company,dc=de -> groupOfNames Our Customer Admins are here cn=GroupLdapAdmin,o=customer1,ou=customer,dc=company,dc=de -> groupOfNames cn=GroupLdapAdmin,o=customer2,ou=customer,dc=company,dc=de -> groupOfNames member is the admin of this tree example member=cn=customer2.admin,ou=user,o=customer2,ou=customer,dc=company,dc=de I have 600 Customerx How can i write one ACL for all customer to access to cn=app1,ou=application,dc=company,dc=de to write access for groupLDAPAdmin for every company? This work for one customer access to dn.regex="cn=([^,]),ou=application,dc=company,dc=de" by by set.expand="(user) & ([cn=GroupLdapAdmin,o=customer1,ou=customer,dc=company,dc=de])/member" write How can write this for all without write 600 ACL? Thanx and stays healthy Thomas

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical