syncrepl and the frontend database
by Andrey Klimentev
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?
6 years
slapd-sock as overlay and PASSMOD
by Michael Ströder
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.
6 years
slapd-sock as overlay, internal modifications
by Michael Ströder
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
6 years
[LMDB] getting MDB_CORRUPTED when deleting within a DUPSORT database
by Klaus Malorny
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
6 years
no TLS 1.2 after changing certificate
by Norbert Gomes
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
6 years
Re: Antw: Re: synrepl error 69
by Quanah Gibson-Mount
--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>
6 years
Re: ldapsearch - unexpected behavior with "-h URI -p PORT"
by Quanah Gibson-Mount
--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>
6 years
ldapsearch - unexpected behavior with "-h URI -p PORT"
by Alexandre Rosenberg
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
6 years
Re: synrepl error 69
by Quanah Gibson-Mount
--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>
6 years
synrepl error 69
by Sami
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
I have a simple provider/consumer replication configured:
olcSyncrepl: {0}rid=xxx provider=ldap://<provider>:389 bindmethod=simple b
inddn="uid=<replicator>,ou=myou,dc=domain,dc=xx" credentials=secret se
archbase="dc=domain,dc=xx" scope=sub schemachecking=on
type=refreshAndPersis
t retry="5 10 300 +"
I couldn't find the error code on search engines. I'd like to know the
possible causes/solutions to this.
Thank you !
6 years
