openldap-technical

openldap-technical@openldap.org

6 participants
9858 discussions

ldap proxy, attribute rwm
by Krisztián Gáhor 17 Oct '23

17 Oct '23

I created an LDAP proxy using an LDAP backend to connect to our Active Directory server. Unfortunately, our AD server has incorrect usernames in the sAMAccountName attribute, so I would like to override this with the prefix of the value found in the userPrincipalName attribute (the part before @domain). Is this possible at all? Unfortunately, I haven't succeeded in doing this so far.

1 0

Key/value chunk sizes / alignment?
by Sam Dave 14 Oct '23

14 Oct '23

Hello, I have two LMDB databases, identical except one has key size 34 bytes and the other key size 33 bytes. (Both have same value sizes and same number of pairs). How can the file sizes on disk be exactly the same? Is this because of the 2-byte alignment mentioned here? https://github.com/AltSysrq/lmdb-zero/issues/8 I wonder if this 2-byte alignment was documented anywhere. This doesn't bother me btw. I was just expecting the file sizes to differ (got scared I had a bug in my program until I did an mdb_dump to see the real difference) Thanks, Samuel

2 2

Trying to create master/slave solution with syncrepl
by Christoph Pleger 13 Oct '23

13 Oct '23

Hello, I am trying to create an OpenLDAP master/slave solution with syncrepl, but I have not been successful so far. I followed the suggestions of this site, with another sync password: https://www.itzgeek.com/how-tos/linux/configure-openldap-master-slave-repli… One thing I made different, on the master server, I created the replication user with a userPassword: in SSHA-Format instead of clear text. Additionally, I set, following the suggestion of another website: olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq Now, I can see with tcpdump that the slave server contacts the master server and that the master server send replies, but no LDAP users are synchronized to the slave. Unfortunately, nothing about replication is logged to syslog, though I started slapd on both master and slave with options "-s Sync -c rid=001". Any idea what is wrong or how I can at least get some debgging output about what is happening on master and slave, related to replication? Regards Christoph

4 6

contextCSN via slapcat outdated, despite having set syncprov-checkpoint
by cYuSeDfZfb cYuSeDfZfb 13 Oct '23

13 Oct '23

Hi, We are running replication checks, including one where we compare "slapcat | grep contextCSN" output across our 4 different openldap 2.5 MRR servers. Relevant config (on each server identically through ansible) database mdb maxsize 10737418240 suffix "o=company,c=com" rootdn "cn=ldapadmin,o=company,c=com" rootpw {SSHA}h9xyz..... directory /var/symas/openldap-data overlay syncprov syncprov-checkpoint 100 1 Now using this config, we would expect the contextCSN to be faily up-to-date across all servers, however, this is not always the case. There are occasions where servers contextCSN become 'outdated', while others are up-to-date. If we query contextCSN though ldapsearch, the correct contextCSN is returned on all servers. This situation can remain for long, and restarting openldap solves it immediately. We could of course change our logging to query contextCSN through an ldapsearch, but we see advantages (no network, no authentication, etc, etc) in using slapcat as well. Is there anything we can do to update on-disk contextCSN more often..? We would expect " syncprov-checkpoint 100 1" to take care of this..? Have a nice weekend, everybody! MJ

2 2

Re: refresh and persistant not always persisting :-)
by cYuSeDfZfb cYuSeDfZfb 11 Oct '23

11 Oct '23

Hi Quanah, I feel stupid for not having googled "openldap keepalive", and instead write to the list. I have read so much (and seen so many samples) about replication configuration lately, that I thought I did everything correctly. Thanks for patiently pointing at what I should have been able to find out myself. MJ On Wed, 11 Oct 2023 at 16:29, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Wednesday, October 11, 2023 4:49 PM +0200 cYuSeDfZfb cYuSeDfZfb > <cyusedfzfb(a)gmail.com> wrote: > > > > > > > Hi, > > > > > > Of course I add many more details like detailed configs and logs, just > > ask. > > > > > > We have a 4-host MMR setup, that all replicate to the three others, > > relevant snippets from the config: > > > > We wondered what could cause this behaviour, and started thinking in the > > direction of long-lived tcp connections that perhaps are used in > > refreshAndPersist functionality. (much like in IMAP idle) > > > > > > Is anything special needed to make refreshAndPersistwork reliably through > > firewalls, and across subnets? Does refreshAndPersistwork use (some kind > > of) long-lived network connections..? Is there a kind of "keepalive" > > setting that we could try..? > > Read the section on keepalive settings. This is a common issue with > firewalls and why those settings were introduced. I usually use > keepalive=240:10:30 to go under the (usually default) 5 minute disconnect > most firewalls have. > > --Quanah > >

1 0

refresh and persistant not always persisting :-)
by cYuSeDfZfb cYuSeDfZfb 11 Oct '23

11 Oct '23

Hi, Of course I add many more details like detailed configs and logs, just ask. We have a 4-host MMR setup, that all replicate to the three others, relevant snippets from the config: * moduleload syncprov.la * different (and consistent) serverID's configured correctly on all hosts and then on each host the three other LDAP servers are defined like the below sample from ldapm01.company.com : syncrepl rid=212 provider=ldaps://ldapm02.company.com:636 bindmethod=simple binddn="cn=ldap_replicate,ou=Directory Access,o=company,c=com" credentials=xyz searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="1 2 3 4 5 +" attrs="*,+" tls_reqcert=demand syncrepl rid=232 provider=ldaps://ldaps01.company.com:636 bindmethod=simple binddn="cn=ldap_replicate,ou=Directory Access,o=company,c=com" credentials=xyz searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="1 2 3 4 5 +" attrs="*,+" tls_reqcert=demand syncrepl rid=242 provider=ldaps://ldaps02.company.com:636 bindmethod=simple binddn="cn=ldap_replicate,ou=Directory Access,o=company,c=com" credentials=xyz searchbase="o=company,c=com" filter="(objectClass=*)" scope=sub schemachecking=on type=refreshAndPersist retry="1 2 3 4 5 +" attrs="*,+" tls_reqcert=demand MirrorMode True We observe that usually replication is quick and instant. But "sometimes" (yes, sometimes...) a replication line (rid) can become 'stuck', and suddeny, after an hour or so it syncs up again. Restarting openldap make it sync immediately. We notice that because we compare contextCSN's across our nodes to monitor replication. There is no significant load, firewall ports are open, but hosts are in different subnets: subnet A: ldapm01 / ldapm02, subnet B: ldaps01 / ldaps02 Of course 389/636 ports are open between the subnets. We wondered what could cause this behaviour, and started thinking in the direction of long-lived tcp connections that perhaps are used in refreshAndPersist functionality. (much like in IMAP idle) Is anything special needed to make refreshAndPersistwork reliably through firewalls, and across subnets? Does refreshAndPersistwork use (some kind of) long-lived network connections..? Is there a kind of "keepalive" setting that we could try..? Input would be appreciated. Also input like: you are looking in the wrong direction, better look into this or that. :-) Thanks!

2 1

pwdEndTime usage
by Volodymyr Lisnyi 11 Oct '23

11 Oct '23

Hello all, I updated our slapd daemon from 2.4 to 2.5 and want to use pwdEndTime operation attribute I read a lot of docs and can not find how I can add this attribute for all existing users. It is an internal operation attribute that was introduced in slapd version 2.5 (OpenLDAP 2.5+ now ships the ppolicy schema hard-coded in the overlay slapo-ppolicy) So as I see this attribute has no true/false or other flag (it is internal scheme attribute), which allows me to add it to dn: cn=passwordDefault,ou=Policies,dc=zone,dc=net or policy overlay olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config os is there any way I can enable it and update existing users with pwdEndTime attribute?

3 11

Re: [EXT] Re: regular yum symas-openldap-servers update breaks permissions on /var/symas/openldap-data
by cYuSeDfZfb cYuSeDfZfb 11 Oct '23

11 Oct '23

Hi Ulrich, I thought the same, but it seems yum/dnf do not have a post-install 'hook', like debian has with DPkg::Pre-Install-Pkgs & DPkg::Post-Invoke, that allows you to define commands/scripts to run before and after. Not sure how to do something similar on RHEL. I have now excluded openldap from auto updates, and added instructions on our manual update.instructions. Any ideas here..? On Wed, 11 Oct 2023 at 11:05, Windl, Ulrich <u.windl(a)ukr.de> wrote: > I wonder: > Couldn't some RPM "pre-script" remember the current permissions for some > RPM "post script" to restore them (after they were messed up)? > > -----Original Message----- > From: cYuSeDfZfb cYuSeDfZfb <cyusedfzfb(a)gmail.com> > Sent: Thursday, September 21, 2023 10:54 AM > To: Ondřej Kuzník <ondra(a)mistotebe.net> > Cc: openldap-technical(a)openldap.org; Dimitar Stoychev <dstoychev(a)symas.com > > > Subject: [EXT] Re: regular yum symas-openldap-servers update breaks > permissions on /var/symas/openldap-data > > Hi Ondřej, > > Thanks for your reply. > > Yes, we are putting our (single file) mdb straight in > /var/symas/openldap-data, using subdirs never crossed our minds. > > Anyway, we just have to document this behaviour in our upgrade > documentation. > > Must say: the behaviour, for us, is a little bit unexcpected. We didn't > expect rpm upgrades to "mess" with fs permissions, but we can simply work > around it. > > Thanks again for your reply, appreciated! > > > On Wed, 13 Sept 2023 at 12:25, Ondřej Kuzník <ondra(a)mistotebe.net <mailto: > ondra(a)mistotebe.net> > wrote: > > > On Tue, Sep 12, 2023 at 04:44:15PM +0200, cYuSeDfZfb cYuSeDfZfb > wrote: > > Hi, > > > > We're seeing this quite consistently. > > > > Before updating: > > [root@ldaps01 log]# ls -l > > /var/symas/ drwx------. 3 ldap ldap 50 Aug 28 16:28 openldap-data > > > > After updating: > > [root@ldaps01 log]# ls -l > > /var/symas/ drwx------. 3 root root 50 Aug 28 16:28 openldap-data > > > > And afterwards symas-openldap-server (running as ldap:ldap) no > longer > > starts, since permission denied on /var/symas/openldap-data. > > > > Reverting the permissions back to ldap:ldap solves it. But...WHY > is this > > happening. > > > > Are we somehow encouraged to run openldap as root..? > > > > Why would a post-install script reset permissions on > > /var/symas/openldap-data? > > Hi, > openldap-data is owned by the package and as such you'll have to > tell > rpm somehow (a trigger, ...) that you don't want it to mess with > it. > AFAIK there's work ongoing to make the directory 711 which should > sort > things for you. > > That's unless you're putting the databases directly into > /var/symas/openldap-data, we advise you create a subdirectory per > DB, > e.g. /var/symas/openldap-data/dc=example,dc=com or > /var/symas/openldap-data/cn=accesslog. > > Regards, > > -- > Ondřej Kuzník > Senior Software Engineer > Symas Corporation http://www.symas.com > Packaged, certified, and supported LDAP solutions powered by > OpenLDAP > > >

1 0

Replication issue during performance test with MMR configuration and LastBind enabled
by Ziani Meheni 10 Oct '23

10 Oct '23

Hello, we are working on a project and we've come across a problem with the replication after performance testing : *Configuration :* RHEL 8.6 OpenLDAP 2.5.14 *MMR-delta *configuration on multiple servers attached 300,000 users configured and used for tests *olcLastBind: TRUE* Use of SLAMD (performance shooting) *Problem description:* We are currently running performance and resilience tests on our infrastructure using the SLAMD tool configured to perform BINDs on a defined range of accounts. We use a load balancer (VIP) to poll all of our servers equally. (but it is possible to do performance tests directly on each of the directories) With our current infrastructure and *LastBind enabled*, we're able to perform 300 BIND/s without any replication delays. Beyond that, we start to generate delays. However, when we run performance tests that exceed our write capacity, our replication between servers can randomly create an incident with directories being unable to catch up with their replication delay. The directories update their contextCSNs, but extremely slowly (like freezing). From then on, it's impossible for the directories to catch again. (even with no incoming traffic) A restart of the instance is required to perform a full refresh and solve the incident. We have enabled synchronization logs and have no error or refresh logs to indicate a problem ( we can provide you with logs if necessary). We suspect a write collision or a replication conflict We've already run several tests. For example, when we run a performance test on a single live server, we don't reproduce the problem. Anothers examples: if we define different accounts ranges for each server with SALMD, we don't reproduce the problem either. If we use only one account for the range, we don't reproduce the problem either. *Symptoms :* One or more directories can no longer be replicated normally after performance testing ends. No apparent error logs. Need a restart of instances to solve the problem. *How to reproduce the problem:* Have at least two servers in MMR mode Set LastBind to TRUE Perform a SLAMD shot from a LoadBalancer in bandwidth mode OR start multiple SLAMD test on same time for each server with the same account range. Exceed the maximum write capacity of the servers. *SLAMD configuration :* authrate.sh --hostname ${HOSTNAME} --port ${PORTSSL} \ --useSSL --trustStorePath ${CACERTJKS} \ --trustStorePassword ${CACERTJKSPW} --bindDN "${BINDDN}" \ --bindPassword ${BINDPW} --baseDN "${BASEDN}" \ --filter "(uid=[${RANGE}])" --credentials ${USERPW} \ --warmUpIntervals ${WARMUP} \ --numThreads ${NTHREADS} ${ARGS}

2 1

export certificate and key
by Stefan Kania 05 Oct '23

05 Oct '23

Hi to all, I have autoca running with my own CA. And I can create certificates and keys for users and hosts. But now I would like to use the certificate and key for radius 802.1x authentication so I need to export the certificate and the key. I know how to convert a DER certificate to a pem certificate. But before I can convert the key and the certificate I need to export it. So how can I do that? Another question: Is there any default password in the key or is it without any password? Stefan

3 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical