- openldap-technical - openldap.org

Tree versus group
by Olivier - 29 Mar '19

29 Mar '19

3 3

Add module crashes slapd
by Gao 29 Mar '19

29 Mar '19

Hi all, I am relatively new to openldap and I am having an issue when I try to setup Master-Slave replication. I don't know how to solve this issue and need your help please. On the master I made a ldif file: [root@test-ldap ldif]# cat syncprov_mod.ldif dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulePath: /usr/lib64/openldap olcModuleLoad: syncprov.la Then I run command: [root@test-ldap ldif]# ldapadd -Y EXTERNAL -H ldapi:/// -f syncprov_mod.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "cn=module,cn=config" The output seems normal. But actually the slapd got messed up. So if I do slapcat I got: [root@test-ldap ldif]# slapcat -n 0 5c9d1323 config error processing cn={0}module,cn=config: slapcat: bad configuration file! And restart slapd failed. journalctl shows: Mar 28 11:40:39 test-ldap systemd[1]: Starting OpenLDAP Server Daemon... -- Subject: Unit slapd.service has begun start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit slapd.service has begun starting up. Mar 28 11:40:39 test-ldap runuser[3427]: pam_unix(runuser:session): session opened for user ldap by (uid=0) Mar 28 11:40:39 test-ldap runuser[3427]: pam_unix(runuser:session): session closed for user ldap Mar 28 11:40:39 test-ldap check-config.sh[3424]: Checking configuration file failed: Mar 28 11:40:39 test-ldap check-config.sh[3424]: 5c9d1527 config error processing cn={0}module,cn=config: Mar 28 11:40:39 test-ldap check-config.sh[3424]: slaptest: bad configuration file! Mar 28 11:40:39 test-ldap slapd[3438]: @(#) $OpenLDAP: slapd 2.4.40 (Nov 6 2016 01:21:28) $ mockbuild@worker1.bsys.centos.org:/builddir/build/BUILD/openldap-2.4.40/openldap-2.4.40 Mar 28 11:40:39 test-ldap slapd[3438]: config error processing cn={0}module,cn=config: Mar 28 11:40:39 test-ldap slapd[3438]: slapd stopped. Mar 28 11:40:39 test-ldap slapd[3438]: connections_destroy: nothing to destroy. Mar 28 11:40:39 test-ldap systemd[1]: slapd.service: control process exited, code=exited status=1 Mar 28 11:40:39 test-ldap systemd[1]: Failed to start OpenLDAP Server Daemon. -- Subject: Unit slapd.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit slapd.service has failed. -- -- The result is failed. Mar 28 11:40:39 test-ldap systemd[1]: Unit slapd.service entered failed state. Mar 28 11:40:39 test-ldap systemd[1]: slapd.service failed. Thank you for your help. Gao

3 2

LMDB crash after power failure
by Abilio Marques 24 Mar '19

24 Mar '19

Hello, I've successfully ported a particular piece of software from multiple plain files in disk to LMDB. There were multiple reasons to do so (i.e., performance and maintenance). The program is making individual calls to a storage API, that in turn creates files or reads them (through a cache). There is no concept of transaction. For performance and lifetime reasons, the original code avoids to perform a fsync every time it writes to a file by queuing renames (for atomic writes) and deletes, which in turn are executed by a background thread after 2 seconds idling (or a max of 15 sec after first write/delete). Replacing such a monster "files + cache" with LMDB was a breeze. I kept the API intact, and to deal with the price of fsyncs, I thought of opening with MDB_NOSYNC, and sync after 2 seconds of inactivity. I must mention that the software runs on an OpenWRT based board, with a MIPS (big endian 32-bit), using UBIFS as storage (with OverlayFS sitting on top of it). Flash memory is rather slow, peaking at ~350 KiB/sec on sequential writing. Kernel version is 3.18.29. This works perfect, except for power failures. With a USB relay board, I'm cutting the power to the CPU during the sync period. After restart, the test program I'm running with LMDB crashes with a sigbus error. Opening the environment seems to work, but the program crashes as soon as it tries to write to it. The file seems "ok" (no visible garbage or missing parts) when viewed with hexdump (but is a 5 Mb file). Any suggestions on where to start looking for issues? I wanted to congratulate Howard Chu for his work with LMDB, and the OpenLDAP team for a wonderful work during the years. Keep it up! Best, Abilio

2 1

olcDbConnectionPoolMax documentation
by Jongeling, Eric C 21 Mar '19

21 Mar '19

I'm running into what appears to be an issue with my olcDatabase meta configuration that appears to be a bottleneck limiting me to 16 concurrent operations when working through the meta database. This seems suspiciously similar to the olcDbConnectionPoolMax setting I've seen in many examples and the value I usually encounter of 16. The schema definition doesn't clear it up entirely, either: olcAttributeTypes: ( OLcfgDbAt:3.23 NAME 'olcDbConnectionPoolMax' DESC 'Max size of privileged connections pool' SYNTAX OMsInteger SINGLE- VALUE ) While I assume that this sets the maximum size of the backend connection pool, I'm confused by the word "privileged" in this situation. Can someone explain what this setting controls or point me towards documentation? Thanks in advance! ~Eric C. J.

2 1

Replication and pwdAccountLockedTime
by Jochen Keutel 21 Mar '19

21 Mar '19

Hello, we are using OpenLDAP 2.4.44 on Debian 9 in a distributed scenario: push based replication (means: using proxies with ldap backend). All works fine, all attributes (normal and operational) are replicated. Only one problem occurs: - when we set pwdAccountLockedTime on the master it gets replicated without problems. - but if we remove this attribute on the master (means: we unlock the account) this change is NOT replicated: The attribute is still there in all replicas, so the accounts stay locked. Is this by design - or is it a bug? Regards Jochen.

2 1

Discarding unused(?) olcRootPW passwords
by Bob Hund 20 Mar '19

20 Mar '19

Hi, I inherited a slapd deployment which rebuilds instances from scratch via automation. All configuration is done by slapadd'ing ldifs when instances are stood up. We don't make configuration changes at run time. When we need to make a change we modify the automation scripts and standup new instances from scratch. I noticed that there are olcRootPW entries for the "cn=admin,cn=config" and "cn=admin,dc=ourcompany,dc=com" root DNs, in the configuration I inherited, but we don't ever use them explicitly. In fact the entries are hashes, and I can't even find any uses of the cleartext in our code. My gut feeling is that I should reset the hashes and discard the cleartext to prevent misuse of these credentials. Is there any reason not to do this? Thanks in advance for any insight you can provide.

3 2

Configuring Back-LDAP as proxy for MirrorMode nodes to ensure writes are always handled by the designated master
by George Diamantopoulos 20 Mar '19

20 Mar '19

Hello all, I've successfully set-up a 2-node LDAP cluster, where each node is a provider to the other according to section 18.3.4 of the Administrator's Guide. The next logical step is to implement Load-Balancer/Proxy entities, which will ensure that writes always go to the same node. So far my preliminary proxy configuration allows reading from the cluster successfully. Here are the relevant bits (LDIF whitespace manipulated for readability): dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break olcAccess: {1}to * by * write olcRootDN: cn=admin,dc=domain,dc=tld olcRootPW: {SSHA}s3krit olcSuffix: olcDbStartTLS: start olcDbURI: ldap://ldap1.domain.tld,ldap://ldap2.domain.tld I understand that this configuration will always use the first URI in olcDbURI unless there is a failure, in which case it will fall back to the second URI (apparently after a timeout, and will then use it for subsequent operations until that fails too). I'm happy with this, although if there were a way to perform round-robin between the two for read operations, it would be ideal (is there?). However, writes to the proxy won't work with this configuration. In the Administrator Manual it is stated that one should use the proxy "as a syncrepl provider", but I am not sure I understand how this is supposed to work. Am I supposed to add another olcSyncrepl attribute (there's already one for syncing the two MirrorMode nodes themselves) to the MirrorMode nodes pointing to the proxy? And if I have more than one proxy, should I add an olcSyncrepl attribute for each? And how do I ensure that only one of the MirrorMode nodes fetches data from the proxy provider(s) at any given time? I've spent quite some time googling this to no avail. Any insight would be greatly appreciated. Thank you! Best regards, George

2 2

Rsyslog stdout and stderr
by Abdelkader Chelouah 17 Mar '19

17 Mar '19

Hi, slapd 2.4.44 OpenLDAP instance configure as a proxy (back-ldap) >From time to time, bind operations can take more than 5 sec. These latencies do not seem to come from a CPU or memory problem. I'm trying to see if the network can be the root cause of the issue. To debug the fonction ldap_sasl_bind (libraries/libldap/sasl.c), I activated trace loglevel (logs are manage by rsyslog). In the definition of ldap_sasl_bind, there is Debug( LDAP_DEBUG_TRACE, "ldap_sasl_bind\n", 0, 0, 0 ); A least the message "ldap_sasl_bind" should appear in logs, which is not the case. Actually, Debug (which is first defined in include/ldap_log.h) is redefined in libraries/libldap/ldap-int.h ... #include "ldap_log.h" #undef Debug #ifdef LDAP_DEBUG #define DebugTest( level ) \ ( ldap_debug & level ) #define Debug( level, fmt, arg1, arg2, arg3 ) \ do { if ( ldap_debug & level ) \ ldap_log_printf( NULL, (level), (fmt), (arg1), (arg2), (arg3) ); \ } while ( 0 ) #define LDAP_Debug( subsystem, level, fmt, arg1, arg2, arg3 )\ ldap_log_printf( NULL, (level), (fmt), (arg1), (arg2), (arg3) ) configure #else #define DebugTest( level ) (0 == 1) #define Debug( level, fmt, arg1, arg2, arg3 ) ((void)0) #define LDAP_Debug( subsystem, level, fmt, arg1, arg2, arg3 ) ((void)0) #endif /* LDAP_DEBUG */ ... A a result, the message is send to standard output. By using rsyslog, it is not possible to catch any message inside ldap_sasl_bind. How to get stdout and stderr messages and still use rsyslog to manage openldap logs ? Thanks in advance.

3 3

How do I enable LDAP or OpenLDAP in Windows Server 2019 Active Directory Domain Services Domain Controller?
by Turritopsis Dohrnii Teo En Ming 14 Mar '19

14 Mar '19

Good morning from Singapore, How do I enable LDAP or OpenLDAP in Windows Server 2019 Active Directory Domain Services Domain Controller so that network devices like network security appliances/firewalls and network attached storages (NAS) are able to join the domain and obtain the list of Active Directory Users for authentication purposes? Thank you. ===BEGIN EMAIL SIGNATURE=== The Gospel for all Targeted Individuals (TIs): [The New York Times] Microwave Weapons Are Prime Suspect in Ills of U.S. Embassy Workers Link: https://www.nytimes.com/2018/09/01/science/sonic-attack-cuba-microwave.html ******************************************************************************************** Singaporean Mr. Turritopsis Dohrnii Teo En Ming's Academic Qualifications as at 14 Feb 2019 [1] https://tdtemcerts.wordpress.com/ [2] https://tdtemcerts.blogspot.sg/ [3] https://www.scribd.com/user/270125049/Teo-En-Ming ===END EMAIL SIGNATURE===

1 0

On pwdGraceUseTime granularity
by Matus Honek 13 Mar '19

13 Mar '19

Hello, currently, granularity of pwdGraceUseTime is one second. This allows client to successfully bind with old password as many times as they want during N seconds (where N is equal to pwdGraceAuthnLimit) which may be unwanted. Would it be possible to increase the granularity, and if so, what size would make sense? Could it be made configurable? FWIW, I know that basically every major LDAP server has one second granularity, and that this does not mitigate the actual issue (only lowers the time window during which this can be misused). Thanks and regards. -- Matúš Honěk Software Engineer Red Hat Czech

2 1

LDAP authentication with just sAMAccountName
by Florea, Cosmin Petre 12 Mar '19

12 Mar '19

Hello, I have a LDAP Linux client written with OpenLDAP and i need it to be able to authenticate a user only by username and password (no domain). By username i mean the sAMAccountName from the LDAP record. The bind succeeds if i use "username@domain" or if i use the userPrincipalName (which is not equal to sAMAccountName), but i am unable to make it work just with username. Anonymous ldap_bind followed by a ldap_search does not work (it works if the bind is not anonymous). I have also a windows client (not using openldap library) implemented with DirectoryEntry from C#. The login with just the username works fine in that implementation (connected to the same LDAP server). In the LDAP log file on Windows i see (i put [...] to hide the server address): <Data Name="Message">ldap_bind called for connection 0xd059b718: DN is (null). Method is 0x486. Synchronous is 0x1. <Data Name="Message">ldapBind found server is Windows 2003 or better AD on connection 0xd059b718 <Data Name="Message">Connection->hostname is '[.........]' <Data Name="Message">Connection->DnsSuppliedNAme is '[.........]' <Data Name="Message">Connection->DomainName is '(null)' <Data Name="Message">LDAP: make spn returned 'ldap/[.........]' with error 0 <Data Name="Message">ldapBind found GSSAPI auth type on connection 0xd059b718 <Data Name="Message">ldapBind found GSS-SPNEGO auth type on connection 0xd059b718 <Data Name="Message">ldapBind found DIGEST auth type on connection 0xd059b718 <Data Name="Message">ldap bind: Server is v3 <Data Name="Message">ldap bind: Server supports both GSS-SPNEGO and GSSAPI <Data Name="Message">New servicename for bind is 'ldap/[.........]' <Data Name="Message">wldap32:Server is capable of 'NTLM' <Data Name="Message">ldap_bind returned 0x0 for connection 0xd059b718. So on windows it does ldap_bind 2 times , but i think it is using a different mechanism, probably Windows specific (i mean not ldap_search) to retrieve the userPrincipalName associated with the sAMAccountName from input. I do not have an account that i can use to make the initial bind (my client should work with several distinct servers). My question is: how to do it on linux with OpenLDAP? Is it possible? Thank you.

2 2

Re: Antw: Expected operation of pwdFailureCountInterval
by Tom Jay 12 Mar '19

12 Mar '19

I think the documentation could do with being updated slightly. This is taken from the slapo-ppolicy manual: pwdFailureCountInterval This attribute contains the number of seconds after which old consecutive failed bind attempts are purged from the failure counter, even though no successful authentication has occurred. If pwdFailureCountInterval is not present, or its value is zero (0), the failure counter will only be reset by a successful authentication. What I think that means is that unless the account is locked, and there are no successful authentication attempts, failed bind attempts are cleared from the LDAP entry after the pwdFailureCountInterval time. If the account is locked, the pwdFailureTime entries remain until the account is unlocked manually (or the pwdLockoutDuration time) and a successful authentication attempt (if the account is not locked) will also clear the pwdFailureTime entries. Tom On 2019-02-28 15:00, Ulrich Windl wrote: >>>> Tom Jay <web(a)tomjay.co.uk> schrieb am 27.02.2019 um 04:05 in >>>> Nachricht > <19f2a950eb051ccafe5a4420752d8b84(a)tomjay.co.uk>: >> Hello, >> >> Can someone explain the expected operation of the >> pwdFailureCountInterval attribute please? The documentation seems to >> be >> fairly clear, but if I add it to the password policy, along with some >> other attributes, the account remains locked, even after the >> pwdFailureCountInterval time. Despite authenticating with a valid >> password, the pwdFailureTime entries remain and the account remains >> locked. > > I think the mechanism is the other way round: As long as the account > is not locked, failed counts are reset every (after?) 1200 seconds. > Once an account is locked, it stays locked. > > Did you look at pwdLockoutDuration? > > Regards, > Ulrich > >> >> These are the attributes in use: >> pwdLockout: TRUE >> pwdMaxFailure: 5 >> pwdFailureCountInterval: 1200 >> >> Thanks. >> >> Tom

1 0

Re: Rsyslog stdout and stderr
by albert de montreuil 12 Mar '19

12 Mar '19

Abdelkader Chelouah wrote: > > Hi, > > > > slapd 2.4.44 > > > > OpenLDAP instance configure as a proxy (back-ldap) > > > > > > From time to time, bind operations can take more than 5 sec. These latencies do not seem to come from a CPU or memory problem. I'm trying to see if the network > > can be the root cause of the issue. To debug the fonction ldap_sasl_bind (libraries/libldap/sasl.c), I activated trace loglevel (logs are manage by rsyslog). In > > the definition of ldap_sasl_bind, there is > > > > Debug( LDAP_DEBUG_TRACE, "ldap_sasl_bind\n", 0, 0, 0 ); > > > > A least the message "ldap_sasl_bind" should appear in logs, which is not the case. Actually, Debug (which is first defined in include/ldap_log.h) is redefined > > in libraries/libldap/ldap-int.h > > > > ... > > > > #include "ldap_log.h" > > > > #undef Debug > > > > #ifdef LDAP_DEBUG > > > > #define DebugTest( level ) \ > > ( ldap_debug & level ) > > > > #define Debug( level, fmt, arg1, arg2, arg3 ) \ > > do { if ( ldap_debug & level ) \ > > ldap_log_printf( NULL, (level), (fmt), (arg1), (arg2), (arg3) ); \ > > } while ( 0 ) > > > > #define LDAP_Debug( subsystem, level, fmt, arg1, arg2, arg3 )\ > > ldap_log_printf( NULL, (level), (fmt), (arg1), (arg2), (arg3) ) > > configure > > #else > > > > #define DebugTest( level ) (0 == 1) > > #define Debug( level, fmt, arg1, arg2, arg3 ) ((void)0) > > #define LDAP_Debug( subsystem, level, fmt, arg1, arg2, arg3 ) ((void)0) > > > > #endif /* LDAP_DEBUG */ > > > > ... > > > > A a result, the message is send to standard output. By using rsyslog, it is not possible to catch any message inside ldap_sasl_bind. > > > > > > How to get stdout and stderr messages and still use rsyslog to manage openldap logs ? > syslog is not fast enough to handle the debug traffic. > You could use ber_set_option() to override the log output functions, and have them write > messages both to rsyslog and stderr. But using syslog on every debug message will slow > things down more than 10x. Hi, I'am also interressed to enable stderr and stdout to rsyslog. I try to figure out how to use ber_set_option(), but i'am pretty sur i miss something in my analysis. Starting from the function ldap_sasl_bind in file libraries/libldap/sasl.c + Debug( LDAP_DEBUG_TRACE, "ldap_sasl_bind\n", 0, 0, 0 ); Debug is macro define in first place in include/ldap_log.h and override by libraries/libldap/ldap-int.h So Debug is replace by ldap_log_printf() which is defined in libraries/libldap/print.c, ldap_log_printf() make some check and get varargs and send to pointer function 'ber_pvt_log_print' ber_pvt_log_print is pointer to ber_error_print() in file libraries/liblber/bprint.c. So the target is to change ber_pvt_log_print In function ber_set_option() we can redefine the print function ber_pvt_log_print to write messages both to rsyslog and stderr. (in /servers/slapd/main.c) ber_set_option(NULL, LBER_OPT_LOG_PRINT_FN, &print_syslog); The function is pretty basic : void print_syslog( LDAP_CONST char *data ) { Log0(LDAP_DEBUG_ANY, ldap_syslog_level, data); return ; } Of course i declare prototype in header file. Is it what you have in mind or should i use a function in OpenLDAP ?

1 0

help needed for further investigation
by Thomas.Meller＠t-systems.com 07 Mar '19

07 Mar '19

Hello together. I am the heir of a setup based on RHEL 6.10 and Openldap 2.4.45 (ltb) A master syncrepls to a slave in type=refreshOnly using bindmethod=sasl, saslmech=external. The mapped techuser resides in ou=ServiceUser. All Clients also use user objects in the same ou to bind to the servers. I need to set new acls and decided to include a dedicated acl- and limits-configfile. The ACLs checked via slapacl look fine and run without problems on the test environment. (Which is based on the same 2.4.45 rpms, but the replica runs on RHEL 7.5) All slapd configuration make use of database mdb and an explicitly set maxsize. (which is sized sufficiently: 12 GB, 49 MB used) When implementing the configuration on a running system, the replica deletes the ou (that one with all the service user objects). Which is not what I want 8-/ How can I find out more about the reason for this peculiar result? I set the loglevel to 'stats sync' on the replica and 'sync' on the master. (fs size is limited for logs) The access limits are in place for this replication account and read access is granted as well. (might be I need to set something extra for operational attributes?) limits dn.subtree="ou=ServiceUser,..." size=unlimited (this is the replica) sizelimit unlimited timelimit 10 and limits dn.subtree="ou=ServiceUser,..." size=unlimited time=120 (in this order, this is the master) What do I need to look at to find what's missing? I am no openldap crack, but no newbie as well. Yet my openldap knowledge ist not very extended. Which further infos do I need to supply to maybe get help? The include statements for limits and acls are defined before the database configuration. I avoid using dynamic configuration to keep it all simple. Overlays in use: chain dynlist valsort memberof ppolicy (replica) syncprov ppolicy unique dynlist memberof refint valsort (master) Thank you, Thomas

3 4

setting up openldap to proxy to AD on SUSE ENT 12
by N6Ghost 06 Mar '19

06 Mar '19

hi all, I am trying to setup an openldap proxy to AD and i need to use SUSE Enterprise Linux 12. Hostname:/etc/openldap # rpm -qa|grep -i openldap openldap2-2.4.41-18.43.1.x86_64 openldap2-client-2.4.41-18.43.1.x86_64 what I am trying to do, is proxy an application (with 1000s of users) from talking directory to AD, to talking to openldap. and then have openldap talk to AD. look across the net is a bunch of stuff, but most of it does not seem to apply, or work. look at the offical doc, says use sasl but you must have an local entry with a {sasl] tag on the user thats not really ideal and work make a huge problem. a few of the posts online just said point to AD via ldap is possible? and this application also has a group lookup as part of its auth process... eg, only member of groupX can access.... any help in this would be huge. seems, i am mixing up a few different ways of doing this whats the bets way to do this? Thanks -N6ghost

5 7

Integer keys - order
by Sam Dave 01 Mar '19

01 Mar '19

When using integer keys (MDB_INTEGERKEY), is it guaranteed that when using mdb_cursor_get() to "loop through" my entire database, I will get the keys in the expected integer order? I thought I'd ask to be sure because I'm not sure if this expected behavior is documented.

1 0

Integer keys - drawbacks
by Sam Dave 01 Mar '19

01 Mar '19

Are there any known drawbacks to using integer keys (MDB_INTEGERKEY), performance or otherwise?

1 0

back-ldap timeout per operation
by Abdelkader Chelouah 01 Mar '19

01 Mar '19

Hello, I'm trying to figure out what is the behavior of back-ldap when the timeout (olcDbTimeout) is exceeded for a given operation ? Is the operation retried or aborted ?

1 0

Expected operation of pwdFailureCountInterval
by Tom Jay 27 Feb '19

27 Feb '19

Hello, Can someone explain the expected operation of the pwdFailureCountInterval attribute please? The documentation seems to be fairly clear, but if I add it to the password policy, along with some other attributes, the account remains locked, even after the pwdFailureCountInterval time. Despite authenticating with a valid password, the pwdFailureTime entries remain and the account remains locked. These are the attributes in use: pwdLockout: TRUE pwdMaxFailure: 5 pwdFailureCountInterval: 1200 Thanks. Tom

2 1

slapd-sock Overlay gives no RESULT on Successful BIND
by Kamal Advani 27 Feb '19

27 Feb '19

Hello, We are attempting to sync over some data from OpenLDAP into Win AD. The approach thus far has been to use slapd-sock in overlay mode and attach a listener. Our configuration snippet is as follows: --- moduleload back_sock overlay sock extensions connid socketpath /var/run/openldap/winad-sync-overlay.sock sockops add bind delete modify modrdn sockresps result --- What I have noticed is that on a successful BIND, no corresponding RESULT is received. However, on a BIND failure, we do, with a non-zero code (as expected). Another interesting situation is as follows: * On an unsuccessful BIND, we get 2 messages, a BIND and a MODIFY -- we also use the `ppolicy` module, so it sets the pwdFailureTime, an 'add' change, on a BIND failure. This is fine. * However, both the BIND and MODIFY have the same msgid. * Finally, we get one RESULT back with the same msgid. Continuing on, if I then BIND successfully, as above, I get: * BIND and MODIFY -- this time the MODIFY clears pwdFailureTime, a delete change. Same msgid on both BIND and MODIFY. * Again, only one RESULT, with the corresponding msgid. Have I misconfigured something, or is this expected behaviour? In all cases, have made sure I'm sending through CONTINUE after each message. I guess, I'd expect a RESULT for each request message, it would certainly make message processing much simpler and deterministic: * Receive request, store, keyed by conn id and msg id. * Receive RESULT, find corresponding request, and process accordingly. I only have this issue on BIND, as far as I can tell, at least for the `sockops` I'm interested in. Any suggestions are much appreciated. Thanks very much. Regards, Kamal PS. Happy to provide transcripts of output, just keeping the initial email size manageable. Please let me know. PPS. Another quirk is, it appears that I get a RESULT for a SEARCH, even though I am not subscribed to it in `sockops`, but happy to ignore this for now! -- There is more to life than increasing its speed. -- Mahatma Gandhi

1 0

Get values of Telephone Tab ( A.D. ) using ldapsearch.
by - - 26 Feb '19

26 Feb '19

Hi, I am trying to get the values of Telephone tab in a Active Directory Server using ldapsearch. http://www.windows-active-directory.com/telephone-tab-in-ad-user-properties… Active Directory User properties – Telephone tab<http://www.windows-active-directory.com/telephone-tab-in-ad-user-properties…> The telephone tab of the user properties window allows you to add detailed telephone contacts for the user. www.windows-active-directory.com I get other values like mail or telephoneNumber at the first tab but I can't get neither information of Telephone Tab . I am using this command: ldapsearch -x -H ldap://IP:PORT -D "cn=userldap,OU=users,DC=domain,DC=local" -w PASSWORD -b "DC=domain,DC=local" "(&(objectclass=person)(mail=user1(a)domain.com))" mail telephoneNumber mobile # extended LDIF # # LDAPv3 # base <DC=domain,DC=local> with scope subtree # filter: (&(objectclass=person)(mail=user1(a)domain.com)) # requesting: mail telephoneNumber mobile # # User 1, Users, domain.local dn: CN=User 1,OU=Users,DC=domain,DC=local l telephoneNumber: 1 mail: user1(a)domain.com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Is posible get this information using ldapsearch tool?. Thanks in advance . Best Regards

1 0

Help to understand "Paged results cookie is invalid"
by Andrea Patricelli 25 Feb '19

25 Feb '19

Good morning, I'm connecting to an OpenLdap through a JNDI client [1] and I "randomly" get this error: [LDAP: error code 2 - paged results cookie is invalid]; I suppose that the problem is related to multiple clients connecting to the LDAP with the same credentials (the same user), since the cookie is somehow related the user. Moreover since two different clients (different machines and IPs) are connecting simultaneously they invalidate the cookie to each other. Googling a bit and looking at the reference [1] and documentation I did not find something that confirm my thesis. Are my assumptions right or I'm misunderstanding the problem? If right, if there are multiple connections from the same client (same machine and IP) does OpenLdap manage this situation? I suppose (obviously) so, but asking anyway :) Thanks in advance, Andrea [1] https://github.com/Tirasa/ConnIdLDAPBundle/blob/net.tirasa.connid.bundles.l… [2] http://www.faqs.org/rfcs/rfc2696.html -- Dott. Andrea Patricelli Tel. +39 3204524292 Engineer @ Tirasa S.r.l. Viale Vittoria Colonna 97 - 65127 Pescara Tel +39 0859116307 / FAX +39 0859111173 http://www.tirasa.net Apache Syncope PMC Member

1 0

Forbidden account password reuse of the last 5 password
by Tian Zhiying 16 Feb '19

16 Feb '19

Hi Is there a feature that OpenLDAP password policy can forbidden user password reuse of the last 5 password? Thanks.

8 19

Re: Switch OpenLDAP backend database from HDB to MDB
by SHarbich＠t-online.de 15 Feb '19

15 Feb '19

Hi Ryan, | Note that the database config attributes for hdb and mdb differ a little bit. For example you should configure olcDbMaxSize for mdb. For example, how would I change the following entry in the config file? dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb olcModuleLoad: {1}dynlist.so olcModuleLoad: {2}ppolicy.la structuralObjectClass: olcModuleList entryUUID: 9495e2a6-da11-1033-97d9-c1ceaf236428 creatorsName: cn=admin,cn=config createTimestamp: 20140926214112Z entryCSN: 20170201184048.317884Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20170201184048Z Should the change be as follows? - - - olcModuleLoad: {0}back_hdb + + + olcModuleLoad: {0}back_mdb dn: olcBackend={0}hdb,cn=config objectClass: olcBackendConfig olcBackend: {0}hdb structuralObjectClass: olcBackendConfig entryUUID: 94960592-da11-1033-97da-c1ceaf236428 creatorsName: cn=admin,cn=config createTimestamp: 20140926214112Z entryCSN: 20140926214112.940239Z#000000#000#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20140926214112Z Should the change be as follows? - - - dn: olcBackend={0}hdb,cn=config + + + dn: olcBackend={0}hmdb,cn=config - - - olcBackend: {0}hdb + + + olcBackend: {0}mdb So I have everywhere the entry of hdb to mdb? Thank you in advance for your support. Greetings from Stefan Harbich

1 0

help with mdb database recovery after crash
by Andrei Mikhailovsky 14 Feb '19

14 Feb '19

Hello everyone, I have a bit of an issue with my ldap database. I have a Zimbra community edition which uses openldap. A server crashed and I am unable to start the ldap services after the reboot. The description of my problem, after some digging about is: the initial error indicated problem with the ldap Starting ldap...Done. Search error: Unable to determine enabled services from ldap. Enabled services read from cache. Service list may be inaccurate. Having investigated the issue, I noticed the following errors in the zimbra.log slapd[31281]: mdb_entry_decode: attribute index 560427631 not recognized I also noticed that the /opt/zimbra/data/ldap/mdb/db/data.mdb is actually 81Gb in size and had reached the limit imposed by the ldap_db_maxsize variable. so over the weekend, the LDAP mdb file became no longer sparse. I tried following the steps described in https://syslint.com/blog/tutorial/solved-critical-ldap-primary-mdb-database… but with no success, as the slapcat segfaults with the following message. /opt/zimbra/common/sbin/slapcat -ccc -F /opt/zimbra/data/ldap/config -b "" -l /opt/zimbra/RECOVERY/SLAPCAT/zimbra_mdb.ldiff 5c583982 mdb_entry_decode: attribute index 560427631 not recognized Segmentation fault (core dumped) the mdb_copy produces a file of 420 mb in size, but it still contains the "mdb_entry_decode: attribute index 560427631 not recognized" error. I've also tried mdb_dump, but had the same issues after using the mdb_load command. I found a post ( http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8360 ) in the openldap community that the mdb gets corrupted if it reaches the maximum defined size. but no solution of how to fix it. any advice on getting the database recovered and working again? Cheers Andrei

3 5

Re: help with mdb database recovery after crash
by Andrei Mikhailovsky 14 Feb '19

14 Feb '19

Hi Howard, Many thanks for your suggestions. I am about to try what you've suggested (download and compile the latest master version of lmdb from git using master branch of https://github.com/LMDB/lmdb). However, just to note, I am running the latest version of zimbra which uses pretty recent version of openldap: ii zimbra-lmdb 2.4.46-1zimbra8.7b amd64 LMDB Binaries ii zimbra-lmdb-lib:amd64 2.4.46-1zimbra8.7b amd64 LMDB Libraries ii zimbra-openldap-client 2.4.46-1zimbra8.7b amd64 OpenLDAP Client Binaries ii zimbra-openldap-lib:amd64 2.4.46-1zimbra8.7b amd64 OpenLDAP Libraries ii zimbra-openldap-server 2.4.46-1zimbra8.7b amd64 OpenLDAP Server Binaries The problem that I am describing occurred with the above version of openldap. I will keep you posted with any updates. Cheers Andrei ----- Original Message ----- > From: "Howard Chu" <hyc(a)symas.com> > To: "Andrei Mikhailovsky" <andrei(a)arhont.com>, "openldap-technical" <openldap-technical(a)openldap.org> > Sent: Thursday, 7 February, 2019 02:42:40 > Subject: Re: help with mdb database recovery after crash > Andrei Mikhailovsky wrote: >> Hello everyone, >> >> I have a bit of an issue with my ldap database. I have a Zimbra community >> edition which uses openldap. A server crashed and I am unable to start the ldap >> services after the reboot. The description of my problem, after some digging >> about is: >> >> >> the initial error indicated problem with the ldap >> >> Starting ldap...Done. >> Search error: Unable to determine enabled services from ldap. >> Enabled services read from cache. Service list may be inaccurate. >> >> Having investigated the issue, I noticed the following errors in the zimbra.log >> >> *slapd[31281]: mdb_entry_decode: attribute index 560427631 not recognized* >> >> I also noticed that the /opt/zimbra/data/ldap/mdb/db/data.mdb is actually 81Gb >> in size and had reached the limit imposed by the ldap_db_maxsize variable. so >> over the weekend, the LDAP mdb file became no longer sparse. >> >> I tried following the steps described in >> https://syslint.com/blog/tutorial/solved-critical-ldap-primary-mdb-database… >> but with no success, as the slapcat segfaults with the following message. >> >> >> /opt/zimbra/common/sbin/slapcat -ccc -F /opt/zimbra/data/ldap/config -b "" -l >> /opt/zimbra/RECOVERY/SLAPCAT/zimbra_mdb.ldiff >> 5c583982 mdb_entry_decode: attribute index 560427631 not recognized >> Segmentation fault (core dumped) >> >> the mdb_copy produces a file of 420 mb in size, but it still contains the >> "mdb_entry_decode: attribute index 560427631 not recognized" error. >> I've also tried mdb_dump, but had the same issues after using the mdb_load >> command. >> >> I found a post ( http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8360 ) >> in the openldap community that the mdb gets corrupted if it reaches the maximum >> defined size. but no solution of how to fix it. > > That's from over 3 years ago and has subsequently fixed. If you're running on > such an old > release, there's likely not much that can be done. Ordinarily it's possible to > back up to > the immediately preceding transaction, in case the last transaction is > corrupted, but with > that particular bug it's likely that the corruption occurred in an earlier > transaction > and has been carried forward in all subsequent ones. >> >> any advice on getting the database recovered and working again? > > You could try using the preceding transaction and see if it's in any better > shape. The code > for this is not released in LMDB 0.9. You can compile the mdb.master branch in > git to obtain > it. Then use the "-v" option with mdb_copy and see if that copy of the database > is usable. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

slapd memory usage
by A. Schulze 13 Feb '19

13 Feb '19

Hello, A friend told me about his findings on slapd memory usage. setup: openldap-2.4.47 back_mdb slapd running as PID 1 inside a docker container docker host and docker conatiner based on Debian 9 / 64 bit finding: with minimal / trivial data slapd consume happily 20% of available phys. memory: # top -p $( pidof slapd) top - 21:47:10 up 10 days, 10 min, 5 users, load average: 0,06, 0,08, 0,09 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie %Cpu(s): 0,9 us, 0,5 sy, 0,0 ni, 97,2 id, 1,3 wa, 0,0 hi, 0,1 si, 0,0 st KiB Mem : 3926252 total, 142672 free, 1517516 used, 2266064 buff/cache KiB Swap: 975868 total, 913316 free, 62552 used. 2065320 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2604 165534 20 0 1039308 732000 5628 S 0,0 18,6 0:00.38 slapd workaround: https://discuss.linuxcontainers.org/t/empty-openldap-slapd-consuming-800-mb… -> limit open files to 1024 # top -p $( pidof slapd) top - 21:49:16 up 10 days, 12 min, 5 users, load average: 0,07, 0,11, 0,10 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie %Cpu(s): 1,7 us, 0,6 sy, 0,0 ni, 90,6 id, 7,1 wa, 0,0 hi, 0,0 si, 0,0 st KiB Mem : 3926252 total, 863500 free, 796492 used, 2266260 buff/cache KiB Swap: 975868 total, 913320 free, 62548 used. 2786248 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2993 165534 20 0 48864 7820 5684 S 0,0 0,2 0:00.01 slapd as far as I can tell from a short test there are no functional drawbacks. Any idea why the memory usage is so different? Andreas

4 8

olcRootPW vs. userPassword of olcRootDN
by Zev Weiss 12 Feb '19

12 Feb '19

Hello, I recently set about changing the rootdn password of my OpenLDAP 2.4 server. I constructed an LDIF file looking something like this: dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcRootPW olcRootPW: {SSHA}new_passwd_hash and fed that into ldapmodify. The server then started accepting the new password and I figured I was done. What I noticed a few minutes later, however, was that the server was *also* still accepting the *old* password. After some peeking around, my guess is that this is due to the fact that while my config database ended up containing, as expected: dn: olcDatabase={1}mdb,cn=config # etc... olcSuffix: dc=mydomain,dc=tld olcRootDN: cn=admin,dc=mydomain,dc=tld olcRootPW:: [base64 of {SSHA}new_passwd_hash] the "main" database entry for cn=admin,dc=mydomain,dc=tld still had a userPassword attribute of [base64 of {SSHA}old_passwd_hash]. Prior to the password change the same base64 hash had been present in both, but my change of course only updated the config database. So I'm left with a few questions: Is it "normal" to have both olcRootPW and the rootdn's userPassword stored redundantly like this? If not, is the fact that I do a sign that I did something inappropriate when initially configuring the server? (Unfortunately I no longer remember exactly what I did at the time.) If so, I assume the recommended password update procedure would be to update both in tandem, though I have to wonder what the point of the redundancy (and resulting potential for inconsistency) is. And should section 5.2.5.5 of the admin guide perhaps make some mention of this? Thanks, Zev Weiss

2 1

Re: LMDB mdb_dbi_open mystery
by Sam Dave 11 Feb '19

11 Feb '19

Thanks for the reply. That's what it says on its own, but the doc also says: * The database handle will be private to the current transaction until * the transaction is successfully committed. If the transaction is * aborted the handle will be closed automatically. * After a successful commit the handle will reside in the shared * environment, and may be used by other transactions. That suggests I have to wait for a transaction to finish before I can reuse the same db handle for other transactions. How would you in practice perform multiple transactions at the same time? I don't see it yet. I'm missing something basic. Feb 11, 2019, 5:50 AM by hyc(a)symas.com: > Sam Dave wrote: > >> Hello, >> >> The doc for mdb_dbi_open says: >> >> * This function must not be called from multiple concurrent >> * transactions in the same process. A transaction that uses >> * this function must finish (either commit or abort) before >> * any other transaction in the process may use this function. >> >> This indicates that each process can only perform one transaction at the same time. >> > > No, it only says you may only call mdb_dbi_open from one transaction at a time. > >> This makes sense for write transactions, but wasn't LMDB supposed to support multiple read transactions at the same time? >> >> I'm a bit confused now. Can you assist? >> >> Thanks, >> Sam >> > > > -- > -- Howard Chu > CTO, Symas Corp. > http://www.symas.com <http://www.symas.com> > Director, Highland Sun > http://highlandsun.com/hyc <http://highlandsun.com/hyc/> > Chief Architect, OpenLDAP > http://www.openldap.org/project <http://www.openldap.org/project/> >

4 7

Issue with replication
by Jignesh Patel 11 Feb '19

11 Feb '19

We are running openldap in cluster mode with MDB setup, and we started second cluster after some time and we observe that data is non synch between those 2 servers. So how do we synchronize the data. > On Sep 7, 2018, at 8:00 AM, openldap-technical-request(a)openldap.org wrote: > > Send openldap-technical mailing list submissions to > openldap-technical(a)openldap.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.openldap.org/lists/mm/listinfo/openldap-technical > or, via email, send a message with subject or body 'help' to > openldap-technical-request(a)openldap.org > > You can reach the person managing the list at > openldap-technical-owner(a)openldap.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openldap-technical digest..." > > > Send openldap-technical mailing list submissions to > openldap-technical(a)openldap.org > When replying, please edit your Subject: header so it is more specific than "Re: openldap-technical digest..." > > Today's Topics: > > 1. Replication issue? Data is different between master and > consumer with same entryCSNs (Dave Steiner) > 2. olcSecurity: tls=1 and olcLocalSSF= : what value should I > use? (Jean-Francois Malouin) > 3. Re: olcSecurity: tls=1 and olcLocalSSF= : what value should I > use? (Quanah Gibson-Mount) > 4. Re: Replication issue? Data is different between master and > consumer with same entryCSNs (Frank Swasey) > 5. Re: Replication issue? Data is different between master and > consumer with same entryCSNs (Quanah Gibson-Mount) > 6. Re: olcSecurity: tls=1 and olcLocalSSF= : what value should I > use? (Jean-Francois Malouin) > 7. Re: Replication issue? Data is different between master and > consumer with same entryCSNs (Dave Steiner) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 5 Sep 2018 16:49:44 -0400 > From: Dave Steiner <steiner(a)rutgers.edu> > To: openldap-technical(a)openldap.org > Subject: Replication issue? Data is different between master and > consumer with same entryCSNs > Message-ID: <129e3614-50fe-ba15-4d4b-5f94d14abcd9(a)oit.rutgers.edu> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > I've been noticing various data discrepancies between our LDAP master and LDAP > consumers.? We are running OpenLDAP v2.4.44.? We have two masters running > "mirromode TRUE" and all updates go through a VIP that points to the first one > unless it's not available (doesn't happen very often except for during patches > and restarts). We have 13 consumers that replicate through that same VIP. > > Here's an example of our syncrepl for a client: > > syncrepl rid=221 > ? type=refreshAndPersist > ? schemachecking=on > ? provider="ldap://ldapmastervip.rutgers.edu/" > ? bindmethod=sasl > ? saslmech=EXTERNAL > ? starttls=yes > ? tls_reqcert=demand > ? tls_protocol_min="3.1" > ? searchbase="dc=rutgers,dc=edu" > ? attrs="*,+" > ? retry="10 10 20 +" > ? logbase="cn=accesslog" > ? logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" > ? syncdata=accesslog > ? network-timeout=30 > ? keepalive=180:3:60 > > I check the contextCSN attributes on all the instances every day and they are > all in sync (except during any major changes, of course). But I occasionally > notice discrepancies in the data.... even though the contextCSNs and entryCSNs > are the same.? For example (note hostnames have been changed): > > $ ldapsearch ... -H ldap://ldapmaster.rutgers.edu uid=XXXX postalAddress > createTimestamp modifyTimestamp entryCSN > dn: uid=XXXX,ou=People,dc=rutgers,dc=edu > createTimestamp: 20121220100700Z > postalAddress: Business And Science Bldg$227 Penn Street$Camden, NJ 081021656 > entryCSN: 20180505002024.083133Z#000000#001#000000 > modifyTimestamp: 20180505002024Z > > $ ldapsearch ... -H ldap://ldapconsumer3.rutgers.edu uid=XXXX postalAddress > createTimestamp modifyTimestamp entryCSN > dn: uid=XXXX,ou=People,dc=rutgers,dc=edu > createTimestamp: 20121220100700Z > postalAddress: BUSINESS AND SCIENCE BLDG$227 PENN STREET$CAMDEN, NJ 081021656 > entryCSN: 20180505002024.083133Z#000000#001#000000 > modifyTimestamp: 20180505002024Z > > So I'm trying to figure out why this happens (config issue, bug, ???) and > second, if I can't use the contextCSN to report that everything is fine, what > else can I do besides trying to compare ldif dumps. > > thanks, > ds > -- > Dave Steiner steiner(a)rutgers.edu > IdM, Enterprise Application Services ?? ASB101; 848.445.5433 > Rutgers University, Office of Information Technology > >

2 1

OpenLDAP 2.4.45 possible denial of service vulnerability?
by Juergen.Sprenger＠swisscom.com 11 Feb '19

11 Feb '19

Hi, After upgrading to the latest Release (Solaris 11.3 SRU35, OpenLDAP 2.4.45) we are experiencing massive workloads caused by single clients consuming all available threads and CPU-resources. Service does not longer respond to requests, even cn=monitor on loopback interface stops to respond properly. OS: # pkg info entire Name: entire Summary: entire incorporation including Support Repository Update (Oracle Solaris 11.3.35.6.0). Description: This package constrains system package versions to the same build. WARNING: Proper system update and correct package selection depend on the presence of this incorporation. Removing this package will result in an unsupported system. For more information see: https://support.oracle.com/rs?type=doc&id=2045311.1 Category: Meta Packages/Incorporations State: Installed Publisher: solaris Version: 0.5.11 (Oracle Solaris 11.3.35.6.0) Build Release: 5.11 Branch: 0.175.3.35.0.6.0 Packaging Date: August 10, 2018 03:22:59 PM Size: 5.46 kB FMRI: pkg://solaris/entire@0.5.11,5.11-0.175.3.35.0.6.0:20180810T152259Z OpenSSL: # pkg info entire Name: entire Summary: entire incorporation including Support Repository Update (Oracle Solaris 11.3.35.6.0). Description: This package constrains system package versions to the same build. WARNING: Proper system update and correct package selection depend on the presence of this incorporation. Removing this package will result in an unsupported system. For more information see: https://support.oracle.com/rs?type=doc&id=2045311.1 Category: Meta Packages/Incorporations State: Installed Publisher: solaris Version: 0.5.11 (Oracle Solaris 11.3.35.6.0) Build Release: 5.11 Branch: 0.175.3.35.0.6.0 Packaging Date: August 10, 2018 03:22:59 PM Size: 5.46 kB FMRI: pkg://solaris/entire@0.5.11,5.11-0.175.3.35.0.6.0:20180810T152259Z OpenLDAP: # pkg info entire Name: entire Summary: entire incorporation including Support Repository Update (Oracle Solaris 11.3.35.6.0). Description: This package constrains system package versions to the same build. WARNING: Proper system update and correct package selection depend on the presence of this incorporation. Removing this package will result in an unsupported system. For more information see: https://support.oracle.com/rs?type=doc&id=2045311.1 Category: Meta Packages/Incorporations State: Installed Publisher: solaris Version: 0.5.11 (Oracle Solaris 11.3.35.6.0) Build Release: 5.11 Branch: 0.175.3.35.0.6.0 Packaging Date: August 10, 2018 03:22:59 PM Size: 5.46 kB FMRI: pkg://solaris/entire@0.5.11,5.11-0.175.3.35.0.6.0:20180810T152259Z Part of slapd.conf: loglevel none stats sync sizelimit 15000 timelimit 30 threads 64 tool-threads 8 idletimeout 0 writetimeout 0 security tls=0 conn_max_pending 100 conn_max_pending_auth 1000 database mdb suffix "dc=scom" rootdn "cn=*****" rootpw {SSHA}***** maxsize 17179869184 maxreaders 4096 searchstack 64 checkpoint 0 1 dbnosync Machine is a X6-2, 44 cores, 88 threads, 256GB RAM: # prtdiag System Configuration: Oracle Corporation ORACLE SERVER X6-2 BIOS Configuration: American Megatrends Inc. 38070000 12/16/2016 BMC Configuration: IPMI 2.0 (KCS: Keyboard Controller Style) ==== Processor Sockets ==================================== Version Location Tag -------------------------------- -------------------------- Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz P0 Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz P1 Even monitoring (cn=monitor) is no longer accessible when this occurs. So far we experienced this behavior with clients of Oracle Enterprise Linux 6.x, Redhat Enterprise Linux 6.x and AIX. Service requests are opened at vendors support, but I'd prefer to have an installation which is less vulnerable and more resilient to issues of this kind. No problems or issues with Solaris and HPUX clients. Has anyone experienced similar problems or suggestions for configuration? To avoid performance issues loglevel is now "none stats sync" but can be changed for some time to track down the cause. Best regards Jürgen Sprenger

4 7

LMDB mdb_dbi_open mystery
by Sam Dave 11 Feb '19

11 Feb '19

Hello, The doc for mdb_dbi_open says: * This function must not be called from multiple concurrent * transactions in the same process. A transaction that uses * this function must finish (either commit or abort) before * any other transaction in the process may use this function. This indicates that each process can only perform one transaction at the same time. This makes sense for write transactions, but wasn't LMDB supposed to support multiple read transactions at the same time? I'm a bit confused now. Can you assist? Thanks, Sam

2 1

Monitor configuration... also for the manual
by Arno Lehmann 09 Feb '19

09 Feb '19

Hi all, I'm currently in the process of migrating LDAP data from a really outdated system to something a bit fresher. So, I started with the OpenLDAP as provided by Debian, and learned that a good part of the system management knowledge I had is outdated. So, I stared reading TFM. ... and stumbled over the section where I wanted to learn how to set up monitoring with the cn=config configuration scheme. Naturally, that was exactly the incentive I needed to actually start giving back something to the community. So, I ended up playing around a bit and googling a bit and scratching my head a lot, taking notes, and came up with something you might want to add into the manual -- see below. Unfortunately, the whole thing did not exactly work out as I intended, because the crucial step insists on failing. Namely, trying to create a monitor database fails, indicating there already is one in existence. However, I can't find any such beast: root@host:~/ldap# ldapsearch -Q -LLL -H ldapi:/// -Y EXTERNAL -b 'cn=config' '(|(olcDatabase=monitor)(objectClass=olcMonitorConfig))' root@host:~/ldap# I have actually tried to add the above data using slapadd, with slapd shut down, and got an even more confusing error message: root@host:~/ldap# slapadd -n 0 -l addMonitorDB.ldif slapadd: could not add entry dn="olcDatabase=Monitor,cn=config" (line=1): autocreation of "olcDatabase={-1}frontend" failed _######### 46.91% eta none elapsed none spd 1.3 M/s Closing DB... So, what do I need to do to get my manual suggestion into working condition? (And also allow me to monitor my all fresh LDAP instance :-) Cheers, Arno -----8<--------------cut here... manual text below ------------->8------ 20.1. Monitor configuration via cn=config(5) To enable monitoring an OpenLDAP server, the "monitor" database needs to be available and configured, also allowing read acces to it. 20.1.1. Ensure the monitor backend is available The first step is to ensure the monitor database is part of the running slapd process. As database backends can be build into the main binary, or loaded dynamically, as configured, the initial step is to check if the module is built in, is already loaded, or, if not, add it to the configuration. 20.1.2. Check the binary for built-in modules By running root@host:~/ldap# slapd -VVV @(#) $OpenLDAP: slapd (May 23 2018 04:25:19) $ Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> Included static backends: config ldif root@host:~/ldap# it is easy to check if the monitor backend database is built-in; in the above case, it is not. If it already is part of the slapd binary, the process goes to section 20.1.5 further below. 20.1.3. Check module loader configuration *Note* that the below examples use one particular scheme to access LDAP with administrative, i.e. full, privileges; things may be configured differently in other environments. (The example is correct for a stock Debian 9 installation, by the way.) Checking if the monitor backend is already configured to be loaded requires querying the LDAP configuration, in particular the module loader configuration: root@host:~/ldap# ldapsearch -LLL -H ldapi:/// -Y EXTERNAL -b 'cn=config' '(objectClass=olcModuleList)' olcModuleLoad SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: cn=module{0},cn=config olcModuleLoad: {0}back_mdb olcModuleLoad: {1}back_monitor root@host:~/ldap# In this example, we see the back_monitor module to be loaded. If a line referencing this module was not shown, the next step is described below. Otherwise, proceed at section 20.1.5. 20.1.4. Add the monitor module to the module loader configuration 20.1.4.1. Verify the necessary module exists. A careful administrator will ensure the needed module is actually available to be loaded. This is done by checking the needed file exists in the module loader's path. We assume the path to be correctly set up in the loaders configuration in the first place, trusting that the package builder prepared this step. Thus: root@host:~/ldap# ldapsearch -LLL -H ldapi:/// -Y EXTERNAL -b 'cn=config' '(objectClass=olcModuleList)' olcModulePath SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: cn=module{0},cn=config olcModulePath: /usr/lib/ldap root@host:~/ldap# ls -l /usr/lib/ldap/*monitor* lrwxrwxrwx 1 root root 26 May 23 2018 /usr/lib/ldap/back_monitor-2.4.so.2 -> back_monitor-2.4.so.2.10.7 -rw-r--r-- 1 root root 109408 May 23 2018 /usr/lib/ldap/back_monitor-2.4.so.2.10.7 -rw-r--r-- 1 root root 976 May 23 2018 /usr/lib/ldap/back_monitor.la lrwxrwxrwx 1 root root 26 May 23 2018 /usr/lib/ldap/back_monitor.so -> back_monitor-2.4.so.2.10.7 root@host:~/ldap# and voilà, things look good, the module shared object file is available, and things are prepared for different versions coexisting in the usual Unix/Linux way. (The author has no idea what to expect on a windows system.) If things did *not* look good, it would be time to check the distribution repositories for packages with OpenLDAP modules, or verify the build and installation process, both of which is out of scope of this chapter. 20.1.4.2. Adding the monitor backend to the loader configuration Assuming paths and binaries are all correct, it's now merely a matter of adding some attributes to the module loader's configuration. This can be done with just a few lines of LDIF: root@host:~/ldap# cat loadMonitor.ldif dn: cn=config,cn=module changetype: modify add: olcModuleLoad olcModuleLoad: back_monitor root@host:~/ldap# ldapmodify -H ldapi:/// -Y EXTERNAL -f loadMonitor.ldif should do all that is necessary. Error messages hopefully provide an indication of what went wrong in case there is a problem. 20.1.5. Verifying the monitor backend needs to be configured Of course, we start out being extra-careful, by checking that no monitor backend is already configured: root@host:~/ldap# ldapsearch -LLL -H ldapi:/// -Y EXTERNAL -b 'cn=config' '(objectClass=olcDataBaseConfig)' olcDatabase objectClass SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb root@host:~/ldap# Carefully checking the output, it becomes clear no monitor database is available as yet, so we need to continue. 20.1.6. Adding a "monitor" database Again, a simple LDAP add operation will be sufficient: root@host:~/ldap# cat addMonitorDB.ldif dn: olcDatabase=monitor,cn=config objectClass: olcDatabaseConfig objectClass: olcMonitorConfig olcDatabase: monitor olcAccess: to dn.subtree=cn=monitor by users read root@host:~/ldap# Naturally, the ACL(s) may be adjusted as needed. root@host:~/ldap# ldapadd -H ldapi:/// -Y EXTERNAL -f addMonitorDB.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcDatabase=monitor,cn=config" ldap_add: Other (e.g., implementation specific) error (80) additional info: only one monitor database allowed (BETTER NOT PUBLISH THE FINAL TWO LINES...)

3 9

Re: help with mdb database recovery after crash
by Andrei Mikhailovsky 08 Feb '19

08 Feb '19

Thanks everyone for their contribution. I will follow the suggestions over the weekend and update the list on the progress. Kind regards ----- Original Message ----- > From: "Enes Kıdık" <enes.kidik(a)pardus.org.tr> > To: "Andrei Mikhailovsky" <andrei(a)arhont.com> > Sent: Thursday, 7 February, 2019 10:01:00 > Subject: Re: help with mdb database recovery after crash > Hello Andrei, > I am not posting this to openldap maillist but It may be useful to you. > > 3 years ago I was working on zimbra collaboration and had hard times with those > sparse files. > I found the links I read. Your situation seems different from mine but take a > shot. > > you may want to search how to copy an old backup of zimbra sparse file to new > location (after using mdb_copy copied file is no longer a a sparse file so > there may be another way like slapcat-slapadd) > https://wiki.zimbra.com/wiki/OpenLDAP_Performance_Tuning_8.0 > https://www.openldap.org/lists/openldap-technical/201305/msg00229.html > https://linuxacademy.com/blog/linux/openldap-fixing-or-recovering-a-corrupt… > > Quannah is ldap-guru. He may give you a specific answer to solve your problem. > > Have a good day. I hope you solve it quickly. > Enes > > ----- Original Message ----- > From: "Howard Chu" <hyc(a)symas.com> > To: "Andrei Mikhailovsky" <andrei(a)arhont.com>, openldap-technical(a)openldap.org > Sent: Thursday, February 7, 2019 5:42:40 AM > Subject: Re: help with mdb database recovery after crash > > Andrei Mikhailovsky wrote: >> Hello everyone, >> >> I have a bit of an issue with my ldap database. I have a Zimbra community >> edition which uses openldap. A server crashed and I am unable to start the ldap >> services after the reboot. The description of my problem, after some digging >> about is: >> >> >> the initial error indicated problem with the ldap >> >> Starting ldap...Done. >> Search error: Unable to determine enabled services from ldap. >> Enabled services read from cache. Service list may be inaccurate. >> >> Having investigated the issue, I noticed the following errors in the zimbra.log >> >> *slapd[31281]: mdb_entry_decode: attribute index 560427631 not recognized* >> >> I also noticed that the /opt/zimbra/data/ldap/mdb/db/data.mdb is actually 81Gb >> in size and had reached the limit imposed by the ldap_db_maxsize variable. so >> over the weekend, the LDAP mdb file became no longer sparse. >> >> I tried following the steps described in >> https://syslint.com/blog/tutorial/solved-critical-ldap-primary-mdb-database… >> but with no success, as the slapcat segfaults with the following message. >> >> >> /opt/zimbra/common/sbin/slapcat -ccc -F /opt/zimbra/data/ldap/config -b "" -l >> /opt/zimbra/RECOVERY/SLAPCAT/zimbra_mdb.ldiff >> 5c583982 mdb_entry_decode: attribute index 560427631 not recognized >> Segmentation fault (core dumped) >> >> the mdb_copy produces a file of 420 mb in size, but it still contains the >> "mdb_entry_decode: attribute index 560427631 not recognized" error. >> I've also tried mdb_dump, but had the same issues after using the mdb_load >> command. >> >> I found a post ( http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8360 ) >> in the openldap community that the mdb gets corrupted if it reaches the maximum >> defined size. but no solution of how to fix it. > > That's from over 3 years ago and has subsequently fixed. If you're running on > such an old > release, there's likely not much that can be done. Ordinarily it's possible to > back up to > the immediately preceding transaction, in case the last transaction is > corrupted, but with > that particular bug it's likely that the corruption occurred in an earlier > transaction > and has been carried forward in all subsequent ones. >> >> any advice on getting the database recovered and working again? > > You could try using the preceding transaction and see if it's in any better > shape. The code > for this is not released in LMDB 0.9. You can compile the mdb.master branch in > git to obtain > it. Then use the "-v" option with mdb_copy and see if that copy of the database > is usable. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Locking down ciphers in OpenLDAP with GnuTLS
by Philip Colmer 08 Feb '19

08 Feb '19

I want to restrict the cipher suites used in OpenLDAP so that only TLS1.2 is supported. Looking at https://openldap.org/doc/admin24/tls.html, I first tried setting olcTLSCipherSuite to "HIGH" but the LDAP server gave an error 80 and then stopped accepted further connections until I restarted it. Since our OpenLDAP installation has been built with GnuTLS, I'm presuming that I have to explicitly list out the GnuTLS cipher suites I want to use. I've used gnutls-cli to list out the cipher suites that support PFS and then extracted the ones that are TLS1.2. So, just to confirm, do I need to provide a colon-separated list of each and every cipher suite or is there a GnuTLS shorthand that I can use? Regards Philip

3 4

[Q] RFC2307bis2 "An Approach for Using LDAP as a Network Information Service"
by Zeus Panchenko 07 Feb '19

07 Feb '19

greetings, We've found RFC2307bis2: "An Approach for Using LDAP as a Network Information Service" and now wondering, what've happened to it finally? Is it just expired and forgotten? Recently we've began to deploy netgroup usage in our network and found it impossible to do search by nisNetgroupTriple attribute due to it's SYNTAX and SUBSTR definition ... We've done "amendments" to nis.schema to fix that and they occured to be the same as the ones offered in RFC2307bis2 :) So, is there any further plans/ideas to do something with RFC2307bis2, please? -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET)

2 1

Re: Antw: Re: slapd memory usage
by Howard Chu 07 Feb '19

07 Feb '19

Ulrich Windl wrote: >>>> Howard Chu <hyc(a)symas.com> schrieb am 07.02.2019 um 11:45 in Nachricht > <07438385-b8a5-92c8-3902-9d3084cbef6d(a)symas.com>: >> A. Schulze wrote: >>> >>> Howard Chu: >>> >>>>> Any idea why the memory usage is so different? >>>> >>>> If the only difference is that you set the open file limit to 1024, then it >> sounds >>>> like whatever your default file limit is is much larger. >>> >>> Hello Howard, >>> >>> yes, it's unlimited by default. Tons of other daemon also run without this >> limits here. >>> >>> But in contrast: all other daemons don't let explode the memory usage. >>> Maybe, it worth to find the difference? >> >> That *is* the difference. slapd allocates an array of connection info, one >> slot per >> file descriptor. Running with "unlimited" files is clearly a bad idea here. > > OTOH slapd could also allocate the table in chunks of 100 or 1000 descriptors (if ever needed that much) No. Such strategies invariably lead to failure under heavy load - precisely the time when you want extra resources to be available for use. Preallocating means we always have predictable and consistent runtime behavior. >> In general, running with larger limits than you actually need is a bad idea. > Yes, but allocating a huge table that is most likely never needed is also a bad idea IMHO. It would not be a huge table if you set your resource limits appropriately. >> This >> is elementary system administration. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

ldap client failing
by sami's strat 30 Jan '19

30 Jan '19

I'm installing ldap client on CentOS 7 hosts. Some work, some do not. For those that don't work, I don't know why. The install / setup process I used was the same on all hosts. yum install nss-pam-ldapd openldap-clients -y authconfig --enableldap --enableldapauth --ldapserver=172.19.33.1 --ldapbasedn="dc=users,dc=domain,dc=com" --enablemkhomedir --update systemctl start nslcd getent passwd useraccount The last command fails. Vital signs on all hosts are fine, network, connectivity, ports, ntp, etc.. Where do I even begin troubleshooting the failure? Thanks in advance.

4 5

RE: OpenLDAP 2.4.45 possible denial of service vulnerability?
by Juergen.Sprenger＠swisscom.com 30 Jan '19

30 Jan '19

Hi Henrik, Many thanks for Your advice, - Yes, we started using mdb-backend and did not use it before. - LDAP tree is not very large, a slapcat dump has about 1.050 Million lines and less than 50'000 dn entries. - LDAP tree contains attributes 21661 of type aliasedObjectName - Yes, alias-dereferencing is used and set to always. Clients should not, but may do searches using "sub" instead of "one" . I will check whether using hdb will mitigate the problem. Jürgen -----Original Message----- From: Henrik Bohnenkamp [mailto:hbohnenkamp@united-internet.de] Sent: Mittwoch, 30. Januar 2019 12:23 To: Sprenger Jürgen, INI-ONE-CIS-SDI-HES <Juergen.Sprenger(a)swisscom.com> Subject: Re: OpenLDAP 2.4.45 possible denial of service vulnerability? On Wed, Jan 30, 2019 at 10:17:47AM +0000, Juergen.Sprenger(a)swisscom.com wrote: Hi Jürgen, if you can answer all of the following questions with "yes", you might have the problem described in ITS#8875/ITS#7657 (http://www.openldap.org/its/index.cgi/Incoming?id=8875;selectid=8875): - with the upgrade to 2.4.45, you started to use the mdb-backend, and did not use it before - your LDAP tree is large (> 1 Million entries) - the LDAP tree contains many alias objects (> 64k ) - the clients causing the trouble make searches with scope "sub", and alias-dereferencing set to "always" That's essential the 4 conditions that lead to a problem at my organisation similar to the one you described. Workaround was to go back to the hdb backend. Henrik -- Henrik Bohnenkamp

1 0

authz-regexp failures
by Dieter Klünter 29 Jan '19

29 Jan '19

Hi, I am facing some problems with authz-regexp configurations. These configurations run for ages on several systems. I only discovered recently, that some errors occured: # ldapwhoami -Y EXTERNAL -H ldapi:/// SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth The appropriate lines in slapd.conf: authz-regexp "gidNumber=0\+uidNumber=0,cn=peercred,cn=external,cn=auth" "cn=config" There are still a few more authz-regexp rules that don't work anymore. Any ideas? -Dieter -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

2 2

Spurious Start TLS failed errors on proxyed bind OpenLDAP 2.4.40
by Janne Peltonen 29 Jan '19

29 Jan '19

Hi! We've got a proxy OpenLDAP setup using the "ldap" proxy database (the newer "meta" backend had some issues, so I couldn't use that one). Most of the time, the proxy bind goes OK, but sometimes, the connection goes like this (proxy log, using ldaps): --clip-- Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 ACCEPT from IP=128.214.54.152:36460 (IP=0.0.0.0:636) Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 TLS established tls_ssf=256 ssf=256 Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 op=0 BIND dn="<removed>" method=128 Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 op=0 RESULT tag=97 err=52 text=Start TLS failed Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 closed (connection lost) --clip-- On the backend, this appears to be the case that a new connection kind of overruns the old one; see what happens with connection 6983: --clip-- Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 fd=23 ACCEPT from IP=128.214.222.155:46144 (IP=0.0.0.0:389) Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 ACCEPT from IP=128.214.222.155:46146 (IP=0.0.0.0:389) Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=0 STARTTLS Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=1 UNBIND Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 fd=23 closed Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 STARTTLS Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 RESULT oid= err=0 text= Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 TLS established tls_ssf=256 ssf=256 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 BIND dn="<removed>" method=128 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 BIND dn="<removed>" mech=SIMPLE ssf=0 Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 RESULT tag=97 err=0 text= [SRCH and result lines] Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=3 UNBIND Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 closed --clip-- This doesn't seem to have any correlation to the amount of binds of server load, at least that I'm aware - and anyway, the servers are nowhere near at capacity - we only get ~2 binds per second. Normal connection would look like this: --clip-- Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 fd=159 ACCEPT from IP=128.214.54.152:36362 (IP=0.0.0.0:636) Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 fd=159 TLS established tls_ssf=256 ssf=256 Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 BIND dn="<removed>" method=128 Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 BIND dn="<removed>" mech=SIMPLE ssf=0 Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 RESULT tag=97 err=0 text= [SRCH and SEARCH RESULT lines] Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7650 op=219 UNBIND Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7650 fd=159 closed --clip-- So this far, it looks as if the problem was that if we accept a second connection for the same client before the proxy has had time to do a bind (or indeed, a STARTTLS for the bind) on the backend for the second connection. But we seem to be getting spurious Start TLS failed messages also without any competing connections. Here's one using ldap+STARTTLS but no other ACCEPTs anywhere near: --clip-- Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 fd=62 ACCEPT from IP=128.214.173.135:43148 (IP=0.0.0.0:389) Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 STARTTLS Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 RESULT oid= err=0 text= Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 fd=62 TLS established tls_ssf=256 ssf=256 Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=1 BIND dn="ou=shibboleth,ou=login,dc=helsinki,dc=fi" method=128 Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=1 RESULT tag=97 err=52 text=Start TLS failed Jan 17 17:46:22 ldap-r-1 slapd[28738]: conn=529684 fd=62 closed (connection lost) --clip-- on the proxy, and backend: --clip-- Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 fd=92 ACCEPT from IP=128.214.222.155:48996 (IP=0.0.0.0:389) Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 STARTTLS Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 RESULT oid= err=0 text= Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 fd=92 closed (TLS negotiation failure) --clip-- Succesful ldap+starttls connection on proxy: --clip-- Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 fd=54 ACCEPT from IP=128.214.173.137:48700 (IP=0.0.0.0:389) Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=0 STARTTLS Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=0 RESULT oid= err=0 text= Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 fd=54 TLS established tls_ssf=256 ssf=256 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=1 BIND dn="<removed>" method=128 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=1 BIND dn="<removed>" mech=SIMPLE ssf=0 Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=1 RESULT tag=97 err=0 text= [SRCH and SEARCH RESULT lines] Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 op=3 UNBIND Jan 17 18:11:01 ldap-r-1 slapd[28738]: conn=531181 fd=54 closed --clip-- Any ideas what could be causing these? It's a bit hard to pinpoint the problem, since it happens so rarely - we seem to get a couple dozen of these every hour to around 16 000 succesful binds, not really depending on system load. This is RHEL 7 and OpenLDAP 2.4.40. It may be the case that the same DN binding very often increases the probability of a Start TLS failed error, which I guess would be the first case (a new ACCEPT + BIND for a DN too soon after the previous one). But as I said, these seem to also sometimes appear even without any other connections being opened at the same time. (Although there might be some old connections open for the same DN.) --Janne Peltonen University of Helsinki

5 11

openldap proxy with uid/gid lookup cache
by vadud3＠gmail.com 28 Jan '19

28 Jan '19

How do I include uid/gid lookup caching to my openldap proxy server? $ cat slapd.conf ### Schema includes ########################################################### include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema ## Module paths ############################################################## modulepath /usr/lib64/openldap/ moduleload back_ldap # Main settings ############################################################### pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args sizelimit unlimited TLSCertificateFile /root/data/certs/ldap.crt TLSCertificateKeyFile /root/data/certs/ldap.key ### Database definition (Proxy to AD) ######################################### database ldap readonly yes protocol-version 3 rebind-as-user yes uri "ldaps://ldap.example.com:1636" suffix "ou=People,dc=example,dc=net" ### Logging ################################################################### loglevel 0 (ignore the other similar email with no subjects.. apologize) -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

3 3

Copying SSHA userPassword from Oracle to OpenLDAP
by Nicholas Carl 23 Jan '19

23 Jan '19

Currently doing a targeted sync of userPassword field from one LDAP to another following this process. 1) Query using ldapsearch and grab userPassword field. 2) Deode string using base64 –d 3) Import resultant encrypted password into other ldap using ldapmodify. This process worked when the password decoded into {crypt} format, but after they upgraded and changed to {SSHA} format passwords, it no longer works. Also confirmed with Oracle LDAP admins that the decode matches our {SSHA} string. *Is there some additional configuration information I need to request from the oracle LDAP server administrators for server or client config in openldap?* # Querying other LDAP server $ ldapsearch -h oracleServer -D - -w - -b - "uid=-" | grep ^userPassword userPassword:: e1NTSEF9S3hNQVVoRGY0Y0ZMVXdVREZQb1VDMFNvRFdRb0c2TnNLRTVZUWc9PQ= $ ldapsearch -h oracleServer -D - -w - -b - "uid=-" | grep ^userPassword | base64 -d {SSHA}KxMAUhDf4cFLUwUDFPoUC0SoDWQoG6NsKE5YQg==base64: invalid input ## After importing decrypted into new server, the encrypted string matches. $ ldapsearch -h openLDAPServer -D - -w - "uid=-" | grep ^userPassword userPassword:: e1NTSEF9S3hNQVVoRGY0Y0ZMVXdVREZQb1VDMFNvRFdRb0c2TnNLRTVZUWc9PQ=

6 6

uniqueness on multiple attributes
by A. Schulze 21 Jan '19

21 Jan '19

Hello, my goal it to extend a uniqueness configuration. I do already enforce uniqueness of mail addresses: slapd.conf: moduleload unique.la overlay unique unique_uri ldap:///dc=basedn?mail?sub? that works. Now also address rewriting data should be migrated LDAP. Rewriting addresses are stored in the attribute "mailalternateaddress" Requirement: no address may occur twice no matter if stored as "mail" or "mailalternateaddress" Logical it's something like unique_uri (ldap:///dc=basedn?mail?sub?) OR (ldap:///dc=basedn?mail?sub?) Now I fail to correctly translate that to a valid configuration. https://www.openldap.org/software/man.cgi?query=slapo-unique say "unique_uri <[strict ][ignore ]URI[URI...]...>" with a formal definition of URI "ldap:///[base dn]?[attributes...]?scope[?filter]" It also say "Multiple URIs may be specified within a domain, allowing complex selections of objects." As the manpage doesn't give an example I tried: unique_uri ldap:///dc=ldap?mailalternateaddress?sub ldap:///dc=ldap?mail?sub slapd logs 5c445384 /etc/openldap/slapd.conf: line 149 (unique_uri ldap:///dc=ldap?mailalternateaddress?sub ldap:///dc=ldap?mail?sub) -> slapd starts but uniqueness is not enforced So I tried multiple versions: To make it readable: uri1=ldap:///dc=ldap?mailalternateaddress?sub uri2=ldap:///dc=ldap?mail?sub unique_uri uri1 uri2 unique_uri uri1uri2 unique_uri uri1,uri2 unique_uri uri1, uri2 unique_uri "uri1 uri2" unique_uri "uri1""uri2" unique_uri "uri1","uri2" unique_uri "uri1", "uri2" Mostly slapd failed to start with an error "invalid ldap urilist" If slapd started, the uniqueness wasn't enforced One version (unique_uri "uri1 uri2") result in slapd consume 100% cpu time. Anybody have a hint how to enforce uniqueness on multiple attributes? Andreas

2 3

lastbind module and missing forwarding updates
by David Magda 17 Jan '19

17 Jan '19

Hello, So I'm looking at the code for the /lastbind/ module, and I see the following: > "MAY ( olcLastBindPrecision $ olcLastBindForwardUpdates) )", https://github.com/openldap/openldap/blob/master/contrib/slapd-modules/last… However, when selecting various tagged releases (OPENLDAP_REL_ENG_2_4_[37-47]) I do not see the code. It was committed in October 2013: https://github.com/openldap/openldap/commit/44e9bda0e42f40e0baf0a2c0ef733eb… This would have been around the time of 2.4.37, but I don't see ITS#7721 mentioned in the release notes anywhere either, only ITS#772{0,2,3,5}: https://www.openldap.org/software/release/changes.html Is there a reason why this commit is in "master", but never made it to any official release? Regards, David

2 3

Shared memory error after reboot
by Marc Roos 17 Jan '19

17 Jan '19

I am getting this error after (re)booting, if I restart slapd it is gone. I guess I can ignore this message because slapd will recover from this eventually? Or do I need to give it a restart every time? After reboot: jan 16 14:57:19 mail04 slapd[3283]: @(#) $OpenLDAP: slapd 2.4.44 (Oct 30 2018 23:14:27) $#012#011mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap -2.4.44/openldap-2.4.44/servers/slapd Jan 16 14:57:19 mail04 slapd[3283]: syncrepl rid=504 searchbase="dc=backoffice,dc=local": no retry defined, using default Jan 16 14:57:19 mail04 slapd[3285]: bdb(dc=backoffice,dc=local): BDB0118 shmat: id 884736: unable to attach to shared system memory region: Invalid argument Jan 16 14:57:19 mail04 slapd[3285]: hdb_db_open: database "dc=backoffice,dc=local": shared memory env open failed, assuming stale env. Jan 16 14:57:19 mail04 slapd[3285]: slapd starting Jan 16 14:57:20 mail04 slapd[3285]: do_syncrep2: rid=504 LDAP_RES_INTERMEDIATE - REFRESH_DELETE After restart: Jan 16 14:58:59 mail04 slapd[3285]: daemon: shutdown requested and initiated. Jan 16 14:58:59 mail04 slapd[3285]: slapd shutdown: waiting for 1 operations/tasks to finish Jan 16 14:58:59 mail04 slapd[3285]: slapd stopped. Jan 16 14:58:59 mail04 slapd[3402]: @(#) $OpenLDAP: slapd 2.4.44 (Oct 30 2018 23:14:27) $#012#011mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap -2.4.44/openldap-2.4.44/servers/slapd Jan 16 14:58:59 mail04 slapd[3402]: syncrepl rid=504 searchbase="dc=backoffice,dc=local": no retry defined, using default Jan 16 14:58:59 mail04 slapd[3404]: slapd starting Jan 16 14:58:59 mail04 slapd[3404]: do_syncrep2: rid=504 LDAP_RES_INTERMEDIATE - REFRESH_DELETE openldap-2.4.44-20.el7.x86_64 openldap-clients-2.4.44-20.el7.x86_64 Linux mail04 3.10.0-957.1.3.el7.x86_64 #1 SMP Thu Nov 29 14:49:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux CentOS Linux release 7.6.1810 (Core)

4 5

RE: Shared memory error after reboot
by Marc Roos 16 Jan '19

16 Jan '19

>> >> >> I am getting this error after (re)booting, if I restart slapd it is >> gone. I guess I can ignore this message because slapd will recover from >> this eventually? Or do I need to give it a restart every time? >> >> >> After reboot: >> >> jan 16 14:57:19 mail04 slapd[3283]: @(#) $OpenLDAP: slapd 2.4.44 (Oct 30 >> 2018 23:14:27) >> $#012#011mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap >> -2.4.44/openldap-2.4.44/servers/slapd >> Jan 16 14:57:19 mail04 slapd[3283]: syncrepl rid=504 >> searchbase="dc=backoffice,dc=local": no retry defined, using default >> Jan 16 14:57:19 mail04 slapd[3285]: bdb(dc=backoffice,dc=local): BDB0118 >> shmat: id 884736: unable to attach to shared system memory region: >> Invalid argument > >It means: > >a) You're using shared memory regions with a BDB backend >b) That slapd is not cleanly shut down on a reboot. It sounds like perhaps >you have a broken init system. > >I would note that BDB based backends are deprecated. It's advised to use >back-mdb instead. I just did a service slapd stop before a reboot, gives the same. What does Slapd do when "assuming stale env.". Tries it to recover? Jan 16 17:41:47 mail04 slapd[3404]: slapd stopped. ... ... ... Jan 16 17:42:18 mail04 slapd[3286]: @(#) $OpenLDAP: slapd 2.4.44 (Oct 30 2018 23:14:27) $#012#011mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap -2.4.44/openldap-2.4.44/servers/slapd Jan 16 17:42:18 mail04 slapd[3286]: syncrepl rid=504 searchbase="dc=backoffice,dc=local": no retry defined, using default Jan 16 17:42:18 mail04 slapd[3288]: bdb(dc=backoffice,dc=local): BDB0118 shmat: id 0: unable to attach to shared system memory region: Invalid argument Jan 16 17:42:18 mail04 slapd[3288]: hdb_db_open: database "dc=backoffice,dc=local": shared memory env open failed, assuming stale env. Jan 16 17:42:18 mail04 slapd[3288]: slapd starting Jan 16 17:42:18 mail04 slapd[3288]: do_syncrep2: rid=504 LDAP_RES_INTERMEDIATE - REFRESH_DELETE

1 0

OpenLDAP Proxy - user authentification problem
by Martin Toth 12 Jan '19

12 Jan '19

Hi all, I am trying to configure OpenLDAP proxy to proxy searches to my 2 (two) different AD servers. I am testing/trying to login as domain user to application that is configured to verify users against this proxy. Context is : - allowed app users from AD1 will be placed to "AllowAPP group" on AD1 - i.e. - CN=AllowAPP,OU=Groups,OU=Something,DC=domain,DC=xy - allowed app users from AD2 will be placed to "AllowAPP group" on AD2 - i.e. - CN=Allow,OU=App,OU=Group,DC=domain2,DC=local - these two groups are be placed in different OUs on both ADs (Active Directories) so special rewriting have to be done on both URIs Problem is that I don't know how to correctly authentificate users. App configuration is that it will allow login only to user which is member of CN=AllowAPP,OU=Groups,DC=grouped,DC=all "virtual” group. All working fine when I am searching group membership of users with ldapsearch. I can find members of both groups by searching virtual group mentioned upper. I suspect there is problem with passing user credentials to one of AD servers that I am proxying to. I am using sAMAccountName as user login. This is debug search base when I am trying to login from app : SRCH base="dc=grouped,dc=all" scope=2 deref=2 filter="(?SAMACCOUNTNAME=test.user)” This is error produced while I am trying to login as user : meta_back_search[0] match="" err=1 (Operations error) text="000004DC: LdapErr: DSID-0C09075A, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, v1db1". Am I doing something wrong? Can you advise? I am probably missing something that refers to validating users credentials.. Thanks, BR, Martin This is my configuration so far : database meta suffix "dc=grouped,dc=all” rootdn "cn=admin,dc=grouped,dc=all” rootpw "password” readonly yes lastmod off uri ldap://AD1/dc=grouped,dc=all suffixmassage "dc=grouped,dc=all" "dc=domain,dc=xy" idassert-bind bindmethod=simple binddn="CN=bind,CN=Users,dc=domain,dc=xy" credentials="password" mode=none flags=non-prescriptive rewriteEngine on chase-referrals yes rewriteContext default rewriteContext searchBase rewriteRule "CN=AllowAPP,OU=Groups,DC=grouped,DC=all$" "CN=AllowAPP,OU=Groups,OU=Something,DC=domain,DC=xy" "@" uri ldap://AD2/dc=grouped,dc=all suffixmassage "dc=grouped,dc=all" "dc=domain2,dc=local" idassert-bind bindmethod=simple binddn="CN=binduser,CN=Users,dc=domain2,dc=local" credentials=“password" mode=none flags=non-prescriptive rewriteEngine on chase-referrals yes rewriteContext default rewriteContext searchBase rewriteRule "CN=AllowAPP,OU=Groups,DC=grouped,DC=all$" "CN=Allow,OU=App,OU=Group,DC=domain2,DC=local" "@"

1 0

Switch OpenLDAP backend database from HDB to MDB
by SHarbich＠t-online.de 12 Jan '19

12 Jan '19

Hello my dears, I have a question about my approach. I want to migrate the backend database of my OpenLDAP server from HDB to MDB. I would do this as follows: Backup my LDAP nice slapcat -n 0 > ${BACKUP_PATH}/config.ldif nice slapcat -n 1 > ${BACKUP_PATH}/meinedomain.local.ldif cp -rp /var/lib/ldap /var/lib/ldap.bak cp -rp /etc/ldap/slapd.d /etc/ldap/slapd.d.bak Modify entries in these two dates with a text editor from hdb to mdb. Stop the OpenLDAP service sudo systemctl stop sldap.service Delete the directories of the LDAP tree rm -r /var/lib/ldap /etc/ldap/slapd.d Rebuild the LDAP database sudo dpkg-reconfigure slapd In the options select the database MDB and leave everything else as before. Then restore the LDAP tree. sudo slapadd -F /etc/ldap/slapd.d -n 0 -l ${BACKUP_PATH}/config.ldif sudo slapadd -F /etc/ldap/slapd.d -n 1 -l ${BACKUP_PATH}/meinedomain.local.ldif Restart the OpenLDAP service sudo systemctl restart slapd.service That should have been my opinion. Can you think of something else I have to pay attention to? Greetings from Stefan Harbich

2 1

Add supportedExtensions to LDAP proxy
by Philip Brusten 11 Jan '19

11 Jan '19

Hi We have set up an LDAP proxy (slapd-ldap) in front of a NetIQ eDirectory. The LDAP-client which connects to the proxy uses an extended operation, but the request fails because the proxy is not aware of this extension: do_extended: unsupported operation "2.16.840.1.113719.1.39.42.100.... RESULT tag=120 err=2 text=unsupported extended operation # ldapsearch -H ldaps://proxy:port -b '' -s base -D <snip> -W -LLL supportedExtension Enter LDAP Password: dn: supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 Whereas the NetIQ eDirectory back-end supports lots of custom NetIQ extensions: # ldapsearch -H ldaps://backend:port -b '' -s base -D <snip> -W -LLL supportedExtension Enter LDAP Password: dn: supportedExtension: 2.16.840.1.113719.1.39.42.100.1 supportedExtension: 2.16.840.1.113719.1.39.42.100.3 supportedExtension: 2.16.840.1.113719.1.39.42.100.5 supportedExtension: 2.16.840.1.113719.1.39.42.100.7 supportedExtension: 2.16.840.1.113719.1.39.42.100.9 supportedExtension: 2.16.840.1.113719.1.39.42.100.11 supportedExtension: 2.16.840.1.113719.1.39.42.100.13 supportedExtension: 2.16.840.1.113719.1.39.42.100.15 supportedExtension: 2.16.840.1.113719.1.39.42.100.17 supportedExtension: 2.16.840.1.113719.1.39.42.100.19 supportedExtension: 2.16.840.1.113719.1.39.42.100.21 supportedExtension: 2.16.840.1.113719.1.39.42.100.23 supportedExtension: 2.16.840.1.113719.1.39.42.100.25 supportedExtension: 2.16.840.1.113719.1.39.42.100.27 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 2.16.840.1.113719.1.39.42.100.29 supportedExtension: 2.16.840.1.113719.1.14.100.1 supportedExtension: 2.16.840.1.113719.1.14.100.3 supportedExtension: 2.16.840.1.113719.1.14.100.5 supportedExtension: 2.16.840.1.113719.1.14.100.7 supportedExtension: 2.16.840.1.113719.1.14.100.9 supportedExtension: 2.16.840.1.113719.1.14.100.11 supportedExtension: 2.16.840.1.113719.1.14.100.13 supportedExtension: 2.16.840.1.113719.1.14.100.15 supportedExtension: 2.16.840.1.113719.1.14.100.17 supportedExtension: 2.16.840.1.113719.1.14.100.21 supportedExtension: 2.16.840.1.113719.1.14.100.23 supportedExtension: 2.16.840.1.113719.1.14.100.25 supportedExtension: 2.16.840.1.113719.1.14.100.27 supportedExtension: 2.16.840.1.113719.1.14.100.29 supportedExtension: 2.16.840.1.113719.1.14.100.31 supportedExtension: 2.16.840.1.113719.1.14.100.33 supportedExtension: 2.16.840.1.113719.1.14.100.35 supportedExtension: 2.16.840.1.113719.1.14.100.37 supportedExtension: 2.16.840.1.113719.1.14.100.39 supportedExtension: 2.16.840.1.113719.1.14.100.41 supportedExtension: 2.16.840.1.113719.1.14.100.43 supportedExtension: 2.16.840.1.113719.1.14.100.45 supportedExtension: 2.16.840.1.113719.1.14.100.47 supportedExtension: 2.16.840.1.113719.1.14.100.49 supportedExtension: 2.16.840.1.113719.1.14.100.51 supportedExtension: 2.16.840.1.113719.1.14.100.53 supportedExtension: 2.16.840.1.113719.1.14.100.55 supportedExtension: 2.16.840.1.113719.1.14.100.57 supportedExtension: 2.16.840.1.113719.1.14.100.59 supportedExtension: 2.16.840.1.113719.1.14.100.61 supportedExtension: 2.16.840.1.113719.1.14.100.63 supportedExtension: 2.16.840.1.113719.1.14.100.65 supportedExtension: 2.16.840.1.113719.1.14.100.67 supportedExtension: 2.16.840.1.113719.1.14.100.69 supportedExtension: 2.16.840.1.113719.1.14.100.71 supportedExtension: 2.16.840.1.113719.1.14.100.73 supportedExtension: 2.16.840.1.113719.1.14.100.75 supportedExtension: 2.16.840.1.113719.1.14.100.77 supportedExtension: 2.16.840.1.113719.1.14.100.79 supportedExtension: 2.16.840.1.113719.1.14.100.81 supportedExtension: 2.16.840.1.113719.1.14.100.19 supportedExtension: 2.16.840.1.113719.1.14.100.83 supportedExtension: 2.16.840.1.113719.1.14.100.85 supportedExtension: 2.16.840.1.113719.1.14.100.87 supportedExtension: 2.16.840.1.113719.1.14.100.89 supportedExtension: 2.16.840.1.113719.1.14.100.91 supportedExtension: 2.16.840.1.113719.1.14.100.93 supportedExtension: 2.16.840.1.113719.1.148.100.1 supportedExtension: 2.16.840.1.113719.1.148.100.3 supportedExtension: 2.16.840.1.113719.1.148.100.5 supportedExtension: 2.16.840.1.113719.1.148.100.7 supportedExtension: 2.16.840.1.113719.1.148.100.9 supportedExtension: 2.16.840.1.113719.1.148.100.11 supportedExtension: 2.16.840.1.113719.1.148.100.13 supportedExtension: 2.16.840.1.113719.1.148.100.15 supportedExtension: 2.16.840.1.113719.1.148.100.17 supportedExtension: 2.16.840.1.113719.1.27.100.1 supportedExtension: 2.16.840.1.113719.1.27.100.3 supportedExtension: 2.16.840.1.113719.1.27.100.5 supportedExtension: 2.16.840.1.113719.1.27.100.7 supportedExtension: 2.16.840.1.113719.1.27.100.11 supportedExtension: 2.16.840.1.113719.1.27.100.13 supportedExtension: 2.16.840.1.113719.1.27.100.15 supportedExtension: 2.16.840.1.113719.1.27.100.17 supportedExtension: 2.16.840.1.113719.1.27.100.19 supportedExtension: 2.16.840.1.113719.1.27.100.21 supportedExtension: 2.16.840.1.113719.1.27.100.23 supportedExtension: 2.16.840.1.113719.1.27.100.25 supportedExtension: 2.16.840.1.113719.1.27.100.27 supportedExtension: 2.16.840.1.113719.1.27.100.29 supportedExtension: 2.16.840.1.113719.1.27.100.31 supportedExtension: 2.16.840.1.113719.1.27.100.33 supportedExtension: 2.16.840.1.113719.1.27.100.35 supportedExtension: 2.16.840.1.113719.1.27.100.37 supportedExtension: 2.16.840.1.113719.1.27.100.39 supportedExtension: 2.16.840.1.113719.1.27.100.41 supportedExtension: 2.16.840.1.113719.1.27.100.96 supportedExtension: 2.16.840.1.113719.1.27.100.98 supportedExtension: 2.16.840.1.113719.1.27.100.101 supportedExtension: 2.16.840.1.113719.1.27.100.103 supportedExtension: 2.16.840.1.113719.1.142.100.1 supportedExtension: 2.16.840.1.113719.1.142.100.4 supportedExtension: 2.16.840.1.113719.1.142.100.6 supportedExtension: 2.16.840.1.113719.1.27.100.9 supportedExtension: 2.16.840.1.113719.1.27.100.43 supportedExtension: 2.16.840.1.113719.1.27.100.45 supportedExtension: 2.16.840.1.113719.1.27.100.47 supportedExtension: 2.16.840.1.113719.1.27.100.49 supportedExtension: 2.16.840.1.113719.1.27.100.51 supportedExtension: 2.16.840.1.113719.1.27.100.53 supportedExtension: 2.16.840.1.113719.1.27.100.55 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 2.16.840.1.113719.1.27.100.79 supportedExtension: 2.16.840.1.113719.1.27.100.84 supportedExtension: 2.16.840.1.113719.1.27.103.1 supportedExtension: 2.16.840.1.113719.1.27.103.2 Is there a way to allow these extensions on the proxy? Thx, Philip

3 7

dynlist and entryUUID
by Jon C Kidder 10 Jan '19

10 Jan '19

I have a very rigid LDAP client and I need to present the entryUUID as both entryUUID and nsUniqueID in the user records. I have chosen to do this with the dynlist overlay rather than build a process to replicate the data. I've had the overlay deployed for quite some time and have several dynamically generated attributes. However, I'm finding that this doesn't work with entryUUID? Here's the relevant configuration: dn: olcOverlay={0}dynlist,olcDatabase={2}mdb,cn=config olcDlAttrSet: {4}aepAuxUser nsUniqueIDURL nsUniqueID nsUniqueID:entryUUID dn: uid=TestEmployee,ou=Employees,ou=Users,dc=global,dc=aep,dc=com nsUniqueIDURL: ldap:///uid= TestEmployee,ou=Employees,ou=Users,dc=global,dc=aep,dc=com?entryUUID?base?(objectClass=*) When I execute a search on the above user DN the nsUniqueID attribute doesn't appear but all of my other dynamic attributes do appear and have correct values. I have modified both of the above entries replacing entryUUID with any number of attributes and nsUniqueID will suddenly appear as expected and contain the value of the attribute chosen. I can't get this to work using entryUUID. I have not tried it with other operational attributes yet. Is this because the overlay doesn’t work with operational attributes? Is this a bug? JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD JCKIDDER(a)AEP.COM | D:614.716.4970 1 RIVERSIDE PLAZA, COLUMBUS, OH 43215

3 2

openldap proxy to kerberos
by vadud3＠gmail.com 09 Jan '19

09 Jan '19

I am using openldap proxy today with ldap backend. Any suggestions on how to use kerberos as the backend? Here is my config (sanitized) $ cat slapd.conf ### Schema includes ########################################################### include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema ## Module paths ############################################################## modulepath /usr/lib64/openldap/ moduleload back_ldap # Main settings ############################################################### pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args sizelimit unlimited TLSCertificateFile /root/data/certs/ldap.crt TLSCertificateKeyFile /root/data/certs/ldap.key ### Database definition (Proxy to AD) ######################################### database ldap readonly yes protocol-version 3 rebind-as-user yes uri "ldaps://ldap.example.com:1636" suffix "ou=People,dc=example,dc=net" ### Logging ################################################################### loglevel 0 -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

5 7

Re: OpenLDAP 2.4.47 available, LMDB 0.9.23 available
by Clément OUDOT 08 Jan '19

08 Jan '19

Hello, for information, LDAP Tool Box packages for OpenLDAP 2.4.47 are available: * https://ltb-project.org/documentation/openldap-rpm * https://ltb-project.org/documentation/openldap-deb Thanks a lot to OpenLDAP community for this great software! Clément.

1 0

How should a cron jobb handle modify(cn=config) error?
by Hallvard Breien Furuseth 07 Jan '19

07 Jan '19

We have a cn=config database with olcDbDirectory: /ldap/var/db/foobar-<directory version> A cron job in a quandary can clear things up thus: Rebuild the database in a new directory with slapadd, ldapmodify cn=config so olcDbDirectory points at the new DB directory, and finally throw away the old DB dir. ldapmodify -H ldapi:// -Q -Y EXTERNAL <<EOF # hdb can have more "interesting" problems than mdb:-) dn: olcDatabase={3}hdb,cn=config changetype: modify replace: olcDbDirectory olcDbDirectory: /ldap/var/db/foobar-$NEW_DIR_VERSION EOF Now if ldapmodify fails, what should the cron job do - in addition to alerting a human? When can it assume that the new DB dir is unused and can be deleted? ...that the old DB dir can be deleted? How complicated code should I have to examine the situation and decide what to do? Do we just wait for a human to fix things? Or is it time to restart slapd? Yet that can fail too, so next question becomes what to do next - reboot? A cron job which keeps escalating the problem in order to fix it makes me nervous - LDAP must be up. It's load balanced, so a single server in trouble is OK - unless the problem is a systemic one so all servers hiccup at once. Do others have something like this implemented? -- Hallvard

2 2

storing large blob in LDAP
by Derek Zhou 02 Jan '19

02 Jan '19

Hi, Is is possible to store large blob outside the main database, and only keep file names in the LDAP database? The blobs I want to stored are not as often used as other attributes and not indexed, so it seems to me that bloating up the main database is not economical in terms of fast disk space and overall database efficiency. Then I suppose I need a middle ware or something to combine the data from file system and data from LDAP server. Has anyone try that before? Or I should just store the blobs inside, and live with the bloated database? Thanks a lot Derek

2 1

Unable to start up the ldap server after reboot
by Bharath, Basutkar (TR Tech, Content & Ops) 02 Jan '19

02 Jan '19

HI Team, Am unable to start up the ldap server on solaris 10, could you please help us with the below error; bash-3.2# /usr/local/openldap/libexec/slapd -d 384 -u ldap -g ldap -h "ldap:/// "& >/dev/null 2>&1 [1] 8686 bash-3.2# @(#) $OpenLDAP: slapd 2.2.15 (Nov 10 2014 13:34:11) $ @opusldap1:/usr/local/sftw/openldap-2.2.15/servers/slapd bdb_initialize: Sleepycat Software: Berkeley DB 4.2.52: (December 3, 2003) Global ACL: access to attrs=userPassword by dn.base="cn=admin,dc=riag,dc=com" write(=wrscx) by group/groupOfUniqueNames/uniqueMember.base="cn=ldap_admins,dc=riag,dc=com" write(=wrscx) by anonymous auth(=x) by self write(=wrscx) by * auth(=x) Global ACL: access to attrs=printQueue by dn.base="cn=admin,dc=riag,dc=com" write(=wrscx) by group/groupOfUniqueNames/uniqueMember.base="cn=ldap_admins,dc=riag,dc=com" write(=wrscx) by self write(=wrscx) by * read(=rscx) Global ACL: access to * by dn.base="cn=admin,dc=riag,dc=com" write(=wrscx) by group/groupOfUniqueNames/uniqueMember.base="cn=ldap_admins,dc=riag,dc=com" write(=wrscx) by * read(=rscx) bdb_db_init: Initializing bdb database bdb(dc=riag,dc=com): PANIC: fatal region error detected; run recovery bdb_db_open: dbenv_open failed: DB_RUNRECOVERY: Fatal error, run database recovery (-30978) backend_startup: bi_db_open failed! (-30978) bdb(dc=riag,dc=com): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem bdb(dc=riag,dc=com): txn_checkpoint interface requires an environment configured for the transaction subsystem bdb_db_destroy: txn_checkpoint failed: Invalid argument (22) slapd stopped. connections_destroy: nothing to destroy. Sensitivity: Confidential

3 2

send_ldap_response: ber write failed
by Jean-Francois Malouin 27 Dec '18

27 Dec '18

Hi, I have those errors BER write errors that have crept up recently on 2 slapd providers in a mirror replication setup and I can't seem to find the cause of them. I must have made a change to the config but pea brain of me can't seem to find the root of it. They are now occurring a few times a day. I have turned on BER, conns, stats, and sync debugging but it's still unclear to me what is going on. Can anyone shed some light? IP=172.16.10.247 is a HAproxy server with the 2 mirrors as backends. There is also a Munin host that polls the providers every 5m or so to gather stats. Thanks and Happy Holiday! jf Here a anonymized excerpt of the logs of one server showing the error message: Dec 26 03:20:45 ldap-server slapd[4306]: daemon: listen=8, new connection on 18 Dec 26 03:20:45 ldap-server slapd[4306]: daemon: added 18r (active) listener=(nil) Dec 26 03:20:45 ldap-server slapd[4306]: conn=2799347 fd=18 ACCEPT from IP=172.16.10.247:33746 (IP=0.0.0.0:389) Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on 2 descriptors Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on: Dec 26 03:20:45 ldap-server slapd[4306]: 18r Dec 26 03:20:45 ldap-server slapd[4306]: Dec 26 03:20:45 ldap-server slapd[4306]: daemon: read active on 18 Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=9 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=10 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: conn=2799347 op=0 BIND dn="" method=128 Dec 26 03:20:45 ldap-server slapd[4306]: conn=2799347 op=0 RESULT tag=97 err=0 text= Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on 1 descriptor Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on: Dec 26 03:20:45 ldap-server slapd[4306]: Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=9 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=10 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on 1 descriptor Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on: Dec 26 03:20:45 ldap-server slapd[4306]: 18r Dec 26 03:20:45 ldap-server slapd[4306]: Dec 26 03:20:45 ldap-server slapd[4306]: daemon: read active on 18 Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=9 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=10 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on 1 descriptor Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on: Dec 26 03:20:45 ldap-server slapd[4306]: Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=9 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=10 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on 1 descriptor Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on: Dec 26 03:20:45 ldap-server slapd[4306]: Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=9 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=10 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: connection_read(18): input error=-2 id=2799347, closing. Dec 26 03:20:45 ldap-server slapd[4306]: connection_closing: readying conn=2799347 sd=18 for close Dec 26 03:20:45 ldap-server slapd[4306]: daemon: removing 18 Dec 26 03:20:45 ldap-server slapd[4306]: conn=2799347 fd=18 closed (connection lost) Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on 1 descriptor Dec 26 03:20:45 ldap-server slapd[4306]: daemon: activity on: Dec 26 03:20:45 ldap-server slapd[4306]: Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=9 active_threads=0 tvp=zero Dec 26 03:20:45 ldap-server slapd[4306]: daemon: epoll: listen=10 active_threads=0 tvp=zero Dec 26 03:20:46 ldap-server slapd[4306]: daemon: activity on 1 descriptor Dec 26 03:20:46 ldap-server slapd[4306]: daemon: activity on: Dec 26 03:20:46 ldap-server slapd[4306]: 15r Dec 26 03:20:46 ldap-server slapd[4306]: Dec 26 03:20:46 ldap-server slapd[4306]: daemon: read active on 15 Dec 26 03:20:46 ldap-server slapd[4306]: daemon: epoll: listen=8 active_threads=0 tvp=zero Dec 26 03:20:46 ldap-server slapd[4306]: daemon: epoll: listen=9 active_threads=0 tvp=zero Dec 26 03:20:46 ldap-server slapd[4306]: daemon: epoll: listen=10 active_threads=0 tvp=zero Dec 26 03:20:46 ldap-server slapd[4306]: conn=2799050 op=3 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=root))" Dec 26 03:20:46 ldap-server slapd[4306]: ber_flush2 failed errno=32 reason="Broken pipe" Dec 26 03:20:46 ldap-server slapd[4306]: connection_closing: readying conn=2799050 sd=15 for close Dec 26 03:20:46 ldap-server slapd[4306]: send_ldap_response: ber write failed Dec 26 03:20:46 ldap-server slapd[4306]: conn=2799050 op=3 SEARCH RESULT tag=101 err=0 nentries=0 text= Dec 26 03:20:46 ldap-server slapd[4306]: connection_resched: attempting closing conn=2799050 sd=15 Dec 26 03:20:46 ldap-server slapd[4306]: daemon: removing 15 Dec 26 03:20:46 ldap-server slapd[4306]: conn=2799050 fd=15 closed (connection lost on write)

3 3

ITS#8928 - SOURCE_DATE_EPOCH (was: OpenLDAP 2.4.47 available)
by Michael Ströder 19 Dec '18

19 Dec '18

On 12/19/18 5:51 PM, OpenLDAP Project wrote: > Added slapd reproducible build support (ITS#8928) What would be an appropriate value for SOURCE_DATE_EPOCH to be chosen when packaging OpenLDAP? Ciao, Michael.

2 2

RE24 testing call (2.4.47) LMDB RE0.9 testing call (0.9.23)
by Quanah Gibson-Mount 19 Dec '18

19 Dec '18

2.4.47 is now believed to be ready for release after tracking down a deadlock and a few other replication issues. Please test. :) Generally, get the code for RE24: <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> Configure & 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.4.47 Engineering Added slapd-sock DN qualifier for subtrees to be processed (ITS#8051) Added slapd-sock ability to send extended operations to external listeners (ITS#8714) Fixed liblber to avoid incremental access to user-supplied bv in dupbv (ITS#8752) Fixed libldap dn to domain parsing with bad input (ITS#8842) Fixed slapd slapcat to correctly honor -g option (ITS#8667) Fixed slapd to correctly handle NO_SUCH_OBJECT with dynamic groups (ITS#8923) Fixed slapd to check status of rdnNormalize (ITS#8932) Fixed slapd cn=config when modifying slapo-syncprov config (ITS#8616) Fixed slapd sasl authz-policy "all" behavior (ITS#8909) Fixed slapd sasl minor typo (ITS#8918) Fixed slapd to correctly hide hidden DBs in the rootDSE (ITS#8912) Fixed slapd domainScope control to match Microsoft specification (ITS#8840) Fixed slapd-bdb/hdb/mdb to not convert certain IDLs to ranges (ITS#8868) Fixed slapo-accesslog deadlock during cleanup (ITS#8752) Fixed slapo-memberof cn=config modifications (ITS#8663) Fixed slapo-ppolicy with multimaster replication (ITS#8927) Fixed slapo-syncprov with NULL modlist (ITS#8843) Build Environment Fixed missing includes with OpenSSL 1.0.2 (ITS#8809) Contrib Fixed slapo-pbkdf2 hash generation (ITS#8878) Documentation admin24 fixed minor typo (ITS#8887) LMDB 0.9.23 Engineering ITS#8756 Fix loose pages in dirty list ITS#8831 Fix mdb_load flag init ITS#8844 Fix mdb_env_close in forked process Documentation ITS#8857 mdb_cursor_del doesn't invalidate cursor ITS#8908 GET_MULTIPLE etc don't change passed in key Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

5 10

ldap user authentication, PAM and chsh (change shell): how to make it work?
by Jean-Francois Malouin 17 Dec '18

17 Dec '18

Hi, Please, bear with me! I know that this is not an openldap question per se, but I've been banging my head on the wall for a long time on this issue and maybe someone knows the quick answer: with user authentication coming from LDAP, what is the magic that has to inserted with the PAM stuff on a client to allow users to change their login shells using 'chsh'? I've been googling this for hours to no avail. I nice hint would just suffice. I'm using libnss-ldap along with pam-ldap on Ubuntu and Debian clients. I managed to make the 'passwd' command to work using the libnss-ldap configuration 'pam_password exop' directive but I'm clueless with chsh... Right now I'm getting messages chsh: user 'luser' does not exist in /etc/passwd and the system auth logs tells me: chsh[4638]: pam_unix(chsh:auth): authentication failure; logname=luser uid=1137 euid=0 tty= ruser= rhost= user=luser /etc/pam.d/chsh originally contained, once the @include included: auth required pam_shells.so auth sufficient pam_rootok.so auth [success=2 default=ignore] pam_unix.so nullok_secure auth [success=1 default=ignore] pam_ldap.so use_first_pass auth requisite pam_deny.so auth required pam_permit.so auth optional pam_cap.so account [success=2 new_authtok_reqd=done default=ignore] pam_unix.so account [success=1 default=ignore] pam_ldap.so account requisite pam_deny.so account required pam_permit.so session [default=1] pam_permit.so session requisite pam_deny.so session required pam_permit.so session optional pam_umask.so session required pam_unix.so session optional pam_ldap.so session optional pam_systemd.so I tried to trim it down -- removing the account and session entries but to no avail so far... thanks, jf

5 11

Antw: Re: fast delete a lot of entries
by Ulrich Windl 17 Dec '18

17 Dec '18

>>> Derek Zhou <derek(a)shannon-data.com> schrieb am 14.12.2018 um 07:27 in Nachricht <4351992.5iqGPAtjck@speedy>: > On Thursday, December 13, 2018 05:24:53 PM Derek Zhou wrote: >> Howard and others: >> >> Again on deleting lots of entries. I have 2 experiments: >> >> 1, in a fresh db insert 10 million entries. let's call this state A. then > delete 9 million entries over night. let's call this state B >> 2, in a fresh db insert 1 million entries I call this state B' >> >> In B and B' even the 1 million entries are the same; so from user's > perspective B and B' are indistinguishable. However, deleting entries from B > is much slower than deleting entries from B', like 10x slower. It seems like > deleting speed depends on the peak db size, and how full the db currently is. > >> >> My question is: is this wide a deletion performance gap expected? >> > Further testing shows that this deletion speed drop only happens in writemap > mode. default mode is much better. When you are that deep into analyzing (assuming you use Linux), it wmight be interesting to run blocktrace to see how your filesystem is accessed. (Once I did that for our database server, and you could clearly see accesses to the redo logs as well as the effects of fsync) [...] Regards, Ulrich

1 0

Q: "deferring operation: too many executing" / "deferring operation: pending operations"
by Ulrich Windl 17 Dec '18

17 Dec '18

Hi! I have a question for the following log messages: slapd[2215]: connection_input: conn=144871 deferring operation: too many executing slapd[2215]: connection_input: conn=144871 deferring operation: pending operations slapd[2215]: connection_input: conn=144871 deferring operation: pending operations What is "too many", i.e. where is that limit configured? Is it possible to tell how many "pending operations" there are? Finally: It seems slapd "drives against the wall hard", meaning it runs at full speed until the limit is reached, the refuses any more connection/operation. Is it possible to activate (configure) a "soft knee" behavior, where after reaching a specified limit of connections or operations rate slapd starts responding increasingly slower? That would help load balancers to select a different server in time... Regards, Ulrich

3 3

ldap_oc_mappings | keycol of type varchar
by Thangavel, Parameswaran 16 Dec '18

16 Dec '18

Hi, While exploring the OpenLDAP's backend-sql package, I found below behavior. The ldap_oc_mappings expects the keycol to be of type integer. For example, if I change the datatype of the identifier (id) of persons table to of type varchar then I am not able to retrieve the persons record during LDAP requests. However, if the column "id" is of type Integer then I am able to view the persons record as part of LDAP search requests. insert into ldap_oc_mappings (id,name,keytbl,keycol,create_proc,delete_proc,expect_return) values (2,'inetOrgPerson','persons','id',NULL,NULL,0); insert into persons (id,name,surname,password) values ('a21qec','Mitya','Kovalev','mit'); Question: 1) Is my observation correct? i.e the keycol used to map the LDAP entries to SQL data expects the primary key (id) to be of type integer. 2) If #1 is correct, do we have a way to support VARCHAR datatype for the primary key? In my application, we use GUID (alpha-numeric characters) as the primary key. Please advise. Thanks Param

2 1

fast delete a lot of entries
by Derek Zhou 14 Dec '18

14 Dec '18

dear list, I was experimenting with slapd by adding a lot of entries then deleting them. What I found is adding speed is not bad but deletion speed is lacking. With or without dbsync, delete speed is around half of that of adding. Naively, I thought deleting should be easier than adding, because in adding you actually need to pass and write whole entry of data, while in delete you can just mark the database page as free? The DB file did not shrink after massive deletion; which kind of suggest that deleting is only marking page as free, not really return them to the OS. I am using the latest git tree and the mdb backend. Another related idea is delete a whole branch from the DIT. LDAP is already hierarchical, to delete all entries under a branch, one would assume that there must be an better way than deleting entries with a client side script, like what I am doing? With SQL you can drop a table. With LDAP, can I delete a whole branch? -- Derek Zhou Shannon Systems http://www.shannon-sys.com

3 6

Please help on Openldap issue
by Eggo why 13 Dec '18

13 Dec '18

Hi All, I have install openldap, openldap-servers and openldap-clients and systemctl start slapd without anyproblem but when try ti do an initial ldapadd I got error. My slapd.conf and oidbase.ldif as below. Please help and thank you very much Garry slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/oidschema/oidbase.schema include /etc/openldap/oidschema/oidnet.schema include /etc/openldap/oidschema/oidrdbms.schema include /etc/openldap/oidschema/alias.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args #default searchbase defaultsearchbase "dc=cornell,dc=edu" ####################################################################### # ldbm and/or bdb database definitions ####################################################################### database bdb suffix "dc=cornell,dc=edu" rootdn "cn=admin,dc=cornell,dc=edu" rootpw {SSHA}gZp2hnEA/xq/FfxMgPTjDmSPo78PuZAs # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap/cornell # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub ### for root oraclecontext # database bdb suffix "" rootdn "cn=admin" rootpw {SSHA}gZp2hnEA/xq/FfxMgPTjDmSPo78PuZAs # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap/rootoraclecontext # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub oidbase.ldif dn: dc=cornell,dc=edu objectClass: top objectClass: dcObject objectClass: organization o: cornell.edu dc: cornell dn: cn=OracleContext,dc=cornell,dc=edu objectclass: orclContext cn: OracleContext l$ ldapadd -vc -x -D “cn=admin,dc=cornell,dc=edu” -w $passwd -f oidbase.ldif ldap_initialize( <DEFAULT> ) ldap_bind: Invalid DN syntax (34) additional info: invalid DN

3 6

speed up parallel add/delete
by Derek Zhou 11 Dec '18

11 Dec '18

all I have a patch that can speed up parallel ldap add/delete a lot; in my testing about 2.5X. The idea is described here: the mdb backend does not really support parallelism in rw transactions, so add/delete are serialized by a mutex inside the mdb backend as small transactions. In my patch, all add/delete are put in a queue and executed in a dedicated worker thread. It may seem pointless at first, but by doing them all in the same thread, now I can merge concurrent ops from different clients into larger transactions, and reduce the number of expensive txn_commit calls (fsyncs). my test results are ( your mileage may vary) 10 thread parallel add: 1, unpatched slapd + default config, ~ 2800 op/s (performance stable over time) 2, unpatched slapd + dbnosync ~9000 op/s (lots of fluctuation due to background dirty page flush) 3, unpatched slapd + dpnosync + checkpoint every minute ~8000 op/s, with reduced fluctuation 4, patched slapd ~7300 op/s (fluctuation nearly gone) 2 is not a recommended config, because crashing or power lost will cause massive data lost. 3 is better, but still up to 1 minutes of data can be lost at crash. With this patch, I can achieve >90% of the performance of 3, with data durability as good as 1; or 2.5X performance of 1 with same data durability guaranty. The patch still need some tidy up; is this email list the place to send patches? -- Derek Zhou Shannon Systems http://www.shannon-sys.com

2 1

not be able to initialize ldap
by Eggo why 05 Dec '18

05 Dec '18

Hi All, I have install openldap, openldap-servers and openldap-clients and systemctl start slapd without anyproblem but when try ti do an initial ldapadd I got error. My slapd.conf and oidbase.ldif as below. Please help and thank you very much Garry slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/oidschema/oidbase.schema include /etc/openldap/oidschema/oidnet.schema include /etc/openldap/oidschema/oidrdbms.schema include /etc/openldap/oidschema/alias.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args #default searchbase defaultsearchbase "dc=cornell,dc=edu" ####################################################################### # ldbm and/or bdb database definitions ####################################################################### database bdb suffix "dc=cornell,dc=edu" rootdn "cn=admin,dc=cornell,dc=edu" rootpw {SSHA}gZp2hnEA/xq/FfxMgPTjDmSPo78PuZAs # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap/cornell # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub ### for root oraclecontext # database bdb suffix "" rootdn "cn=admin" rootpw {SSHA}gZp2hnEA/xq/FfxMgPTjDmSPo78PuZAs # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap/rootoraclecontext # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub oidbase.ldif dn: dc=cornell,dc=edu objectClass: top objectClass: dcObject objectClass: organization o: cornell.edu dc: cornell dn: cn=OracleContext,dc=cornell,dc=edu objectclass: orclContext cn: OracleContext l$ ldapadd -vc -x -D “cn=admin,dc=cornell,dc=edu” -w $passwd -f oidbase.ldif ldap_initialize( <DEFAULT> ) ldap_bind: Invalid DN syntax (34) additional info: invalid DN

3 3

Re: On removing a duplicated ppolicy overlay
by Derek Zhou 05 Dec '18

05 Dec '18

On Monday, December 03, 2018 02:11:27 PM Quanah Gibson-Mount wrote: > --On Monday, December 03, 2018 1:57 PM -0800 Daniel Howard > <dannyman(a)toldme.com> wrote: > > > > A potentially minor improvement along these lines could be a very nice > > feature enhancement for OpenLDAP. Thank you for your consideration. > > You're talking about two things: a) slapmodify, which is slated for > release with OpenLDAP 2.5, which allows offline modifications of cn=config, > and b) delete support in cn=config, also slated for release with OpenLDAP > 2.5. slapmodify is nice, however modifying schema is still hard. The old schema file format is still much better than the ldif format for viewing and editing. It would be a nice to have a tool that can parse and diff schemas in the old format and generate ldif modifications for slapmodify or ldapmodify to handle. -- Derek Zhou Shannon Systems http://www.shannon-sys.com

1 0

Re: On removing a duplicated ppolicy overlay
by Daniel Howard 04 Dec '18

04 Dec '18

On Wed, Nov 28, 2018 at 11:05 AM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Wednesday, November 28, 2018 10:16 AM -0800 Daniel Howard > <dannyman(a)toldme.com> wrote: > > ># This file MUST be edited with the 'visudo' command as root. > > > > Perhaps this is a consideration that is already on the roadmap? > > You mean like it already does? :) > > head -1 cn\=config.ldif > # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. > Quanah, (and Howard) That is certainly a warning. It would be more easily noticed with a bit more whitespace around it, as you find in the sudoers file. This warning is not as helpful as the visudo warning, as it does not give the user a way to edit the file. A wrapper script, or a link to a good document on managing configurations, would be more useful. For example, if I follow the advice in sudoers, and I type "visudo" then I get to edit /etc/sudoers, with a validation before the file can go live. This is fantastic! If I follow the advice here, and type "ldapmodify" then I get an error message. If I research the correct command line, then, in my experience, I manage to import multiple conflicting configs into the system that crash the server. I then research some more, and find that ldapmodify can not delete the conflicting configs. I research some more, and learn that I could just remove them from the filesystem. As I wish to be a good citizen, I share this knowledge, and I am told that this is wrong, and I need to use slapcat to export, delete my config files, then slapadd to import, using a different set of flags than ldapmodify. Perhaps, you can spare a moment of empathy to acknowledge how frustrating this must be for a user. I appreciate your warnings, but given the cumbersome and, in my experience, dangerous nature of managing config files through ldapmodify, I am inclined to very carefully tweak the config files in the config directory. If, however, there was a convenient, safe wrapper, like visudo, or a reference to a reassuring doc that explains the right way to do things, then I would preach the good news. A potentially minor improvement along these lines could be a very nice feature enhancement for OpenLDAP. Thank you for your consideration. Sincerely, -danny -- http://dannyman.toldme.com

3 2

Re: On removing a duplicated ppolicy overlay
by Daniel Howard 04 Dec '18

04 Dec '18

On Mon, Dec 3, 2018 at 2:11 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Monday, December 03, 2018 1:57 PM -0800 Daniel Howard > <dannyman(a)toldme.com> wrote: > > > > A potentially minor improvement along these lines could be a very nice > > feature enhancement for OpenLDAP. Thank you for your consideration. > > You're talking about two things: a) slapmodify, which is slated for > release with OpenLDAP 2.5, which allows offline modifications of > cn=config, > and b) delete support in cn=config, also slated for release with OpenLDAP > 2.5. > I love these features already. ;) -- http://dannyman.toldme.com

1 0

syncrepl + rid
by A. Schulze 28 Nov '18

28 Nov '18

Hello, I run a N-Way Multi-Master setup (N=4) and multiple read-only syncrepl. I like to make sure I understand the "rid" correct. According to http://www.openldap.org/doc/admin24/guide.html#olcSyncrepl, the "rid" has to be unique per "slapd" So I would configure on /every host/ (4x Multi-Master and multiple read-only syncrepl) rid=1..4 to identify the other servers. The 4 Multi-Master server get 4 additional "ServerID 1..4 ldaps://multimaster1..4.example" Is that right? Thanks for clarification. Andreas

2 2

Re: On removing a duplicated ppolicy overlay
by Daniel Howard 28 Nov '18

28 Nov '18

On Tue, Nov 27, 2018 at 3:17 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Tuesday, November 27, 2018 2:22 PM -0800 Daniel Howard > <dannyman(a)toldme.com> wrote: > > > I had been yearning for a config file, and it turns out I had them all > > along! > > It's a database, not configuration files. Removing files from underneath > a > database is generally not a good idea, although YMMV. > > > I am sharing my experience here, for the next person who finds themselves > > googling around, trying to figure out how to remove or tweak a config in > > OpenLDAP. It is nowhere near as complicated as what I had read. > > This is the wrong advice. It is also fairly trivial to do what you > avoided. > > a) slapcat -n 0 -l /tmp/config.ldif > b) Remove the duplicate entries from /tmp/config.ldif > c) mv /path/to/current/config /path/to/current/config.old;mkdir -p > /path/to/current/config > d) slapadd -n 0 -l /tmp/config.ldif > I can see how a naive sysadmin might interpret the various text files in /etc/ldap/slapd.d/cn=config/ as configuration files ... that could be carefully edited by hand ... or managed programatically through the local configuration management system. I appreciate your admonition that this interpretation is wrong, and that these would-be "config" files in the system configuration file hierarchy are in fact a software-managed database, so we should not edit what appear to be plain text configuration files, but simply export them to a text file, carefully edit the export of the database, delete the entire config file hierarchy, and then reimport the database. If I may make a minor feature suggestion: whenever I get a file into /etc that needs a special workflow, I like to put warnings in the comments at the top of such files, advising that the file(s) shouldn't be edited by hand, and explaining the proper workflow. (The visudo command is a golden standard in this regard.) djh@djh-p5510 ~> sudo head -3 /etc/sudoers # # This file MUST be edited with the 'visudo' command as root. # Perhaps this is a consideration that is already on the roadmap? Thanks, -danny -- http://dannyman.toldme.com

3 2

On removing a duplicated ppolicy overlay
by Daniel Howard 28 Nov '18

28 Nov '18

Hello, Back in April or May, I was trying to add and tweak a password policy, invoking a command like this multiple times: sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -a -f ppolicy-overlay.ldif This created multiple password policy overlays, and the LDAP server started to crash with some frequency. Of course, you can not use this interface to DELETE a policy overlay, so I went about researching "hot to remove a ppolicy overlay" and go into some complicated process where you have to export the database, remove olc* entries, delete your database and re-import. My attention shifted to other priorities. Yesterday, I turned back to the question of how to remove the duplicated ppolicy overlays and started exporting the database, but I couldn't find the ppolicy stuff in my slapcat output. Another trip to the search mines and I discovered this gem: https://serverfault.com/a/280836/72839 While you are asked to configure stuff using an LDAP command that cannot delete duplicate policy overlays, the config data doesn't get written into the database, but just placed in plain-text files in a directory structure. Removing duplicated overlays is as simple as stop slapd, remove the files, start slapd. Similarly, you could tweak your ppolicy overlay or possibly even bootstrap new servers by merely editing the right config files in the right place. I had been yearning for a config file, and it turns out I had them all along! I am sharing my experience here, for the next person who finds themselves googling around, trying to figure out how to remove or tweak a config in OpenLDAP. It is nowhere near as complicated as what I had read. Thanks, -danny -- http://dannyman.toldme.com

2 1

openldap stopped authenticating
by Lang, Adam 27 Nov '18

27 Nov '18

Hello, I woke up to an issue today where SSH access to our servers no longer works due to issues with LDAP authentication. Oddly, ldapsearch with admin credentials interacts with the LDAP server fine. If I check for ldapusers using getent passwd, none are returned. The slapd auditlog records the failed attempts. When trying to su as an ldap user, it returns "no passwd entry". Nothing "should" have changed over night, so any ideas of where to look will be appreciated. Adam The information contained in or attached to this e-mail is intended only for the use of the addressee. If you are not the intended recipient of this e-mail, or a person responsible for delivering it to the intended recipient, you are strictly prohibited from disclosing, copying, distributing, or retaining this e-mail or any part of it. It may contain information which is confidential and/or covered by legal, professional or other privilege under applicable law. If you have received this e-mail in error, please notify the author by replying to this e-mail immediately and delete this e-mail from your system. The views expressed in this email may not necessary be the views held by the organization. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.

2 2

Empty search result
by Fabiano Sidler 27 Nov '18

27 Nov '18

Hello! What can be the cause for ldapsearch without filter returning everything as expected, but adding a filter (which works well against a 389 and an AD installation) just returns nothing? I can provide configs and logs if this is normal but unexpected (by me) behaviour. Greetings, Fabiano

3 2

SSL_library_init in -lssl... no, configure: error: Could not locate TLS/SSL package
by Synthea 27 Nov '18

27 Nov '18

While I try to configure openldap 2.4.44 I get this error: checking openssl/ssl.h usability... yes checking openssl/ssl.h presence... yes checking for openssl/ssl.h... yes checking for SSL_library_init in -lssl... no checking for ssl3_accept in -lssl... no configure: error: Could not locate TLS/SSL package ssl.h is in /usr/include/openssl/ssl.h and the version of openssl library is 1.1.0f-3

2 1

Q: meaning of ACL "disclose" access
by Ulrich Windl 26 Nov '18

26 Nov '18

Hi! The manual page slapd.access explains: "The disclose access level allows disclosure of information on error." I don't quite understand what this is saying: Can the requester find out a specific object or attribute exists without actually reading its value? Regards, Ulrich

2 1

N-Way MMR between local LDAP and Cloud LDAP
by Alan Lukens 26 Nov '18

26 Nov '18

I have been asked to look into adding an LDAP instance in AWS Cloud environment. This LDAP instance would participate in our current N-Way MMR that we have locally. Does anyone have any recommendations, experience, or insight into attempting something like this? Any help would be appreciated. Alan Lukens Identity Management Specialist University of Massachusetts Amherst, IT NSS

1 0

ldapmodify add olcSyncrepl (okey but not okey)
by lejeczek 19 Nov '18

19 Nov '18

hi everyone I'm must be doing something trivially wrong and am hoping someone could help. I'm trying to add second replica: $ ldapmodify -vv -h rider.my.dom:1389 -D "cn=admin,cn=config" -w my.Biotec13 -x ldap_initialize( ldap://rider.my.dom:1389 ) dn: olcDatabase={1}bdb,cn=config changetype: modify add: olcSyncrepl: rid=002 provider=ldap://swir.my.dom:1389 bindmethod=simple timeout=0 network-timeout=0 binddn="uid=replicator,ou=people,dc=my,dc=dom" credentials="lejek9090" keepalive=0:0:0 starttls=no filter="(objectclass=*)" searchbase="dc=my,dc=dom" scope=sub attrs="*,+" schemachecking=off type=refreshOnly interval=00:00:10:00 retry="5 5 300 +" exit code of the above to shell is 0 yet next ldapsearch finds no such new entry exists. At the time of ldapmodify in logs I see: Nov 19 14:40:48 rider slapd[90048]: slap_queue_csn: queueing 0x7f22cc111e00 20181119144048.167126Z#000000#005#000000 Nov 19 14:40:48 rider slapd[90048]: slap_graduate_commit_csn: removing 0x7f22cc111e00 20181119144048.167126Z#000000#005#000000 How to get it work? Many thanks, L.

4 3

Re: syncrepl schema error
by aRaviNd 19 Nov '18

19 Nov '18

HI Quanah, Yes, there was duplicate values in DIT which was causing slaves to not sync the data. Thanks for your guidance Regards, Aravind M D On Sun, Nov 18, 2018 at 3:35 AM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Saturday, November 17, 2018 9:38 PM +0530 aRaviNd > <ambadiaravind(a)gmail.com> wrote: > > > If remove the schema changes replication works fine. Could you please let > > us know whats going wrong with the configuration? > > Most likely, you have two values in the attribute that are different when > case sensitive, but the same when case insensitive, i.e.: > > memberUID: AbcD > memberUID: aBCd > > Before your schema change, these are considered different. AAfter your > schema change, they are the same. So when a modification occurs to the > attribute they are now seen as duplicate values and it breaks replication. > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

delete a user schema from cn=config
by Derek Zhou 19 Nov '18

19 Nov '18

Hi list, I was experimenting locally written schema with a recent build of slapd. I added the schema ldif with no problem using ldapadd -QY EXTERNAL -H ldapi:/// ... But then I realized I made a mistake, so I try to delete it with ldapdelete -QY EXTERNAL -H ldapi:/// it says: ldap_delete: Server is unwilling to perform (53) what does it mean? The schema is not used by any data on the server. I can use slapmodify to remove it after server shutdown, but that kind of suck and not much different, or even worse than editing conf file? Derek

4 8

syncrepl schema error
by aRaviNd 17 Nov '18

17 Nov '18

Hi Team, We have configured master slave openldap replication in our environment. Default NIS schema was modified for the attribute memberUid to be case insensitive. During replication after some of the records are transferred we are seeing below error. Nov 17 08:06:57 abc.com slapd[2356]: syncrepl_message_to_entry: rid=003 mods check (memberUid: value #30 provided more than once) Nov 17 08:06:57 abc.com slapd[2356]: do_syncrepl: rid=003 rc 20 retrying If remove the schema changes replication works fine. Could you please let us know whats going wrong with the configuration? Thanks in advace Regards, Aravind M D

2 1

cn=config default access control
by Derek Zhou 17 Nov '18

17 Nov '18

Hi list, I've been using openldap for a few years but yesterday I compiled slapd from git head for the first time. To my supprise that: root@my-machine:/root#: ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config does not work. It took me a while to find out that by default the cn=config database has 'olcAccess: {0}to * by * none' and 'olcRootDN: cn=config' with no olcRootPW, so all access from ldap is denied. Once I know I used slapmodify to change olcRootDN to 'gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth' and everything works as expected afterward. My argument is why isn't it the default? I think debian packages already did that. cn=config is stored as plain text on the local file system so local root can read and change anyway. Changing cn=config is the first thing to do for any admin, and I am not exactly a newbie yet I still stumbled on it. By the way, if we really want people to use cn=config exclusively, I suggest to remove all mentioning of slapd.conf from the latest documentation. Old admins appreciate cn=config more and there will be less distraction for newbies. Derek

2 3

OpenLDAP thread-safety nowadays
by openldap-technical＠kolttonen.fi 15 Nov '18

15 Nov '18

Hello, I am new to OpenLDAP and I was wondering whether the OpenLDAP client C API is thread-safe. I found this old thread: https://www.openldap.org/lists/openldap-software/200606/msg00252.html Does anyone know whether there is still a need for separate libldap_r or is the default library okay as it is? Thanks for the information. Best regards, Unto Sten

2 1

Using unique overlay per OU
by Ervin Hegedüs 14 Nov '18

14 Nov '18

Hi, here is an OpenLDAP cluster, with few DC's, eg: dc=service1,dc=company1,dc=hu and dc=company2,dc=hu. All DC's containts few ten of OU, where few ten of user. Now the uniq overlay is set for some attributes, eg. "mail", which means an e-mail address can occures only once in all DB. (The help came on this list: http://www.openldap.org/lists/openldap-technical/201808/msg00016.html) Now, is there any way that I can use the unique rule for every OU, but not for all. I mean an e-mail address can be used under several OU, but only once per OU. Thanks, a.

2 1

Re: Resizing of LMDB map
by Daniel Kraft 13 Nov '18

13 Nov '18

On 2018-11-13 09:59, hyc(a)highlandsun.com wrote: > On Tue, Nov 13, 2018 at 07:09:08AM +0000, Daniel Kraft wrote: >> On 2018-11-12 21:21, Howard Chu wrote: >> Ah ok, so mdb_txn_commit also frees the transaction if it then actually >> fails with MDB_MAP_FULL -- I was missing that. By avoiding the >> mdb_txn_abort in that case, my example code indeed works now! >> >> So is it correct to assume that the transaction is "effectively aborted" >> after mdb_txn_commit fails with MDB_MAP_FULL (or, for that matter, any >> error)? > > http://www.lmdb.tech/doc/group__mdb.html#ga846fbd6f46105617ac9f4d76476f6597 > > The doc is quite clear. After you call commit the txn is freed. Yes, that part is clear (I just missed it before). But the doc doesn't say anything about what happens to the transaction data in case of an error. I think it is quite reasonable to assume that the transaction is fully aborted (as if mdb_txn_abort was called instead of mdb_txn_commit) in case of an error (since otherwise transaction atomicity would be violated), but I just wanted to check this is indeed what happens. Yours, Daniel -- https://www.domob.eu/ OpenPGP: 1142 850E 6DFF 65BA 63D6 88A8 B249 2AC4 A733 0737 Namecoin: id/domob -> https://nameid.org/?name=domob -- 3.6.0: Bar-Pri-Ran-Rog-Sam-Val-Wiz To go: Arc-Cav-Hea-Kni-Mon-Tou

2 1

Why built-in schemas are a bad idea
by Ulrich Windl 13 Nov '18

13 Nov '18

Hi! I had reported about trouble when upgrading the openldap from SLES11 SP4 to that from SLES12 SP3. Besides the version jump, SUSE also removed some modules that had been static in SLES11, so that they need to be loaded dynamically now. Besides that, the bdb version was updated as well, and some other minor things. The real problem is that I'll need to change cn=config to include the modules, one of them being accesslog. The main problem there seems to be that the accesslog module provides the accesslog schema also, meaning the schema is unknown until the module is loaded. Now no configuration change is accepted, because there are attributes in the config database without a schema: # slapadd -q -n0 -F /etc/openldap/slapd.d/ -l module.ldif 5be00c86 <= str2entry: str2ad(olcAccessLogDB): attribute type undefined slapadd: bad configuration directory I once did edit the config-db files directly and managed to get slapd running (and bdb auto-upgraded itself), but I'm looking for a clean solution. The other things I've noticed was that the old SLES11 openldap would not accept a module load directive when the module is not found (mdb in particular); loading modules that are statically included is no problem, however. This makes a replicated cn=config very difficult for a rolling upgrade of MMR servers. Any splendid idea how to add the accesslog module to a cn=config that already has accesslog configured for ist databases? Even temporarily removing the conflicting attributes does not work. Regards, Ulrich

3 13

openldap proxy giving TLS certificate error
by vadud3＠gmail.com 13 Nov '18

13 Nov '18

I am failing to authenticate through ldap proxy and I am seeing this error coming in continuously *TLS certificate verification: Error, self signed certificate in certificate chain* *TLS: can't connect: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (self signed certificate in certificate chain).* Any suggestions how to resolve this? Here is my slapd.conf. ### Schema includes > ########################################################## > include /etc/openldap/schema/core.schema > include /etc/openldap/schema/cosine.schema > include /etc/openldap/schema/inetorgperson.schema > include /etc/openldap/schema/misc.schema > include /etc/openldap/schema/nis.schema > ## Module paths > ############################################################## > modulepath /usr/lib64/openldap/ > moduleload back_ldap > # Main settings > ############################################################### > pidfile /var/run/openldap/slapd.pid > argsfile /var/run/openldap/slapd.args > sizelimit unlimited > TLSCACertificateFile /root/data/certs/ldap.crt > TLSCertificateFile /root/data/certs/ldap.crt > TLSCertificateKeyFile /root/data/certs/ldap.key > ### Database definition (Proxy to Corp LDAP) > ######################################### > database ldap > readonly yes > protocol-version 3 > rebind-as-user yes > uri "ldaps://192.168.1.100:636" > suffix "ou=People,dc=example,dc=net" > ### Logging > ################################################################### > loglevel 0 > It had been working until last week when IT changed there ldap certificate I generate the certificate using this command *openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /root/data/certs/ldap.key -out /root/data/certs/ldap.crt -subj "/CN=host.example.net/OU=Example/O=Example/L=City/ST=ST/C=US <http://host.example.net/OU=Example/O=Example/L=City/ST=ST/C=US>"* So I recreated against the same IT ldap server, so I do have the new cert and keys produced same way as before. All new authentication are failing now. -- Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

2 2

Resizing of LMDB map
by Daniel Kraft 13 Nov '18

13 Nov '18

Hi! I'm trying to use LMDB in a way that automatically resizes the map whenever it becomes too small, i.e. a function fails with MDB_MAP_FULL. I've created and attached a program that resembles my real usecase in a very simplified fashion: It just writes data to the database, and tries to double the map size whenever MDB_MAP_FULL is received. However, for me this program (as well as my real code) produces a segfault in the mdb_put call that follows after the first resize. What am I doing wrong here, and how can I correctly implement a resize when full? According to the docs [1], it is ok to call mdb_env_set_mapsize for an open environment as long as no transactions are active. My code ensures this by aborting the current transaction before resizing the map. Also, there seems to be other code out there [2] that does the resize in a way that looks like what I'm trying to do, and presumably works fine. [1] http://www.lmdb.tech/doc/group__mdb.html#gaa2506ec8dab3d969b0e609cd82e619e5 [2] https://github.com/BVLC/caffe/pull/3731 Yours, Daniel -- https://www.domob.eu/ OpenPGP: 1142 850E 6DFF 65BA 63D6 88A8 B249 2AC4 A733 0737 Namecoin: id/domob -> https://nameid.org/?name=domob -- 3.6.0: Bar-Pri-Ran-Rog-Sam-Val-Wiz To go: Arc-Cav-Hea-Kni-Mon-Tou -- https://www.domob.eu/ OpenPGP: 1142 850E 6DFF 65BA 63D6 88A8 B249 2AC4 A733 0737 Namecoin: id/domob -> https://nameid.org/?name=domob -- 3.6.0: Bar-Pri-Ran-Rog-Sam-Val-Wiz To go: Arc-Cav-Hea-Kni-Mon-Tou

2 2

Re: Why built-in schemas are a bad idea
by Michael Ströder 12 Nov '18

12 Nov '18

On 11/12/18 11:27 AM, Ulrich Windl wrote: > So far nobody did comment of what I think is the real issue: I did. But obviously you did not like my answer. Ciao, Michael.

1 0

syncrepl with exattrs
by Frank Swasey 08 Nov '18

08 Nov '18

I am attempting to set up a replication using delta-syncrepl that will ignore four objectClasses. I am able to prevent the attributes of those objectClasses from being sent, by using @objectClassName in the exattrs value of the statement. However, I also have to set schemachecking off because the objectClass: objectClassName value is still coming over. I was not able to find any examples of using the exattrs option in the tests/data directory. And, I have failed to find anything relevant from google. Is there a way to prevent the four possible objectClass values that I don't want to see from being sent so I can leave schemachecking turned on? Thanks, - Frank

3 9

upgrade procedure
by BÖSCH Christian 06 Nov '18

06 Nov '18

Hi, What would be the best approach to upgrade a multimaster setup? Is it possible to stop node#1 (version 2.4.43), do the upgrade to 2.4.45 and then start the node again, let it replicate (does the version mismatch matter?), and afterwards do the same with node#2? Or is it better to build a fresh environment with the new version in parallel, get the data with slapcat/slapadd and switchover IPs? Thanks in advance, Christian

3 3

Upgrading from 2.4.26 to 2.4.41: Stricter checks prevent startup?
by Ulrich Windl 30 Oct '18

30 Oct '18

Hi! I wonder whether there is a summary of additional checks that may prevent 2.4.41 from starting in a 2.4.26 MMR configuration (What I did was upgrading SLES11 SP4 to SLES12 SP3). What I found out is: 1) olcServerID does not longer accept fifferent URIs mapping to the same ID, like here (" slapd[3299]: olcServerID: value #1: <olcServerID> multiple server ID URLs matched, only one is allowed 1"): olcServerID: 1 ldap://host.domain.org:389 olcServerID: 1 ldaps://host.domain.org:636 (The idea was that whatever URI is used to contact the server, the server ID is the same) As we do not actually use ldaps for replication that second line could be dropped easily 2) After fixing the first problem, I get another one: "5bd06634 <= str2entry: str2ad(olcAccessLogDB): attribute type undefined". The schema files seem to be the same, and the manual page slapo-accesslog also seems to be the same. Any instructions fixing all the issues that may prevent 2.4.41 from starting up? (please no comments on "2.4.41 is obsolete" unless exactly these problems were fixed in a later version) I'm continuing with BDB, BTW, and also please no comments on "MDB is better", please. Regards, Ulrich

4 13

question mark at the beggining of the search
by Angel L. Mateo 27 Oct '18

27 Oct '18

Hi, I'm having searchs like this in my openldap logs: Oct 25 12:46:41 canis30 slapd[25736]: conn=1192458 op=1 SRCH base="ou=Usuarios,dc=Telematica" scope=2 deref=0 filter="(&(?objectClass=posixGroup)(objectClass=irisInetEntity)... What does this "?" mean? -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información y las Comunicaciones Aplicadas (ATICA) http://www.um.es/atica Tfo: 868889150 Fax: 868888337

2 1

Re: ACL contextCSN
by Lirien Maxime 25 Oct '18

25 Oct '18

Thanks !! Have a nice day !! On Thu, Oct 25, 2018 at 5:02 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Thursday, October 25, 2018 10:25 AM +0200 Lirien Maxime > <maxime.lirien(a)gmail.com> wrote: > > > OK thanks Quanah ! > > I removed the "*" on ACL except for the last rule. > > I don't understand : it is rejected by the last rule. Why does it not > > match rule #3 ? Normally it may stop at the first match ? > > > Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_mask: access to entry > > "dc=fr", attr "objectClass" requested > > Hi Lirien, > > It's clearly asking for access to the objectClass attribute in "dc=fr", > which is not a part of your ACL#3, so it's correctly denied: > > # 3) ********* CONTEXTCSN ********* > access to dn.base="dc=fr" attrs=entry,children,contextcsn > by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read > by dn.exact="cn=supervision,ou=Comptes Clients,dc=fr" read > by * none > > You need to modify the access to line to include objectClass. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Re: ACL contextCSN
by Lirien Maxime 25 Oct '18

25 Oct '18

OK thanks Quanah ! I removed the "*" on ACL except for the last rule. I don't understand : it is rejected by the last rule. Why does it not match rule #3 ? Normally it may stop at the first match ? Here's my request and the ACL log : ldapsearch -x -H ldap://127.0.0.1 -b "dc=fr" -D "cn=supervision,ou=Comptes clients,dc=fr" -s base contextCSN Oct 25 08:31:08 apsim-qualif slapd[27308]: => access_allowed: result not in cache (userPassword) Oct 25 08:31:08 apsim-qualif slapd[27308]: => access_allowed: auth access to "cn=supervision,ou=Comptes Clients,dc=fr" "userPassword" requested Oct 25 08:31:08 apsim-qualif slapd[27308]: => dn: [1] ou=comptes admin,dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_get: [2] attr userPassword Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_mask: access to entry "cn=supervision,ou=Comptes Clients,dc=fr", attr "userPassword" requested Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_mask: to value by "", (=0) Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: cn=admingdr,ou=comptes admin,dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: cn=ldapsynchro,ou=comptes admin,dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: users Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: anonymous Oct 25 08:31:08 apsim-qualif slapd[27308]: <= acl_mask: [4] applying auth(=xd) (stop) Oct 25 08:31:08 apsim-qualif slapd[27308]: <= acl_mask: [4] mask: auth(=xd) Oct 25 08:31:08 apsim-qualif slapd[27308]: => slap_access_allowed: auth access granted by auth(=xd) Oct 25 08:31:08 apsim-qualif slapd[27308]: => access_allowed: auth access granted by auth(=xd) Oct 25 08:31:08 apsim-qualif slapd[27308]: => access_allowed: search access to "dc=fr" "entry" requested Oct 25 08:31:08 apsim-qualif slapd[27308]: => dn: [1] ou=comptes admin,dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: => dn: [3] dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_get: [3] matched Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_get: [3] attr entry Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_mask: access to entry "dc=fr", attr "entry" requested Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_mask: to all values by "cn=supervision,ou=comptes clients,dc=fr", (=0) Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: cn=ldapsynchro,ou=comptes admin,dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: cn=supervision,ou=comptes clients,dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: <= acl_mask: [2] applying read(=rscxd) (stop) Oct 25 08:31:08 apsim-qualif slapd[27308]: <= acl_mask: [2] mask: read(=rscxd) Oct 25 08:31:08 apsim-qualif slapd[27308]: => slap_access_allowed: search access granted by read(=rscxd) Oct 25 08:31:08 apsim-qualif slapd[27308]: => access_allowed: search access granted by read(=rscxd) Oct 25 08:31:08 apsim-qualif slapd[27308]: => access_allowed: search access to "dc=fr" "objectClass" requested Oct 25 08:31:08 apsim-qualif slapd[27308]: => dn: [1] ou=comptes admin,dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: => dn: [3] dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_get: [3] matched Oct 25 08:31:08 apsim-qualif slapd[27308]: => dn: [5] dc=gouv,dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_get: [6] attr objectClass Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_mask: access to entry "dc=fr", attr "objectClass" requested Oct 25 08:31:08 apsim-qualif slapd[27308]: => acl_mask: to all values by "cn=supervision,ou=comptes clients,dc=fr", (=0) Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: cn=root,dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: ou=comptes admin,dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: cn=ldapsynchro,ou=comptes admin,dc=fr Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: self Oct 25 08:31:08 apsim-qualif slapd[27308]: <= check a_dn_pat: users Oct 25 08:31:08 apsim-qualif slapd[27308]: <= acl_mask: [5] applying none(=0) (stop) Oct 25 08:31:08 apsim-qualif slapd[27308]: <= acl_mask: [5] mask: none(=0) Oct 25 08:31:08 apsim-qualif slapd[27308]: => slap_access_allowed: search access denied by none(=0) Oct 25 08:31:08 apsim-qualif slapd[27308]: => access_allowed: no more rules On Wed, Oct 24, 2018 at 5:15 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Wednesday, October 24, 2018 5:17 PM +0200 Lirien Maxime > <maxime.lirien(a)gmail.com> wrote: > > ># 2) userPassword accessible by all > > access to * attrs=userPassword > > by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read > > by users auth > > by anonymous auth > > by * none > > This should be just access to attrs=userPassword, no need for the *. > > Similar comment for some of your other ACLs using the same format. > > I would generaly advise enabling "acl" level logging to see how things are > being processed so you can determine what additional access is needed or > which rule(s) are blocking access. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

2 1

two subtrees replication
by Miroslav Misek 24 Oct '18

24 Oct '18

Hi, I am trying setup replication of two subtrees: olcDatabase={-1}frontend,cn=config cn=schema,cn=config I was advised at #openldap channel to set syncrepl for whole cn=config and restrict it by ACL at provider side. Which looks like elegant solution to me. I tried it, but without success. As long, as replication user does not have access to cn=config, replication fails. And I don`t want replicate it, because of TLS settings etc. So I tried this: olcAccess: {0}to dn.subtree="olcDatabase={-1}frontend,cn=config" by dn.exact="uid=replicator,dc=ententee,dc=com" read by * break olcAccess: {1}to dn.subtree="cn=schema,cn=config" by dn.exact="uid=replicator,dc=ententee,dc=com" read by * break olcAccess: {2}to dn.subtree="cn=config" by dn.exact="uid=replicator,dc=ententee,dc=com" search by * break But it didn`t help either. Does anyone have any advice please? Thank you, Miroslav Misek

3 3

ACL contextCSN
by Lirien Maxime 24 Oct '18

24 Oct '18

Hi all, sorry for this second post. I have a "supervision" account on all my ldap servers. With the plugin nagios , it check the synchro. I would like this account read only contextcsn at the top (dc=fr). And only contextcsn not the other entries. Quanah helped me (and thanks again) but it not seems to work. It's my bad, I don't see something... In the log it seems that "supervision" can't access dc=fr and it starts browsing from dc=gouv,dc=fr. Without rule#3, it's ok because of rule #5. But with rule#3 it's supposed to match contextCSN ?! Thanks guys. PS : "supervision" is in "Comptes Admin" Here are my ACL : # 1) Admin's branch access to dn.subtree="ou=Comptes Admin,dc=fr" by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read by self auth by users auth by anonymous auth # 2) userPassword accessible by all access to * attrs=userPassword by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read by users auth by anonymous auth by * none *# 3) ********* CONTEXTCSN *********access to dn.base="dc=fr" attrs=entry,children,contextcsn by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read by dn.exact="cn=supervision,ou=Comptes Clients,dc=fr" read by * none* # 4) Certificate access to * attrs=userCertificateAuthentication,userCertificateConfidentiality,userCertificateSigning by dn.exact="cn=clienttest,ou=Comptes Clients,dc=fr" read by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read by * none # 5) Branch dc=gouv,dc=fr access to dn.subtree="dc=gouv,dc=fr" by dn.subtree="ou=Comptes Clients,dc=fr" read by dn.subtree="ou=Comptes Admin,dc=fr" write by * none # 6) All the tree access to * by dn.exact="cn=root,dc=fr" write by dn.subtree="ou=Comptes Admin,dc=fr" read by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read by self none by users none by anonymous none by * none

2 1

Adding read-only consumers to a Mirror Mode Replication setup?
by Jean-Francois Malouin 24 Oct '18

24 Oct '18

Hi, Is it possible, or even sane to consider adding read-only consumers to a MMR setup? If so, any recommendations, pitfalls or gotchas? Or should I simply re-start from scratch -- I'm still not in production. Just for the record, I'm using 2.4.46 on Debian/Stretch 9.5. Both mirrors are backends to an HA haproxy server. Thanks, jf

6 12

Re: Permissions required to perform OU/DN filtering?
by Philip Colmer 24 Oct '18

24 Oct '18

So, in the end, it was literally the "ou" attribute that I needed to grant read access to. Just in case anyone else needs to do something similar in the future … Regards Philip On Tue, 23 Oct 2018 at 23:05, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > Hi Philip, > > --On Tuesday, October 23, 2018 2:21 PM +0100 Philip Colmer > <philip.colmer(a)linaro.org> wrote: > > > Yes, I can run slapd in debug mode but this is a production system so > > that means scheduling a maintenance window in several weeks' time. I > > was rather hoping to have a solution in place sooner than that thanks > > to the kind support of this list but, if I don't have it, I'll figure > > it out for myself. > > I don't know the answer off the top of my head, but I would imagine you > could set up a test/dev server fairly quickly to figure this out? Should > be pretty straight forward. If you have the cn=config database enabled, > you could change the loglevel to ACL on the fly (just to note). > > Warm regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

Permissions required to perform OU/DN filtering?
by Philip Colmer 24 Oct '18

24 Oct '18

I'm trying to use the following search filter: (&(objectClass=organizationalPerson)(!(ou:dn:=external-community))(memberOf=cn=users,ou=mailing,ou=groups,dc=linaro,dc=org)) If I use an admin account, the search works. If I use a restricted account, the search doesn't work. The restricted account is only allowed to retrieve a subset of attributes, e.g.: add: olcAccess olcAccess: to dn.children="dc=linaro,dc=org" filter=(objectClass=organizationalUnit) attrs=entry,description,organizationalStatus,mail,jpegPhoto,@organizationalUnit by group="cn=binder-group,ou=binders,dc=linaro,dc=org" read add: olcAccess olcAccess: to dn.children="dc=linaro,dc=org" filter=(objectClass=inetOrgPerson) attrs=businessCategory,jpegPhoto,labeledURI,roomNumber,modifyTimestamp,employeeNumber,memberOf by group="cn=binder-group,ou=binders,dc=linaro,dc=org" read (That is only a snippet of our configuration) What do I need to grant read access to in order to get the search filter to work with restricted accounts? Thanks. Philip

4 7

granting write privileges to alternate updatedn
by Heinemann, Peter G 24 Oct '18

24 Oct '18

Running Openldap 2.4.40 under RHEL 6.10 Trying to get this to work without success (from the slapd.access man page): " One useful application is to easily grant write privileges to an updatedn that is different from the rootdn. In this case, since the updatedn needs write access to (almost) all data, one can use access to * by dn.exact="cn=The Update DN,dc=example,dc=com" write by * break " I have this as the only access rule in slapd.conf but any write operation using this dn gives me insufficient access, and slapacl verifies that read access only is permitted. access to dn.subtree="dc=university,dc=edu" by dn.exact="cn=grouper-admin,dc=university,dc=edu" write by * break Standard rootdn works fine. This system is a master for two consumers, but there's no external access to the master so a stripped-down acl list is appropriate. Thanks for any direction for what I've missed. Peter

2 1

nonpresent_callback present UUID in logs
by Florent LARTET 23 Oct '18

23 Oct '18

Hello, I migrated my OpenLDAP data from bdb to mdb in a Multi-Master Replication architecture that is working for years now. Unfortunately using only 2.4.31-2+deb7u2 from Debian 7. In the 2nd server (yyyyyy in the configuration below), I noticed new log lines for each LDAP entry. nonpresent_callback: rid=002 present UUID 345d766c-b2d5-1030-9b6b-85786c41386a, dn uid=tve0320,ou=people,dc=univ-tlse2,dc=fr It occurs if the server yyyyyy is down, a modification is done on the server xxxxx and yyyy is started. I saw it's related to the "PRESENT" step on replication. I haven't the sync logs for long so I cannot say if it happened with the previous backend. So, is this a warning about a data problem or does it only mean "I'm looking for the existence on rid=002 and that's fine, here are the UUID and dn" ? Here is part of my conf, also replicated : /etc/ldap/slapd.d/cn=config.ldif:olcServerID: 1 ldap://xxxxxxx/ /etc/ldap/slapd.d/cn=config.ldif:olcServerID: 2 ldap://yyyyyyy/ olcSyncrepl: {0}rid=002 provider=ldap://xxxxxxx/ binddn="--------" bindmethod=simple credentials=---- searchbase="dc=univ-tlse2,dc=fr" type=refreshAndPersist retry="5 5 300 +" attrs="*,+" tls_reqcert=never olcSyncrepl: {1}rid=003 provider=ldap://yyyyyyy/ binddn="--------" bindmethod=simple credentials=---- searchbase="dc=univ-tlse2,dc=fr" type=refreshAndPersist retry="5 5 300 +" attrs="*,+" tls_reqcert=never olcMirrorMode: TRUE olcDbCacheSize: 10000 olcDbCheckpoint: 512 5 olcDbNoSync: TRUE olcDbMaxSize: 3221225472 olcIndex: entryUUID,entryCSN,contextCSN eq Thanks for your advices, Florent Lartet University of Toulouse Jean Jaurès

3 6

OpenLDAP and Google Cloud Directory Sync
by Brian Hill 19 Oct '18

19 Oct '18

I would like to get OpenLDAP to trigger a GCDS sync whenever either certain attributes are modified or even anything the DB, if it isn't possible to limit it to certain attributes. I am thinking along the lines of OpenLDAP calling some external program after a modification, but if there is another way to do this that I am missing, I am all ears. I have looked at the various overlays but none seem relevant. Has anyone done this or have general suggestions? Brian

5 4

Re: Check synchro : access only to contextcsn
by Lirien Maxime 18 Oct '18

18 Oct '18

Damn ! my ACL don't work despites your help :-/ In the log it seems that "supervision" can't access dc=fr, it starts from dc=gouv,dc=fr. Without rule#3, it's ok because of rule #5. But with rule#3 it's supposed to match contextCSN Thanks guys. Here are my ACL : # 1) Admin's branch access to dn.subtree="ou=Comptes Admin,dc=fr" by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read by self auth by users auth by anonymous auth # 2) userPassword accessible by all access to * attrs=userPassword by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read by users auth by anonymous auth by * none *# 3) ********* CONTEXTCSN ********** *access to dn.base="dc=fr" attrs=entry,children,contextcsn* * by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read by dn.exact="cn=supervision,ou=Comptes Clients,dc=fr" read by * none* # 4) Certificate access to * attrs=userCertificateAuthentication,userCertificateConfidentiality,userCertificateSigning by dn.exact="cn=clienttest,ou=Comptes Clients,dc=fr" read by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read by * none # 5) Branch dc=gouv,dc=fr access to dn.subtree="dc=gouv,dc=fr" by dn.subtree="ou=Comptes Clients,dc=fr" read by dn.subtree="ou=Comptes Admin,dc=fr" write by * none # 6) All the tree access to * by dn.exact="cn=root,dc=fr" write by dn.subtree="ou=Comptes Admin,dc=fr" read by dn.exact="cn=Synchro,ou=Comptes Admin,dc=fr" read by self none by users none by anonymous none by * none On Tue, Oct 16, 2018 at 6:31 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Tuesday, October 16, 2018 6:54 PM +0200 Dieter Klünter > <dieter(a)dkluenter.de> wrote: > > > Am Tue, 16 Oct 2018 15:51:50 +0200 > > schrieb Lirien Maxime <maxime.lirien(a)gmail.com>: > > > >> Hi all, > >> thanks for reading. > >> I have a "supervision" account on all my ldap servers. With the plugin > >> nagios , it check the synchro. I would like this account read only > >> contextcsn to check synchro. And only contextcsn not the other > >> entries. (plugin check nagios). > >> Can someone help me to write the right ACL ? > >> > >> Here what I tried but not really right :-/ > >> # ContextCSN > >> access to dn.subtree="dc=fr" attrs=contextCSN > >> by dn.subtree="cn=supervision,ou=Comptes Clients,dc=fr" read > >> by * none > > > > access to dn.base=dc=fr > > attrs=entry,children,contextCSN read > > I'd also be careful of doing "by * none" to the contextCSN, etc, as that > can break replication depending on the DN that binds to the master(s), > since the replication DN must be able to read the contextCSN. > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

2 1

Re: Adding read-only consumers to a Mirror Mode Replication setup?
by Quanah Gibson-Mount 18 Oct '18

18 Oct '18

--On Thursday, October 18, 2018 1:44 PM +0200 Ondřej Kuzník <ondra(a)mistotebe.net> wrote: > I can see cn=config is being replicated in that ticket. It makes more > sense that the 'unwilling to perform' issue would be limited to > replicating the config (which can be more picky about its modifications) > rather than regular databases. cn=config is not being replicated in that ticket. I simply said in one follow up that things broke after I made a change to cn=config. Later, I clearly stated that was entirely unrelated. ;) > That kind of setup is being used in a significant number of deployments > and by Linus' law we'd have more reports like this one. I've never seen that setup in any deployment. I've seen lots of deployments that say, have 2-way MMR, and 3 replicas that feed of Master #1 and 3 replicas that feed off of Master #2. But not where any replica feeds from *both* masters, as is discussed in the ticket. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

ODD #5 Proceedings
by Howard Chu 17 Oct '18

17 Oct '18

Proceedings are partially online now. http://www.openldap.org/conf/odd-tuebingen-2018/ (The last 2 talks are still missing, will be uploaded when available.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Check synchro : access only to contextcsn
by Lirien Maxime 16 Oct '18

16 Oct '18

Hi all, thanks for reading. I have a "supervision" account on all my ldap servers. With the plugin nagios , it check the synchro. I would like this account read only contextcsn to check synchro. And only contextcsn not the other entries. (plugin check nagios). Can someone help me to write the right ACL ? Here what I tried but not really right :-/ # ContextCSN access to dn.subtree="dc=fr" attrs=contextCSN by dn.subtree="cn=supervision,ou=Comptes Clients,dc=fr" read by * none Thanks.

3 2

Password policy messages - how can I pass back
by Ervin Hegedüs 13 Oct '18

13 Oct '18

Hi there, there is a password policy external module with this config: dn: cn=default,ou=pwpolicies,dc=hu cn: default objectClass: pwdPolicy objectClass: pwdPolicyChecker objectClass: device pwdAllowUserChange: TRUE pwdInHistory: 5 pwdMinLength: 10 pwdAttribute: userPassword pwdCheckQuality: 1 pwdCheckModule: pwdCheckModule-poc.so I've grabbed this source: https://github.com/bindle/bofh-pwdCheckModules Everything works as well: I can change the password with ldappasswd tool, or ldap_exop() in PHP - the policy check works in both cases. I just have one question: is there any way to send back to the client the error message? I mean: # /usr/bin/ldappasswd -H ldaps://dev-ldap-01 -w "secret" -D "UID="dminuser,dc=hu" -s "abcdefghijkl" "uid=airween,ou=Users,dc=hu" Result: Constraint violation (19) There isn't any detailed information, what's the reason why the policy module drops the request, but I can see that in the logfile: Oct 10 20:05:21 dev-ldap-01 slapd[16312]: check_password_quality: module error: (pwdCheckModule-poc.so) Passwords less than 16 characters require at least 3 traits (upper case, lower case, digits, or special characters).[1] Oct 10 20:05:21 dev-ldap-01 slapd[16312]: send_ldap_result: conn=1742 op=1 p=3 Oct 10 20:05:21 dev-ldap-01 slapd[16312]: send_ldap_result: err=19 matched="" text="Passwords less than 16 characters require at least 3 traits (upper case, lower case, digits, or special characters)" It would be very good to catch this message at client side. Is it possible? Note, that in PHP side I'm using: ldap_get_option($ldapconn, LDAP_OPT_DIAGNOSTIC_MESSAGE, $_err); and $_err variable is empty. When I send the old password, which exists in history, I got: ldappasswd -H ldaps://... ... ... -s "oldpasswd" "uid=airween,..." Result: Constraint violation (19) Additional info: Password is not being changed from existing value in PHP: "Password is not being changed from existing value" In syslog I can see: Oct 10 20:09:36 dev-ldap-01 slapd[16312]: send_ldap_result: err=19 matched="" text="Password is not being changed from existing value" Oct 10 20:09:36 dev-ldap-01 slapd[16312]: send_ldap_extended: err=19 oid= len=0 Oct 10 20:09:36 dev-ldap-01 slapd[16312]: send_ldap_response: msgid=2 tag=120 err=19 Oct 10 20:09:36 dev-ldap-01 slapd[16312]: conn=1743 op=1 RESULT oid= err=19 text=Password is not being changed from existing value Should I fill some member of Entry struct in 3rd argument in policy module? int check_password (char *pPasswd, char **ppErrStr, Entry *pEntry) ....................................................^^^^^^^^^^^^^^ Thanks, a.

3 6

How to add a new schema on N-way multi-master with legacy config
by Martin Božič 12 Oct '18

12 Oct '18

Hello, We've inherited an N-way multi-master setup (based on CentOS OpenLDAP v. 2.4.39) which was setup with text conf in slapd.conf instead of online configuration in cn=config. Due to various dependencies from other internal systems we can't migrate to online configuration quickly, but we to urgently have to add an additional schema to our cluster. My Google-fu and wading through the openldap list archives was unsuccessful. I suppose that adding a new schema to such a setup would require the following steps: 1. stop all instances in the cluster 2. add schema to all instances to /etc/openldap/schema 3. start all instances in the cluster Would this be the correct approach or is there something else I should be aware of? Regards, Martin Božič

4 3

role based authorization -> dynacl module?
by Daniel Tröder 11 Oct '18

11 Oct '18

Hello everyone, I am in the process of implementing a role concept via ACLs and hope for a hint so that I don't invent the wheel a second time. Specifically, it is about identity management for schools. A user (object) can have several roles in multiple schools. Permissions on other LDAP objects can thus differ depending on the role(s) the user and the object have in the same school(s). For example, a user could have been assigned the following roles that are scattered over several schools: → "Teacher" in school 1 → "School admin" in school 2 → "Parent" in school 3 → both "Teacher" and "Staff" in school 4 ACLs should now be defined accordingly, e.g. → the role "teacher" at school X can reset the password for the role "student" at school X → the role "teacher" at school X *cannot* reset the password for the role "student" of school Y → the role "school administrator" at school X can reset the password for the roles "student" and "teacher" at school X → ... So far I have not seen any way to map such a construct via groups or sets without including a separate ACL for each group, which is a performance issue. Is there another way to map the role concept besides implementing an own dynacl module? Greetings, Daniel

4 13

Fwd: ppolicy and logging
by Maurice Barlow 10 Oct '18

10 Oct '18

Greetings, using 2.4.45 on Solaris 11 ( shipped with the distro ) with ppolicy. Working on the locking out of the accounts and want to configure detailed messages pumped into syslog to track lockout activity. At the moment what i see is only "errorno=49". Any ideas or a secure log_level ? cheers MB

1 0

Using ppolicy and autogroup to apply policy to a group a users
by Clément OUDOT 08 Oct '18

08 Oct '18

Hello, we often have the question on this list: how apply a policy to a branch or a group of users? I was thinking we could use autogroup we this kind of configuration: dn: olcOverlay={9}autogroup,olcDatabase={1}mdb,cn=config objectClass: top objectClass: olcConfig objectClass: olcAutomaticGroups objectClass: olcOverlayConfig olcOverlay: {9}autogroup olcAGattrSet: pwdPolicy memberUrl seeAlso olcAGmemberOfAd: pwdPolicySubentry The goal is to have a memberUrl inside a pwdPolicy object, that can target accounts that need to have this policy. For example: dn: cn=default,ou=ppolicies,dc=example,dc=com changetype: modify replace: memberURL memberURL: ldap:///ou=users,dc=example,dc=com??one?(uid=user*) The autogroup "olcAGattrSet" is working well, I can see the seeAlso values. But the "olcAGmemberOfAd" does not seem to be applied. I don't know if this is a conflict with ppolicy overlay, or other overlays (dynlist, memberof). I join a full debug log, maybe you can find what is going wrong. We see that "autogroup_member_search_modify_cb" function is called, but user entry is not modified. Do you think this configuration could work? -- Clément Oudot | Identity Solutions Manager clement.oudot(a)worteks.com Worteks | https://www.worteks.com

1 0

oracle user authentication through OpenLDAP
by appana anil 04 Oct '18

04 Oct '18

We have recently replaced OID with OpenLDAP and looking to see if the Oracle db user can authenticate through OpenLDAP. Appreciate your help. -- Regards, A.Anil Kumar

1 0

RE24 testing call (2.4.47) LMDB RE0.9 testing call (0.9.23)
by Quanah Gibson-Mount 04 Oct '18

04 Oct '18

This is expected to be the only testing call for 2.4.47, with an anticipated release, depending on feedback, during the week of 2018/10/15. Generally, get the code for RE24: <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> Configure & 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.4.47 Engineering Added slapd-sock DN qualifier for subtrees to be processed (ITS#8051) Added slapd-sock ability to send extended operations to external listeners (ITS#8714) Fixed libldap dn to domain parsing with bad input (ITS#8842) Fixed slapd slapcat to correctly honor -g option (ITS#8667) Fixed slapd cn=config when modifying slapo-syncprov config (ITS#8616) Fixed slapd sasl authz-policy "all" behavior (ITS#8909) Fixed slapd sasl minor typo (ITS#8918) Fixed slapd to correctly hide hidden DBs in the rootDSE (ITS#8912) Fixed slapd domainScope control to match Microsoft specification (ITS#8840) Fixed slapd-bdb/hdb/mdb to not convert certain IDLs to ranges (ITS#8868) Fixed slapo-memberof cn=config modifications (ITS#8663) Fixed slapo-syncprov with NULL modlist (ITS#8843) Build Environment Fixed missing includes with OpenSSL 1.0.2 (ITS#8809) LMDB 0.9.23 Engineering ITS#8756 Fix loose pages in dirty list ITS#8831 Fix mdb_load flag init ITS#8844 Fix mdb_env_close in forked process Documentation ITS#8857 mdb_cursor_del doesn't invalidate cursor ITS#8908 GET_MULTIPLE etc don't change passed in key Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Making contextCSN, entryCSN visible only to sync user?
by Karsten Heymann 02 Oct '18

02 Oct '18

Hi, I wonder if it would be harmful to modify our slapd acls so that only the user used for syncrepl replication can view the contextCSN/entryCSN attributes on the master servers. We're considering this to prevent unintended partial replication (for example without password fields) in case there is a misconfiguration and the slave comes as another user/anomymous. Ideally I would block anonymous access to our database completely but we have to update a lot of services until this can be achieved. Does this idea make sense or am I missing something? Best regards Karsten

2 1

Q: Renewing certificates online
by Ulrich Windl 02 Oct '18

02 Oct '18

Hi! I have a question: I updated the contents of certificate and key file (same location and file name) while slapd was running. Is it expected that slapd will recognize (and use) the new certificates, or is a restart or reload needed? Out certificates will expire soon... Regards, Ulrich

4 3

Re: slapo-memberof and Replication
by Meike Stone 02 Oct '18

02 Oct '18

Hello Quanah, Thanks for clarification. > > That confuses me a little bit. > > All replication on openLDAP are based on syncreplication (slurpd is > > vanished a long time ago) > > So what kind of replication means the manual page (-> "Replica servers")? > > It means that you run it in a replicated environment at your own risk. > Unfortunately, there is no defined standard for the "memberOf" > functionality (it's a MS hack) and so there's nothing that details how it > should or shouldn't behave with replication. In general, things work fine > as long as: > > a) The server(s) never go into REFRESH > and > b) You never bring up a new replica with an empty database (which then does > a full REFRESH) That means, if I run in mirrormode, I can turn on the memberOf overlay on the active openLDAP server and off on the slave. Then REFESH ist supported?! In emegency case (hardware error) I can make the mirror (manual) aktive an turn the overlay on?! Thanks Meike

2 1

Program of the Silver Jubilee Open LDAP Developper's Day
by Peter 01 Oct '18

01 Oct '18

please find attached the program of the Silver Jubilee Open LDAP Developper's Day. Last minute registration at odd-silverjubilee(a)daasi.de ist still possible. Cheers Peter -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 407109-0 Europaplatz 3 Fax: +49 7071 407109-9 D-72072 Tübingen mail: peter.gietz(a)daasi.de Germany Web: www.daasi.de DAASI International GmbH, Tübingen Geschäftsführer Peter Gietz, Amtsgericht Stuttgart HRB 382175 Directory Applications for Advanced Security and Information Management _______________________________________________________________________

1 0

issues with equality matching and slapd death
by Christopher Paul 28 Sep '18

28 Sep '18

Hello Fellow OpenLDAP Techs, I'm having an issue with equality matching and slapd death (just another day in the life of an LDAP guy...). version info: OpenLDAP: slapd 2.4.44 Red Hat Enterprise Linux Server release 7.5 (Maipo) RH package: openldap-servers-2.4.44-15.el7_5.x86_64 While planning for a migration, I ran into the following error: $ ldapmodify -x -y ~/.ldappw dn: uid=cs5555,ou=testPrimary,ou=mailhosts,dc=test,dc=com changetype: modify add: mailAlternateAddress mailAlternateAddress: cs5555(a)test.com [CTRL-D] modifying entry "uid=cs5555,ou=testPrimary,ou=mailhosts,dc=test,dc=com" ldap_modify: Inappropriate matching (18) additional info: modify/add: mailAlternateAddress: no equality matching rule I tried to fix this by updating the schema to add "EQUALITY caseIgnoreMatch" to the attribute definition for mailAlternateAddress. dn: cn={5}inetLocalMailRecipient,cn=schema,cn=config objectClass: olcSchemaConfig cn: {5}inetLocalMailRecipient olcAttributeTypes: {0}( 2.16.840.1.113730.3.1.24 NAME 'mailRoutingAddress' DES C 'iPlanet defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORI GIN 'iPlanet Messaging Server' ) olcAttributeTypes: {1}( 2.16.840.1.113730.3.1.18 NAME 'mailHost' DESC 'iPlanet defined attribute type' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'iPlan et Messaging Server' ) olcAttributeTypes: {2}( 2.16.840.1.113730.3.1.13 NAME 'mailAlternateAddress' D ESC 'iPlanet defined attribute type'EQUALITY caseIgnoreMatchSYNTAX 1.3.6.1. 4.1.1466.115.121.1.15 X-ORIGIN 'iPlanet Messaging Server' ) olcObjectClasses: {0}( 2.16.840.1.113730.3.2.4 NAME 'inetLocalMailRecipient' D ESC 'iPlanet defined objectclass' AUXILIARY MAY ( mailAlternateAddress $ mail Host $ mailRoutingAddress ) X-ORIGIN 'iPlanet Messaging Server' ) Now, after the schema change, the same ldapmodify kills slapd. $ ldapmodify -x -y ~/.ldappw dn: uid=cs5555,ou=testPrimary,ou=mailhosts,dc=test,dc=com changetype: modify add: mailAlternateAddress mailAlternateAddress: cs5555(a)test.com modifying entry "uid=cs5555,ou=testPrimary,ou=mailhosts,dc=test,dc=com" ldap_result: Can't contact LDAP server (-1) Trying this with slapd running with olcLogLevel=-1, I get the following output before slapd death: Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: connection_get(11) Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: connection_get(11): got connid=1008 Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: connection_read(11): checking for input on id=1008 Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: op tag 0x60, time 1537906659 Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: conn=1008 op=0 do_bind Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: >>> dnPrettyNormal: <cn=manager,dc=test,dc=com> Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: <<< dnPrettyNormal: <cn=manager,dc=test,dc=com>, <cn=manager,dc=test,dc=com> Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: conn=1008 op=0 BIND dn="cn=manager,dc=test,dc=com" method=128 Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: do_bind: version=3 dn="cn=manager,dc=test,dc=com" method=128 Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: ==> hdb_bind: dn: cn=manager,dc=test,dc=com Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: conn=1008 op=0 BIND dn="cn=manager,dc=test,dc=com" mech=SIMPLE ssf=0 Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: do_bind: v3 bind: "cn=manager,dc=test,dc=com" to "cn=manager,dc=test,dc=com" Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: send_ldap_result: conn=1008 op=0 p=3 Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: send_ldap_result: err=0 matched="" text="" Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: send_ldap_response: msgid=1 tag=97 err=0 Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: conn=1008 op=0 RESULT tag=97 err=0 text= Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: daemon: activity on 1 descriptor Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: daemon: activity on: Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal slapd[22363]: daemon: epoll: listen=9 active_threads=0 tvp=NULL Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal systemd[1]: slapd.service: main process exited, code=killed, status=6/ABRT Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal systemd[1]: Unit slapd.service entered failed state. Sep 25 20:17:39 ip-172-31-94-0.ap-south-1.compute.internal systemd[1]: slapd.service failed. Does anyone have any insight into this issue? somehow I've never run into this one before. Many thanks, CP -- Rex ConsultingChris Paul Rex Consulting, Inc 5652 Florence Terrace, Oakland, CA 94611 email: chris.paul(a)rexconsulting.net web: http://www.rexconsulting.net phone, toll-free: +1 (888) 403-8996 ext 1 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Rex Consulting, Inc. has been a California Corporation since 2001.

6 22

Re: slapo-memberof and Replication
by Dave Macias 28 Sep '18

28 Sep '18

> > It means that you run it in a replicated environment at your own risk. > Unfortunately, there is no defined standard for the "memberOf" > functionality (it's a MS hack) and so there's nothing that details how it > should or shouldn't behave with replication. In general, things work fine > as long as: > Does the same apply to the rfc2307bis schema which gives your the groupOfMembers objectclass? Out of curiosity. Thanks!

2 1

olcTLSCACertificateFile and olcTLSCertificateFile displayed as encrypted?
by Jean-Francois Malouin 28 Sep '18

28 Sep '18

Hi, Not a very important question, just a little puzzled by this... Is there a reason why the olcTLSCACertificateFile and olcTLSCertificateFile paths show up as encrypted in this cn=config search? slapd 2.4.46 on Debian 9.5 (Stretch) ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b 'cn=config' -s base dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcLogLevel: stats olcLogLevel: sync olcPidFile: /var/run/slapd/slapd.pid olcServerID: 1 olcTLSCACertificateFile:: IC9ldGMvbGRhcC9zc2wvQ09NT0RPX0NBX2J1bmRsZS5jcnQ= olcTLSCertificateFile:: ICAgL2V0Yy9sZGFwL3NzbC9TVEFSX2JpY19tbmlfbWNnaWxsX2NhLmNydA== olcTLSCertificateKeyFile: /etc/ldap/ssl/STAR_bic_mni_mcgill_ca.key olcTLSCipherSuite: NORMAL olcTLSVerifyClient: allow olcToolThreads: 1 There is an extra ':' ... When I edit/display the cn=config with ldapvi (old fart here!) they show up as: olcTLSCACertificateFile:; /etc/ldap/ssl/COMODO_CA_bundle.crt olcTLSCertificateFile:; /etc/ldap/ssl/STAR_bic_mni_mcgill_ca.crt again, notice the ';' this time... Just curious! Thanks, jf

3 3

slapo-memberof and Replication
by Meike Stone 28 Sep '18

28 Sep '18

Hello, I need the memberof Attribute on users, and I configured it with the memberof overlay. Every thing ist working fine. I like to deploy a second server for redundancy reason., but the manual page of the overlay says: " .. Replica servers should be configured with their own instances of the memberOf overlay if it is desired to maintain these memberOf attributes on the replicas. Note that slapo-memberOf is not compatible with syncrepl based replication, and should not be used in a replicated environment. ..." That confuses me a little bit. All replication on openLDAP are based on syncreplication (slurpd is vanished a long time ago) So what kind of replication means the manual page (-> "Replica servers")? Thanks Meike

2 1

SASL EXTERNAL olcRootDN and ACLs
by linux nuse 28 Sep '18

28 Sep '18

https://www.openldap.org/doc/admin24/access-control.html says: Regardless of what access control policy is defined, the rootdn is always allowed full rights (i.e. auth, search, compare, read and write) on everything and anything. As a consequence, it's useless (and results in a performance penalty) to explicitly list the rootdn among the <by> clauses. "Well", said I and set olcRootDN to gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth. Then I've tried to add an entry with $ sudo ldapadd -Y EXTERNAL -H ldapi:/// .... and OpenLDAP told that I don't have permission to modify the DB. I had to grant gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth access to everything in the backend's ACL to make it working. Is it expected that gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth rootdn does not have full rights without explicit permission or I need to recheck because I could get something wrong (didn't restart slapd or something like that)?

2 3

RE: Restarting syncrepl based provider / consumer setup trawls through whole DIT - why?
by Ole Nomann Thomsen 26 Sep '18

26 Sep '18

> --On Monday, September 24, 2018 2:51 PM +0000 Ole Nomann Thomsen > <ole.nomann(a)stil.dk> wrote: > > > 2018-09-12T16:25:41.526574+02:00 nonpresent_callback: rid=001 present > > UUID 9b99ec5a-4cfe-1029-9a2e-80309636f032, dn > > ou=Authentication,o=UNI-C,c=DK > > This is the presence phase. > > > > I'm guessing that that the Consumer is looking up every entry to decide > > if it has changed. > > It is confirming each entry is still present (not deleted). > > > > But why is it not persistent? Am a missing some obvious explanation as to > > why this is not possible, or have I just misconfigured something? Any > > hints where I should look? > > > > Is there a better way to set up replication to avoid this? > > a) Use delta-syncrepl > b) Ensure you have a large sessionlog setting (See ITS#8125, ITS#8486) > > Warm regards, > Quanah Thanks - You too. In my case, the present-phase is not really useful, since this particulat ldap-instance only ever adds and modifies entries, never deletes. Would it then be possible to skip it ? - Ole.

2 1

Slapd generate SQL by PostgreSQL based syntax
by 横山善行 25 Sep '18

25 Sep '18

Hi I use openldap slapd 2.4.40 + MySQL5.5 as back-sql on CentoS 6.9 It seems slapd generate PostgreSQL based syntax SQL Here is the error message for ldapsearch -x -b "dc=example,dc=com" '(objectClass=*)' 5b70e25c <==backsql_srch_query() returns SELECT DISTINCT ldap_entries.id,eduperson.id,text('inetOrgPerson') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,eduperson WHERE eduperson.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND 3=3 5b70e25c Constructed query: SELECT DISTINCT ldap_entries.id,eduperson.id,text('inetOrgPerson') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,eduperson WHERE eduperson.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND 3=3 5b70e25c id: '3' 5b70e25c backsql_oc_get_candidates(): error executing query 5b70e25c Return code: -1 5b70e25c nativeErrCode=1064 SQLengineState=37000 msg="[unixODBC][MySQL][ODBC 5.1 Driver][mysqld-5.5.57]You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '('inetOrgPerson') AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,edupers' at line 1" 5b70e25c send_ldap_result: conn=1000 op=1 p=3 5b70e25c send_ldap_result: err=80 matched="" text="" 5b70e25c send_ldap_response: msgid=2 tag=101 err=80 I take same message as I execute below from MySQL console. I can see text('inetOrgPerson') in the SQL which was generated by slapd however,MySQL doesn’t support text() function in its SQL. When I use Postgeresql as back-sql it works properly Is it a bug or setting error for some directives? ######################################### 一般財団法人日本建設情報総合センター（JACIC:ジャシック）建設副産物・発生土情報交換システム担当　国際土木委員会　事務局担当　　システムエンジニアリング部　横山　善行　電話　03-3505-2661　 FAX 03-3589-6258 mail yokoyamy(a)jacic.or.jp ########################################

1 0

How to make ldap evaluate clear text password vs DES stored password
by yokoyamy＠jacic.or.jp 25 Sep '18

25 Sep '18

Hi. I have user information in RDB which include user-id and password set. I’ve been trying to use this RDB as backend database for openldap server. Now,I can find user information in RDB through openldap. However, I recognized I can’t use this user information for ldap login certification process. LDAP’s userPassowrd stored in the RDB has been already DES hashed by original app. On the other hand, input password from ldapseach command line is CREARTEXT. Now I’d like my openldap to change CREATEXT input password into DES hassed text so that they'll match for certification. I've asked this topic on stackoverflow web site how to do that by server settings.But I couldn’t find proper directives to set. How to make ldap evaluate clear text password vs DES stored password Since then,I’ve been searching LDAP source files which is matching input password from ldapsearch command line against userPassword stored in backend RDB for slapd. I’d like to change certification process of LDAP source file to make input password into DES hashed by using 2 characters of userPassword as its SALT. I've already known that 2 characters at the beginning of userPasswordwas used as its SALT when it was hashed. So the fact is ,my slapd can read userPassword from the RDB. I think I'll be able to find out what will be SALT to make input password into DES hashed text. If I can make opeldap to act this way,I can use user's infomation in the RDB to ldap login inforomation wiht seamless.

5 15

Restarting syncrepl based provider / consumer setup trawls through whole DIT - why?
by Ole Nomann Thomsen 24 Sep '18

24 Sep '18

Hi, my problem is this: Whenever I restart a Consumer in our single-provider, multi-consumer syncrepl setup, type=refreshAndPersist (OpenLdap 2.4.45), It spends about half an hour running through the whole DIT (about 5.5 million entries), doing this for each: 2018-09-12T16:25:41.526574+02:00 nonpresent_callback: rid=001 present UUID 9b99ec5a-4cfe-1029-9a2e-80309636f032, dn ou=Authentication,o=UNI-C,c=DK I'm guessing that that the Consumer is looking up every entry to decide if it has changed. This has the unfortunate effect that the Consumer is deemed out-of-sync in the timespan (referring to the contextCSN in the root entry), even if only one entry has actually changed in the master. And it cannot be let back into the serverfarm before it is synchronized, thus making every restart of a Consumer require at least 30 mins downtime for that Consumer. If I read the docs correctly (https://www.openldap.org/doc/admin24/replication.html), there should be a synchronization cookie set after the refresh stage (and during the persist-stage). It looks to me like at least in my case, that cookie is not persistent - it seems that when the Consumer is restarted, this cookie is either lost or reset, causing the whole DIT to be read, and not just those entries, younger than the cookie. But why is it not persistent? Am a missing some obvious explanation as to why this is not possible, or have I just misconfigured something? Any hints where I should look? Is there a better way to set up replication to avoid this? Thanks - Ole N Thomsen

2 1

Trigger-like function
by Ervin Hegedüs 24 Sep '18

24 Sep '18

Hi, as I described in my previous thread[1], I have a web frontend tool, where user can modify its own password - here the password is a set of passwd attributes: userPassword, sambaNTPassword, sambaLMPassword. Is there any way that when I give access to users to modify its own password, and the user wants to modify it through LDAP(S), instead of out web frontend, the samba passwords also updated (with correct hash algorithm)? I've found that the password policy and history should handle inside of OpenLDAP, only this feature missing. I've also found slapo-shell and slapo-sock overlays, but as I interpret those mechanism, they sends the client request to an external software, so when I want to change the userPassword, the slapd send this request to the external tool, which sends a modify request to slapd, which sends the request to external tool, whcih.... Em I right? Or should I use some filter to exclude, which requests sending to external program and which not? Is there any solution for this request? Thanks, a. [1]: https://www.openldap.org/lists/openldap-technical/201809/msg00021.html

3 6

A couple of questions regarding replication and user mapping
by Karsten Heymann 21 Sep '18

21 Sep '18

Hi, I'm having a rough week as a long planned ldap migration this week went semi-bad, in that we noticed a good day after the new cluster went productive that both masters and both clients started to diverge data-wise. I'm still sorting out the details, but while troubleshooting some questions arose already. (I'm running 2.4.46+dfsg-5~bpo9+1 on debian 9 with two masters (syncrepl, mirror mode) behind a load balancer and two slaves, also behind a load balancer. I was authenticating the replication with client certificates, but had to switch back to simple bind usind rootdn/rootpw als sync credentials to rule out any acl problems causing our problems.) 1. I've read in an older debian bug report, that changing olcAuthRegexp requires a slapd restart in order to be effective. Is that still the case? If yes, could this *please* be added to the manpage and the documentation? Pretty please? 2. Is ldapwhoami supposed to also print out the result of a authz-regexp mapping? 3. The slapd.conf manpage mentions: "The replaced name can be either a DN, i.e. a string prefixed by "dn:", or an LDAP URI." Is prepending dn: really required? The examples on https://www.openldap.org/doc/admin24/sasl.html don't have it. 4. What happens when a lot of concurrent writes happen to two masters configured in mirror mode? We had a loadbalancer misconfiguration and the loadbalancers were using simple round robin to write to the masters. Can this result in diverging content on the two masters? 5. At one time we had diverging content on both masters for the same entries, probably due to a broken acl config that did not allow the sync user to see all alltributes on the other master. Is there any way to cause a "re-sync" of an entry without actually changing data on the entry? The only way I found was to use slapd -c, but And finally not a question, but a recommendation for anyone in a similiar situation: The ldifdiff-tool (https://github.com/nxadm/ldifdiff) proved extremely valuable in sorting out the mess and understanding what actually was the situation data-wise between the systems. Best regards Karsten

6 6

Password policy questions
by Ervin Hegedüs 20 Sep '18

20 Sep '18

Hi, looks like I've successfully configured the ppolicy overlay, but I have some questions. The relevant config: olcModuleLoad: {0}ppolicy structuralObjectClass: olcModuleList dn: olcOverlay={2}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {2}ppolicy olcPPolicyDefault: cn=default,ou=pwpolicies,dc=hu olcPPolicyHashCleartext: FALSE olcPPolicyUseLockout: FALSE dn: cn=default,ou=pwpolicies,dc=hu cn: default objectClass: pwdPolicy objectClass: pwdPolicyChecker objectClass: device pwdAllowUserChange: TRUE pwdInHistory: 5 pwdMinLength: 10 pwdAttribute: userPassword pwdCheckQuality: 0 When I change my passwd with ldappasswd, the history check works: ldappasswd -H ldaps://dev-ldap-01:636 -W -D uid=airween,ou=Users,ou=company,dc=comp,DC=hu -S New password: Re-enter new password: Enter LDAP Password: Result: Constraint violation (19) Additional info: Password is in history of old passwords but I can set up new password with less than 10 characters, eg "abc". What em I missed? I've never read it, but looks like the policy has effect only when I'm changing passwd with 'ldappasswd', but when I'm using ldapmodify, then I can bypass the rules ldapmodify -H ldaps://dev-ldap-01:636 -D 'uid=airween,ou=Users,ou=company,dc=comp,dc=hu' -x -W -f file.ldif modifying entry "uid=airween,ou=Users,ou=company,dc=comp,DC=hu" [DONE WITH PREV PASSWD] Is it right? How can I validate the policy for all methods? Thanks, a.

3 4

Worse search performance on a branch than at the tree base
by Glover, Matthew 19 Sep '18

19 Sep '18

I'm having a performance problem with searches on a branch and I'm hoping someone can explain it. A search for "(uid=12345)" on basedn "dc=example,dc=com" with a subtree scope returns much more quickly than the same filter and scope on basedn "ou=People,dc=example,dc=com". To confirm this wasn't just a problem with my schema or configuration, I loaded Ubuntu 18 (slapd 2.4.45+dfsg-1ubuntu1), used ldctl to generate 100,000 inetOrgPerson records with uids from 00000 to 99999, loaded them in with ldapadd, then used ldctl to test performance of searches: Both tests were scope subtree, 20 seconds, hitting the test server as fast as possible with randomly generated filters of "(uid=<random uid from 00000 to 99999>)". basedn: dc=example,dc=com - 5455.30/sec - total: 109106 successful searches basedn: ou=People,dc=example,dc=com - 198.80/sec - total: 3976 successful searches Also, while testing against ou=People, the CPU load from slaps went through the roof. It feels rather like the index isn’t being used when the base isn’t the root. I can provide the ldif of my test users and the parameters I used for ldctl tests if desired. Thanks for any help you can offer, Matthew

2 2

groupOfMembers doesn't work with memberOf overlay
by tran dung 19 Sep '18

19 Sep '18

Hi I am using groupOfNames and memberOf overlay works fine. However, groupOfNames requires "member" attribute so in case a group doesn't have a member, I have to use a dummy user. Since groupOfMembers doesn't require "member" attribute, I replaced groupOfNames by groupOfMembers in ldif file and re-built ldap server. However, when I delete member attribute, corresponding menberOf isn't deleted. When I add member attribute, memberOf isn't added. Is this expected behavior of groupOfMembers or is something missing in memberOf overlay setting? Here is my memberOf overlay setting ------------------------------------- # Memberof overlay overlay memberof memberof-dangling drop memberof-refint true ------------------------------------- Best Regards ----------------------- Tran Dung

2 2

Insufficient acces in some cases
by Ervin Hegedüs 19 Sep '18

19 Sep '18

Hi, there is an interesting insufficient access problem... There are 3 (in dev environment 2) multimaster ldap node. There is a simple web frontend, written in PHP, where user can change its own password, or can get a link to set up a new pass if old one had lost. In some cases (some users) the user can't change the own password through PHP. When I change it from webserver with ldapmodify and a simple ldif file, it works as well. But when I try to modify the passwd through PHP, I got "Insufficient access" error, and these lines are in syslog: Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => access_allowed: search access to "uid=comp1_user1,ou=Users,ou=COMP1,dc=wificloud,dc=company,dc=hu" "objectClass" requested Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => dn: [2] ou=djp,dc=wificloud,dc=company,dc=hu Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => dnpat: [3] ou=(AH|Delta|Comp1|Comp2|Comp3),dc=wificloud,dc=company,dc=hu nsub: 1 Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => acl_get: [3] matched Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => acl_get: [3] attr objectClass Sep 18 17:48:13 dev-ldap-01 slapd[12125]: => match[dn0]: 26 60 Sep 18 17:48:13 dev-ldap-01 slapd[12125]: o Sep 18 17:48:13 dev-ldap-01 slapd[12125]: u Sep 18 17:48:13 dev-ldap-01 slapd[12125]: = Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: o Sep 18 17:48:13 dev-ldap-01 slapd[12125]: m Sep 18 17:48:13 dev-ldap-01 slapd[12125]: p Sep 18 17:48:13 dev-ldap-01 slapd[12125]: 1 Sep 18 17:48:13 dev-ldap-01 slapd[12125]: , Sep 18 17:48:13 dev-ldap-01 slapd[12125]: d Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: = Sep 18 17:48:13 dev-ldap-01 slapd[12125]: w Sep 18 17:48:13 dev-ldap-01 slapd[12125]: i Sep 18 17:48:13 dev-ldap-01 slapd[12125]: f Sep 18 17:48:13 dev-ldap-01 slapd[12125]: i Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: l Sep 18 17:48:13 dev-ldap-01 slapd[12125]: o Sep 18 17:48:13 dev-ldap-01 slapd[12125]: u Sep 18 17:48:13 dev-ldap-01 slapd[12125]: d Sep 18 17:48:13 dev-ldap-01 slapd[12125]: , Sep 18 17:48:13 dev-ldap-01 slapd[12125]: d Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: = Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: o Sep 18 17:48:13 dev-ldap-01 slapd[12125]: m Sep 18 17:48:13 dev-ldap-01 slapd[12125]: p Sep 18 17:48:13 dev-ldap-01 slapd[12125]: a Sep 18 17:48:13 dev-ldap-01 slapd[12125]: n Sep 18 17:48:13 dev-ldap-01 slapd[12125]: y Sep 18 17:48:13 dev-ldap-01 slapd[12125]: , Sep 18 17:48:13 dev-ldap-01 slapd[12125]: d Sep 18 17:48:13 dev-ldap-01 slapd[12125]: c Sep 18 17:48:13 dev-ldap-01 slapd[12125]: = Sep 18 17:48:13 dev-ldap-01 slapd[12125]: h Sep 18 17:48:13 dev-ldap-01 slapd[12125]: u Sep 18 17:48:13 dev-ldap-01 slapd[12125]: (I replaced names and chars, so the match[dn0] numbers are not correct). Only few users can trigger this problem (don't know why), and only through PHP. What's the problem here? Thanks, a.

2 7

Re: Re: OpenLDAP instances crashes
by Saurabh Lahoti 17 Sep '18

17 Sep '18

Hi, Tried with the clone command & received below error: Initialized empty Git repository in /usr/app/ldap/ReOpenLDAP-mobiuniquemember/ReOpenLDAP/.git/ error: while accessing https://github.com/leo-yuriev/ReOpenLDAP.git/info/refs fatal: HTTP request failed What could be wrong here from my side..? ---- *Thanks & Kind Regards,* Saurabh LAHOTI. *Ideas enlighten Innovation**!!!* Please consider the environment before printing this mail..!! On Fri, 14 Sep 2018 at 12:19, Леонид Юрьев <leo(a)yuriev.ru> wrote: > Hi, Saurbh. > > I apologize, long time did not answer, was off-line. > But there would be no problem if you did everything exactly as I wrote. > > Once again: > git clone https://github.com/leo-yuriev/ReOpenLDAP.git -b > mobiuniquemember > cd ReOpenLDAP > ./bootstrap.sh > ./configure --enable-contrib --prefix=... [other relevant options...] > make > make install > > On the other hand, building from the source requires certain competencies. > For instance, you should be known about all implicit (git, make, > autotools, gcc, binutils...) pre-requirements tools and packages/libraries, > and be able to install it. > Also you should known about `configure` and about corresponding options. > > Leonid. > > > пт, 14 сент. 2018 г. в 12:40, Saurabh Lahoti <saurabh.astronomy(a)gmail.com > >: > >> Many thanks Brian for your kind help. >> >> Tried with the command mentioned, below is the output: >> >> root@souslik # sh -x ./bootstrap.sh >> + '[' '' = --dont-cleanup ']' >> + rm -rf '/usr/app/ldap/LdapTest/*' >> + git clean -x -f -d -e tests/testrun -e releasenotes.txt >> fatal: Not a git repository (or any of the parent directories): .git >> + failure cleanup >> + echo 'Oops, cleanup failed ;(' >> Oops, cleanup failed ;( >> + exit 2 >> >> Could you please guide further on this..? >> ---- >> >> *Thanks & Kind Regards,* >> Saurabh LAHOTI. >> *Mob: +32.499.82.37.88* >> *Ideas enlighten Innovation**!!!* >> Please consider the environment before printing this mail..!! >> >> >> >> >> >> On Thu, 13 Sep 2018 at 23:56, Brian Reichert <reichert(a)numachi.com> >> wrote: >> >>> On Thu, Sep 13, 2018 at 10:12:34PM +0200, Saurabh Lahoti wrote: >>> > Dear, >>> > >>> > What does below error mean..? >>> > >>> > fatal: Not a git repository (or any of the parent directories): .git >>> > Oops, cleanup failed ;( >>> > >>> > While running bootstrap.sh, above mentioned error was interpreted. >>> >>> I think the source for 'bootstrap.sh' is here: >>> >>> https://github.com/leo-yuriev/ReOpenLDAP/blob/master/bootstrap.sh >>> >>> I only see one invocation of 'git' in that script, and I don't see >>> why that would fail. >>> >>> Try running >>> >>> sh -x ./bootstrap.sh >>> >>> That will show the commands the script is running; they may provide >>> a clue as to what command was being run, and with what arguments. >>> >>> > ---- >>> > >>> > *Thanks & Kind Regards,* >>> > Saurabh LAHOTI. >>> > *Ideas enlighten Innovation**!!!* >>> > Please consider the environment before printing this mail..!! >>> > >>> > >>> > >>> > >>> > >>> > On Thu, 30 Aug 2018 at 08:04, Ulrich Windl < >>> > Ulrich.Windl(a)rz.uni-regensburg.de> wrote: >>> > >>> > > >>> Saurabh Lahoti <saurabh.astronomy(a)gmail.com> schrieb am >>> 29.08.2018 um >>> > > 14:45 >>> > > in >>> > > Nachricht >>> > > <CAB5-Mqq2Epvoz-U_=1zNoz-JVSE9e5mu=MWemjyTEM7QuXaZDQ(a)mail.gmail.com >>> >: >>> > > > Dear Leo, >>> > > > >>> > > > We tried the steps mentioned below using the ReOpenLDAP package >>> provided >>> > > by >>> > > > you. >>> > > > >>> > > > But, we're start at the very first step while running bootstrap.sh >>> & >>> > > > encountered below errors: >>> > > > >>> > > > root@pygarg # ./bootstrap.sh >>> > > > ./bootstrap.sh: line 39: git: command not found >>> > > > Oops, cleanup failed ;( >>> > > >>> > > I wonder: How could you "git clone" without git? >>> > > >>> > > > >>> > > > >>> > > > Could you please guide us further into this..? >>> > > > >>> > > > ---- >>> > > > >>> > > > *Thanks & Kind Regards,* >>> > > > Saurabh LAHOTI. >>> > > > *Ideas enlighten Innovation**!!!* >>> > > > Please consider the environment before printing this mail..!! >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > On Thu, 23 Aug 2018 at 23:17, ???????????? ?????????? < >>> leo(a)yuriev.ru> wrote: >>> > > > >>> > > >> Hi, Saurabh. >>> > > >> >>> > > >> Your custom overlay "mobiuniquemember" now intergated into >>> ReOpenLDAP >>> > > >> (mobiuniquemember branch). >>> > > >> Please check it: >>> > > >> >>> > > >> git clone https://github.com/leo-yuriev/ReOpenLDAP.git -b >>> > > mobiuniquemember >>> > > >> cd ReOpenLDAP >>> > > >> ./bootstrap.sh >>> > > >> ./configure --enable-contrib [other relevan options] >>> > > >> make install >>> > > >> >>> > > >> Regards, >>> > > >> Leonid. >>> > > >> >>> > > >> >>> > > >> ????, 22 ??????. 2018 ??. ?? 18:04, ???????????? ?????????? < >>> leo(a)yuriev.ru>: >>> > > >> >>> > > >>> You could submit source code of your custom overlay to >>> > > >>> https://github.com/leo-yuriev/ReOpenLDAP, i.e. pull-request >>> into the >>> > > >>> 'devel' branch. >>> > > >>> >>> > > >>> Then I will try fix it and merge-in, in success case you will be >>> able >>> > > to >>> > > >>> build and use it with ReOpenLDAP. >>> > > >>> >>> > > >>> >>> > > >>> Regards, >>> > > >>> Leonid. >>> > > >>> >>> > > >>> ????, 22 ??????. 2018 ??., 17:37 Saurabh Lahoti < >>> saurabh.astronomy(a)gmail.com >>> > > >: >>> > > >>> >>> > > >>>> Dear, >>> > > >>>> >>> > > >>>> What is you're recommendation to fix this problem on our >>> side..? It's >>> > > >>>> been haunting our operational activities on daily basis.. ?????? >>> > > >>>> ---- >>> > > >>>> >>> > > >>>> *Thanks & Kind Regards,* >>> > > >>>> Saurabh LAHOTI. >>> > > >>>> *Mob: +32.499.82.37.88* >>> > > >>>> *Ideas enlighten Innovation**!!!* >>> > > >>>> Please consider the environment before printing this mail..!! >>> > > >>>> >>> > > >>>> >>> > > >>>> >>> > > >>>> >>> > > >>>> >>> > > >>>> On Fri, 17 Aug 2018 at 16:43, Brian Reichert < >>> reichert(a)numachi.com> >>> > > >>>> wrote: >>> > > >>>> >>> > > >>>>> On Thu, Aug 16, 2018 at 02:00:20PM +0200, Saurabh Lahoti wrote: >>> > > >>>>> > Dear, >>> > > >>>>> > >>> > > >>>>> > Today, received below error in /var/log/messages with >>> OpenLDAP >>> > > >>>>> instance >>> > > >>>>> > crashing. >>> > > >>>>> >>> > > >>>>> That looks like either: >>> > > >>>>> >>> > > >>>>> - You have a bad SIM (very unlikely) >>> > > >>>>> - You have a corrupted uniquemember.so.0.0.0 shared library. >>> > > >>>>> - You may have conflated OpenLDAP packages installed that have >>> a >>> > > >>>>> critical >>> > > >>>>> incompatibility amidst the installed binaries/libraries. >>> > > >>>>> >>> > > >>>>> It did write a core file; there are many tutorials about >>> exploring >>> > > >>>>> a core file to help understand why the segfault occurred. >>> > > >>>>> >>> > > >>>>> > >>> > > >>>>> > Aug 16 13:21:07 muledeer kernel: slapd[29253]: segfault at 0 >>> ip >>> > > >>>>> > 00007fbeddf3af09 sp 00007fb72effc480 error 4 in >>> > > >>>>> > uniquemember.so.0.0.0[7fbeddf3a000+2000] >>> > > >>>>> > Aug 16 13:21:08 muledeer abrt[24629]: Saved core dump of pid >>> 16470 >>> > > >>>>> > (/usr/app/ldap/openldap2.4.46/libexec/slapd) to >>> > > >>>>> > /var/spool/abrt/ccpp-2018-08-16-13:21:07-16470 (472973312 >>> bytes) >>> > > >>>>> > Aug 16 13:21:08 muledeer abrtd: Directory >>> > > >>>>> 'ccpp-2018-08-16-13:21:07-16470' >>> > > >>>>> > creation detected >>> > > >>>>> > Aug 16 13:21:08 muledeer abrtd: Executable >>> > > >>>>> > '/usr/app/ldap/openldap2.4.46/libexec/slapd' doesn't belong >>> to any >>> > > >>>>> package >>> > > >>>>> > and ProcessUnpackaged is set to 'no' >>> > > >>>>> > Aug 16 13:21:08 muledeer abrtd: 'post-create' on >>> > > >>>>> > '/var/spool/abrt/ccpp-2018-08-16-13:21:07-16470' exited with >>> 1 >>> > > >>>>> > Aug 16 13:21:08 muledeer abrtd: Deleting problem directory >>> > > >>>>> > '/var/spool/abrt/ccpp-2018-08-16-13:21:07-16470' >>> > > >>>>> > >>> > > >>>>> > >>> > > >>>>> > Could you please guide us in finding probable root of this >>> error..? >>> > > >>>>> > ---- >>> > > >>>>> > >>> > > >>>>> > *Thanks & Kind Regards,* >>> > > >>>>> > Saurabh LAHOTI. >>> > > >>>>> > *Ideas enlighten Innovation**!!!* >>> > > >>>>> > Please consider the environment before printing this mail..!! >>> > > >>>>> >>> > > >>>>> -- >>> > > >>>>> Brian Reichert <reichert(a)numachi.com> >>> > > >>>>> BSD admin/developer at large >>> > > >>>>> >>> > > >>>> >>> > > >>> > > >>> > > >>> > > >>> >>> -- >>> Brian Reichert <reichert(a)numachi.com> >>> BSD admin/developer at large >>> >>

1 0

Re: OpenLDAP instances crashes
by Saurabh Lahoti 14 Sep '18

14 Sep '18

Dear Leo, We tried the steps mentioned below using the ReOpenLDAP package provided by you. But, we're start at the very first step while running bootstrap.sh & encountered below errors: root@pygarg # ./bootstrap.sh ./bootstrap.sh: line 39: git: command not found Oops, cleanup failed ;( Could you please guide us further into this..? ---- *Thanks & Kind Regards,* Saurabh LAHOTI. *Ideas enlighten Innovation**!!!* Please consider the environment before printing this mail..!! On Thu, 23 Aug 2018 at 23:17, Леонид Юрьев <leo(a)yuriev.ru> wrote: > Hi, Saurabh. > > Your custom overlay "mobiuniquemember" now intergated into ReOpenLDAP > (mobiuniquemember branch). > Please check it: > > git clone https://github.com/leo-yuriev/ReOpenLDAP.git -b mobiuniquemember > cd ReOpenLDAP > ./bootstrap.sh > ./configure --enable-contrib [other relevan options] > make install > > Regards, > Leonid. > > > ср, 22 авг. 2018 г. в 18:04, Леонид Юрьев <leo(a)yuriev.ru>: > >> You could submit source code of your custom overlay to >> https://github.com/leo-yuriev/ReOpenLDAP, i.e. pull-request into the >> 'devel' branch. >> >> Then I will try fix it and merge-in, in success case you will be able to >> build and use it with ReOpenLDAP. >> >> >> Regards, >> Leonid. >> >> ср, 22 авг. 2018 г., 17:37 Saurabh Lahoti <saurabh.astronomy(a)gmail.com>: >> >>> Dear, >>> >>> What is you're recommendation to fix this problem on our side..? It's >>> been haunting our operational activities on daily basis.. 😓 >>> ---- >>> >>> *Thanks & Kind Regards,* >>> Saurabh LAHOTI. >>> *Mob: +32.499.82.37.88* >>> *Ideas enlighten Innovation**!!!* >>> Please consider the environment before printing this mail..!! >>> >>> >>> >>> >>> >>> On Fri, 17 Aug 2018 at 16:43, Brian Reichert <reichert(a)numachi.com> >>> wrote: >>> >>>> On Thu, Aug 16, 2018 at 02:00:20PM +0200, Saurabh Lahoti wrote: >>>> > Dear, >>>> > >>>> > Today, received below error in /var/log/messages with OpenLDAP >>>> instance >>>> > crashing. >>>> >>>> That looks like either: >>>> >>>> - You have a bad SIM (very unlikely) >>>> - You have a corrupted uniquemember.so.0.0.0 shared library. >>>> - You may have conflated OpenLDAP packages installed that have a >>>> critical >>>> incompatibility amidst the installed binaries/libraries. >>>> >>>> It did write a core file; there are many tutorials about exploring >>>> a core file to help understand why the segfault occurred. >>>> >>>> > >>>> > Aug 16 13:21:07 muledeer kernel: slapd[29253]: segfault at 0 ip >>>> > 00007fbeddf3af09 sp 00007fb72effc480 error 4 in >>>> > uniquemember.so.0.0.0[7fbeddf3a000+2000] >>>> > Aug 16 13:21:08 muledeer abrt[24629]: Saved core dump of pid 16470 >>>> > (/usr/app/ldap/openldap2.4.46/libexec/slapd) to >>>> > /var/spool/abrt/ccpp-2018-08-16-13:21:07-16470 (472973312 bytes) >>>> > Aug 16 13:21:08 muledeer abrtd: Directory >>>> 'ccpp-2018-08-16-13:21:07-16470' >>>> > creation detected >>>> > Aug 16 13:21:08 muledeer abrtd: Executable >>>> > '/usr/app/ldap/openldap2.4.46/libexec/slapd' doesn't belong to any >>>> package >>>> > and ProcessUnpackaged is set to 'no' >>>> > Aug 16 13:21:08 muledeer abrtd: 'post-create' on >>>> > '/var/spool/abrt/ccpp-2018-08-16-13:21:07-16470' exited with 1 >>>> > Aug 16 13:21:08 muledeer abrtd: Deleting problem directory >>>> > '/var/spool/abrt/ccpp-2018-08-16-13:21:07-16470' >>>> > >>>> > >>>> > Could you please guide us in finding probable root of this error..? >>>> > ---- >>>> > >>>> > *Thanks & Kind Regards,* >>>> > Saurabh LAHOTI. >>>> > *Ideas enlighten Innovation**!!!* >>>> > Please consider the environment before printing this mail..!! >>>> >>>> -- >>>> Brian Reichert <reichert(a)numachi.com> >>>> BSD admin/developer at large >>>> >>>

3 4

Failed to create more than 1024 LMDB environment objects
by Jeremy Chen 12 Sep '18

12 Sep '18

Hi I have been using lmdb (with java binding on Ubuntu 14.04+, or Centos 7) to manage daily data sets for a while and so far it works beautifully. Now I am trying to add multi-tenancy support with physical partitioning, but fails to create more than 1024 environments (1017 to be exact). The error msg is "Resource temporarily unavailable" (not sure if it's accurate since it's from the lmdbjni binding), and it will only generate a lock.mdb of 0 length in the failed environment. I tuned a few parameters, like reducing the map size to a few MB each, etc, but to no avail. Is this a hard limit? Or I could change something in lmdb source code to extend it? Thank you very much! Jeremy

1 1

multiple syncrepl statements for partial DIT replication
by Manuela Mandache 11 Sep '18

11 Sep '18

Hi, I just subscribed to ask this question, I found no answer in the archives - sorry if I haven't looked well enough. There are three branches in the DIT on the provider and only two of them must be replicated to the consumers. Can this be done by defining two syncrepl statements on the consumers, one for each branch to be replicated and each one having a different rid? I run OpenLDAP 2.4.40 on CentOS 7. I know this result can be obtained by defining the right ACLs for the replication account on the provider and giving the parent of the three branches in the syncrepl statement, I was wondering if there are other ways of achieving it. Thank you, Manuela Mandache

2 1

Replication issue? Data is different between master and consumer with same entryCSNs
by Dave Steiner 10 Sep '18

10 Sep '18

I've been noticing various data discrepancies between our LDAP master and LDAP consumers. We are running OpenLDAP v2.4.44. We have two masters running "mirromode TRUE" and all updates go through a VIP that points to the first one unless it's not available (doesn't happen very often except for during patches and restarts). We have 13 consumers that replicate through that same VIP. Here's an example of our syncrepl for a client: syncrepl rid=221 type=refreshAndPersist schemachecking=on provider="ldap://ldapmastervip.rutgers.edu/" bindmethod=sasl saslmech=EXTERNAL starttls=yes tls_reqcert=demand tls_protocol_min="3.1" searchbase="dc=rutgers,dc=edu" attrs="*,+" retry="10 10 20 +" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog network-timeout=30 keepalive=180:3:60 I check the contextCSN attributes on all the instances every day and they are all in sync (except during any major changes, of course). But I occasionally notice discrepancies in the data.... even though the contextCSNs and entryCSNs are the same. For example (note hostnames have been changed): $ ldapsearch ... -H ldap://ldapmaster.rutgers.edu uid=XXXX postalAddress createTimestamp modifyTimestamp entryCSN dn: uid=XXXX,ou=People,dc=rutgers,dc=edu createTimestamp: 20121220100700Z postalAddress: Business And Science Bldg$227 Penn Street$Camden, NJ 081021656 entryCSN: 20180505002024.083133Z#000000#001#000000 modifyTimestamp: 20180505002024Z $ ldapsearch ... -H ldap://ldapconsumer3.rutgers.edu uid=XXXX postalAddress createTimestamp modifyTimestamp entryCSN dn: uid=XXXX,ou=People,dc=rutgers,dc=edu createTimestamp: 20121220100700Z postalAddress: BUSINESS AND SCIENCE BLDG$227 PENN STREET$CAMDEN, NJ 081021656 entryCSN: 20180505002024.083133Z#000000#001#000000 modifyTimestamp: 20180505002024Z So I'm trying to figure out why this happens (config issue, bug, ???) and second, if I can't use the contextCSN to report that everything is fine, what else can I do besides trying to compare ldif dumps. thanks, ds -- Dave Steiner steiner(a)rutgers.edu IdM, Enterprise Application Services ASB101; 848.445.5433 Rutgers University, Office of Information Technology

4 6

olcSecurity: tls=1 and olcLocalSSF= : what value should I use?
by Jean-Francois Malouin 06 Sep '18

06 Sep '18

Sorry if this is long and naive, I'm making my way with OpenLDAP. I have this annoying problem of local access over ldapi:/// of a configured mdb database using its rootDN. Some details: (I typically use ldapvi to access/modify/edit config as I'm an old wolf with vi hard-wired in my brain!) (Same could be done using native OpenLDAP utilities ldapadd/search/delete/etc: just replace the ldapvi '-h' option with '-H' to specify the protocol/host/port). Binding using EXTERNAL mech over local ldapi:/// works correctly for 'cn=config'. For example, here I made a mod to olcLogLevel for 'cn=config': ~# ldapvi -Y EXTERNAL -h ldapi:/// -b 'cn=config' SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 24 entries read add: 0, rename: 0, modify: 1, delete: 0 Action? [yYqQvVebB*rsf+?] y Done. Server logs for slapd show the binding with ssf=71: Sep 6 11:40:52 slapd[677]: conn=48667 fd=17 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi) Sep 6 11:40:52 slapd[677]: conn=48667 op=0 BIND dn="" method=163 Sep 6 11:40:52 slapd[677]: conn=48667 op=0 BIND authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" Sep 6 11:40:52 slapd[677]: conn=48667 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=71 However for the configured mdb database 'olcDatabase={1}mdb,cn=config' I have set olcSecurity: tls=1 to force binding with StartTLS. Here the relevant config piece for it: ('--out' makes ldapvi behave like ldapsearch). ~# ldapvi --out -Y EXTERNAL -h ldapi:/// -b 'olcDatabase={1}mdb,cn=config' SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=com olcRootDN: cn=admin,dc=example,dc=com olcRootPW: {SSHA}XXXXXXXXXXXXXXXXXXXX olcSecurity: tls=1 ... However this setting prohibits me from binding to it using ldapi:/// with EXTERNAL mech with its rootDN 'cn=admin,dc=example,dc=com' as I then get the message: ~# ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -D 'cn=admin,dc=example,dc=com' -b 'dc=example,dc=com' SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 Confidentiality required (13) Additional information: TLS confidentiality required I can however do a simple bind over StartTLS with the rootDN of the database either over localhost or a remote client: ~# ldapsearch -LLL -Z -x -w xxxxxxxx -H ldap://localhost -D 'cn=admin,dc=example,dc=com' -b 'dc=example,dc=com' slapd logs show: Sep 6 11:54:40 slapd[677]: conn=48699 fd=17 ACCEPT from IP=127.0.0.1:53542 (IP=0.0.0.0:389) Sep 6 11:54:40 slapd[677]: conn=48699 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Sep 6 11:54:40 slapd[677]: conn=48699 op=0 STARTTLS Sep 6 11:54:40 slapd[677]: conn=48699 op=0 RESULT oid= err=0 text= Sep 6 11:54:40 slapd[677]: conn=48699 fd=17 TLS established tls_ssf=256 ssf=256 Sep 6 11:54:40 slapd[677]: conn=48699 op=1 BIND dn="cn=admin,dc=example,dc=com" method=128 Sep 6 11:54:40 slapd[677]: conn=48699 op=1 BIND dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0 So ssf=265... I guess I need to modify either 'olcSecurity: tls=1' in the database config or add/insert the proper value for 'olcLocalSSF=' in the cn=config. What value should I use in order to still force StartTLS over simple binding and allow read/write/modify local access on the ldapi:/// listener. Regards! jf

2 2

duplicated naming context when using syncrepl proxy
by Jochen Keutel 05 Sep '18

05 Sep '18

Hallo, I'm using OpenLDAP on Debian 9 (2.4.44) and started to configure replication: szenario syncrepl proxy (push based replication, see 18.3.5 in OpenLDAP Admin Guide - "primary directory also contains back-ldap databases"). Configuring the LDAP backend leads unfortunately to a root DSE showing the same name context twice: namingContexts: dc=keutel,dc=de namingContexts: dc=keutel,dc=de Is this a known problem? Esp. this stops PHPLDAPAdmin from working: It prints a lot of PHP arrays in this case. I've set "hidden on" for this backend but the problem remains. My configuration: 1. slapd.conf on server1 (master): database ldap hidden on suffix "dc=keutel,dc=de" rootdn "cn=admin,dc=keutel,dc=de" uri ldaps://server2/ lastmod on restrict all acl-bind bindmethod=simple binddn="cn=replication,dc=keutel,dc=de" credentials=secret syncrepl rid=001 provider=ldaps://server1/ binddn="cn=replication,dc=keutel,dc=de" bindmethod=simple credentials=secret searchbase="dc=keutel,dc=de" type=refreshAndPersist retry="5 5 300 5" 2. converting this to dynamic config using slaptest gives the following entry: dn: olcDatabase={2}ldap objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcHidden: TRUE olcSuffix: dc=keutel,dc=de ... 3. starting slapd with this dynamic configuration 4. reading rootDSE: attribute namingContexts occurs twice with the same value. How can this be solved? Regards Jochen.

3 4

Problem with ACLs
by Bill Bradford 31 Aug '18

31 Aug '18

Trying to give a single user "read only" access to everything in the database including userPassword info. Here's the LDIF file I'm using w/ldapmodify: dn: olcDatabase={2}hdb,cn=config changetype: modify replace: olcAccess olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=Manager,dc=domain,dc=com" write by dn.exact="uid=romanager,ou=Users,dc=domain,dc=com" read by anonymous auth by self write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by dn="cn=Manager,dc=domain,dc=com" write by * read However, authenticating as uid=romanager,ou=Users,dc=domain,dc=com lets that user read his own password hash, but nobody else's. In other words it's authenticating just like any other user, and it's as if the by dn.exact="uid=romanager,ou=Users,dc=domain,dc=com" read line is being ignored. The change is being applied as I've looked at the database files for the config. I've tried restarting slapd, etc. Any suggestions? @(#) $OpenLDAP: slapd 2.4.44 (Aug 4 2017 14:23:27) $ Bill -- Bill Bradford Houston, Texas USA

3 11

empty reqmod attribute
by David Coutadeur 31 Aug '18

31 Aug '18

Hi, I am experiencing a segfault on an OpenLDAP 2.4.44 instance. The architecture is: - 2 OpenLDAP - multimaster mirrormode - delta-syncrepl The error seems to be in the syncrepl process, in a particular accesslog entry. When I give a look to the entry, I realize that some attributes in reqmod are empty, which seems strange because the value can't be empty in the directory. For example: reqMod: inetUserStatus:= Does anyone know if this behaviour is normal, and what is happening? Thanks in advance. David

2 4

Unique overlay confusing
by Ervin Hegedüs 30 Aug '18

30 Aug '18

Hi there, I've followed the docs (and some forums), and made these modifications: (OpenLDAP doc: http://www.openldap.org/doc/admin24/overlays.html#Attribute%20Uniqueness) dn: cn=module,cn=config cn: module objectClass: olcModuleList olcModulePath: /usr/lib/ldap/ olcModuleLoad: unique.la dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: unique olcUniqueAttribute: uid olcUniqueAttribute: mail olcUniqueAttribute: uidNumber olcUniqueAttribute: sn olcUniqueAttribute: cn but I still can set the mail attribute as same e-mail address for two different users. I've tried this config too: dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcUniqueConfig olcOverlay: unique olcUniqueUri: ldap:///?uid?sub? olcUniqueUri: ldap:///?mail?sub? olcUniqueUri: ldap:///?uidNumber?sub? olcUniqueUri: ldap:///?sn?sub? olcUniqueUri: ldap:///?cn?sub? What em'I missing? Thanks, a.

5 17

Call fo Papers - Paris Open Source Summit
by Clément OUDOT 30 Aug '18

30 Aug '18

Hello, There is an important event about free software and open source in Paris in december, with topics about identity management. The CFP is here: http://cfp.opensourcesummit.paris/ It should close friday but I think the deadline will be reported. Feel free to propose technical talks or customer success stories (for example migration from proprietary softwares to free softwares). Hope to see you soon, Clément.

1 0

Recommended way to transfer data from one cluster to the other?
by Karsten Heymann 29 Aug '18

29 Aug '18

Hi, We're replacing our aging LDAP Cluster (Debian 7, slapd 2.4.40, 2 masters with syncrepl and mirror mode, 2 slaves) with a new cluster of the same layout (2.4.44, probably 2.4.46, on Debian 9). I now wonder what the best way is to transfer the data from the old to the new cluster. As far as I can see, we have three options to transfer the data: 1) ldapsearch + ldapadd 2) slapcat + slapadd 3) Configure a temporary syncrepl rule on the new masters to fetch the data from the old ones. Which one is the preferred one? I would assume slapcat and slapadd, but I must admit I have not fully understood the purpose of the -S and -w switch. Should we somehow filter the *CSN-fields from the exported ldif as I assume they make no sense for the new cluster or are they automatically fixed when using slapadd with said options? I'm sorry if this topic has been discussed here before but my (probably lacking) google skills did not return anything obvious. Best regards Karsten

3 2

Re: Recommended way to transfer data from one cluster to the other?
by Quanah Gibson-Mount 29 Aug '18

29 Aug '18

--On Wednesday, August 29, 2018 12:50 PM +0200 Karsten Heymann <karsten.heymann(a)gmail.com> wrote: > Hi Quanah, > > Am Di., 28. Aug. 2018 um 21:05 Uhr schrieb Quanah Gibson-Mount > <quanah(a)symas.com>: >> --On Tuesday, August 28, 2018 9:48 PM +0200 Karsten Heymann >> <karsten.heymann(a)gmail.com> wrote: >> >> > Which one is the preferred one? >> >> Indeed, slapcat + slapadd is the preferred route. > > Great, so I was not too far off. > >> d) slapadd this second export to the rest of the new cluster > > I gess with no extra options regarding replication this time? Correct. Can just use "-q" at this point. >> * <http://www.openldap.org/its/index.cgi/?findid=8902> > > Ok, didn't know that. > > Thanks a lot. I performed a test import following your instructions > and so far everything looks good. > Karsten Glad it's looking good. :) In the future, please keep replies on the list unless they contain some type of sensitive info (passwords, etc). ;) This helps ensure others have the possibility of making use of the information. :) Warm regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Q: Co-existence of OpenLDAP and 389 Directory Server?
by Ulrich Windl 25 Aug '18

25 Aug '18

Hi! As stated some time ago the SUSE Linux Enterprise Server 15 (SLES15) switched from OpenLDAP to 389 Directory Server. Trying the latter, I see that it still works with BDB (4.8), and setup is easy. It also seems to have modern features like these: \n+Entry cn=SSHA256,cn=Password Storage Schemes,cn=plugins,cn=config is added \n+Entry cn=SSHA384,cn=Password Storage Schemes,cn=plugins,cn=config is added \n+Entry cn=SSHA512,cn=Password Storage Schemes,cn=plugins,cn=config is added \n+Entry cn=SHA256,cn=Password Storage Schemes,cn=plugins,cn=config is added \n+Entry cn=SHA384,cn=Password Storage Schemes,cn=plugins,cn=config is added \n+Entry cn=SHA512,cn=Password Storage Schemes,cn=plugins,cn=config is added \n+Entry cn=PBKDF2_SHA256,cn=Password Storage Schemes,cn=plugins,cn=config is added However I wonder if it's possible to integrate a 389DS (ns-slapd, http://www.port389.org/) into an OpenLDAP multi-master configuration. Definitely one cannot sync the configuration section, because it's too different. For example the ACL Syntax looks like this: (targetattr="carLicense || description || displayName || facsimileTelephoneNumber || homePhone || homePostalAddress || initials || jpegPhoto || labeledURI || mail || mobile || pager || photo || postOfficeBox || postalAddress || postalCode || preferredDeliveryMethod || preferredLanguage || registeredAddress || roomNumber || secretary || seeAlso || st || street || telephoneNumber || telexNumber || title || userCertificate || userPassword || userSMIMECertificate || x500UniqueIdentifier")(version 3.0; acl "Enable self write for common attributes"; allow (write) userdn="ldap:///self";) Regards, Ulrich

3 4

OpenLDAP instances crashes
by Saurabh Lahoti 23 Aug '18

23 Aug '18

Dear, Today, received below error in /var/log/messages with OpenLDAP instance crashing. Aug 16 13:21:07 muledeer kernel: slapd[29253]: segfault at 0 ip 00007fbeddf3af09 sp 00007fb72effc480 error 4 in uniquemember.so.0.0.0[7fbeddf3a000+2000] Aug 16 13:21:08 muledeer abrt[24629]: Saved core dump of pid 16470 (/usr/app/ldap/openldap2.4.46/libexec/slapd) to /var/spool/abrt/ccpp-2018-08-16-13:21:07-16470 (472973312 bytes) Aug 16 13:21:08 muledeer abrtd: Directory 'ccpp-2018-08-16-13:21:07-16470' creation detected Aug 16 13:21:08 muledeer abrtd: Executable '/usr/app/ldap/openldap2.4.46/libexec/slapd' doesn't belong to any package and ProcessUnpackaged is set to 'no' Aug 16 13:21:08 muledeer abrtd: 'post-create' on '/var/spool/abrt/ccpp-2018-08-16-13:21:07-16470' exited with 1 Aug 16 13:21:08 muledeer abrtd: Deleting problem directory '/var/spool/abrt/ccpp-2018-08-16-13:21:07-16470' Could you please guide us in finding probable root of this error..? ---- *Thanks & Kind Regards,* Saurabh LAHOTI. *Ideas enlighten Innovation**!!!* Please consider the environment before printing this mail..!!

6 13

help to get our openldap updated and replicated
by admin＠genome.arizona.edu 23 Aug '18

23 Aug '18

Hi all, I am about the 4th sysadmin for our organization, and our openldap is old, 2.4.40 system version for CentOS 6.9. Also there might have been incorrect modifications to the slapd.d files since it was really difficult to update things. The olcRootDN was set to "cn=config" somehow so I had to manually update that to the Manager account and figure out the CRC32 and everything, but at least I could make some updates now. Anyway, I would like to get our installation updated to a current version, as well as set up some sort of replication with our other server, in case one goes down then our users could still login and use our applications, or I could still add/delete users. Perhaps a multi-master config would be best? (Also maybe update the databases too since they are using bdb format? but maybe that is just unnecessary extra work) I tried to setup replication by following a guide, but was not successful and actually made things worse for our demon, so had to undo the changes for now. I guess 2.4.40 has some problems with replication anyway from what I've heard. First, to get openldap updated, would it be as simple as compiling the new version and then updating the init script /etc/init.d/slapd to point to the new binaries? I would stop slapd and get a backup of /etc/openldap and /var/lib/ldap. Then I could just leave our current config in /etc/openldap and databases in /var/lib/ldap? I've already built the new version and "make test" was successful so am ready to proceed from there with your assistance and suggestions. Thanks, -- Chandler Arizona Genomics Institute www.genome.arizona.edu

2 1

OpenLDAP Developer Day 2018
by Howard Chu 23 Aug '18

23 Aug '18

In case you missed it, we're holding an event to celebrate the 20th anniversary of the OpenLDAP Project this October in Germany. Talks are being solicited now. https://daasi.de/de/call-for-content_odd2018/ -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

OpenLDAP Developpers Day Silver Jubilee
by Peter 22 Aug '18

22 Aug '18

Dear all, something completely different: Join Us Celebrating 20 Years of OpenLDAP The community is coming together! ON:*October 8th, 2018* IN:*Tübingen, Germany* LOCATION: *Computing Center of the University of Tübingen* You are invited to join this forum, which is a great way to share and discuss your ideas, achievements and visions with the community. With this Call for Content we want to enable the community to continue the professional discourse. For this we are looking for contributions: either deployment success stories or reports on new development activities. This event brings together developers of OpenLDAP software, directory researchers and other OpenLDAP community members interested in discussing ongoing and future development efforts. If you want to participate and to present a topic, please contact odd-silverjubilee(a)daasi.de <mailto:odd-silverjubilee@daasi.de>before September 10th, 2018. Meet the team, learn and network. More info at: https://daasi.de/en/2018/08/14/5th-openldap-developer-day-2018-20-years-are… And please forward this to people connected with OpenLDAP. Cheers, Peter -- _______________________________________________________________________ Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 407109-0 Europaplatz 3 Fax: +49 7071 407109-9 D-72072 Tübingen mail: peter.gietz(a)daasi.de Germany Web: www.daasi.de DAASI International GmbH, Tübingen Geschäftsführer Peter Gietz, Amtsgericht Stuttgart HRB 382175 Directory Applications for Advanced Security and Information Management _______________________________________________________________________

1 0

Re: Multiprocess LMDB transaction: resource not available
by Stefano Cossu 19 Aug '18

19 Aug '18

So, while perusing lmdb.h I saw this: > Use an MDB_env* in the process which opened it, not after fork(). That was my problem. It had nothing to do with transactions. I need to open the environment and hold a separate handle in each process. Right? Moving the mdb_env_create and mdb_env_open functions and related variables inside the get_() function got rid of the errors. In my dummy code below that is obviously terribly expensive, but my real application is running a pool of long-lived workers (HTTP server) and the cost of opening the environments only happens at server start. Thanks, Stefano On 08/19/2018 10:36 AM, Stefano Cossu wrote: > Hello, > I am writing a framework in Cython using multi-process access to an LMDB > database. I ran into a "Resource not available" error. > > I isolated the problem in the following script (this is Cython calling > the LMDB C API, so bear with the hybrid syntax): > > > import time > cimport cylmdb as lmdb # This is a Cython header mirroring lmdb.h > > import multiprocessing > import threading > > cdef: > lmdb.MDB_env *env > lmdb.MDB_dbi dbi > > > cdef void _check(int rc) except *: > if rc != lmdb.MDB_SUCCESS: > out_msg = 'LMDB Error ({}): {}'.format( > rc, lmdb.mdb_strerror(rc).decode()) > raise RuntimeError(out_msg) > > > cpdef void get_() except *: > cdef: > lmdb.MDB_txn *txn > lmdb.MDB_val key_v, data_v > > _check(lmdb.mdb_txn_begin(env, NULL, lmdb.MDB_RDONLY, &txn)) > > key_v.mv_data = b'a' > key_v.mv_size = 1 > > _check(lmdb.mdb_get(txn, dbi, &key_v, &data_v)) > print((<unsigned char *>data_v.mv_data)[:data_v.mv_size]) > time.sleep(1) > _check(lmdb.mdb_txn_commit(txn)) > print('Thread {} in process {} done.'.format( > threading.currentThread().getName(), > multiprocessing.current_process().name)) > > > def run(): > cdef: > unsigned int flags = 0 > #unsigned int flags = lmdb.MDB_NOTLS # I tried this too. > lmdb.MDB_txn *wtxn > lmdb.MDB_val key_v, data_v > > # Set up environment. > _check(lmdb.mdb_env_create(&env)) > _check(lmdb.mdb_env_set_maxreaders(env, 128)) > _check(lmdb.mdb_env_open(env, '/tmp/test_mp', flags, 0o644)) > > # Create DB. > _check(lmdb.mdb_txn_begin(env, NULL, 0, &wtxn)) > _check(lmdb.mdb_dbi_open(wtxn, NULL, lmdb.MDB_CREATE, &dbi)) > > # Write something. > key_v.mv_data = b'a' > key_v.mv_size = 1 > ts = str(time.time()).encode() > data_v.mv_data = <unsigned char *>ts > data_v.mv_size = len(ts) > _check(lmdb.mdb_put(wtxn, dbi, &key_v, &data_v, 0)) > _check(lmdb.mdb_txn_commit(wtxn)) > > > print('Multiprocess jobs:') > for i in range(5): > multiprocessing.Process(target=get_).start() > # Env should be closed only after all processes return. > #lmdb.mdb_env_close(env) > > > If I execute run(), the first process runs successfully, but apparently > it's holding on to some resources that the other processes need. > > Multiprocess jobs: > b'1534691578.4300401' > Process Process-2: > Traceback (most recent call last): > File "/usr/lib/python3.6/multiprocessing/process.py", line 258, in > _bootstrap > self.run() > File "/usr/lib/python3.6/multiprocessing/process.py", line 93, in run > self._target(*self._args, **self._kwargs) > File "lakesuperior/sandbox/threading_poc.pyx", line 23, in > lakesuperior.sandbox.threading_poc.get_ > cpdef void get_() except *: > File "lakesuperior/sandbox/threading_poc.pyx", line 28, in > lakesuperior.sandbox.threading_poc.get_ > _check(lmdb.mdb_txn_begin(env, NULL, lmdb.MDB_RDONLY, &txn)) > File "lakesuperior/sandbox/threading_poc.pyx", line 20, in > lakesuperior.sandbox.threading_poc._check > raise RuntimeError(out_msg) > RuntimeError: LMDB Error (11): Resource temporarily unavailable > Process Process-3: > Traceback (most recent call last): > File "/usr/lib/python3.6/multiprocessing/process.py", line 258, in > _bootstrap > self.run() > File "/usr/lib/python3.6/multiprocessing/process.py", line 93, in run > self._target(*self._args, **self._kwargs) > File "lakesuperior/sandbox/threading_poc.pyx", line 23, in > lakesuperior.sandbox.threading_poc.get_ > cpdef void get_() except *: > File "lakesuperior/sandbox/threading_poc.pyx", line 28, in > lakesuperior.sandbox.threading_poc.get_ > _check(lmdb.mdb_txn_begin(env, NULL, lmdb.MDB_RDONLY, &txn)) > File "lakesuperior/sandbox/threading_poc.pyx", line 20, in > lakesuperior.sandbox.threading_poc._check > raise RuntimeError(out_msg) > RuntimeError: LMDB Error (11): Resource temporarily unavailable > Process Process-4: > > Process Process-5: > Traceback (most recent call last): > File "/usr/lib/python3.6/multiprocessing/process.py", line 258, in > _bootstrap > self.run() > File "/usr/lib/python3.6/multiprocessing/process.py", line 93, in run > self._target(*self._args, **self._kwargs) > File "lakesuperior/sandbox/threading_poc.pyx", line 23, in > lakesuperior.sandbox.threading_poc.get_ > cpdef void get_() except *: > Traceback (most recent call last): > File "lakesuperior/sandbox/threading_poc.pyx", line 28, in > lakesuperior.sandbox.threading_poc.get_ > _check(lmdb.mdb_txn_begin(env, NULL, lmdb.MDB_RDONLY, &txn)) > File "lakesuperior/sandbox/threading_poc.pyx", line 20, in > lakesuperior.sandbox.threading_poc._check > raise RuntimeError(out_msg) > File "/usr/lib/python3.6/multiprocessing/process.py", line 258, in > _bootstrap > self.run() > File "/usr/lib/python3.6/multiprocessing/process.py", line 93, in run > self._target(*self._args, **self._kwargs) > File "lakesuperior/sandbox/threading_poc.pyx", line 23, in > lakesuperior.sandbox.threading_poc.get_ > cpdef void get_() except *: > RuntimeError: LMDB Error (11): Resource temporarily unavailable > File "lakesuperior/sandbox/threading_poc.pyx", line 28, in > lakesuperior.sandbox.threading_poc.get_ > _check(lmdb.mdb_txn_begin(env, NULL, lmdb.MDB_RDONLY, &txn)) > File "lakesuperior/sandbox/threading_poc.pyx", line 20, in > lakesuperior.sandbox.threading_poc._check > raise RuntimeError(out_msg) > RuntimeError: LMDB Error (11): Resource temporarily unavailable > > > If I run the same function multiple times on the same process, > everything is fine. > > Can someone point out what is wrong with this script? > > Thank you, > Stefano > > > -- exitsts .not exeunt hoall. http://stefano.cossu.cc

1 0

Re: Possible transaction issue with LMDB
by Howard Chu 17 Aug '18

17 Aug '18

William Brown wrote: > On Fri, 2018-08-17 at 07:33 +0100, Howard Chu wrote: >> William Brown wrote: >>> On Fri, 2018-08-17 at 07:06 +0100, Howard Chu wrote: >>>>> I'm quite aware that it is COW - this issue is specific to COW >>>>> trees. >>>>> Transactions must be removed in order, they can not be removed >>>>> out >>>>> of >>>>> order. It is about how pages are reclaimed for the freelist >>>> >>>> Incorrect. >>> >>> We may have to "agree to disagree" then. >> >> Pure, utter nonsense. You're simply wrong, and at this point you're >> spewing FUD. > > You know what - I made a mistake. I read "free list" when it should be > "pending free list". Which makes much more sense, but is poorly > signaled in the naming conventions. > > I also misread this comment about "incorrect". You meant "incorrect" > about the reclaiming of freelist not about the ordering. > > Instead of trying to have a constructive discussion, I believe your > responses here were quite hostile, and their "short" nature has led to > further miscommunication. My mistake was answering too quickly. I have > removed myself from the list because I really just don't want to be > involved in this style of discussion in the future. You claimed to have actual code showing a misbehavior in LMDB when the described misbehavior is impossible. That's not a misunderstanding or a mistake - that's pure fabrication. Dishonesty is absolutely not welcome. Bye. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Possible transaction issue with LMDB
by William Brown 17 Aug '18

17 Aug '18

Hi there, While doing some integration testing of LMDB I noticed that there may be an issue with out of order transaction handling. The scenario is: Open Read TXN A Open Write TXN X, and change values of the DB Commit X Open Read TXN B Open Write TXN Y, and change values of the DB Commit Y Open Read TXN C Abort/Close TXN B. At this point, because of the page touch between A -> B and B -> C, B now believes that the pages of A are the "last time" they are available as they were all subsequently copied for TXN C. The pages of A are then added to the freelists when B closes. When TXN A is read from the data may have been altered due to future writes as LMDB attempts to use previously allocated pages first. This situation is more likely to arise on large batch writes, but could manifest with smaller series of writes. This would be a silent issue, as the over-written pages may be valid, and could cause data to "silently vanish" inside of the read transaction A leading to unpredictable results. I hope that this report helps you to diagnose and resolve the issue. -- Sincerely, William

3 6

Re: [LMDB] What pointer is returned with combination of MDB_WRITEMAP and MDB_RESERVE?
by Victor Baybekov 16 Aug '18

16 Aug '18

Hello, Working with overflow pages directly via pointers outside write transactions works great and it helps that they do not move "by design" in current versions as discussed in this thread. I have two related scenarios that will give a substantial performance boost in my case. *The first one* is updating a value in-place via pointer from aborted write transaction. If I 1) use MDB_WRITEMAP, 2) from **write** transaction find a record (which is small and not in an overflow page), 3) modify a part of it's value (for duplicates this part is not used in the compare function) directly via the MDB_VAL data pointer (e.g. interlocked_increment or compare_and_swap), 4) and **abort** the transaction, then readers see the updated value via normal read transactions later. Since I do the direct updates from inside a write transaction all other writers should be locked until I exit the transaction (abort in this case), and no pages should move since the transaction is aborted. Is this correct? Does this work "by design" or "by accident" currently? *The second one* is about updating values in-place from read transactions. If I 1) use MDB_WRITEMAP, 2) open a database with MDB_INTEGERKEY (and could use a dedicated environment with a single DB if that changes the answer), 3) add values to the DB *only* using MDB_APPEND | MDB_NOOVERWRITE, 4) modify a part of a value directly via the MDB_VAL data pointer, is it possible that the page from the read transaction is replaced with a new one if there is a parallel write transaction? There is a quote from Howard on GitHub (https://github.com/lmdbjava/ benchmarks/issues/9#issuecomment-354184989): "When we do sequential inserts using MDB_APPEND, there is* no page split at all* - we just allocate a new page and fill it, sequentially." Does this mean that if there are no page splits then existing pages do not move as well, and it is "safe" to use pointers outside of write transactions as is the case with the overflow pages? In both cases I update values of a struct that indicate e.g. some lifecycle stage of an object the LMDB record refers to and stage transitions are idempotent. If a direct pointer write doesn't make to disk due to system failure subsequent readers (workers) will see an older stage and repeat stage transition. Therefore missed direct writes do not break application logic, I only care about physical corruption of the entire DB. If I update the values in-place inside read transactions and the page becomes stale this should not corrupt DB since the old page will go to the free list only after the read transaction is finished, so this "hack" should not break DB. But then missed writes will be a norm and not a special-case on OS failure. But if pages do not move, all these "soft" updates could be done in parallel and be very fast. Unfortunately I cannot answer this myself while trying to read the mbd.c file. In the second scenario I'm specifically concerned what is happening when DB becomes large and the tree needs rebalancing. At least in this case some pages need to move, but does the rebalancing replace/split existing pages? Thanks & best regards, Victor On Fri, Oct 30, 2015 at 9:26 PM, Howard Chu <hyc(a)symas.com> wrote: > Victor Baybekov wrote: > >> Thanks a lot! My proof-of-concept code works OK. >> >> I do not understand all subtle details of mmap reliability, could you >> please >> help with these two: >> >> If I write data to a pointer to an opaque blob as discussed above, and my >> process crashes before mdb_env_sync, but OS doesn't crash - will that >> data be >> secure in the mmap file? >> > > Of course. The OS owns the memory, it doesn't matter if your process > crashes. > > Also, am I correct that mdb_env_sync synchronizes all dirty pages in the >> mmap >> file as seen by a file system, regardless how they were modified - either >> via >> LMDB API or via a direct pointer writes? >> > > Yes. > > As for "you could at least set a callback to notify you that a block has >> moved" - if that is implemented, it would be nice to have a notification >> /before/ a block is moved (with old and new address, so that right after >> the >> callback it is OK to use the new address), otherwise this non-intended but >> convenient use of LMDB won't work anymore. >> > > "right after the callback it is OK to use the new address" - that's the > point of the callback, it's job is to make the new address valid. So yes, > when it returns, you use the new address. > >> >> >> Best regards, >> Victor >> >> >> >> On Sat, Oct 3, 2015 at 1:27 AM, Howard Chu <hyc(a)symas.com >> <mailto:hyc@symas.com>> wrote: >> >> Howard Chu wrote: >> >> Victor Baybekov wrote: >> >> Thank you! I understand this copy-on-write behavior, but am >> interested if I >> could control it a little. What if I use records that are >> always >> much bigger >> than a single page, e.g. 100 kb with 4kb pages, and make sure >> that >> a record is >> never updated (via LMDB means) during a lifetime of an >> environment, - is there >> any scenario that the location of such a big record could be >> changed during a >> lifetime of an environment, without updating the record? >> >> >> At this point in time, no, if you don't update a large record >> there is no >> reason that it will move. That is not to say that this won't >> change in the >> future. The documentation tells you what promises we are willing >> to make. >> Relying on any non-documented behavior is your own responsibility. >> >> >> Note that the relocation functions in LMDB are intended to accommodate >> blocks being moved around. The actual guts of that API haven't been >> implemented, but probably in 1.x we'll flesh them out. Given that >> support, >> you could at least set a callback to notify you that a block has >> moved. >> But currently, overflow pages don't move if they're not modified. >> >> >> >> >> On Fri, Oct 2, 2015 at 4:38 PM, Howard Chu <hyc(a)symas.com >> <mailto:hyc@symas.com> >> <mailto:hyc@symas.com <mailto:hyc@symas.com>>> wrote: >> >> Victor Baybekov wrote: >> >> Hi, >> >> Docs for MDB_RESERVE say that a returned pointer to >> the >> reserved >> space is >> valid "before the next update operation or the >> transaction ends." Docs >> for MDB_WRITEMAP say that it "writes directly to the >> mmap >> instead of >> using >> malloc for pages." Does combining the two options >> return >> a pointer >> directly to >> a place in a mmap >> >> >> Yes. >> >> so that this pointer could be used after a >> transaction ends >> or after the next update? >> >> >> No. >> >> Longer answer: maybe. >> >> Full answer: LMDB is copy-on-write. If you update another >> record on the >> same page, in a later transaction, the contents of that >> page >> will be >> copied to a new page and the original page will go onto >> the >> freelist. In >> that case, the pointer you got must not be used again. >> >> If you don't directly update that page and cause it to be >> copied, then you >> might get lucky and be able to use the pointer for a >> while. >> It all depends >> on what other modifications you do and how they affect >> that >> node or >> neighboring nodes. >> >> >> I have a use case where I want to somewhat abuse LMDB >> safety for >> convenience. >> If I could get a pointer to a place inside a mmap I >> could >> work with >> LMDB value >> as opaque blob or as a region inside the single big >> mmap. >> This could >> be more >> convenient than creating and opening hundreds of >> temporary memory >> mapped files >> and keeping open handles to them. For example, Aeron >> terms could be >> stored >> like this: a stream id per an LMDB db and a term id >> for a >> key in the >> db. >> >> >> Thanks! >> Victor >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ >

2 2

permissions replication
by Miroslav Misek 13 Aug '18

13 Aug '18

Hi, I am setting up master-slave replication for our off-site office, so it can use authentication against ldap even with internet connectivity issues. Replication itself is working without problems. But it replicates only data and not olcAccess attributes on database. So I have to set them manually. Please is there any way to replicate those attributes too? I found only one way, and it is master-master replication of cn=config database. And it is not usable in our environment. Off-site office don`t have public ip. And it is better for me to have this ldap instance read-only. Thank you, Miroslav Misek

4 4

Re: Search memberOf
by Arianna Milazzo 09 Aug '18

09 Aug '18

Ok, I understand that it isn't supported, but at the moment I can't try other solutions. And since that aside from that filter, the rest works, I don't want to give up like that. Infact if I look for the following values (then on the groups) Search base: cn=groupname,ou=group,dc=pigreco,dc=it Filter: (member=cn=Name Surname,ou=people,dc=pigreco,dc=it) I get if Name Surname is part of the groupname group If I search Search base: dc=pigreco,dc=it Filter: (member=cn=Name Surname,ou=people,dc=pigreco,dc=it) I get the list of which groups Name Surname belongs *But with this (then on the people)* Search base: dc=pigreco,dc=it Filter: (memberOf=cn=groupname,ou=group,dc=pigreco,dc=it) *I have no result and in the log I read:get_ava: illegal value for attributeType memberof* obviously same thing with: (& (uid=n.surname) (memberOf=cn=groupname,ou=group,dc=pigreco,dc=it) ) :( On the "groups" it is works! On the "people" it doesn't work (*get_ava: illegal value for attributeType memberof*) It's frustrating! 2018-08-07 21:35 GMT+02:00 Quanah Gibson-Mount <quanah(a)symas.com>: > --On Tuesday, August 07, 2018 1:30 PM -0700 Quanah Gibson-Mount < > quanah(a)symas.com> wrote: > > --On Tuesday, August 07, 2018 11:23 AM +0200 Arianna Milazzo >> <arianna(a)ariannamicrochip.it> wrote: >> Trying to force LDAP >> functionality with back-sql is going to work well as a path to pursue. >> > > *is not going to work well. > > --Qunah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

3 4

Re: Search memberOf
by Arianna Milazzo 07 Aug '18

07 Aug '18

Hello. Thank you for your reply. I have many applications using a db to manage access and profiles. Now I have to use even other application supporting ldap. So I’m hoping to use same db, so I can manage only a datasource for all Applications (same users!!!) But I need to use memberOf to manage the access to theese applications (profiling). (Excuse me for My English!) Thanks, Arianna Il giorno gio 2 ago 2018 alle 19:54 Quanah Gibson-Mount <quanah(a)symas.com> ha scritto: > --On Thursday, August 02, 2018 5:25 PM +0200 Arianna Milazzo > <arianna(a)ariannamicrochip.it> wrote: > > > > > > > Hello! > > I use OpenLDAP wuth MySQL backend. > > The MySQL backend is experimental and generally unsupported. It should > not > be used as a general purpose backend for an LDAP server. > > > Can someone help me? > > Is there a particular reason you're trying to wedge memberof support into > mysql, which is likely not designed to handle it? > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

3 4

daemon: bind(11) failed errno=2 (No such file or directory)
by Alan Lukens 07 Aug '18

07 Aug '18

I encountered a problem with openldap-2.4.40 on debian when a vm crashed. Upon restore i could not start slapd service. But typing slapd on the command line would start slapd. I tried defining the urls, and tried defining the configuration directory with the slapd command, however that only resulted in the same error. After extensive searching i could only find one reference to the error "daemon: bind(11) failed errno=2 (No such file or directory)". and that was leading me in the direction of the directory /var/run/ldap didnt have the right permissions, but it was there and had openldap owner and group. I spent a number of hours double checking directories making sure everything was there and had the right permissions. I finally found /var/run/slapd was missing! A file called ldapi is created there on startup. What is /var/run/slapd/ldapi ?? And what does it do? For future reference what is bind(11) referring to? Where can i find the reference to error codes? Thanks for your help, Alan Lukens Identity Management Specialist University of Massachusetts Amherst, IT NSS voice: 413.545.1654 email: alan.lukens(a)umass.edu

2 1

ldapi and StartTLS
by Norman Gray 07 Aug '18

07 Aug '18

Greetings. I would have thought (possibly naively) that StartTLS was unnecessary when connecting to slapd through a unix socket -- the client and the server are on the same machine, and so don't need to be reassured about each other's identity. However this seems not to be be the case: % ldapsearch -LLL -H ldapi://%2Fvar%2Frun%2Fopenldap%2Fldapi '(uid=foo)' ldap_sasl_interactive_bind_s: Confidentiality required (13) additional info: stronger confidentiality required (same result with ldapi:///). What am I misunderstanding? In the slapd.ldif I have: dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap/slapd.args olcPidFile: /var/run/openldap/slapd.pid olcSecurity: ssf=128 olcTLSCertificateFile: /usr/local/etc/openldap/certs/XXX.crt olcTLSCertificateKeyFile: /usr/local/etc/openldap/certs/XXX.key olcTLSCACertificateFile: /usr/local/etc/openldap/certs/FOO olcLogLevel: 0 The machine is also listening on ldap://0.0.0.0 and requiring TLS. I don't see anything in the documentation which seems to suggest I can have different TLS rules on different interfaces or protocols (ie, ldap: vs ldapi:) -- am I just missing that? The /usr/local/etc/ldap.conf doesn't mention TLS, so the TLS requirement isn't coming in from there. My practical problem is that I'm trying to get nslcd (on the same machine) to talk to OpenLDAP locally. If there's a certificate problem I can sort that out, but I can't help feeling that that ought to be unnecessary -- that I'm missing something simple. This is 2.4.45 on FreeBSD. Best wishes, Norman -- Norman Gray : https://nxg.me.uk

3 3

root server and subtree server replicate.
by Tian Zhiying 03 Aug '18

03 Aug '18

Dear all, I'd like to have a subtree managed by a second LDAP server and its contents replicated to the "upper" root server. server A(root server): suffix="dc=domain,dc=org" server B(subtree server): suffix="ou=people,dc=domain,dc=org" B's subtree should be replicated to A and should be searchable on A. Is there any solutions can fix this case? Thanks.

2 1

<olcMirrorMode> database is not a shadow
by admin＠genome.arizona.edu 02 Aug '18

02 Aug '18

Hello, Was setting up replication for our LDAP server, and was following the guide here, https://wiki.gentoo.org/wiki/Centralized_authentication_using_OpenLDAP#Sett… I had success with this guide but just a problem with authentication, I could see in the ldap debug log for node1 entries like this: Jul 20 16:21:22 node1 slapd[10218]: conn=3497 fd=38 ACCEPT from IP=<node1's IP>:34606 (IP=0.0.0.0:389) Jul 20 16:21:22 node1 slapd[10218]: conn=3497 op=0 BIND dn="cn=Manager,dc=genome,dc=arizona,dc=edu" method=128 Jul 20 16:21:22 node1 slapd[10218]: conn=3497 op=0 BIND dn="cn=Manager,dc=genome,dc=arizona,dc=edu" mech=SIMPLE ssf=0 Jul 20 16:21:22 node1 slapd[10218]: conn=3497 op=0 RESULT tag=97 err=0 text= Jul 20 16:21:22 node1 slapd[10218]: conn=3497 op=1 MOD dn="olcDatabase={1}bdb,cn=config" Jul 20 16:21:22 node1 slapd[10218]: conn=3497 op=1 MOD attr=olcSyncrepl Jul 20 16:21:22 node1 slapd[10218]: conn=3497 op=1 RESULT tag=103 err=0 text= Jul 20 16:21:22 node1 slapd[10218]: conn=3497 op=2 MOD dn="olcDatabase={1}bdb,cn=config" Jul 20 16:21:22 node1 slapd[10218]: conn=3497 op=2 MOD attr=olcMirrorMode Jul 20 16:21:22 node1 slapd[10218]: slap_client_connect: URI=ldap://node2.genome.arizona.edu DN="cn=ldapreader,dc=genome,dc=arizona,dc=edu" ldap_sasl_bind_s failed (49) Jul 20 16:21:22 node1 slapd[10218]: do_syncrepl: rid=001 rc 49 retrying Jul 20 16:21:22 node1 slapd[10218]: conn=3497 op=2 RESULT tag=103 err=0 text= Jul 20 16:21:22 node1 slapd[10218]: conn=3497 op=3 UNBIND Jul 20 16:21:22 node1 slapd[10218]: conn=3497 fd=38 closed and in the debug log for node2 entries like this: Jul 20 16:21:22 node2 slapd[25327]: conn=14036 fd=17 ACCEPT from IP=<node1's IP>:56460 (IP=0.0.0.0:389) Jul 20 16:21:22 node2 slapd[25327]: conn=14036 op=0 BIND dn="cn=ldapreader,dc=genome,dc=arizona,dc=edu" method=128 Jul 20 16:21:22 node2 slapd[25327]: conn=14036 op=0 RESULT tag=97 err=49 text= Jul 20 16:21:22 node2 slapd[25327]: conn=14036 op=1 UNBIND Jul 20 16:21:22 node2 slapd[25327]: conn=14036 fd=17 closed It turns out i had literally used credentials="secret" in the add-replication-node1/node2.ldif files! So I went back and used slappasswd to generate a new password and put it into the ldapreader.ldif and use ldapmodify instead this time with success on both nodes, [root@node1 openldap]# cat ldapreader.ldif dn: cn=ldapreader,dc=genome,dc=arizona,dc=edu changetype: modify replace: userPassword userPassword: <hash from slappasswd> [root@node1 openldap]# ldapmodify -x -W -D "cn=Manager,dc=genome,dc=arizona,dc=edu" -f ldapreader.ldif Enter LDAP Password: modifying entry "cn=ldapreader,dc=genome,dc=arizona,dc=edu" [root@node1 openldap]# [root@node2 openldap]# cat ldapreader.ldif dn: cn=ldapreader,dc=genome,dc=arizona,dc=edu changetype: modify replace: userPassword userPassword: <hash from slappwasswd> [root@node2 openldap]# ldapmodify -x -W -D "cn=Manager,dc=genome,dc=arizona,dc=edu" -f ldapreader.conf Enter LDAP Password: modifying entry "cn=ldapreader,dc=genome,dc=arizona,dc=edu" [root@node2 openldap]# Then I updated the add-replication-node1/node2.ldif to modify the entry with the actual password instead of "secret"... on node1 i got two success messages, [root@node1 openldap]# cat add-replication-node1.ldif dn: olcDatabase={1}bdb,cn=config changetype: modify replace: olcSyncrepl olcSyncrepl: rid=001 provider=ldap://node2.genome.arizona.edu binddn="cn=ldapreader,dc=genome,dc=arizona,dc=edu" bindmethod=simple credentials="<actual password>" searchbase="dc=genome,dc=arizona,dc=edu" type=refreshAndPersist timeout=0 network-timeout=0 retry="60 +" dn: olcDatabase={1}bdb,cn=config changetype: modify replace: olcMirrorMode olcMirrorMode: TRUE [root@node1 openldap]# ldapmodify -x -W -D "cn=Manager,dc=genome,dc=arizona,dc=edu" -f add-replication-node1.ldif Enter LDAP Password: modifying entry "olcDatabase={1}bdb,cn=config" modifying entry "olcDatabase={1}bdb,cn=config" [root@node1 openldap]# However when I went to modify the entries on node2, I now got the error <olcMirrorMode> database is not a shadow, [root@node2 openldap]# cat add-replication-node2.ldif dn: olcDatabase={1}bdb,cn=config changetype: modify replace: olcSyncrepl olcSyncrepl: rid=002 provider=ldap://node1.genome.arizona.edu binddn="cn=ldapreader,dc=genome,dc=arizona,dc=edu" bindmethod=simple credentials="<actual password>" searchbase="dc=genome,dc=arizona,dc=edu" type=refreshAndPersist timeout=0 network-timeout=0 retry="60 +" dn: olcDatabase={1}bdb,cn=config changetype: modify replace: olcMirrorMode olcMirrorMode: TRUE [root@node2 openldap]# ldapmodify -x -W -D "cn=Manager,dc=genome,dc=arizona,dc=edu" -f add-replication-node2.ldif Enter LDAP Password: modifying entry "olcDatabase={1}bdb,cn=config" modifying entry "olcDatabase={1}bdb,cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: <olcMirrorMode> database is not a shadow [root@node2 openldap]# Now the replication has stopped and there are no connection entries in the ldap debug logs. So what did i do wrong and how to get replication going again? Thanks, -- Chandler / Systems Administrator Arizona Genomics Institute www.genome.arizona.edu

2 4

Search memberOf
by Arianna Milazzo 02 Aug '18

02 Aug '18

Hello! I use OpenLDAP wuth MySQL backend. I added even memberOf and it's all ok on db and I see the correct members (on groups) and memberOf (on people). But I have a problem: I can't search if a user is member of a group. filter: (& (objectClass=inetOrgPerson) (uid=username) (memberOf=cn=test,ou=group,dc=organization,dc=it) ) on the log I read: *get_ava: illegal value for attributeType memberOf* Can someone help me? Thanks, Arianna

2 1

Keeping a new n-master environment in sync with an old single master env during a migration
by Chris Cardone 02 Aug '18

02 Aug '18

Hello all, I have a question I'm sure some folks have already addressed and hope there is a solution for my problem I am in the process of migrating from an old single master --> multiple slave env running on OpenBSD 4.9 openldap-server-2.4.23p2 - configured with slapd.conf over to 4-master (regional) to 4 slaves (now - more to come regionally) running Ubuntu 16.04 and openldap 2.4.42 - configured with a cn=config database I am trying to keep the environments in sync as we migrate dozens of different environments from the old slaves to the new slaves - which may take as long as 4 months :( I started out by using slapcat to export the contents of the old server, then loading them into the new server. I would originally drop all the data on the new servers and reload from the old. this is now no longer an option, as we migrate to the new servers, i cannot be dropping the entire database and replacing it with the new one - the time it takes to execute such a task creates an outage for users as well as applications that rely on the LDAP database. So im looking for some guidance / options to keep my new LDAP environment in sync with my old, without any service disruptions on either set of systems. Any help would be greatly appreciated!! Christopher

2 1

Number of requests served in ideal condition by version 2.4.46 with lmdb backend.
by Saurabh Lahoti 01 Aug '18

01 Aug '18

Dear All, For preparing a technical scope of OpenLDAP; do we have any maximum threshold of requests served per second by single instance of 2.4.46 with lmdb backend..? Thanks & Kind Regards, Saurabh Lahoti.

3 2

how to run script on event (modify/delete/add)?
by Zeus Panchenko 31 Jul '18

31 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 greetings, please advise how can I run external script on event (LDAP operation)? for example: I am generating config files for users from LDAP data with perl script I want to re-generate config files each time LDAP operation (modify, add, delete) performed how to do that and what is the best way to do that? - -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQYIXL6FUmD7SUfqoOveOk+D/ejKgUCW18FeQAKCRCveOk+D/ej KtXaAJ949HG/9hwOP9z5RgvSUfjRR27nQQCgljD0MPOTdZevhdBt2u87Oeq1Frk= =NBxz -----END PGP SIGNATURE-----

4 5

python-ldap validate LDAPObject.modify_ext_s
by Sam Culley 31 Jul '18

31 Jul '18

I am trying to research how I can validate/verify executing an LDAPObject.modify_ext_s request in Python. If I print the response of the result it returns (103, [], 3, []) But I can't find much documentation on what that means? Any ideas? Regards, Sam

2 1

Syncrepl + suffixmassage + uniqueMember
by Steffen Kaiser 27 Jul '18

27 Jul '18

Hi, currently we have three OpenLDAP servers in multi-master mode and with MemberOf . Currently, the base DN is dc=oldorgname,dc=de. The name of the organization changed and all entries should be accessable through base dc=neworgname,dc=de and all attributes with DNs as value shall return this new base. First I tried relay with rwm in this configuration: dn: cn=module{1},cn=config changetype: modify add: olcmoduleload olcModuleLoad: back_relay.la dn: olcDatabase={2}relay,cn=config changetype: add objectClass: olcRelayConfig olcSuffix: dc=neworgname,dc=de olcRelay: dc=oldorgname,dc=de dn: olcOverlay=rwm,olcDatabase={2}relay,cn=config changetype: add objectClass: olcRwmConfig olcRwmRewrite: rwm-suffixmassage "dc=oldorgname,dc=de" But this caused slapd to dump core at different entries, when I query the whole database as administrator pulling all attributes. As this module is "experimental", so I went another way. Should I try another config? Second, I tried to create a consumer server with a separate database using and suffixmassage. olcSyncrepl: {2}rid=004 provider=ldap://server:389/ bindmethod=simpl e binddn="cn=dn" credentials="pwd" s earchbase="dc=oldorgname,dc=de" scope=sub schemachecking=on type=re freshAndPersist retry="5 2 30 2 60 +" interval=00:00:00:30 timeout=0 network-time out=0 keepalive=0:0:0 attrs="*,+" suffixmassage="dc=neworgname,dc=de" The sync proceeded, but I ended with uniqueMember attributes with the old base: dn: cn=team,ou=groups,dc=ou,dc=neworgname,dc=de uniqueMember: uid=user,ou=peolple,dc=ou,dc=oldorgname,dc=de The value of the attribute "member" gets rewritten into the new orgname. Ist this a bug or intentional behaviour? Kind regards, -- Steffen Kaiser

2 1

Re: Replication mutli-master via DNS record ?
by Lirien Maxime 27 Jul '18

27 Jul '18

Thanks Quanah. On Thu, Jul 26, 2018 at 10:20 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Thursday, July 26, 2018 4:28 PM +0200 Lirien Maxime < > maxime.lirien(a)gmail.com> wrote: > > b) Master to multi-master >> >> Mirrormode is set to TRUE. >> Can I use only one "syncrepl" with the DNS record ldap://master.toto.fr >> Or should I set one "syncrepl" for each master ? >> > > One syncrepl to each master. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

1 0

Replication mutli-master via DNS record ?
by Lirien Maxime 26 Jul '18

26 Jul '18

Hi all, I have 3 masters and 3 slaves. Two DNS records : - Masters are recorded under master.toto.fr - Slave are recorded under slave.toto.fr Two type of replication : a) Slave to master Slaves replicate from one of 3 master with this configuration : syncrepl rid=100 provider=ldap://master.toto.fr/ type=refreshAndPersist interval=00:00:30:00 [...] b) Master to multi-master Mirrormode is set to TRUE. Can I use only one "syncrepl" with the DNS record ldap://master.toto.fr Or should I set one "syncrepl" for each master ? I mean , in my master1 conf file can I use this : syncrepl rid=1 provider=ldap://master.toto.fr/ type=refreshAndPersist interval=00:00:30:00 [...] or syncrepl rid=12 provider=ldap://IP_master2.toto.fr/ type=refreshAndPersist interval=00:00:30:00 [...] syncrepl rid=13 provider=ldap://IP_master3.toto.fr/ type=refreshAndPersist interval=00:00:30:00 [...] Thanks guys.

2 1

ldapmodify -Y EXTERNAL failure - Confidentiality required (13)
by Mark Foster 26 Jul '18

26 Jul '18

This used to work... $ sudo ldapmodify -Y EXTERNAL -f 30logging.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" ldap_modify: Confidentiality required (13) additional info: stronger confidentiality required The log says slapd[1266]: conn=6619437 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=71 This is my olcSecurity setting: olcSecurity: ssf=128 simple_bind=128 How would I fix this? It seems to be a catch-22.

3 2

Re: AW:ldap server stops responding periodically?
by John Jasen 23 Jul '18

23 Jul '18

On 07/20/2018 04:41 AM, Ulrich.Windl(a)rz.uni-regensburg.de wrote: > Hi! > > Stupid question: could it be your load-balancer that had a problem? > How does the netstat look like (sockets opened, queued data, etc.?) I do not believe it to be the load-balancer. They log loss of contact with the LDAP servers and drop them from the relay group shortly after one of these events start; and when it gets cleaned up, they're added back in. I also do not suspect network between the load balancers and the LDAP servers. During such an event, ps -efT will usually show slapd running at full thread capacity. Comparing that to threads in cn=monitor is not possible, as those ldap searches fail. Open sockets does not substantially change until after the event subsides. The servers will show 1200-2000 open sockets before an event, and drop lower when it clears up -- to quickly scale back up to pre-event levels. The queues will show data being held until the socket(s) time out. Thanks for the feedback!

2 1

Re: ldap server stops responding periodically? WAS: openldap-technical Digest, Vol 128, Issue 12
by John Jasen 21 Jul '18

21 Jul '18

On 07/21/2018 08:00 AM, openldap-technical-request(a)openldap.org wrote: > From: Ryan Tandy <ryan(a)nardis.ca> To: openldap-technical(a)openldap.org > Subject: Re: ldap server stops responding periodically? Message-ID: > <20180720185004.po4pckupxyjrrih4(a)comet.nardis.ca> Content-Type: > text/plain; charset=iso-8859-1; format=flowed On Fri, Jul 20, 2018 at > 08:39:55PM +0200, Dieter Kl?nter wrote: >> If that really is 2.4.4 > Given the mention of "CentOS7 stock RPM" I would expect this was a typo > and John is actually running 2.4.44. Yes, my apologies. I meant 2.4.44. -- John Jasen

1 0

back-ldap redirect RootDSE? RWM re-encode attributes?
by B Galliart 21 Jul '18

21 Jul '18

I am trying to use OpenLDAP slapd to proxy to multiple LDAP servers but run into some issues with how the LDAP client application is written. I wondered if anyone has any suggestions for doing either of the following with slapd: (1) Can the back-ldap suffix override the RootDSE of the OpenLDAP server so that all RootDSE requests get proxied? (2) Is there a way with the RWM or a different overlay to convert specific attributes to hex or MIME before passing it back to the LDAP client? For example, if an attribute is given to back-ldap as a BLOB, can it convert the BLOB to hex before passing it along? It would be nice to have the option to do both of the above but for my current situation being able to do just one or the other would work. Thanks

1 0

ldap server stops responding periodically?
by John Jasen 20 Jul '18

20 Jul '18

Summary: an openldap 2.4.4 (CentOS7 stock RPM) replication consumer slapd server stops responding to requests for a period of up to fifteen minutes. Environment: Two centos7 ldap servers in mirror mode, providers to 4 openldap syncrepl consumers. The systems are 2 CPU, 12 core Intel Xeon E5-2420s, and have 48GB of RAM. The four consumers are load-balanced through a FreeBSD "relayd" redirector, facing approximately six thousand clients. Problem: Periodically, one or more (or all) of the consumers will stop responding, including localhost cn=monitoring traffic and anything over the network. Note, only slapd stops responding. email out, logging in, etc, all remain unaffected. Analysis after the event starts doesn't show anything unusual in CPU usage or memory. Analysis of the ldap logs doesn't show anything unusual in number of requests, number of connects, etc until the system stops responding -- at which point, they drop to zero. I'm stumped as to a) what's causing it, and b) how to address it on the slapd side so my servers stop dozing off. Any suggestions? -- John Jasen (jjasen(a)gmail.com)

4 3

Re: ldap server stops responding periodically? WAS: openldap-technical Digest, Vol 128, Issue 11
by John Jasen 20 Jul '18

20 Jul '18

On 07/20/2018 08:00 AM, openldap-technical-request(a)openldap.org wrote: > Date: Thu, 19 Jul 2018 13:50:47 -0500 From: Andy Dorman > <adorman(a)ironicdesign.com> To: openldap-technical(a)openldap.org > Subject: Re: ldap server stops responding periodically? Message-ID: > <6ca235e9-10e6-df27-f06c-359875407a6b(a)ironicdesign.com> Content-Type: > text/plain; charset=utf-8; format=flowed > <snip> > So when this happens you can still log into the consumer and run typical > slapdump/slapcat, ldapsearch, etc. commands with no problem? or are you > only losing access via the network? I've not tried slap* commands on an afflicted consumer, nor have I tried locally through ldapi:/// Both are good ideas. Thank you. local lapsearch, etc with a URL to the listening network socket fail from localhost as well.

1 0

Where does the debugging message come from?
by Ray Lauff 16 Jul '18

16 Jul '18

Hello- I'm testing out some local mods I've made to the ldapsearch command and I have the -d 2 flag to enable debugging set. /usr/local/src/openldap/openldap-2.4.46/clients/tools/ldapsearch -h ldap-test1.test.org -p 11389 -ZZ -D cn=somecn -w somepw -b 'dc=test,dc=org' '(uid=husk)' -d 2 When I run this, I get a lot of what I need, but I noticed the following is emitted at the top. *Using CA cert /etc/openldap/cacerts/ca-bundle.crt as stipulated by environment variable $LDAPTLS_CACERT.* I was looking to see where in the openldap code this string comes from, but I can't seem to find it. (I thought a thorough 'grepping' would locate it, but it did not, nor does strings /usr/local/src/openldap/openldap-2.4.46/clients/tools/ldapsearch |grep "stipulated" ). So it's from the ssl library I assumed. Nope, didn't find it there either. Can someone point me to where it comes from please? Sorry if this is a dumb question that I should already know.

2 1

Is checkpoint required any more?
by Geoff Swan 11 Jul '18

11 Jul '18

I am running openldap-2.4.44 (source build) using lmdb backend with configuration set in slapd.conf on a Linux machine. The configuration includes dbnosync and also checkpoint settings. The kernel vm settings are flushing dirty cache pages to disc periodically, so my question is what is the reason for the checkpoint setting if the kernel is already taking care of page flushing?

2 1

OpenSLP anyone?
by Michael Ströder 09 Jul '18

09 Jul '18

HI! Is anybody here using OpenSLP with OpenLDAP libs to locate LDAP directory servers? I never used it and I only vaguely remember that Novell eDirectory instances was announced via SLP. But I don't know of any clients supporting that and therefore I wonder whether Linux distros should package libldap with SLP support. Ciao, Michael.

2 1

back-mdb and alias dereferencing
by Henrik Bohnenkamp 07 Jul '18

07 Jul '18

Hi, I would like to bring up the problem with back-mdb and alias-dereferening again. There is Bug ITS#7657 for this already, and in http://www.openldap.org/lists/openldap-technical/201504/msg00008.html the problem was also addressed. Probably in other places as well, but I did not find anything else in the archives. I would like to reconfigure all my LDAP clusters to use back-mdb, however, I can't: my LDAP tree has about 2 Mio entries, 600000 of which are alias entries. I observe that when using back-mdb and making search request with search scope "sub" and deref=always, than this search request will take seconds before a response... in contrast, with deref=never, the same search request takes only millisecs. It does not matter whether there are aliases in the search scope or not... with deref=always it always takes seconds, each request keeping one CPU thread very busy. So if many requests come in with sub/always (which unfortunately happens a lot because many LDAP clients just set deref=always as a default) it is a sure way to bring down an LDAP cluster configured with back-mdb. The problem has haunted me for a while (incidents, incidents :-), and I have tried to find out where it comes from. I would like to share my conjectures here. A search request with sub/always eventually ends up in the function search_aliases(..), located in back-mdb/search.c (code/linenumbers is from v2.4.46 ): 157 /* Find all aliases in database */ 158 MDB_IDL_ZERO( aliases ); 159 rs->sr_err = mdb_filter_candidates( op, isc->mt, &af, aliases, 160 curscop, visited ); 161 if (rs->sr_err != LDAP_SUCCESS || MDB_IDL_IS_ZERO( aliases )) { 162 return rs->sr_err; 163 } 164 oldsubs[0] = 1; 165 oldsubs[1] = e_id; 166 167 MDB_IDL_ZERO( visited ); 168 MDB_IDL_ZERO( newsubs ); 169 170 cursoro = 0; 171 ido = mdb_idl_first( oldsubs, &cursoro ); 172 173 for (;;) { 174 /* Set curscop to only the aliases in the current scope. Start with 175 * all the aliases, then get the intersection with the scope. 176 */ 177 rs->sr_err = mdb_idscope( op, isc->mt, e_id, aliases, curscop ); After adding a bit of extra debug code, I could see in the logs that the time is actually spent in line 177, i.e. the mdb_idscope function. What I believe is happening is the following: in line 159 the index list of all aliases in the DB is constructed and put into the "aliases" list. The list comes from the objectClass index, but since there are so many alias entries, the index contains not an explicit list, but a range... a range that covers basically *all* 2 Mio entries in the DB. (this happens also with the hdb backend, so the fact that "aliases" is a range is perhaps part, but not cause of the problem). Then the for loop is entered in 173, and mdb_idscope in 177 is called. The idea there is to compute the intersection of alias list "aliases" and search scope, i.e. get all aliases that are in the actual search scope. This is done by walking through the 2 millions indexes represented by the range in "aliases", and deciding whether the id is in the scope or not. This, if I understand correctly, by walking up the LDAP tree from leaf towards root (actually walking up the structure of the dn2id DB) ... if we encounter the search base on the way, the alias is part of the search scope, if we reach the root, then not. Computing this intersection is what costs time, and it does not depend on whether the intersection is empty or not. Apparently it is done differently in back_hdb and by extension, back_bdb. I have not analysed that code there in detail but I believe the intersection is computed by actually looking at 2 different ID lists, one containing the aliases (range) again, the other one the actual IDs of the search scope. Which, it appears, is more efficient. So the problem seems to be to compute the relevant aliases to start expanding from. The way it is done now the complexity seems to be linear in the number of aliases, if not number of entries on the LDAP tree. For my own use cases at least it would be much more efficient to just do a tree traversal of the search scope, pick up the relevant aliases and put them in the list. I believe even for large trees this would work quite well... if I search my whole tree for entries with objectClass=alias (deref=never, of course), this is amazingly fast. I am currently looking into how something like that could be implemented, but I need to dive much deeper in the code before I could come up with something worth considering. What are the views of the developers on this? Does the analysis sound plausible? Could a fix be easily obtained? I'm willing to try out any patch thrown my way. Somewhere is written that mdb will replace hdb/bdb eventually ... I believe this problem needs a fix before that can happen. Henrik -- Henrik Bohnenkamp Senior Sysadmin Linux & Applications Operation United Internet Corporate Services GmbH | Brauerstraße 50 | 76135 Karlsruhe | Germany Phone: +49 721 91374 - 4159 E-mail: hbohnenkamp atatatat united-internet.de | Web: www.united-internet.de Amtsgericht Montabaur / HRB 23031 Geschäftsführer: Verena Amann, Markus Kadelke, Frank Krause, Guido Mannshausen Member of United Internet This e-mail may contain confidential and/or privileged information. If you are not the intended recipient of this e-mail, you are hereby notified that saving, distribution or use of the content of this e-mail in any way is prohibited. If you have received this e-mail in error, please notify the sender and delete the e-mail.

2 2

Fixing slapo-nops (ITS#8759)
by manu＠netbsd.org 06 Jul '18

06 Jul '18

Hello Following ITS#8759, I am looking for ideas about how to fix slapo-nops. This overlays suppress nilpotent operations that replace an attribute values by the same values. The code is in contrib/slapd-modules/nops/nops.c The problem is that slapo-nops assumes it can free the nilpotent struct Modifications after removing them from the list, but for instande slapo-memberof uses struct Modifications allocated on the stack. Not freeing in slapo-nops is not a fix, since unlinked struct Modifications will not be freed anywhere else, and we will get a memory leak. Would it make sense to add a SLAP_MOD_ONSTACK flag in struct Modification's sm_flags so that we can tell the difference? Any other idea? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

2 1

slapd crashes on startup
by BÖSCH Christian 06 Jul '18

06 Jul '18

Hi, I have 2 nodes in multimaster setup. Node1 doesn’t startup anymore and crashes. In debug mode the last lines are: 5b3f6b78 <= index_entry_del( 1121725, "uid=jst9897,ou=ais2ldap,o=abc.at" ) success ./../../../libraries/liblmdb/mdb.c:5276: Assertion 'NUMKEYS(mp) > 1' failed in mdb_page_search_root() Abort What does that mean, and what to do to get online again and have the DB in sync with Node2? Thanks in advance, Christian

2 4

Client IP in Loadbalanced configuration
by Pascal kolijn 06 Jul '18

06 Jul '18

List, I have a haproxy loadbalanced ldap service. I would like to see the 'original' client IP in the openldapserver log files, because now I only see the haproxies IP addresses for all sessions. I understand that haproxy has a 'feature' called the PROXY protocol [https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt] that adds the original IP as metadata somewhere in the request, I had hopes that this would work with openldap >= 2.3, because they tested such a PROXY protocol signature packet. But it is not, yet(?), implemented in openldap. I also understand that the slapd-ldap backend has a option called session-tracking-request so some serverside/backend side stuff seems to be available somewhere in openldap.. So any pointers or tips to achieve this, or use a different setup? -- Pascal Kolijn Vrije Universiteit Amsterdam

2 1

time-base release schedule?
by David Magda 03 Jul '18

03 Jul '18

Hello, Would it be possible to moved to a timed release schedule? Looking at the ChangeLog, the current release 'schedule' seems to be a bit... non-deterministic: http://www.openldap.org/software/release/changes.html Moving towards a fixed-date schedule (once or twice a year?) would allow downstream maintainers to update things like Linux distributions in a more predictable fashion. The "maintenance releases" would be nothing more than tagging all of the patches since the last release and creating a tarball. If there are zero patches since the last releases, then a new tarball may not be needed (or a "NOP release" could be done just to keep people in-practice). Otherwise, regardless of whether is is one or one-dozen patches, a new version is revved. If there is a security issue, a release could be issued outside of the fixed schedule. Ideally (IMHO) security releases would only include the security fix so people can be confident that it is a low-risk change that won't change / break other behaviours. Given that most users of OpenLDAP "consume" it via their distribution-of-choice's package, this would (IMHO) increase the chances of more recent versions of OpenLDAP being used (especially in Debian and Ubuntu, but also Fedora). Recent Debian releases occur in Q2, and Ubuntu does April/October (LTSes are April), while Fedora (roughly) does May/November. Perhaps a February/September cycle? Not sure whether this is something for 2.4, or for 2.5 when it comes out. Any thoughts? Regards, David

5 8

LMDB docs
by KS Sreeram 03 Jul '18

03 Jul '18

Hello folks On this page: http://www.lmdb.tech/doc/starting.html The following passage occurs: > Because LMDB is very efficient (and usually zero-copy), the data returned in an MDB_val structure may be memory-mapped straight from disk. In other words look but do not touch (or free() for that matter). Once a transaction is closed, the values can no longer be used, so make a copy if you need to keep them after that. The second sentence above is a bit misleading. Returned data cannot be used after a subsequent update. Not mentioning that is misleading. Perhaps the second sentence can be replace with this: > The values can no longer be used after a subsequent update or after the transaction ends. Make a copy if you need to keep them after that. The documentation for `mdb_get` is correct and does mention the constraints. It’ll be nice to update this page too. Best KS Sreeram

1 0

test059-slave-config schema replication
by Richard Gray 03 Jul '18

03 Jul '18

Hi, I am trying to get cn=config replication working as demonstrated by the test059-slave-config test script, but have run into a problem with schema replication. This is the same issue raised on the list previously by Christopher Strider Cook [1], but I thought I'd bring it up again as it's been seven years, so perhaps there are new ideas in this space. Furthermore, I can demonstrate how to reproduce the problem with a simpler configuration than that described by Christopher. [1]: https://www.openldap.org/lists/openldap-technical/201106/msg00157.html test059-slave-config describes two configuration trees, cn=config as used by a master server, and cn=config,cn=slave which is replicated to any number of replica servers. Furthermore, there is a syncrepl agreement defined on the cn=config,cn=slave database that replicates the master schema from cn=schema,cn=config into the replica configuration tree as cn=schema,cn=config,cn=slave. If you make any changes to the cn=config,cn=slave tree however, the next time the master is restarted, it will complain that the "consumer state is newer than provider". At this point, I'm considering ditching the schema replication, and maintaining it independently on the master and replica servers. It's probably not much of an imposition seeing as I will need to maintain the rest of the master and replica configuration independently anyway. Nevertheless, I thought I'd raise the issue here to see if anyone had any clever solutions to this problem. Here's how to reproduce the issue (OpenLDAP 2.4.46 on Linux 4.15.12): 1. Download and build OpenLDAP 2. Run test059-slave-config: ./run test059-slave-config 3. Start a slapd using the provider config created by the test script: /home/richard/working/openldap-2.4.46/tests/../servers/slapd/slapd -F /home/richard/working/openldap-2.4.46/tests/testrun/cfpro.d -h ldap://localhost:9011/ -d 0x4105 4. Make a change under cn=config,cn=slave: $ ldapadd -x -h localhost -p 9011 -D cn=config -w EMWRueBU dn: olcBackend=bdb,cn=config, cn=slave objectClass: olcBackendConfig olcBackend: bdb adding new entry "olcBackend=bdb,cn=config, cn=slave" ^C 5. Restart the slapd instance: ^C /home/richard/working/openldap-2.4.46/tests/../servers/slapd/slapd -F /home/richard/working/openldap-2.4.46/tests/testrun/cfpro.d -h ldap://localhost:9011/ -d 0x4105 ...SNIP... 5b3b0202 conn=1005 op=1 SRCH base="cn=schema,cn=config" scope=2 deref=0 filter="(objectClass=*)" 5b3b0202 conn=1005 op=1 SRCH attr=* + 5b3b0202 send_ldap_result: conn=1005 op=1 p=3 5b3b0202 send_ldap_result: err=0 matched="" text="" 5b3b0202 send_ldap_result: conn=1005 op=1 p=3 5b3b0202 send_ldap_result: err=53 matched="" text="consumer state is newer than provider!" 5b3b0202 send_ldap_response: msgid=2 tag=101 err=53 ber_flush2: 52 bytes to sd 16 read1msg: ld 0x7fd46c109ba0 msgid 2 all 0 ber_get_next 5b3b0202 conn=1005 op=1 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! ber_get_next: tag 0x30 len 50 contents: read1msg: ld 0x7fd46c109ba0 msgid 2 message type search-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x7fd46c109ba0 0 new referrals read1msg: mark request completed, ld 0x7fd46c109ba0 msgid 2 request done: ld 0x7fd46c109ba0 msgid 2 res_errno: 53, res_error: <consumer state is newer than provider!>, res_matched: <> ldap_free_request (origid 2, msgid 2) 5b3b0202 do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_err2string 5b3b0202 do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform ldap_err2string Any suggested workarounds would be appreciated. Regards, -- *Richard Gray* | Operations Technical Lead *DDI:* +64 9 950 2196 *Fax:* +64 9 302 0518 *Mobile:* +64 21 050 8178 *Freephone:*0800 SMX SMX (769 769) *SMX Limited:* Level 15, 19 Victoria Street West, Auckland, New Zealand *Web:* http://smxemail.com SMX | Cloud Email Hosting & Security _____________________________________________________________________________ This email has been filtered by SMX. For more info visit http://smxemail.com _____________________________________________________________________________

1 0

sql backend & upate data
by Arianna Milazzo 29 Jun '18

29 Jun '18

Hello! I use openLDAP with a sql backend. I use mySQL with InnoDB engine. Well, if I modify a data on db, I can't see the new value on openLDAP until I restart it. :O I can't restart openLDAP every time I modify something! Any solution? Thanks, Arianna

1 1

Performance problem with slapd instances.
by Saurabh Lahoti 28 Jun '18

28 Jun '18

Dear, We've started observing strange & peculiar performance behavior for slapd instances. While ldap bind response is more than 1.5 second on one server then on another it's just 0.006 seconds. Both the servers have similar OS, system resources & ldap version. OS: RHEL 6.9 LDAP: 2.4.44 Backend: bdb Could you please suggest some probable causes..? Thanks & Kind Regards, Saurabh Lahoti.

2 2

replicating memberOf attribute
by Chris 27 Jun '18

27 Jun '18

Hi, We are using a provider and three consumers that are not syncing the memberOf attributes of inetOrgPerson entries. memberof and refint modules are loaded on the provider and inetOrgPersons' memberOf attributes are correctly updated on the provider. How can I troubleshoot this? Thanks. Chris.

2 2

Debian getting rid of nis and adding rfc2307bis
by malcolm moore 27 Jun '18

27 Jun '18

Are there any instructions for this anywhere ? I've been seaching and struggling now for several days and I can't work out how to do it. It can't be as difficult as i am making it Ta Mal

2 1

Re: OPenLDAP instances frequently crashes
by Saurabh Lahoti 25 Jun '18

25 Jun '18

Dear, Just before crash below message logged into system logs of servers: Jun 11 23:01:37 musang kernel: Out of memory: Kill process 22184 (slapd) score 888 or sacrifice child Jun 11 23:01:37 musang kernel: Killed process 22184, UID 0, (slapd) total-vm:52226320kB, anon-rss:37170216kB, file-rss:1044kB Although, my physical RAM size is 38 GB & actual database size is 32 GB. Why is it not managing memory appropriately with the help from swap...? ---- *Thanks & Kind Regards,* Saurabh LAHOTI. On Wed, 13 Jun 2018 at 15:57, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Wednesday, June 13, 2018 8:56 AM +0200 Michael Ströder > <michael(a)stroeder.com> wrote: > > > On 06/12/2018 06:15 AM, Saurabh Lahoti wrote: > >> Frequently, our OpenLDAP instances crashes thereby leading us into > severe > >> disastrous results & outages for business. > >> > >> While going through slapd logs, it always says " bdb_db_open: database: > >> unclean shutdown detected; attempting recovery" > >> > >> What could possibly go wrong here..? > > > > Which OpenLDAP version are you using? Which OS? > > What does openldap log before it crashes? > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

3 2

Meta backend and attributes mapping
by ROY Grégory 22 Jun '18

22 Jun '18

Hello, I try somehow to do what I explain below. But without success... I think I'm doing badly for the attribute mapping, maybe it would be better with the rwm overlay? Could someone put me on the right track? -> I have this : ---------------------------------------------------------------------------------------------------------------------------------------------------- dc=domain1,dc=local dc=domain2, dc=local |__ou=users |__ou= apps |__ou=standard |__ou= app1 |__cn = JOHN DOE | |__cn = DOEJOHN |__ att: sAMAccountName= DOEJOHN | |__att: Appval=valuex |__att: phonenumber=0102030405 |__ou= app2 |__cn= DOEJOHN |__att: Appval=valuey ---------------------------------------------------------------------------------------------------------------------------------------------------- -> and i wan't to do this : ---------------------------------------------------------------------------------------------------------------------------------------------------- dc=meta,dc=local |_ou=users |_cn= DOEJOHN |_att: phonenumber=0102030405 |_att: App1val=valuex |_att: App2val=valuey ---------------------------------------------------------------------------------------------------------------------------------------------------- -> I do it this way, with the meta backend : ---------------------------------------------------------------------------------------------------------------------------------------------------- ######################################################################### defaultsearchbase dc=meta,dc=local ### database META ##################################################### database meta suffix dc=meta,dc=local rootdn "cn=admin,dc=meta,dc=local" rootpw secret ## AD1 USERS ### uri "ldap://ad.domain1.local:389/ou=users,dc=meta,dc=local" suffixmassage "ou=users,dc=meta,dc=local" "ou=users,ou=standard,dc=domain1,dc=local" idassert-bind bindmethod=simple binddn="CN=reader,DC=domain1,DC=local" credentials="password" mode=self idassert-authzFrom "dn.regex:.*" access to * by * read map attribute uid sAMAccountname ## AD2 APP 1 ############### uri "ldap://ad.domain2.local:389/ou=users,dc=meta,dc=local" suffixmassage "ou=users,dc=meta,dc=local" "ou=app1,ou=apps,dc=domain2,dc=local" idassert-bind bindmethod=simple binddn="CN=reader,DC=domain2,DC=local" credentials="password" mode=self idassert-authzFrom "dn.regex:.*" access to * by * read map attribute uid cn map attribute App1val Appval ## AD2 APP 2 ############### uri "ldap://ad.domain2.local:389/ou=users,dc=meta,dc=local" suffixmassage "ou=users,dc=meta,dc=local" "ou=app2,ou=apps,dc=domain2,dc=local" idassert-bind bindmethod=simple binddn="CN=reader,DC=domain2,DC=local" credentials="password" mode=self idassert-authzFrom "dn.regex:.*" access to * by * read map attribute uid cn map attribute App2val Appval lastmod off ---------------------------------------------------------------------------------------------------------------------------------------------------- I get this result, and it does not really correspond to what I want to get .... : ---------------------------------------------------------------------------------------------------------------------------------------------------- [root@server openldap]# ldapsearch -x "uid=DOEJOHN" -H 'ldap://localhost/' -b dc=meta,dc=local -LLL phonenumber App1val App2val dn: cn=JOHN DOE,ou=users,dc=meta,dc=local phonenumber: 0102030405 dn: cn=DOEJOHN,ou=users,dc=meta,dc=local App1val: valuex dn: cn=DOEJOHN,ou=users,dc=meta,dc=local App2val: valuey ---------------------------------------------------------------------------------------------------------------------------------------------------- Regards, -- Greg

2 2

warning about rootdn privileges
by Chris Hoogendyk 21 Jun '18

21 Jun '18

When one's Google Foo fails, turn to an appropriate list. I would like to get rid of these warnings (rootdn is always granted unlimited privileges). First, it's annoying that our cron always spits back an email. Second, one assumes that where there is a warning, there might be something that should be done differently. I've tried searching, but it seems this warning always comes up in conjunction with some other error that someone is concerned about. This particular warning is always ignored in the discussion of the error of concern as far as I have been able to find. 5b2472a5 /usr/local/etc/openldap/slapd.conf: line 170: rootdn is always granted unlimited privileges. 5b2472a5 /usr/local/etc/openldap/slapd.conf: line 293: rootdn is always granted unlimited privileges. 5b2472a5 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable 5b2472a5 /usr/local/etc/openldap/slapd.conf: line 170: rootdn is always granted unlimited privileges. 5b2472a5 /usr/local/etc/openldap/slapd.conf: line 293: rootdn is always granted unlimited privileges. 5b2472a5 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable I don't think I need to include anything about my slapd.conf, because this is more a general question of what causes this warning, and what is the recommended guidance for avoiding it. -- --------------- Chris Hoogendyk - O__ ---- Systems Administrator c/ /'_ --- Biology & Geosciences Departments (*) \(*) -- 315 Morrill Science Center ~~~~~~~~~~ - University of Massachusetts, Amherst <hoogendyk(a)bio.umass.edu> --------------- Erdös 4

2 2

About the bdb and hdb backends
by JC 20 Jun '18

20 Jun '18

I am a bit confused about the bdb and hdb backends. My understanding is that the former is based on the Berkeley database, whereas the latter uses an Oracle version of Berkeley database. In my slapd.conf configuration file there is an entry that specifies that bdb, not hdb, is to be used. However, when launching slapd, it attempts to use hdb_db_open(). Why would that be the case?

2 1

master/slave sync stops working
by Kai Wiechers 17 Jun '18

17 Jun '18

Hi List, I have trouble with my fresh setup openLDAP Master/Slave sync. The slave stops syncing every few hours with the message shown below. If I restart the slave things start working again. I monitored the network connectivity between th hosts and there is no issue with that. Debug output running slapd -d 256 -d 128 5b23c9dc do_syncrep2: rid=001 (-1) Can't contact LDAP server 5b23c9dc do_syncrepl: rid=001 rc -1 retrying (4 retries left) /var/log/syslog: Jun 15 16:14:52 ldap-server slapd[5178]: do_syncrep2: rid=001 (-1) Can't contact LDAP server Jun 15 16:14:52 ldap-server slapd[5178]: do_syncrepl: rid=001 rc -1 retrying (4 retries left) I'm running Ubuntu 16.04.4 openLDAP 2.4.42 (from Ubuntu repository) on both servers. I setup the sync using these LDIF files on master: dn: olcDatabase={1}mdb,cn=config changetype: modify delete: olcAccess olcAccess: {0} - add: olcAccess olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=admin,dc=domain,dc=com" write by dn="cn=replicator,dc=domain,dc=com" write by self write by anonymous auth by * none - delete: olcAccess olcAccess: {2} - add: olcAccess olcAccess: {2}to * by dn="cn=admin,dc=domain,dc=com" manage by dn="cn=replicator,dc=domain,dc=com" manage by self write by anonymous auth by users read dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov.la dn: olcDatabase={1}mdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: entryUUID,entryCSN eq dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov On the Slave I imported these LDIF files: dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov.la dn: olcDatabase={1}mdb,cn=config changetype: modify add: olcDbIndex olcDbIndex: entryUUID,entryCSN eq dn: olcDatabase={1}mdb,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=ldap://ldap-master.domain.com/ bindmethod=simple binddn="cn=replicator,dc=domain,dc=com" credentials=PASSWORD searchbase="dc=domain,dc=com" scope=sub schemachecking=on type=refreshAndPersist retry="30 5 300 3" interval=00:00:00:30 starttls=yes tls_reqcert=allow I'm really new to openLDAP so please let me know how to provide additional Info if you need them. Thanks and best regards, Kai

1 0

master/slave sync stops working
by Kai Wiechers 15 Jun '18

15 Jun '18

Hi List, I have trouble with my fresh setup openLDAP Master/Slave sync. The slave stops syncing every few hours with the message shown below. If I restart the slave things start working again. I monitored the network connectivity between th hosts and there is no issue with that. Debug output running slapd -d 256 -d 128 5b23c9dc do_syncrep2: rid=001 (-1) Can't contact LDAP server 5b23c9dc do_syncrepl: rid=001 rc -1 retrying (4 retries left) /var/log/syslog Jun 15 16:14:52 ldap-server slapd[5178]: do_syncrep2: rid=001 (-1) Can't contact LDAP server Jun 15 16:14:52 ldap-server slapd[5178]: do_syncrepl: rid=001 rc -1 retrying (4 retries left) I'm running Ubuntu 16.04.4 openLDAP 2.4.42 (from Ubuntu repository) on both servers. I setup the sync using these LDIFs on the master. |dn: olcDatabase={||1||}mdb,cn=config| |changetype: modify| |delete: olcAccess| |olcAccess: {||0||}| |-| |add: olcAccess| |olcAccess: {||0||}to attrs=userPassword,shadowLastChange| | ||by dn=||"cn=admin,dc=domain,dc=com"| |write| | ||by dn=||"cn=replicator,dc=domain,dc=com"| |write| | ||by self write| | ||by anonymous auth| | ||by * none| |-| |delete: olcAccess| |olcAccess: {||2||}| |-| |add: olcAccess| |olcAccess: {||2||}to *| | ||by dn=||"cn=admin,dc=domain,dc=com"| |manage| | ||by dn=||"cn=replicator,dc=domain,dc=com"| |manage| | ||by self write| | ||by anonymous auth| | ||by users read| |dn: cn=module{||0||},cn=config| |changetype: modify| |add: olcModuleLoad| |olcModuleLoad: syncprov.la <https://confluence.2rioffice.com/display/SA/syncprov.la>| |dn: olcDatabase={||1||}mdb,cn=config| |changetype: modify| |add: olcDbIndex| |olcDbIndex: entryUUID,entryCSN eq| |dn: olcOverlay=syncprov,olcDatabase={||1||}mdb,cn=config| |changetype: add| |objectClass: olcOverlayConfig| |objectClass: olcSyncProvConfig| |olcOverlay: syncprov| On the Slave I imported these LDIFs |dn: cn=module{||0||},cn=config| |changetype: modify| |add: olcModuleLoad| |olcModuleLoad: syncprov.la <https://confluence.2rioffice.com/display/SA/syncprov.la>| |dn: olcDatabase={||1||}mdb,cn=config| |changetype: modify| |add: olcDbIndex| |olcDbIndex: entryUUID,entryCSN eq| |dn: olcDatabase={||1||}mdb,cn=config| |changetype: modify| |add: olcSyncRepl| |olcSyncRepl: rid=||001| | ||provider=ldap:||//ldap-master.domain.com/ <https://confluence.2rioffice.com/display/SA/ldap-grev-ham-de.2rioffice.com/>| | ||bindmethod=simple| | ||binddn=||"cn=replicator,dc=domain,dc=com"| | ||credentials=PASSWORD| | ||searchbase=||"dc=domain,dc=com"| | ||scope=sub| | ||schemachecking=on| | ||type=refreshAndPersist| | ||retry=||"30 5 300 3"| | ||interval=||00||:||00||:||00||:||30| | ||starttls=yes| | ||tls_reqcert=allow| I'm really new to openLDAP so please let me know how to provide additional Info if you need them. Thanks and best regards, Kai

1 0

monitoring response queue (was: (ITS#8852) slapd memory use grows..)
by Michael Ströder 15 Jun '18

15 Jun '18

On 05/19/2018 08:18 AM, hyc(a)symas.com wrote: > I've run your reproducer and see no memory leak. The response queue will > indeed grow without bound if the consumer runs slower than the provider, and > doesn't read responses fast enough. But in the case of this test script, > eventually the client finishes and the consumer catches up. How to monitor this response queue? The reason I'm asking: I see memory growth on customer's Æ-DIR providers and I'd like to track down the reason for it eventually by excluding other possible causes. Ciao, Michael.

2 1

olcDBMap error
by w.turner＠mailoo.org 14 Jun '18

14 Jun '18

Hello, I am trying to update my LDAAP configuration to use cn=config. For this, I have converted my slapd.config file to a cn=config using the the slaptest command. After it had finished converting, the terminal showed multiple times the following line: warning, source attributeType 'olcDBMap:value #x' should be defined in schema Do I need to add a specific schema for this attribute ?

1 0

Re: OPenLDAP instances frequently crashes
by Saurabh Lahoti 13 Jun '18

13 Jun '18

Dear, Firstly, would like to sincerely extend my gratitude for illustrative explanation & clarity on slapd instability problem. Indeed, your correlations with our symptoms truly solves this jigsaw puzzle. To conclude on this discussion, does OS flavor affects the slapd operations & management. Earlier we were on Solaris & recently moved to RHEL. And we had ensure exact replica of Solaris is taken into RHEL with CPU, RAM, HDD & other system parameters. On Solaris our LDAP environment was pretty much quiet & stable. It was this migration post which we started encountering memory problem & instability of instances. Kindly suggest your advice.. ---- *Thanks & Kind Regards,* Saurabh LAHOTI. On Wed, 13 Jun 2018 at 22:57, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Wednesday, June 13, 2018 11:30 PM +0200 Saurabh Lahoti > <saurabh.astronomy(a)gmail.com> wrote: > > > Jun 11 23:01:37 musang kernel: Out of memory: Kill process 22184 (slapd) > > score 888 or sacrifice child > > Jun 11 23:01:37 musang kernel: Killed process 22184, UID 0, (slapd) > > total-vm:52226320kB, anon-rss:37170216kB, file-rss:1044kB > > This is not slapd crashing. This is linux OOM deciding to kill slapd for > you because your system ran out of memory, and slapd was the last thing to > ask for more memory. The total memory requirements for slapd are not > limited to just what's stored in the database. And, given that you're > using back-bdb or back-hdb, the memory requirements are significantly > higher than the size of the DB, as slapd has to have multiple caches (at > least 3) to help overcome performance issues in BDB (dncache, idlcache, > entrycache). > > Add more memory. Better, yet, ensure you are running the latest version > of > OpenLDAP and switch to back-mdb, which has significantly smaller memory > requirements than back-bdb/hdb. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > >

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical