openldap-technical

openldap-technical@openldap.org

18 participants
9785 discussions

Re: unable to authenticate, ldaps
by cYuSeDfZfb cYuSeDfZfb 26 Jun '23

26 Jun '23

Hi, I was preparing some more logging to show. You were *really* quick in your reply! :-) Below more logging, and I will reply to your ACL question next. Replication after setting the password: Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 ACCEPT from IP= 192.168.16.36:45316 (IP=0.0.0.0:636) Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.2 tls_cipher=ECDHE-RSA-AES256-GCM-SHA384 Jun 26 16:35:59 ldapserver1 slapd[409642]: conn=1163 fd=17 closed (connection lost) Jun 26 16:36:09 ldapserver1 slapd[409642]: do_syncrep2: rid=234 cookie=rid=234,sid=0dd,csn=20230626143609.891703Z#000000#0dd#000000 Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_message_to_entry: rid=234 DN: uid=testuser,ou=Users,o=ldap,c=com, UUID: a8ccf30a-88d0-103d-8b70-5f35ddf1cc44 Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20230626143609.891703Z#000000#0dd#000000 tid 0x7f68a6afd640 Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234 be_search (0) Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234 uid=testuser,ou=Users,o=ldap,c=com Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_queue_csn: queueing 0x7f689c10e190 20230626143609.891703Z#000000#0dd#000000 Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=-1 op=0 syncprov_matchops: recording uuid for dn=uid=testuser,ou=Users,o=ldap,c=com on opc=0x7f689c008f90 Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=1155 op=1 syncprov_matchops: skipping original sid 0dd Jun 26 16:36:09 ldapserver1 slapd[409642]: conn=1155 op=1 syncprov_matchops: skipping original sid 0dd Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_graduate_commit_csn: removing 0x7f689c10e190 20230626143609.891703Z#000000#0dd#000000 Jun 26 16:36:09 ldapserver1 slapd[409642]: syncrepl_entry: rid=234 be_modify uid=testuser,ou=Users,o=ldap,c=com (0) Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_queue_csn: queueing 0x7f689c10a010 20230626143609.891703Z#000000#0dd#000000 Jun 26 16:36:09 ldapserver1 slapd[409642]: slap_graduate_commit_csn: removing 0x7f689c10a010 20230626143609.891703Z#000000#0dd#000000 Failed authentication using the correct password: Jun 26 16:36:26 ldapserver1 slapd[409642]: conn=1164 fd=17 ACCEPT from IP= 192.168.16.36:46196 (IP=0.0.0.0:636) Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 fd=17 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.2 tls_cipher=ECDHE-RSA-AES256-GCM-SHA384 Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=0 BIND dn="uid=testuser,ou=Users,o=ldap,c=com" method=128 Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=0 syncprov_matchops: recording uuid for dn=uid=testuser,ou=Users,o=ldap,c=com on opc=0x7f689c008ed0 Jun 26 16:36:27 ldapserver1 slapd[409642]: slap_get_csn: conn=1164 op=0 generated new csn=20230626143627.270437Z#000000#0de#000000 manage=1 Jun 26 16:36:27 ldapserver1 slapd[409642]: slap_queue_csn: queueing 0x7f689c110220 20230626143627.270437Z#000000#0de#000000 Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1155 op=1 syncprov_qresp: set up a new syncres mode=2 csn=20230626143627.270437Z#000000#0de#000000 Jun 26 16:36:27 ldapserver1 slapd[409642]: slap_graduate_commit_csn: removing 0x7f689c110220 20230626143627.270437Z#000000#0de#000000 Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1155 op=1 syncprov_sendresp: to=0dd, cookie=rid=243,sid=0de,csn=20230626143627.270437Z#000000#0de#000000 Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1155 op=1 syncprov_sendresp: sending LDAP_SYNC_MODIFY, dn=uid=testuser,ou=Users,o=ldap,c=com Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=0 RESULT tag=97 err=49 qtime=0.000015 etime=0.001002 text= Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 op=1 UNBIND Jun 26 16:36:27 ldapserver1 slapd[409642]: conn=1164 fd=17 closed On Mon, 26 Jun 2023 at 16:36, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Monday, June 26, 2023 5:28 PM +0200 cYuSeDfZfb cYuSeDfZfb > <cyusedfzfb(a)gmail.com> wrote: > > > > > > > Hi all! > > > > > > We have this in place:olcAccess: {1}to attrs=userpassword by anonymous > > auth by * none break > > It's impossible to answer this question without knowing the rest of your > ACLs. For example the acl in slot {0} could mean that the acl in slot {1} > is never evaluated. > > --Quanah > > > >

2 2

unable to authenticate, ldaps
by cYuSeDfZfb cYuSeDfZfb 26 Jun '23

26 Jun '23

Hi all! We have this in place: olcAccess: {1}to attrs=userpassword by anonymous auth by * none break Using the RootDN to set a user password: # ldappasswd -H ldaps://my.ldapserver1.com -D "cn=admin,o=ldap,c=com" -W -S "uid=testuser,ou=Users,o=ldap,c=com" -v New password: <newpassword> Re-enter new password: <newpassword> Enter LDAP Password: <very_secret_and_difficult> ldap_initialize( ldaps://my.ldapserver1.com:636/??base ) Enter LDAP Password: Result: Success (0) We observe the password change replicate (master-master) to our other server. Then to test access: # ldapsearch -H ldaps://my.ldapserver1.com -s base -b o=ldap,c=com -D "uid=testuser,ou=Users,o=ldap,c=com" -w <newpassword> -v ldap_initialize( ldaps://my.ldapserver1.com:636/??base ) ldap_bind: Invalid credentials (49) More background: this is fresh a master-master setup, replication works with the root DN, and all other user authentications fails with the same Invalid credentials (49) The server ldaps://my.ldapserver1.com is an actual single (master) server, no load balancers, no firewalling. Configured an with actual (and valid) certificate, ldapsearch uses the correct CA, and ldapsearch with the root DN works fine. This is latest symas openldap 2.5 on RHEL9. Anyone with an idea why we can only authenticate as the RootDN, and all other authentications give Invalid credentials (49)? We have double checked whatever we can think of, and are *really* unsure what is going on.... Hoping for some clues from the experts here :-)

2 1

RE: Queries regarding Openldap migration from 2.6.2 to 2.6.4
by Quanah Gibson-Mount 23 Jun '23

23 Jun '23

--On Friday, June 23, 2023 2:19 PM +0000 "Sudarshan Sutar (EXT-NSB)" <sudarshan.sutar.ext(a)nokia-sbell.com> wrote: > > > Hi Team > > > Currently we are using openldap 2.6.2 and we want to upgrade it to latest > openldap i.e 2.6.4. So, is there any patch file available that can be > applied directly on to openldap 2.6.2 code base on our build machine ? > Or do I have to take the changes manually from below link ? Hello, a) Stop emailing openldap-technical-owner(a)openldap.org b) stop CCing people at your work This is not how you do proper software deployments/management. I would again *strongly* advise that if you are unable to generate properly packaged software that you use any of the freely available options I already listed. The correct way to get the source for a given release for building a new version is to download the source for the current release from: https://www.openldap.org/ Regards, Quanah

1 0

architectural question on master-slave vs multi-master
by cYuSeDfZfb cYuSeDfZfb 22 Jun '23

22 Jun '23

Hi, As you have already may have discovered by my many posts lately, we're busy with our ldap environment, and migrating from openldap 2.4 (bdb/RHEL7) to 2.5 on mbd/RHEL9. We've always had a duo of masters, replicating to a (READ ONLY) duo of slaves. All clients are configured to talk to the slaves, through a load balancer, and the masters pretty much only receive updates to the DIT from IdM. Our problem is: how to handle failed authentications (ppolicy) considering that the slaves are read-only and the slaves is where the failed authentications take place. Hence, my request for feedback: is master-slave still considered "the best way" of doing this? And then, is there a "standard way" to handle failed authentications on read-only slaves? Or perhaps... is it nowadays better to chose for a simpler multi-master (4 hosts) LDAP setup: four identical servers, where we choose to send clients to two specific servers (firewalled differently to handle client access) and two others to receive updates from IdM, but use multi-master replication so that all changes (either from IdM, or from failed authentications) are replicated equally between all four servers. Seems that new approach is much simpler. Any feedback? What is wise?

2 1

Re: migration 2.4 -> 2.5 (bdb -> mdb) | monitoring & health checks
by cYuSeDfZfb cYuSeDfZfb 22 Jun '23

22 Jun '23

Hi Quanah, Thanks for your answer and kind suggestions! We will implement them. And anyone here using zabbix, and has some scripting for monitoring laying around..? Thanks! On Fri, 16 Jun 2023 at 16:42, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Thursday, June 15, 2023 10:51 PM +0200 sacawulu <cyusedfzfb(a)gmail.com> > > wrote: > > > > Most of these things can be done similarly in 2.4/bdb and 2.5/mbd but not > > the db_verify, which is bdb specific. > > > > I don't find a lot of info on the maintenance / integrity checks that can > > be done on mdb databases. In fact: Mostly what I can find is: "MDB uses > > no caching and requires no tuning to deliver maximum search performance" > > There's very little necessary to be done when using back-mdb as you've > already discovered > > > That is very good. :-) We have already discovered that we need to > > increase maxsize, as our database is (much) larger than 10MB. > > The rule of thumb for maxsize is to set it to something larger than you > ever expect to hit. For example, with a database I'm using that's ~3.4GB > in size, I have a 20GB maxsize set. You may want to monitor the size of > your database vs the configured maxsize. This can be done with data > available in the back-monitor database (at least with 2.6, not sure with > 2.5) or via the mdb_stat utility. > > python-ldap3 snippet using back-monitor: > > try: > tls = Tls(validate=ssl.CERT_NONE, version=ssl.PROTOCOL_TLSv1_2) > conn = Connection(Server(ldap_url, tls=tls, use_ssl=True), > auto_bind=True) > conn.search( > "cn=monitor", > "(&(objectClass=olmMDBDatabase))", > attributes=["olmMDBPagesMax", "olmMDBPagesUsed", > "namingContexts"], > ) > > for db in conn.entries: > suffix = db.namingContexts.value > # 4096 is the page size in use > # can be found with mdb_stat -e /path/to/database > max_size = int(db.olmMDBPagesMax.value) * 4096 > current_size = int(db.olmMDBPagesUsed.value) * 4096 > pct_used = float(current_size / max_size * 100) > > > > > Anyone else with tips and tricks on daily maintenance or monitoring? > > Scripts to share..? Perhaps zabbix templates..? > > The only other bits I would recommend is if you have object in the > directory that have very large multi-valued attribute data. For example, > if you use groups extensively, and the 'member' attribute has hundreds of > entries, you would probably want to do something like: > > a) Add member as an attribute to be handled by olcSortvals > > b) Add a multival configuration to back-mdb if the attribute is indexed. > For example, if you indexed member "eq". I usually do 100,10. This will > put the index databse into its own subdb, which helps keep fragmentation > from being an issue. > > For example, I had a ~5.5GB DB that was swelling to over 11GB in size due > to fragmentation before implementing those two configuration options. > > > Regards, > Quanah > > > >

2 2

Data migration
by Jean-Luc Chandezon 16 Jun '23

16 Jun '23

Hello dear community, I have to migrate our ldap database from OpenLDAP (from 2019 version hosted on Debian, to Symas OpenLDAP 2.4.59 on ). I need to change our DN from "dc=lexp,dc=fr" to "dc=directory,dc=lan-explore,dc=fr". I installed OpenLDAP and configure directory with new DN. For data migration, I exported data: slapcat -b dc=lexp,dc=fr > /tmp/20230616_save_data.ldif .. and for recovery, I changed all dn mentions from old to new dn. 1. Is the correct way? When import, you can see error message: slapadd: slap_init invalid suffix ("dc=directory,dc=lan-explore,dc=fr ") 2. When searching, I discovered that each line can contains 77 columns. Next, line is truncated, and it's difficult to replace all dn. Thanks, Jean-Luc

4 4

migration 2.4 -> 2.5 (bdb -> mdb) | monitoring & health checks
by sacawulu 16 Jun '23

16 Jun '23

Hi, We are in the middle of a move from 2.4/bdb to 2.5/mdb, and I am working on implementing monitoring for the new systems. In the 2.4/bdb environment, we run several scripts to check sanity of the servers: * checks of the contextCSN value across the masters/slaves * regular db_verify on the actual bdb files * compare all DN & entryCSN in the DB across all the masters/slaves * do a write on a master, and verify that it is replicated everywhere Most of these things can be done similarly in 2.4/bdb and 2.5/mbd but not the db_verify, which is bdb specific. I don't find a lot of info on the maintenance / integrity checks that can be done on mdb databases. In fact: Mostly what I can find is: "MDB uses no caching and requires no tuning to deliver maximum search performance" That is very good. :-) We have already discovered that we need to increase maxsize, as our database is (much) larger than 10MB. Two questions: - Is there really nothing else to tune or adjust? - Is there really no way to verify the internal structures within the MDB file, to make sure everything is valid and healthy? Perhaps things I have missed with our four checks above? Anyone else with tips and tricks on daily maintenance or monitoring? Scripts to share..? Perhaps zabbix templates..? If anyone would be interested in (for example) my script to verify the complete directory contents based on DN&entryCSN across a (multi)master/(multi)slave setup, I'd be happy to share too, of course. Thanks!

2 1

Vulnerability CVE-2023-2953 found in latest version
by Sahil Sharma D 15 Jun '23

15 Jun '23

Hi Team, We are currently using OpenLDAP version 2.4.57 in which vulnerability CVE-2023-2953 was not there. We are planning to upgrade to OpenLDAP-2.6.4 however in this version we found CVE-2023-2953 in our scanning, can you please help in understanding why this vulnerability is opened in latest release. In which release we can expect this vulnerability to get resolved? Appreciate your earliest response. Regards, Sahil

2 2

Re: no contextCSN attribute on consumers
by cYuSeDfZfb cYuSeDfZfb 15 Jun '23

15 Jun '23

Hi! I am using the cn=admin,o=infra,c=com with correct password to connect. I will further check ACLs! Thank you for that suggestion. Just to make things more concrete, below are two samples. One on the MASTER with contextCSN, and one from the SLAVE without contextCSN. EXAMPLE SLAVE: ldapsearch -x -H ldaps://$SERVER -D $LDAPBINDDN -w $ADMINPW -b "o=infra,c=com" -s base contextCSN # extended LDIF # # LDAPv3 # base <o=infra,c=com> with scope baseObject # filter: (objectclass=*) # requesting: contextCSN # # search result search: 2 result: 0 Success # numResponses: 1 EXAMPLE MASTER: ldapsearch -x -H ldaps://$SERVER -D $LDAPBINDDN -w $ADMINPW -b "o=infra,c=com" -s base contextCSN # extended LDIF # # LDAPv3 # base <o=infra,c=com> with scope baseObject # filter: (objectclass=*) # requesting: contextCSN # # infra, com dn: o=infra,c=com contextCSN: 20180917142109.765066Z#000000#000#000000 contextCSN: 20230612144901.796553Z#000000#001#000000 contextCSN: 20230612144904.899482Z#000000#002#000000 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 On Mon, 12 Jun 2023 at 16:42, Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Monday, June 12, 2023 5:36 PM +0200 cYuSeDfZfb cYuSeDfZfb > <cyusedfzfb(a)gmail.com> wrote: > > > Hi Quanah, > > > > Thanks for the swift reponse! I think I do, yes, see, from consumer one: > > > > olcSyncrepl: {0}rid=202 > > provider=ldap://master-acc-02.ldap.infra.com:389 bindmethod=simple > > filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory > > Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com" > > schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" > > starttls=critical tls_reqcert=demand > > olcSyncrepl: {1}rid=201 > > provider=ldap://master-acc-01.ldap.infra.com:389 bindmethod=simple > > filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory > > Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com" > > schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+" > > starttls=critical tls_reqcert=demand > > olcUpdateRef: ldap://provider-acc-02.ldap.infra.com:389 > > olcUpdateRef: ldap://provider-acc-01.ldap.infra.com:389 > > That's syncrepl, not syncprov. > > However, the issue could be ACLs. If you use the rootdn for your database > to run the query, can you see the contextCSN value stored in your database > root? > > --Quanah > > > >

3 4

Problem with restoring using ldif, OpenLDAP 2.6.3
by awsome jang 14 Jun '23

14 Jun '23

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 " >>> dnPrettyNormal: <dc=vmbox,dc=int> <<< dnPrettyNormal: <dc=vmbox,dc=int>, <dc=vmbox,dc=int> >>> dnNormalize: <uid=root,ou=invalid,dc=vmbox,dc=int> <<< dnNormalize: <uid=root,ou=invalid,dc=vmbox,dc=int> >>> dnNormalize: <uid=root,ou=invalid,dc=vmbox,dc=int> <<< dnNormalize: <uid=root,ou=invalid,dc=vmbox,dc=int> <= str2entry NULL (smr_normalize contextCSN 21) slapadd: could not parse entry (line=1) slapadd shutdown: initiated slapadd destroy: freeing system resources. When I look into backup.ldif files I see that there is an '-' in contextCSN timestamp which cause this behaviour: entryCSN: 20230410111051.368528Z#000000#000#000000 modifiersName: uid=root,ou=invalid,dc=vmbox,dc=int modifyTimestamp: 20230410111050Z contextCSN: 20230410125515.-401856Z#000000#000#000000 ^^^^^^ contextCSN: 20230412130738.035155Z#000000#002#000000 I also see that entryCSN also can be negative which also causes similar problems when loading files. I would like to ask if there is any way to restore backup in this scenario in a proper way? for instance removing the "-" sign? Thank in advance for your response, Best regards, Peter

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