openldap-technical

openldap-technical@openldap.org

13 participants
9794 discussions

adding a new module smbkrb5pwd - error missingAttributeDescription
by Heinemann, Peter G 23 Jul '21

23 Jul '21

Hello, Using: openldap 2.4.58 RHEL 8 I'm attempting to add a new module, smbkrb5pwd (because we use MIT Kerberos). Compiled and linked under the full openldap2.4.58 source tree per instructions (README and here https://github.com/opinsys/smbkrb5pwd) ldapadd is failing, the log shows: conn=19701 op=1 ADD dn="cn=module{0},cn=config" Jul 22 12:15:58 slapd[605702]: lt_dlopenext failed: (smbkrb5pwd.so) file not found Jul 22 12:15:58 slapd[605702]: conn=19701 op=1 RESULT tag=105 err=80 text=<olcModuleLoad> handler exit Using this ldif: dn: cn=module{0},cn=config objectClass: olcModuleList cn: module olcModulepath: /etc/openldap/smbkrb5pwd olcModuleload: {0}smbkrb5pwd.so I've tried olcModuleload with the full path, or olcModulepath with just the module name and still get the lt_dlopenext The directory and files are visible: ll /etc/openldap/smbkrb5pwd/smbkrb5pwd.* -rw-r--r--. 1 ldap ldap 145638 Jul 22 12:13 /etc/openldap/smbkrb5pwd/smbkrb5pwd.a -rw-r--r--. 1 ldap ldap 888 Jul 22 12:13 /etc/openldap/smbkrb5pwd/smbkrb5pwd.la -rw-r--r--. 1 ldap ldap 889 Jul 22 12:13 /etc/openldap/smbkrb5pwd/smbkrb5pwd.lai -rw-r--r--. 1 ldap ldap 146720 Jul 22 12:13 /etc/openldap/smbkrb5pwd/smbkrb5pwd.o lrwxrwxrwx. 1 root root 19 Jul 22 12:13 /etc/openldap/smbkrb5pwd/smbkrb5pwd.so -> smbkrb5pwd.so.0.0.1 lrwxrwxrwx. 1 root root 19 Jul 22 12:13 /etc/openldap/smbkrb5pwd/smbkrb5pwd.so.0 -> smbkrb5pwd.so.0.0.1 -rwxr-xr-x. 1 ldap ldap 97624 Jul 22 12:13 /etc/openldap/smbkrb5pwd/smbkrb5pwd.so.0.0.1 Thanks for any guidance as to what I've missed in the setup. Peter

4 4

RE25 testing call #1 (OpenLDAP 2.5.6)
by Quanah Gibson-Mount 22 Jul '21

22 Jul '21

This is the first testing call for OpenLDAP 2.5.6. Depending on the results, this may be the only testing call. Generally, get the code for RE25: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_5/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. Thanks! OpenLDAP 2.5.6 Engineering Fixed libldap buffer overflow (ITS#9578) Fixed libldap missing mutex unlock on connection alloc failure (ITS#9590) Fixed lloadd cn=config olcBkLloadClientMaxPending setting (ITS#8747) Fixed slapd multiple config defaults (ITS#9363) Fixed slapd ipv6 addresses to work with tcp wrappers (ITS#9603) Fixed slapo-syncprov delete of nonexistent sessionlog (ITS#9608) Build Fixed library symbol versioning on Solaris (ITS#9591) Fixed compile warning in libldap/tpool.c (ITS#9601) Fixed compile wraning in libldap/tls_o.c (ITS#9602) Contrib Fixed ppm module for sysconfdir (ITS#7832) Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Replacing memberof with dynlist
by j.vandeville＠gmail.com 16 Jul '21

16 Jul '21

Hello, Apologies for my bad English, it's not my native langage I'm toying with openldap 2.5.5 and the dynlist overlay to replace the memberof overlay (since it's the recommanded way to manage the memberof attribute in a replicate environnement). My configuration for the dynlist overlay is like this : overlay dynlist dynlist-attrset groupOfURLs memberURL memberOf If I create a group like this : dn: cn=GroupB,ou=Groups,dc=appartement,dc=me objectClass: posixGroup objectClass: top objectClass: groupOfNames cn: GroupB member: uid=bob,ou=Users,dc=appartement,dc=me gidNumber: 14056 and a user like this : dn: uid=bob,ou=Users,dc=appartement,dc=me objectClass: posixAccount objectClass: top objectClass: inetOrgPerson objectClass: shadowAccount objectClass: groupOfURLs [...Attributes omitted for clarity...] givenName: bob sn: bob displayName: bob uid: bob memberURL: ldap:///ou=Groups,dc=appartement,dc=me??sub?(member=uid=bob,ou=Users,dc=appartement,dc=me) everything works fine, the memberof attribute is generate on the fly if I request it in the search My "issue" is that my LDAP Client is not capable of creating a posix account with the objectclass groupOfURLs or the memberURL attribute... So when I create a new user, I need to manually edit the user in the database to add the objectclass groupOfURLs and the memberURL, which is very tedious. Is there a way for openldap to dynamically add theses attributes when a new user is created ? For exemple, my LDAP client send an "Addrequest" with the following attributes : dn: uid=leon,ou=Users,dc=appartement,dc=me objectClass: posixAccount objectClass: top objectClass: inetOrgPerson objectClass: shadowAccount [...Attributes omitted for clarity...] givenName: leon sn: leon displayName: leon uid: leon openldap intercept the request, add the following attributes : objectClass: groupOfURLs memberURL: ldap:///ou=Groups,dc=appartement,dc=me??sub?(member=uid=bob,ou=Users,dc=appartement,dc=me) and then write the new entry in the database. Is that possible ? I looked at slapo-rwm but I'm not sure if this overlay can add attributes... Thanks !

2 2

Re: Symas OpenLDAP for Linux 2.5
by Dave Macias 15 Jul '21

15 Jul '21

> > Yes, although we haven't yet announced it since it's still a WIP. > I see. So if I understand correctly, the 2.5 release is good to go, but the packaged (rpm/deb/etc) files are still WIP? Best, Dave

2 1

Re: Symas OpenLDAP for Linux 2.5
by Dave Macias 14 Jul '21

14 Jul '21

Looking at: https://repo.symas.com/sofl/ They mention 2.4.59.1 But looks like the baseurl for 2.5 is now: https://repo.symas.com/repo/rpm/SOLDAP/release25/ Yes? Thanks, Dave On Wed, Jul 14, 2021 at 11:19 AM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > > --On Tuesday, July 13, 2021 5:37 PM -0700 "Paul B. Henson" <henson(a)acm.org> > > wrote: > > > We're currently using the RHEL8 sofl repo, which currently has version > > 2.4.59.1 available. Our management wants to start doing automatic > > updates to the latest patches for security compliance reasons. This > > isn't an issue with the native RHEL repos as they generally never > > release major updates or incompatible packages. > > > > I wanted to check though how the release of openldap 2.5 via sofl is > > going to be handled. Is it just going to show up one day in the existing > > repo such that it would automatically get upgraded to, or is it going to > > be a different package name or a new repo that will require manual > > intervention in order to upgrade? > > Symas OpenLDAP packages for 2.5 will be an entirely different beast. > > Regards, > Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

Symas OpenLDAP for Linux 2.5
by Paul B. Henson 14 Jul '21

14 Jul '21

We're currently using the RHEL8 sofl repo, which currently has version 2.4.59.1 available. Our management wants to start doing automatic updates to the latest patches for security compliance reasons. This isn't an issue with the native RHEL repos as they generally never release major updates or incompatible packages. I wanted to check though how the release of openldap 2.5 via sofl is going to be handled. Is it just going to show up one day in the existing repo such that it would automatically get upgraded to, or is it going to be a different package name or a new repo that will require manual intervention in order to upgrade? Thanks...

2 1

password complexity controls and gecos
by kevin martin 08 Jul '21

08 Jul '21

using ppolicy and a Default User Policy, along with ppm, I achieve the ability to control password length, password history, and complexity in as much as I can regulate that users must include numbers/special characters/letters (upper and lower case). However, what I can't find a way to add to this is to have the gecos field be checked against the password being submitted during a change to verify that a users userid and/or first or last names aren't part of the password. Is this possible in openldap? --- Regards, Kevin Martin

2 1

Consumer Delta Sync Lost After Provider Restarted
by thomaswilliampritchard＠gmail.com 07 Jul '21

07 Jul '21

Hi, I'm experiencing an issue between my 3 providers and multiple consumer setup and delta sync repl. We manage a primary, or active, provider and send all writes to the primary as long as it's healthy letting the two others replicate and be standby providers ready to take over in the event of a failure. All consumers replicate from all providers and all providers replicate from all providers. After the system was running healthily for over a week a standby provider was restarted. This caused my consumers to re-establish the persistent sync connection. Upon re-establishing the connection, some consumers began a sync refresh with the following message. Jun 28 18:32:55 openldap-hdb-consumer slapd[15746]: do_syncrep1: rid=003 starting refresh (sending cookie=rid=003,csn=20210331192036.214412Z#000000#000#000000;20210119225955.133811Z#000000#001#000000;20210128213906.596429Z#000000#002#000000;20210226190704.219043Z#000000#005#000000;20210412181659.152626Z#000000#065#000000;20210610231714.990702Z#000000#066#000000;20210614191744.122968Z#000000#44d#000000;20210412175600.595586Z#000000#835#000000;20210423182110.684843Z#000000#836#000000;20210331193249.570935Z#000000#ce5#000000) Jun 28 18:32:55 openldap-hdb-consumer slapd[15746]: do_syncrep2: rid=003 LDAP_RES_SEARCH_RESULT Jun 28 18:32:55 openldap-hdb-consumer slapd[15746]: do_syncrep2: rid=003 delta-sync lost sync, switching to REFRESH Jun 28 18:32:55 openldap-hdb-consumer slapd[15746]: do_syncrep2: rid=003 (4096) Content Sync Refresh Required This was re-establishing a connection with rid=003 which is "20210412175600.595586Z#000000#835#000000" (a standby system) however we have only been sending writes to server #44d# (the primary provider). We see 44d CSN is over 7 days old, beyond our providers access log period. On the consumer that did not trigger sync refresh we see Jun 28 18:32:55 openldap-hdb-consumer slapd[24439]: do_syncrep1: rid=003 starting refresh (sending cookie=rid=003,csn=20210331192036.214412Z#000000#000#000000;20210119225955.133811Z#000000#001#000000;20210128213906.596429Z#000000#002#000000;20210226190704.219043Z#000000#005#000000;20210412181659.152626Z#000000#065#000000;20210621212459.620195Z#000000#066#000000;20210621214400.407867Z#000000#44d#000000;20210412175600.595586Z#000000#835#000000;20210423182110.684843Z#000000#836#000000;20210331193249.570935Z#000000#ce5#000000) Here we see 20210621214400.407867Z#000000#44d#000000 is much more recent and did not trigger a full resync, although it is close to the 7 day threshold at this point. We notice the rid=003 835 csn is the same as the consumer experiencing the problem which makes me believe the #44d# csn being old is what causes this sync refresh. I am concerned why when the standby provider is restarted the connection is getting re-established with old provider CSNs, when I search the CSNs on the consumers they look newer than the ones used to reestablish the connection. If we restart slapd on the providers after running consumers for 7 days it seems like it will trigger a sync refresh. How can we make the consumers re-establish the connection with the most recent CSN? Replication is working as expected, just the CSNs seem to remain old in this connection message. The sync refresh behavior causes a large load on the consumers and providers spiking bind times and degrading service making this concerning for our production environment. Configuration details are below. Your insights are appreciated. @(#) $OpenLDAP: slapd 2.4.56 (Dec 14 2020 17:31:23) $ @57af0b7ce0ba:/root/rpmbuild/BUILD/openldap-2.4.56/openldap-2.4.56/servers/slapd Provider config Primary DB # {2}mdb, config dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcDbDirectory: /var/lib/ldap ... olcSizeLimit: unlimited olcSyncrepl: {0}rid=1 provider=ldap://10.20.0.4 bindmethod=simple binddn ="cn=replicant,dc=example,dc=com" credentials="" searchbase="dc=example,dc=com" schemachecking=on type=refresh AndPersist retry="5 10 60 +" sizelimit=unlimited timelimit=unlimited starttls=critical tls_reqcert=demand logbase="cn=accesslog" logfilter=" (&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog olcSyncrepl: {1}rid=2 provider=ldap://10.20.1.151 bindmethod=simple bind dn="cn=replicant,dc=example,dc=com" credentials="" searchbase="dc=example,dc=com" schemachecking=on type=refre shAndPersist retry="5 10 60 +" sizelimit=unlimited timelimit=unlimited starttls=critical tls_reqcert=demand logbase="cn=accesslog" logfilter ="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog olcSyncrepl: {2}rid=3 provider=ldap://10.20.2.240 bindmethod=simple bind dn="cn=replicant,dc=example,dc=com" credentials="" searchbase="dc=example,dc=com" schemachecking=on type=refre shAndPersist retry="5 10 60 +" sizelimit=unlimited timelimit=unlimited starttls=critical tls_reqcert=demand logbase="cn=accesslog" logfilter ="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog olcMirrorMode: TRUE ... olcDbMaxSize: 15000000000 Sync Prov # {1}syncprov, {2}mdb, config dn: olcOverlay={1}syncprov,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov olcSpCheckpoint: 1 1 Access Log # {3}accesslog, {2}mdb, config dn: olcOverlay={3}accesslog,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {3}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 07+00:00 01+00:00 olcAccessLogSuccess: TRUE # {3}mdb, config dn: olcDatabase={3}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {3}mdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=admin,dc=example,dc=com olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart olcDbMaxSize: 15000000000 # {0}syncprov, {3}mdb, config dn: olcOverlay={0}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE Consumer Config: # {2}hdb, config dn: olcDatabase={2}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=com olcRootDN: cn=admin,dc=example,dc=com olcRootPW: {SSHA} olcSyncrepl: {0}rid=1 provider=ldap://10.20.0.4 bindmethod=simple binddn ="cn=replicant,dc=example,dc=com" credentials="" searchbase="dc=example,dc=com" schemachecking=on type=refresh AndPersist retry="60 +" sizelimit=unlimited timelimit=unlimited start tls=critical tls_reqcert=demand logbase="cn=accesslog" logfilter="(&(ob jectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog olcSyncrepl: {1}rid=2 provider=ldap://10.20.1.151 bindmethod=simple bind dn="cn=replicant,dc=example,dc=com" credentials="" searchbase="dc=example,dc=com" schemachecking=on type=refre shAndPersist retry="60 +" sizelimit=unlimited timelimit=unlimited sta rttls=critical tls_reqcert=demand logbase="cn=accesslog" logfilter="(&( objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog olcSyncrepl: {2}rid=3 provider=ldap://10.20.2.240 bindmethod=simple bind dn="cn=replicant,dc=example,dc=com" credentials="" searchbase="dc=example,dc=com" schemachecking=on type=refre shAndPersist retry="60 +" sizelimit=unlimited timelimit=unlimited sta rttls=critical tls_reqcert=demand logbase="cn=accesslog" logfilter="(&( objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog olcDbCheckpoint: 102400 10

2 4

Are Password Expired and Password Expiry warning (2.16.840.1.113730.3.4.5) controls supported in OpenLDAP
by cst labs 06 Jul '21

06 Jul '21

hello: I am currently evaluating the OpenLDAP version 2.4.58. I was told by someone that it does support the password expired control but I don't see that it is working. As per the RFC, the server should send this control as a part of response but it doesn't. I do see that the server returns the password policy state control that has expired and warning information. However, I am interested in the password expired control since I am looking to support an existing implementation that leverages that control. Can someone tell me how to configure openldap to return that control?

3 2

enable WiredTiger not defaulting to no
by dbray925+openldap＠gmail.com 30 Jun '21

30 Jun '21

I'm currently testing out the 2.5.5 install, and during the configure process it fails with: configure: error: Package requirements (wiredtiger) were not met: Package 'wiredtiger', required by 'virtual:world', not found The documentation (--help) shows that this should be default to no: --enable-wt enable WiredTiger backend no|yes|mod [no] However, this is not the case, and I have to manually set: ./configure --enable-wt=no

3 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical