openldap-technical

openldap-technical@openldap.org

18 participants
9785 discussions

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

Re: error while setting password policy
by Quanah Gibson-Mount 04 Oct '23

04 Oct '23

--On Tuesday, October 3, 2023 11:57 PM -0400 Jignesh Patel <jignesh(a)icare.com> wrote: > > We are using LDAP version 2.5.16 . > > > when we try to set policy > we are getting this error olcAttributeTypes: value #0 olcAttributeTypes: > Duplicate attributeType: > "1.3.6.1.4.1.42.2.27.8.1.1" slapadd: could not add entry > The .ldif file is as attached. > > > And if we don't import than we are getting pException: [LDAP result > code 17 - undefinedAttributeType] pwdAttribute: attribute type undefined I suggest carefully reading the release notes for OpenLDAP 2.5, specifically around the changes to ppolicy since the 2.4 series. --Quanah

3 2

Configuring custom port 10389 for openldap-servers
by Kaushal Shriyan 04 Oct '23

04 Oct '23

Hi, I am running the openldap server on Red Hat Enterprise Linux release 8.8 (Ootpa) # rpm -qa | grep -i ldap sssd-ldap-2.8.2-3.el8_8.x86_64 symas-openldap-servers-2.4.59-1.el8.x86_64 openldap-2.4.46-18.el8.x86_64 symas-openldap-2.4.59-1.el8.x86_64 symas-openldap-clients-2.4.59-1.el8.x86_64 # cat /etc/redhat-release Red Hat Enterprise Linux release 8.8 (Ootpa) # Port 389 is the default port. Can it be configured for custom port 10389 for example? Please guide me. Thanks in advance. Best Regards, Kaushal

2 1

Group ACLs
by Emmanuel Seyman 04 Oct '23

04 Oct '23

Hello, all. I have an instance of OpenLDAP in which I use groups to manage access controls, similar to the way the FAQ and admin guide describe it. My DIT layout: uid=userildr1,ou=people,o=gdAA,dc=example,dc=com uid=userildr2,ou=people,o=gdAA,dc=example,dc=com ... cn=readINT,ou=groups,o=gdAA,dc=example,dc=com cn=writeINT,ou=groups,o=gdAA,dc=example,dc=com cn=superadmin,ou=groups,o=gdAA,dc=example,dc=com ... ou=people,o=INT,dc=example,dc=com ... ou=groups,o=INT,dc=example,dc=com Outside of the DIT, my slapd.conf file (yes, I know) contains: access to dn.sub="o=INT,dc=example,dc=com" by self write by group/groupOfUniqueNames/uniqueMember="cn=superadmin,ou=groups,o=gdAA,dc=example,dc=com" write by group/groupOfUniqueNames/uniqueMember="cn=writeINT,ou=groups,o=gdAA,dc=example,dc=com" write by group/groupOfUniqueNames/uniqueMember="cn=readINT,ou=groups,o=gdAA,dc=example,dc=com" read The uid=userildr1,ou=people,o=gdAA,dc=example,dc=com entry is in the readINT group yet seems unable to run a search. I get an error 50 ("Operations are restricted to bind/unbind/abandon/StartTLS/modify password") and cannot figure out why this is happening. If anyone can tell me what's going on, I would appreciate it. I'm seeing "config_back_db_open: line 0: warning: cannot assess the validity of the ACL scope within backend naming context" in the log files but this looks harmless. This is OpenLDAP 2.5.14 running on RHEL 8, with the LTB packages. Logs and the configuration file are available if necessary. Emmanuel

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical