openldap-technical July 2023

openldap-technical@openldap.org

29 participants
33 discussions

Rotating olcRootPW
by thomaswilliampritchard＠gmail.com 13 Jul '23

13 Jul '23

Hi, We have a 3 node multi master replication configuration setup with many consumers replicating from all 3 provider nodes. The consumers and providers replicate the from the MDB tree dc=example,dc=com. They do not replicate their config databases. The root password we are rotating is for cn=admin,dc=example,dc=com. Upon updating the olcRootPW we see the provider where the password was updated commit a new CSN and then syncrepl seems to fail for connected consumers with slapd[9227]: conn=1439 op=1 syncprov_op_search: consumer 2102 state 20230712210938.878334Z#000000#836#000000 is newer than provider 2102 state 20230712210402.018624Z#000000#836#000000 It seems as if the consumers reconnect with a state newer than the provider that just committed a new CSN for the new root password? It did not seem like the root password was replicated across the cluster however which I imagine is a deliberate choice to not replicate root db DNs. Is there a recommended workflow to rotate the root credential for a replicated database to avoid syncrepl disruption? OpenLDAP 2.4.56 (we are working to upgrade to OpenLDAP 2.5 LTS)

3 3

Re: Problem with restoring using ldif, OpenLDAP 2.6.3
by awsome jang 13 Jul '23

13 Jul '23

Hello, Thank you for your response - it was very helpful. Bug is registered with a solution proposal: https://bugs.openldap.org/show_bug.cgi?id=10077 I also saw that entryCSN can be negative as well but the proposed solution should fix the problem. createTimestamp: 20230110130503 entryCSN: 20230110130503.*-060060Z*#000000#000#000000 modifiersName: uid=root,ou=invalid,dc=vmbox,dc=int I was wondering how to handle this issue in case there is already this negative context CSN in the database? So scenario would be as follow: 1) do a backup create ldif (contains contextCSN: 20230410125515*.-401856Z* #000000#000#000000 or entryCSN with minus) 2) do an update of openldap, 3) restore backup from ldif. In this case restoring backup ends up with an error so there is no possibility to restore the backup database. Could you please provide some guidance on how to clean up this corruption in a proper way? Should I remove the line with negative contextCSN/entryCSN or remove the minus in the ldif file to restore the backup? Or is there any other way? Configuration uses provider and consumer with replication. Thank you in advance for your response, BR, Peter Am Mi., 14. Juni 2023 um 17:09 Uhr schrieb Quanah Gibson-Mount < quanah(a)fast-mail.org>: > > > --On Tuesday, June 13, 2023 12:11 PM +0200 awsome jang > <jangawsome(a)gmail.com> wrote: > > > > > Hello, > > > > I am running openldap 2.6.3 configured as provider-consumer and I would > > like to do backup/restore of the database on the provider. > > > > I create a backup on working sladp using command(ends with success, file > > created): > > slapd.exe –T cat –f slapd.conf –l backup.ldif > > > > And then trying to load it using slapd command into a new > > database(restore): > > slapd.exe -T add -f slapd.conf -l backup.ldif -d -1 > > > > Command ends with: > > . > > creatorsName: uid=root,ou=invalid,dc=vmbox,dc=int > > createTimestamp: 20230410111050Z > > entryCSN: 20230410111051.368528Z#000000#000#000000 > > modifiersName: uid=root,ou=invalid,dc=vmbox,dc=int > > modifyTimestamp: 20230410111050Z > > contextCSN: 20230410125515.-401856Z#000000#000#000000 > > > This appears to be a bug with generating the CSN on windows, likely due to > some type of overflow. Can you please file a bug report at > https://bugs.openldap.org > > Thanks! > > Regards, > Quanah > > >

3 3

auditlog to syslog
by cYuSeDfZfb cYuSeDfZfb 13 Jul '23

13 Jul '23

Hi, Playing with openldap 2.5 auditlog. Logging to a file works nicely. We wonder (as we use graylog for syslog aggregation for all (LDAP) servers) ... Is it possible to process the auditlogs through syslog? Tip for all: we have solved so many problems just by searching through graylog... if you don't use graylog (or some other log aggregation tool)... consider implementing it!

3 2

RE: [EXT] Re: CSN too old on each MOD, on working 4-node multi-master
by Quanah Gibson-Mount 12 Jul '23

12 Jul '23

--On Wednesday, July 12, 2023 2:13 PM +0000 "Windl, Ulrich" <u.windl(a)ukr.de> wrote: > Hi! > > I always wondered (assuming you have four MM servers A-D): > Assuming A has a local change, so it will sent them to B-D > When B receives a change from A, it will "check and perform", then > sending the changes to C and D (not back to A, right?) Likewise for C > and D > However B-D will send out more changes, but not to A (right?): > B->C, B->D > C->B, C->D > D->B, D->C > What will B (and C and D) do when receiving A's change via C for the > second time: Will it ignore the change, but still send out to other > (non-originating) nodes, or will it just "swallow" the change? I guess > it will "swallow", because otherwise the messages would circulate > forever, right? Correct, they discard ops they've already received. Which was the point of the log message referenced originally. --Quanah

1 0

LTB packages available for OpenLDAP 2.5.15 and 2.6.5
by Clément OUDOT 12 Jul '23

12 Jul '23

Hello, for people interested, the LDAP Tool Box project has published the packages for OpenLDAP 2.5.15 and 2.6.5. https://projects.ow2.org/view/ldaptoolbox/ltb-openldap-2-5-15-and-2-6-5-pac… -- Clément Oudot | Identity Solutions Manager clement.oudot(a)worteks.com Worteks | https://www.worteks.com

1 0

pwdAccountLockedTime does not have any impact
by CVZ 11 Jul '23

11 Jul '23

Hi Everybody, <https://stackoverflow.com/posts/76341444/timeline> Sorry, we are figghting with pwdAccountLockedTime. I want to use "pwdAccountLockedTime" attribute to automatically lock an account using OpenLDAP (v.2.5.14). Whatever the value in the field, the account is never locked. I first started by activating the "ppolicy" module using slapadd and a ppolicy-module.ldif file suh as mentioned here "https://stackoverflow.com/questions/49257247/how-to-activate-ppolicy-module…", then I have checked that the module is loaded and I did not have any problem: |$ sudo slapcat -n 0 | grep olcModuleLoad | grep ppolicy olcModuleLoad: {0}ppolicy | Then, I have extended the LDAP scheme to allow using of ppolicy attributes such as "pwdAccountLockedTime". I have set it to "00000101000000Z" in order to lock permanently an account (to check if it was working). But I still can connect (using LDAP Admin tools) with the account that was supposed to be locked. We also tried to modify the value dn: uid=... replace: pwdAccountLockedTime pwdAccountLockedTime: 20221021135537Z And even with dates in the future, but we are still able to connect. With whoami command, or from a SOGo webmail connected to the LDAP server. Any idea? Thank in advance for your help. Best Damien

3 2

Re: CSN too old on each MOD, on working 4-node multi-master
by cYuSeDfZfb cYuSeDfZfb 11 Jul '23

11 Jul '23

Thanks for confirming what we already suspected (and hoped as well) :-) On Tue, 11 Jul 2023 at 16:54, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Tuesday, July 11, 2023 2:26 PM +0200 cYuSeDfZfb cYuSeDfZfb > <cyusedfzfb(a)gmail.com> wrote: > > > > > > > Hi, > > > > > > We have a four-node MultiMaster setup, symas 2.5.14, and everyhing seems > > to work perfectly now. With some (highly appreciated) help from this > list. > > > > > But actually: content *is* replicated instantly (within the same second) > > and the actual served contents between the four ldap (MultiMaster) > > servers matches. > > The RID changes, and is always one of the configured replication lines, > > and the date/time on the four involved hosts is in sync. > > > > > > > > Is this 'just an informational message', and 'normal', and should we > > ignore it? Or is it something to worry about and investigate further? > > Yes, it's informational. Think of it this way: > > Server A receives the modification. Servers B, C, D, replicate the change. > Server A sees that a change was made on Server B, then sees it's too old > and discards it. Same happens when Server A sees the change show up on > Servers C & D as well. And same thing happens for B with servers C & D, > and Server C with B & D, etc. The replication protocol can be very chatty > with MMR because it's constantly noting it is skipping changes it already > received. > > --Quanah > > > >

1 0

CSN too old on each MOD, on working 4-node multi-master
by cYuSeDfZfb cYuSeDfZfb 11 Jul '23

11 Jul '23

Hi, We have a four-node MultiMaster setup, symas 2.5.14, and everyhing seems to work perfectly now. With some (highly appreciated) help from this list. However, there is one observation we don't understand, that we would appreciate feedback on. On directory edits, such as a password change, using the rootDN: ldappasswd -H ldaps://ldap01.company.com -D "cn=admin,o=company,c=com" -W -S "uid=username,ou=Users,o=company,c=com" New password: <new_userpw> Re-enter new password: <new_userpw> Enter LDAP Password: <very_secret_root_pw> we always receive several (mostly three, sometimes four) of these messages instantly: do_syncrep2: rid=212 CSN too old, ignoring 20230710140929.887114Z#000000#0de#000000 (uid=username,ou=Users,o=company,c=com)" But actually: content *is* replicated instantly (within the same second) and the actual served contents between the four ldap (MultiMaster) servers matches. The RID changes, and is always one of the configured replication lines, and the date/time on the four involved hosts is in sync. Is this 'just an informational message', and 'normal', and should we ignore it? Or is it something to worry about and investigate further? In the latter case, of course I will share our configs, which are taken from https://www.openldap.org/doc/admin25/replication.html#N-Way%20Multi-Master As otherwise everything seems to be working correctly, I don't expect major issues there. (but again: of course willing to share!)

2 1

Re: trying to understand SID portion in contextCSN
by cYuSeDfZfb cYuSeDfZfb 11 Jul '23

11 Jul '23

Hi Quanah, Thanks again for your answer. From what you have written, we understand now that we should not aim for four identical timestamps in contextCSN attributes on each node. As contextCSN is updated (as you said) only when a server receives a direct write. (and NOT for writes received through replication) So, as long as the contextCSN output across all four MM-ldap nodes is identical, replication is doing it's thing. Specifically, from my original post: > contextCSN: 20230622151102.137085Z#000000#001#000000 > contextCSN: 20230622151105.174343Z#000000#002#000000 > contextCSN: 20230627112536.529432Z#000000#0dd#000000 > contextCSN: 20230627112536.529512Z#000000#0de#000000 The first two servers (001/002) are just as up-to-date as the last two, only: more recent writes have come into the cluster through the 0de/0dd servers. I have written a script to compare actual ldap served content, and that confirms that they all serve the same data. If any of the above is wrong, I'd appreciate to be corrected :-) On Wed, 5 Jul 2023 at 17:09, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Wednesday, July 5, 2023 11:17 AM +0200 cYuSeDfZfb cYuSeDfZfb > <cyusedfzfb(a)gmail.com> wrote: > > > serverID 222 ldaps://ldapm01.company.com > > serverID 221 ldaps://ldapm02.company.com > > serverID 212 ldaps://ldapm03.company.com > > serverID 211 ldaps://ldapm04.company.com > > > > And when I (quick and dirty) check contextCSN using slapcat (I know that > > ldapsearch is the better way) I get: > > > > [root@ldapm04 ~]# slapcat | grep contextcsn -i > > contextCSN: 20180917142109.765066Z#000000#000#000000 > > contextCSN: 20230622151102.137085Z#000000#001#000000 > > contextCSN: 20230622151105.174343Z#000000#002#000000 > > contextCSN: 20230627112536.529432Z#000000#0dd#000000 > > contextCSN: 20230627112536.529512Z#000000#0de#000000 > > > > The first 2018 contextCSN is irrelevant (it has alwas been there, and I > > should probably try to get rid of it) but the last four seem to be the > > "actual" configured replication 'lines' on each node to the other three, > > like this: > > > > > > Yet: all info I can find tells me that the third field of contextCSN is > > "the SID". > > > > > > Can anyone explain? Are they perhaps HEX? If why the large gap between to > > consequtive pairs..? > > > Hi! > > So #000# is as you noted an old SID from when the system used single > provider. > > The SID values are indeed in hex. Your current non-zero SIDS indicate: > > You have servers with SID values 001, 002 that last received a direct > write > operation on 2023/06/22, about 3 seconds apart. > > You have servers with SID values 221 (0dd) and 222 (0de) that last > received > a direct write operation on 2023/06/27, during the same second. > > Any server that has a different SID value that has never received a direct > write operation will not appear in the list. > > Regards, > Quanah > >

3 6

OpenLDAP 2.5 + GSSAPI + Kerberos
by dbarstis＠nd.edu 06 Jul '23

06 Jul '23

Total newbie here so please be gentle. I'm trying to set up a simple ldap server that uses SASL and Kerberos for authentication. I built OpenLDAP --with-cyrus-sasl and --enable-spasswd. I have the service principal and testsaslauthd works. I used slapadd to build the initial config (from slapd.ldif) and ldapadd to define a rootdn and basedn (basically ou=people and ou=groups). Added a user (me) and a group. I have a slapd.conf file at /usr/lib/sasl2 that defines keytab: krb5.keytab, mech_list: GSSAPI, pwcheck_method: saslauthd, saslauthd_path: /run/saslauthd/mux. Running pluginviewer, I see GSSAPI. Running ldapsearch ... supportedSASLMechanisms, it returns nothing. I've found websites that talk about adding sasl-realm <Kerberos-Realm> sasl-host <ldap-host> sasl-secprops none to slapd.conf. But this isn't the same slapd.conf I mentioned above correct? And since I used slapd.ldif to do the inital load, I don't have another slapd.conf. How to I define these variables? Also, it looks like I need a direct mapping i.e. authz-regexp uid=([^,]*),cn=example.com,cn=gssapi,cn=auth uid=$1,ou=people,dc=example,dc=com Where and how does that get defined? Any and all help would be greatly appreciated!

3 5

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical July 2023