openldap-technical March 2017

openldap-technical@openldap.org

33 participants
56 discussions

Possible to rebind-as-user with chain overlay using TLS client certificates?
by Matthew Kemp 21 Mar '17

21 Mar '17

Hey all, We've got a fairly straightforward producer/consumer setup with a single producer and multiple syncrepl consumers configured with an updateref back to the producer. The consumers are set up to use the chain overlay with the ldap backend for transparent password updates. We use TLS client certificates to authenticate the clients to the consumers and the consumers to the producers with SASL EXTERNAL binds. However, I've been struggling with configuring what I had hoped would be a simple part of the setup. We would like the ability to have the user simple bind as themselves to the consumer and then have the chain overlay transparently follow the updateref back to the producer and rebind as the user there to do the PASSMOD update. For whatever reason, I haven't been successful at making that happen. I've tried several attempts at various back_ldap configurations, to no avail. By playing with the olcDbIdAssertBind and various mode/flags, I can get the backend to attempt ProxyAuth (which we'd prefer not to use if possible), and alternatively I am able to get the chain to anonymously bind, but I am not able to initiate a rebind as the originating user. We're running slapd 2.4.31 under Debian Wheezy on the producer and a variety of 2.4.31 and 2.4.40 slapd consumers under Debian Wheezy and Debian Jesse, respectively. I was hoping you'd be able to shed some light whether this is even possible? Attached are the most recent configuration that I believe should work for my needs. Thanks! --- Current consumer config: dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {0}chain olcChainReturnError: TRUE structuralObjectClass: olcChainConfig dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1} frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap structuralObjectClass: olcLDAPConfig olcDbURI: ldap://ldap-primary olcDbRebindAsUser: TRUE olcDbStartTLS: start tls_cert=/etc/ssl/certs/ldap-consumer.crt tls_key=/etc/ssl/private/ldap-consumer.key tls_cacert=/usr/share/ca-certi ficates/cosmos/ldap_producer_ca_pem.crt -- Matt Kemp Production Engineer Braintree

1 0

syncrepl and the frontend database
by Andrey Klimentev 21 Mar '17

21 Mar '17

Hello. I've got a question about replicating the frontend database. Should I send syncprov on it and replicate it with cn=config and other databases? Or is it somehow handled in automated manner?

1 0

slapd-sock as overlay and PASSMOD
by Michael Ströder 20 Mar '17

20 Mar '17

HI! As said I'd like to intercept password changes (clear-text password) via back-sock used as overlay. Especially the client (Mac OS X) sends a Password Modify ext. op. Unfortunately back-sock does not send the PASSMOD itself to the external listener (which could parse the ASN.1) and therefore I have to look at the MODIFY messages. I'm using my package: https://pypi.python.org/pypi/slapdsock Problem: Everything works as expected with this configuration when rootdn is used with ldappasswd but not as normal user. Excerpt of slapd.conf: database mdb suffix "ou=realdb,dc=example,dc=org" rootdn "cn=root,ou=realdb,dc=example,dc=org" [..] overlay sock extensions binddn peername ssf connid socketpath sockoverlay-listener sockops modify Command: ldappasswd -H ldapi:// -s test uid=test1,ou=realdb,dc=example,dc=org slapd's log (LDAPI and SASL/EXTERNAL maps local user to rootdn): 58d03e84 conn=1000 fd=15 ACCEPT from PATH=/home/michael/Proj/slapd_sockd/examples/openldap/ldapi (PATH=/home/michael/Proj/slapd_sockd/examples/openldap/ldapi) 58d03e84 conn=1000 op=0 BIND dn="" method=163 58d03e84 conn=1000 op=0 BIND authcid="gidNumber=100+uidNumber=1000,cn=peercred,cn=external,cn=auth" authzid="gidNumber=100+uidNumber=1000,cn=peercred,cn=external,cn=auth" 58d03e84 conn=1000 op=0 BIND dn="cn=root,ou=realdb,dc=example,dc=org" mech=EXTERNAL sasl_ssf=0 ssf=71 58d03e84 conn=1000 op=0 RESULT tag=97 err=0 text= 58d03e84 conn=1000 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.1 58d03e84 conn=1000 op=1 PASSMOD id="uid=test1,ou=realdb,dc=example,dc=org" new 58d03e84 sock search reading line (CONTINUE ) 58d03e84 conn=1000 op=1 RESULT oid= err=0 text= 58d03e84 conn=1000 op=2 UNBIND 58d03e84 conn=1000 fd=15 closed The log of my external listener: 2017-03-20 21:41:40,620 DEBUG 140544537579816 ----- incoming request via 'openldap/sockoverlay-listener' from pid=28285 uid=1000 gid=100 ----- 2017-03-20 21:41:40,620 DEBUG 140544537579816 request_data='MODIFY\nmsgid: 2\nbinddn: cn=root,ou=realdb,dc=example,dc=org\npeername: PATH=/home/michael/Proj/slapd_sockd/examples/openldap/ldapi\nssf: 71\nconnid: 1000\nsuffix: ou=realdb,dc=example,dc=org\ndn: uid=test1,ou=realdb,dc=example,dc=org\nreplace: userPassword\nuserPassword:: dGVzdA==\n-\n\n' 2017-03-20 21:41:40,620 DEBUG 140544537579816 reqtype='MODIFY' 2017-03-20 21:41:40,620 DEBUG 140544537579816 sock_req=<slapdsock.message.MODIFYRequest object at 0x7fd3133f10d0> // {'dn': 'uid=test1,ou=realdb,dc=example,dc=org', 'binddn': u'cn=root,ou=realdb,dc=example,dc=org', 'connid': 1000, 'suffix': u'ou=realdb,dc=example,dc=org', '_linecount': 7, 'msgid': 2, '_req_lines': ['MODIFY', 'msgid: 2', 'binddn: cn=root,ou=realdb,dc=example,dc=org', 'peername: PATH=/home/michael/Proj/slapd_sockd/examples/openldap/ldapi', 'ssf: 71', 'connid: 1000', 'suffix: ou=realdb,dc=example,dc=org', 'dn: uid=test1,ou=realdb,dc=example,dc=org', 'changetype: modify', 'replace: userPassword', 'userPassword:: dGVzdA==', '-', '', ''], 'peername': u'PATH=/home/michael/Proj/slapd_sockd/examples/openldap/ldapi', 'modops': [(2, 'userPassword', ['test'])], 'reqtype': 'MODIFY', 'ssf': 71} 2017-03-20 21:41:40,620 DEBUG 140544537579816 connid=1000 msgid=2 Request not cached: cache_key=None 2017-03-20 21:41:40,620 DEBUG 140544537579816 connid=1000 msgid=2 response_str='CONTINUE\n' 2017-03-20 21:41:40,620 DEBUG 140544537579816 connid=1000 msgid=2 response_delay=0.001 So far so good. But with this command (own password change) there's no MODIFY sent to the extenal listener at all: $ ldappasswd -H ldapi://%2Fhome%2Fmichael%2FProj%2Fslapd_sockd%2Fexamples%2Fopenldap%2Fldapi -D "uid=test1,ou=realdb,dc=example,dc=org" -w test -s test23 uid=test1,ou=realdb,dc=example,dc=org ldap_parse_extended_result: Bad parameter to an ldap routine (-9) slapd's log: 58d03f05 conn=1003 fd=15 ACCEPT from PATH=/home/michael/Proj/slapd_sockd/examples/openldap/ldapi (PATH=/home/michael/Proj/slapd_sockd/examples/openldap/ldapi) 58d03f05 conn=1003 op=0 BIND dn="uid=test1,ou=realdb,dc=example,dc=org" method=128 58d03f05 conn=1003 op=0 BIND dn="uid=test1,ou=realdb,dc=example,dc=org" mech=SIMPLE ssf=0 58d03f05 conn=1003 op=0 RESULT tag=97 err=0 text= 58d03f05 conn=1003 op=1 EXT oid=1.3.6.1.4.1.4203.1.11.1 58d03f05 conn=1003 op=1 PASSMOD id="uid=test1,ou=realdb,dc=example,dc=org" new 58d03f05 conn=1003 op=1 RESULT tag=103 err=50 text= 58d03f05 conn=1003 op=1 RESULT oid= err=50 text= 58d03f05 conn=1003 op=2 UNBIND 58d03f05 conn=1003 fd=15 closed Any clue what's going on? Ciao, Michael.

1 1

slapd-sock as overlay, internal modifications
by Michael Ströder 20 Mar '17

20 Mar '17

HI! I'd like to intercept password changes (clear-text password) via back-sock used as overlay: # send all modify requests to external listener (after ppolicy checking) overlay sock extensions binddn peername ssf connid socketpath /tmp/noop-listener sockops modify What seems odd is that internal modifications done by slapo-lastbind have binddn: uid=bccb,cn=test,ou=ae-dir like the bound user and same connid (see log excerpt attached below). Shouldn't internal write operations set another binddn (e.g. to the rootdn)? Ciao, Michael. My listeners log: 2017-03-20 19:13:35,000 DEBUG 140308582867240 ----- incoming request via '/tmp/noop-listener' from pid=21348 uid=1000 gid=100 ----- 2017-03-20 19:13:35,000 DEBUG 140308582867240 request_data='MODIFY\nmsgid: 1\nbinddn: uid=bccb,cn=test,ou=ae-dir\nsuffix: ou=ae-dir\ndn: uid=bccb,cn=test,ou=ae-dir\nreplace: authTimestamp\nauthTimestamp: 20170320181334Z\n-\n\n' 2017-03-20 19:13:35,000 DEBUG 140308582867240 reqtype='MODIFY' 2017-03-20 19:13:35,000 DEBUG 140308582867240 sock_req=<slapdsock.message.MODIFYRequest object at 0x7f9c233fe250> // {'dn': 'uid=bccb,cn=test,ou=ae-dir', 'binddn': u'uid=bccb,cn=test,ou=ae-dir', 'suffix': u'ou=ae-dir', '_linecount': 4, 'msgid': 1, '_req_lines': ['MODIFY', 'msgid: 1', 'binddn: uid=bccb,cn=test,ou=ae-dir', 'suffix: ou=ae-dir', 'dn: uid=bccb,cn=test,ou=ae-dir', 'changetype: modify', 'replace: authTimestamp', 'authTimestamp: 20170320181334Z', '-', '', ''], 'modops': [(2, 'authTimestamp', ['20170320181334Z'])], 'reqtype': 'MODIFY'} 2017-03-20 19:13:35,001 DEBUG 140308582867240 msgid=1 Request not cached: cache_key=None 2017-03-20 19:13:35,001 DEBUG 140308582867240 msgid=1 response_str='CONTINUE\n' 2017-03-20 19:13:35,001 DEBUG 140308582867240 msgid=1 response_delay=0.001

1 0

[LMDB] getting MDB_CORRUPTED when deleting within a DUPSORT database
by Klaus Malorny 20 Mar '17

20 Mar '17

Hi, I am using version 0.9.20 on Linux (Ubuntu derivates, uname see [1], [2]). One of the databases is used as an index to another database and thus has been created using the MDB_DUPSORT. Running my software in a test environment, about 33 million entries were generated in this database. In order to falsify a suspicion that my software would not perform housekeeping correctly, I copied the LMDB file to my workstation and forced my software to delete all "legal" entries in order to see whether any entries remain. Unfortunately, I got an MDB_CORRUPTED during the delete operation on that database. Some more details: The deletion takes place in multiple steps, calling a function that deletes ranges in databases multiple times. The code is as follows (leaving some boilerplate code away): unsigned int dbFlags; int error = mdb_dbi_flags (txn, dbi, &dbFlags); // [...] bool isDupSort = dbFlags & MDB_DUPSORT; error = mdb_cursor_open (txn, dbi, &cursor); // [...] error = mdb_cursor_get (cursor, &ckey, &cdata, MDB_SET_RANGE); while (error != MDB_NOTFOUND) { // [...] int compResult = mdb_cmp (txn, dbi, &ckey, &ekey); if (compResult > 0 || !compResult && !endIsInclusive) break; error = mdb_cursor_del (cursor, isDupSort ? MDB_NODUPDATA : 0); // [...] error = mdb_cursor_get (cursor, &ckey, &cdata, MDB_NEXT); } mdb_cursor_close (cursor); Is this the correct way to delete the data? The MDB_CORRUPTED error occurs in the mdb_cursor_del call. Other operations on that specific database are mdb_put (with no flags) and mdb_del, supplying both key and data. One side observation: In a similar test with a lower number of entries, the database was completely emptied. However, the mdb_stat function still reported a larger number of entries for the database (5-6 digit figures). I also use the stat data to estimate the size of the database by adding all page counts and multiplying it by the page size. This puzzles me, as it is lower than I expected (it is roughly the net size of only the data part of the entries). I guess that the provided information might not be sufficient to find the problem. What additional information would be helpful? How can I test whether the database is already corrupt at the start of the deletion or whether it becomes corrupt during the deletion (I guess the latter)? Shall I attempt to write a specific test case? While I could produce the error a second time with running my software from scratch, but I don't know to which extent the data pattern affects the problem and whether I can artificially reproduce this pattern. Regards, Klaus [1] Linux aaa 4.4.0-65-generic #86-Ubuntu SMP Thu Feb 23 17:49:58 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux [2] Linux bbb 4.8.0-42-generic #45-Ubuntu SMP Wed Mar 8 20:06:06 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

1 1

no TLS 1.2 after changing certificate
by Norbert Gomes 17 Mar '17

17 Mar '17

Hi I need to change my certificate on a Openldap server (Debian Wheezy with the latest updates (slapd-2.4.31-2+deb7u2) but I'm facing a strange problem using ldaps protocol : With the old certificate, I can use TLS 1.2 Cipher, but with the new one, the TLS 1.2 is not possible I use this nmap command to see what ciphers are proposed : nmap --script ssl-enum-ciphers -p 636 <fqdn> When using the command with the old certificate, the following cipher appears (with also a TLSv1.1 cipher) : | TLSv1.2: | ciphers: | TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - A | TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: client But when doing the same command, on the same server, with only the certificate files modified, I do not have the TLSv1.2 cipher. And no other configuration change is made on the slapd.conf file. The certificates doesn't contain the cipher instructions, so I don't understand why I have this behavior. Any ideas ? Regards Norbert Gomes

1 1

Re: Antw: Re: synrepl error 69
by Quanah Gibson-Mount 16 Mar '17

16 Mar '17

--On Thursday, March 16, 2017 9:08 AM +0100 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: >> It may also indicate that the >> schema between the master and replica do not match. > Can you explain? See above. Without knowledge of the schema on both servers, nor the knowledge of what the entry looked like on the master pre-modification and the entry on the replica as it exists, and what the entry is now, everything is all speculation. The fact the master accepted the operation would generally indicate that there is a serious mismatch in some way between the master and the replica. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: ldapsearch - unexpected behavior with "-h URI -p PORT"
by Quanah Gibson-Mount 15 Mar '17

15 Mar '17

--On Thursday, March 16, 2017 8:29 AM +0900 Alexandre Rosenberg <alex(a)r42.ch> wrote: > Hello, > > I run into some unexpected behavior using ldapsearch today and believe it > is a bug. It all started with following command: Hi Alex, This definitely appears to be a bug. Please open an ITS at http://www.openldap.org/its/ Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

ldapsearch - unexpected behavior with "-h URI -p PORT"
by Alexandre Rosenberg 15 Mar '17

15 Mar '17

Hello, I run into some unexpected behavior using ldapsearch today and believe it is a bug. It all started with following command: ldapsearch -x -LLL -h ldap://localhost -p 10636 -b ${BASEDN} \ uid=${USER} -D ${BINDINGUSER} -W After checking the man page, it became clear that: 1. '-h' should take a *hostname* as argument (not "ldap://...") 2. Using '-H' (+ URI) is recommended instead of '-h'/'-p' And sure enough following command works as expected: ldapsearch -x -LLL -H ldap://localhost:10636 (...) The actual issue is what happens when running the fist command. - The "-h" option takes a hostname. As "ldap://localhost" is *not* a valid hostname, I would expect the command the fail - What happens instead is that ldapsearch connect to localhost on port 389 (!) $ ldapsearch -x -d 255 -h ldap://localhost -p 10389 ldap_create ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:389 Note this *only* happens when both '-h' and '-p' are used. When only '-h' is used, following happens which seem fine: $ ldapsearch -x -d 255 -h ldap://localhost ldap_create ldap_url_parse_ext(ldap://ldap:%2F%2Flocalhost) ldap_err2string Could not create LDAP session handle for URI=ldap://ldap: %2F%2Flocalhost (-9): Bad parameter to an ldap routine Bellow are some more example: 1. $ ldapsearch -x -d 255 -h example.org -p 10636 -> Connects to example.org on port 10636 (as expected) 2. $ ldapsearch -x -d 255 -h /example.org -p 10636 -> Connects to localhost on port 389 (!) - note the added "/" 3. $ ldapsearch -x -d 255 -h /example.org -> Fails as "/example.org" is not resolvable (as expected) Running the command will give you the debug output (which I omitted here). Note I am using openldap 2.4.44. I hope the explanation is clear. The behavior must definitely looks like a bug to me and got me very confused. Best, Alex

1 0

Re: synrepl error 69
by Quanah Gibson-Mount 15 Mar '17

15 Mar '17

--On Wednesday, March 15, 2017 2:17 PM +0100 Sami <s.aitalioulahcen(a)cnrst.ma> wrote: > Hello Openldap community, > > I have an openldap syncrepl consumer that started producing this error: > > Mar 15 11:52:47 ldap-replic.domain.local slapd[27770]: syncrepl_entry: > rid=xxx be_add uid=xxxxx,ou=myou,dc=domain,dc=xx failed (69) > Mar 15 11:52:47 ldap-replic.domain.local slapd[27770]: do_syncrepl: > rid=xxx rc 69 retrying decimal 69 is hex 45. Hex 45 is: LDAP_NO_OBJECT_CLASS_MODS which is: Indicates that the modify operation attempted to modify the structure rules of an object class. Generally, it sounds like you're attempting to change the structural makeup of the object in question (say, changing from an "inetOrgPerson" to an "account" or similar action). It may also indicate that the schema between the master and replica do not match. Hope that helps! Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical March 2017