openldap-technical December 2021

openldap-technical@openldap.org

21 participants
32 discussions

Interpreting username@domainname
by Volodymyr Melnyk 03 Jan '22

03 Jan '22

Hello, Is that possible to tweak some settings that would make OpenLDAP always interpreting `uid=username@domainname` as `uid=username,ou=domainname` in authentication queries? Of course, making the clients to do its job would be preferred, but this would be less preferable option in my case. With thanks in advance, V.Melnyk

2 1

right order mmr-main-DB combined with mmr cn=config
by Stefan Kania 15 Dec '21

15 Dec '21

Hello, I'm still working on replication of cn=config. The replication of the main DB is working with delta-syncrepl but I still have problems getting mmr running for cn=config. As I use Ansible to configure it here my question: Is the order of setting up the replication relevant? What I do at the moment: Setting up a basic config for all 4 servers: ----------------------------------------- dn: cn=config objectClass: olcGlobal cn: config olcLogLevel: sync olcLogLevel: stats olcPidFile: /var/symas/run/slapd.pid olcArgsFile: /var/symas/run/slapd.args olcToolThreads: 1 olcServerID: 1 ldap://ldap01.example.net olcServerID: 2 ldap://ldap02.example.net olcServerID: 3 ldap://ldap03.example.net olcServerID: 4 ldap://ldap04.example.net # create cn=config #dn: olcBackend={0}mdb,cn=config #objectClass: olcBackendConfig #olcBackend: {0}mdb dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /opt/symas/lib/openldap olcModuleLoad: back_mdb olcModuleLoad: back_monitor olcModuleLoad: autoca.la olcModuleLoad: otp.la olcModuleLoad: argon2.la olcModuleLoad: syncprov olcModuleLoad: back_monitor olcModuleLoad: accesslog.la include: file:///opt/symas/etc/openldap/schema/core.ldif include: file:///opt/symas/etc/openldap/schema/cosine.ldif include: file:///opt/symas/etc/openldap/schema/nis.ldif include: file:///opt/symas/etc/openldap/schema/inetorgperson.ldif include: file:///opt/symas/etc/openldap/schema/dyngroup.ldif include: file:///opt/symas/etc/openldap/schema/kerberos.openldap.ldif dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcSizeLimit: 500 olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth manage by * break olcAccess: {1}to dn="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcPasswordHash: {ARGON2} dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootDN: cn=admin,cn=config olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4 olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth manage by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write by * break dn: olcDatabase={1}monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: {1}monitor olcAccess: {0}to dn.subtree="cn=monitor" by dn.exact=cn=admin,cn=config read by dn.exact=cn=admin,dc=example,dc=net read dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcmdbConfig olcDatabase: {2}mdb olcSuffix: dc=example,dc=net olcRootDN: cn=admin,dc=example,dc=net olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4 olcSizeLimit: unlimited olcTimeLimit: unlimited olcDbCheckpoint: 512 30 olcDbDirectory: /var/symas/openldap-data olcDbIndex: default eq olcDbIndex: objectClass olcDbIndex: entryUUID olcDbIndex: entryCSN olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: mail pres,eq,sub olcDbIndex: sn pres,eq,sub olcDbIndex: description pres,eq,sub olcDbIndex: title pres,eq,sub olcDbIndex: givenName pres,eq,sub olcDbMaxSize: 85899345920 olcAccess: {0} to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth manage by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write by dn.exact=uid=repl-user,ou=users,dc=example,dc=net read by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcAccess: {3} to attrs=userPassword by anonymous auth by self write by * none olcLimits: {0} dn.exact="uid=repl-user,ou=users,dc=example,dc=net" time=unlimited size=unlimited olcLimits: {1} dn.exact="uid=ldap-admin,ou=users,dc=example,dc=net" time=unlimited size=unlimited ----------------------------------------- As you can see serverID is already set to URL-style for all servers ;-) But now I'm not sure, do I have to set up the replication for cn=config on all 4 servers and then set up replication of the main DB on just one of the servers and let it be replicated by the cn=config-replication? Or do I have to set up replication of the main DB on all servers first and then add the replication of cn=config to all servers and only replicate the changes made afterwards? Or do I have to set up the replication of main-DB and replication of cn=config on one server at a time? Or can I do it either way? The testsuit is showing using updateref on the replication of the main-DB do I really need it for mmr? If yes, do I need it for mmr of cn=config? I could not find any example that uses both, mmr for main-DB and mmr for cn=config. here is the order of my set up for cn=config replication: ------------------------ dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={0}config,cn=config changetype: modify replace: olcSyncRepl olcSyncRepl: rid=1 provider=ldap://ldap01.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes tls_reqcert=allow olcSyncRepl: rid=2 provider=ldap://ldap02.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes tls_reqcert=allow olcSyncRepl: rid=3 provider=ldap://ldap03.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes tls_reqcert=allow olcSyncRepl: rid=4 provider=ldap://ldap04.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes tls_reqcert=allow - add: olcMultiprovider olcMultiprovider: TRUE ------------------------ And last but not least the set up of the main-DB replication: ----------------------- dn: olcDatabase={2}mdb,cn=config changetype: modify replace: olcSyncrepl olcSyncrepl: rid=102 provider=ldap://ldap02.example.net bindmethod=simple timeout=0 network-timeout=0 binddn=uid=repl-user,ou=users,dc=example,dc=net credentials=secret filter="(objectclass=*)" searchbase="dc=example,dc=net" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=accesslog scope=sub schemachecking=off type=refreshAndPersist retry="60 +" syncdata=accesslog keepalive=240:10:30 starttls=yes tls_reqcert=allow olcSyncrepl: rid=103 provider=ldap://ldap03.example.net bindmethod=simple timeout=0 network-timeout=0 binddn=uid=repl-user,ou=users,dc=example,dc=net credentials=secret filter="(objectclass=*)" searchbase="dc=example,dc=net" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=accesslog scope=sub schemachecking=off type=refreshAndPersist retry="60 +" syncdata=accesslog keepalive=240:10:30 starttls=yes tls_reqcert=allow olcSyncrepl: rid=104 provider=ldap://ldap04.example.net bindmethod=simple timeout=0 network-timeout=0 binddn=uid=repl-user,ou=users,dc=example,dc=net credentials=secret filter="(objectclass=*)" searchbase="dc=example,dc=net" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=accesslog scope=sub schemachecking=off type=refreshAndPersist retry="60 +" syncdata=accesslog keepalive=240:10:30 starttls=yes tls_reqcert=allow - add: olcMultiprovider olcMultiprovider: TRUE ----------------------- This is the ldif for the first server so olcSyncrepl for ldap01.example.net is not configured. On the other servers is the same the own URI has no olcSyncrepl entry. Here olcUpdatRef is not configured. Replication of the main-DB is running. BTW olcUpdateRef is also not configured in the howto of Quanah ;-) So it must be ok :-) Could you please take a look if I did something wrong. I don't know where to look anymore.

2 5

ldap_search_ext_s fails with "Operations error" when using root as base dn
by Alex Ditu 15 Dec '21

15 Dec '21

Hi, When I try to query the root of my AD with scope LDAP_SCOPE_SUBTREE ldap_search_ext_s() fails with "Operations error". It happens only when I set the ldap_search_options.base to the domain DN (eg. DC=example,DC=com). If I use a more specific base, such as CN=Computers,DC=example,DC=com the operation succeeds. Is there a limitation to the search function? pseudocode snippet: ``` ldap_search_options ldap_opts; ldap_opts.base = "DC=example,DC=com"; ldap_opts.scope = LDAP_SCOPE_SUBTREE; ```

2 1

Ldap sync has broken from time to time
by skeletor 15 Dec '21

15 Dec '21

Hi. We have a one master and 8 slaves. From time to time replication has broken and data has stopped to update on slaves. In logs i see next: syncrepl_null_callback : error code 0x50 syncrepl_entry: rid=000 be_modify cn=union,ou=roles,dc=staff,dc=com (80) syncrepl_entry: rid=000 be_modify failed (80) do_syncrepl: rid=000 rc 80 retrying do_syncrep1: rid=000 starting refresh (sending cookie=rid=000,csn=20211213150433.004754Z#000000#000#000000) do_syncrep2: rid=000 LDAP_RES_INTERMEDIATE - SYNC_ID_SET syncrepl_message_to_entry: rid=000 DN: cn=union,ou=roles,dc=staff,dc=com, UUID: 67c22522-0749-1039-933a-fdc6b5a9b3b7 syncrepl_entry: rid=000 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 4 "error code 0x50" means other ldap error. How to determine, what exactly wrong? There is no dependence with slaves or versions: - master has 2.4.50 - slaves have different versions: 2.4.50, 2.4.55, 2.4.57. All of slaves can breake. We use next configuration: syncrepl rid=000 provider=ldaps://ldap-master.domain.com type=refreshAndPersist retry="5 5 300 +" searchbase="dc=staff,dc=com" attrs="*,+" bindmethod=simple binddn="cn=slapd-slave,ou=services,dc=staff,dc=com" We can't try newer version, because use Oracle solaris and there are only 2.4.X versions. Should we create a bug or it was fixed in newer versions?

2 1

Symas OpenLDAP 2.6.0-5 released
by Quanah Gibson-Mount 14 Dec '21

14 Dec '21

Symas OpenLDAP 2.6.0 patch level 5 has been released for all supported platforms. It includes the following changes since the prior release: Fixed slapo-lastbind to work with 2.6 lastbind-precision configuration (ITS#9725) Added slapd config keyword for logfile format (ITS#9745) Fixed slapo-dynlist compare operation for static groups (ITS#9747) Fixed slapo-accesslog to fix inconsistently normalized minCSN (ITS#9752) Fixed slapd-mdb to update indices correctly on replace ops (ITS#9753) Fixed slapo-syncprov to generate a more accurate accesslog query (ITS#9756) New contrib module: slapo-allowed is now available. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Symas OpenLDAP 2.5.9-5 released
by Quanah Gibson-Mount 14 Dec '21

14 Dec '21

Symas OpenLDAP 2.5.9 patch level 5 has been released for all supported platforms. It includes the following changes since the prior release: Fixed slapo-dynlist compare operation for static groups (ITS#9747) Fixed slapo-accesslog to fix inconsistently normalized minCSN (ITS#9752) Fixed slapd-mdb to update indices correctly on replace ops (ITS#9753) Fixed slapo-syncprov to generate a more accurate accesslog query (ITS#9756) Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: 2.6 slapadd bug? - SHA512 userPassword hash get 2 characters appended to the end at import
by Dave Macias 13 Dec '21

13 Dec '21

Thank you Quanah for the input. I will say that i always turn off line wrap “ldif-wrap=no” when i export. Dont like how it looks with the wrap. So each attribute is one line on import. I still have yet to try what Michael suggested about scping the mdb files over. I’ll report on that hopefully this week. Thank you, Dave On Dec 6, 2021, 12:46 PM -0500, Quanah Gibson-Mount <quanah(a)symas.com>, wrote: > > > --On Saturday, December 4, 2021 2:58 AM -0500 Dave Macias > <davama(a)gmail.com> wrote: > > > > > > > Hello, > > > > Playing with 2.6 on rhel8 > > > > When imported my data.ldif I noticed i no longer could bind and my > > credentials would fail. Thought it was simply my account and tried with > > other test accounts and failed too. > > > > When i compare the userPassword attributes from the source to my 2.6 > > environment, i see there are two extra characters at the end. > > > > So original looks like: (and whats in data.ldif file) > > > > userPassword:: e2Nblablasuperdupper512hashthatendshere > > > > vs the one in 2.6 > > > > userPassword:: e2Nblablasuperdupper512hashthatendshereXX > > > > This happens on all the userPassword attributes that are SHA512. The XX > > characters seem random, no pattern to it. In other words each > > userPassword attribute has its own XX characters. > > I've generally seen issues like this when a script that munges data fails > to correctly delete multi-line attribute values and the leftover bits get > tacked onto the previous attribute. One way around this is to turn off > LDIF line wraps on export. > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com>

1 1

OpenLDAP 2.6.0 testing call #3
by Quanah Gibson-Mount 13 Dec '21

13 Dec '21

This is the third testing call for OpenLDAP 2.6.0 Release. This is expected to be the final testing call. Generally, get the code for RE26: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_6/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. A list of items fixed and added in 2.6 can be found at: <https://bugs.openldap.org/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFI…> A major change with 2.6 is the optional ability to bypass syslog for logging (ITS#6949). This significantly improves slapd and lloadd performance. Additionally, the following deprecated backends have been removed: back-ndb back-shell Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 2

Re: Antw: [EXT] OpenLDAP Upgrade
by Ulrich Windl 13 Dec '21

13 Dec '21

>>> Quanah Gibson-Mount <quanah(a)symas.com> schrieb am 09.12.2021 um 17:54 in Nachricht <9E71A1C6CC6C9A43887B2B56(a)[192.168.1.3]>: > > ‑‑On Tuesday, December 7, 2021 8:39 AM ‑0800 Quanah Gibson‑Mount > <quanah(a)symas.com> wrote: > >> >> >> ‑‑On Tuesday, December 7, 2021 9:57 AM +0000 santoshk.sethi(a)tcs.com wrote: >> >>> Thanks Emmanuel, >>> Is it a stable version we can reply upon? Because the request is for a >>> production environment which are running critical business applications >>> >>> As part the OS upgrade (6.4 to 7.9), the default OpenLDAP comes in >>> RHEL7.9 is openldap‑servers‑2.4.44‑24.el7_9. >>> >>> This is a existing setup in production. We just want to upgrade it (rpm >>> ‑Uvh) :) on the exisitng RPMs. >> >> OpenLDAP 2.6 is the current release series. OpenLDAP 2.4 is no longer in >> support. As I noted previously, Symas provides pre‑built binaries via a >> repository as described at <https://repo.symas.com/soldap/>. Paid >> support is optionally available as well. > > Also, I'd note again that the vendor supplied builds are woefully out of > date and are generally unsuitable for a production environment, especially > one running business critical applications. Well, as long as those vendors offer support for their packages it's discussable whether those packages are suitable for production environments. At the moment I'm taking part in some online training, and I found out that the OS of the training environment had its last update in 2019, so probably the effective date of the software is even older. The company offering the training has _lots_ of money, however... Not all production environment needs bleeding edge software. Regards, Ulrich

2 3

OpenLDAP Upgrade
by santoshk.sethi＠tcs.com 13 Dec '21

13 Dec '21

HI, We have OpenLDAP 2.4.xx running in RHEL6.4. We are planning to upgrade the RHEL version to 7.9 and then upgrade the OpenLDAP to 2.6. The OpenLDAP installed are all RPMs #rpm -qa | grep -i openldap openldap-2.4.23-31.el6.x86_64 compat-openldap-2.3.43-2.el6.x86_64 openldap-devel-2.4.23-31.el6.x86_64 openldap-servers-2.4.23-31.el6.x86_64 openldap-clients-2.4.23-31.el6.x86_64 But the package for OpenLDAP available is binary packages. I need help how to upgrade considering the existing LDAP database, schema and configuration are required to be there after the upgrade. We have 2 Master server, 2 Consumer server and 2 loadbalancer running keepalived. Appreciate if anyone can help to upgrade the OS as well as the OpenLDAP package. Thanks Santosh

4 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical December 2021