Re: Regression after ITS#8427 fix with back-ldap
by a.chelouah＠gmail.com
This is a multi-part message in MIME format.
--------------AC617754E4A0ACE1B2AD0EAA
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Le 09/07/2019 à 14:14, ondra(a)mistotebe.net a écrit :
> On Thu, Jun 27, 2019 at 08:08:19PM +0000, a.chelouah(a)gmail.com wrote:
>> Hello,
>>
>> Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set up
>> TLS settings on each reconnection) introduce a regression when the proxy
>> connect to the**Backend ldap server via ldaps://
>>
>> The relevent part of my config is:
>>
>> dn: olcDatabase={2}ldap,cn=config
>> objectClass: olcDatabaseConfig
>> objectClass: olcLDAPConfig
>> olcDatabase: {2}ldap
>> olcSuffix: dc=local
>> olcDbURI: ldaps://ldap.local
>> olcDbChaseReferrals: TRUE
>> olcDbRebindAsUser: TRUE
>> olcDbIDAssertBind: bindmethod=none tls_cacert=/etc/pki/tls/certs/ca.crt
>> olcDbIDAssertAuthzFrom: "*"
>>
>> (I also tried by setting LDAPTLS_CACERT env var when starting slapd)
>>
>> On backend ldap server logs, I get the message "TLS negociation failure"
> I've set up a test script here
> https://github.com/mistotebe/openldap/tree/its8427-regression
>
> This runs without issues but if you replace olcDbStartTLS with an
> analogous olcDbIDAssertBind in the configs, it seems the CA certificate
> is not set for the connection.
>
> I guess we've introduced a behaviour change with ITS#8427, not sure what
> the documentation implies should happen in these cases, whether the new
> behaviour is inconsistent with it or you've been relying on incorrect
> behaviour that has since been corrected.
>
> Regards,
>
I confirm that using the configuration
dn: olcDatabase={2}ldap,cn=config
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
olcDatabase: {2}ldap
olcSuffix: dc=local
olcDbURI:ldaps://ldap.local
olcDbChaseReferrals: TRUE
olcDbRebindAsUser: TRUE
olcDbIDAssertAuthzFrom: "*"
olcDbStartTLS: ldaps tls_cacert=/etc/pki/tls/certs/ca.crt
/i.e/,removing olcDbIDAssertBind, test is running without issue.
Regards.
--------------AC617754E4A0ACE1B2AD0EAA
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Le 09/07/2019 à 14:14,
<a class="moz-txt-link-abbreviated" href="mailto:ondra@mistotebe.net">ondra(a)mistotebe.net</a> a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:E1hkp0a-0005zG-VU@gauss.openldap.net">
<pre class="moz-quote-pre" wrap="">On Thu, Jun 27, 2019 at 08:08:19PM +0000, <a class="moz-txt-link-abbreviated" href="mailto:a.chelouah@gmail.com">a.chelouah(a)gmail.com</a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hello,
Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set up
TLS settings on each reconnection) introduce a regression when the proxy
connect to the**Backend ldap server via <a class="moz-txt-link-freetext" href="ldaps://">ldaps://</a>
The relevent part of my config is:
dn: olcDatabase={2}ldap,cn=config
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
olcDatabase: {2}ldap
olcSuffix: dc=local
olcDbURI: <a class="moz-txt-link-freetext" href="ldaps://ldap.local">ldaps://ldap.local</a>
olcDbChaseReferrals: TRUE
olcDbRebindAsUser: TRUE
olcDbIDAssertBind: bindmethod=none tls_cacert=/etc/pki/tls/certs/ca.crt
olcDbIDAssertAuthzFrom: "*"
(I also tried by setting LDAPTLS_CACERT env var when starting slapd)
On backend ldap server logs, I get the message "TLS negociation failure"
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I've set up a test script here
<a class="moz-txt-link-freetext" href="https://github.com/mistotebe/openldap/tree/its8427-regression">https://github.com/mistotebe/openldap/tree/its8427-regression</a>
This runs without issues but if you replace olcDbStartTLS with an
analogous olcDbIDAssertBind in the configs, it seems the CA certificate
is not set for the connection.
I guess we've introduced a behaviour change with ITS#8427, not sure what
the documentation implies should happen in these cases, whether the new
behaviour is inconsistent with it or you've been relying on incorrect
behaviour that has since been corrected.
Regards,
</pre>
</blockquote>
<p>I confirm that using the configuration</p>
<pre class="moz-quote-pre" wrap="">dn: olcDatabase={2}ldap,cn=config
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
olcDatabase: {2}ldap
olcSuffix: dc=local
olcDbURI: <a class="moz-txt-link-freetext">ldaps://ldap.local</a>
olcDbChaseReferrals: TRUE
olcDbRebindAsUser: TRUE
olcDbIDAssertAuthzFrom: "*"
olcDbStartTLS: ldaps tls_cacert=/etc/pki/tls/certs/ca.crt
</pre>
<p><i>i.e</i>,removing <font size="-1" face="Courier New, Courier,
monospace">olcDbIDAssertBind</font>, test is running without
issue.<br>
</p>
<pre class="moz-quote-pre" wrap="">
</pre>
<p>Regards.</p>
<pre class="moz-quote-pre" wrap="">
</pre>
<p><br>
</p>
</body>
</html>
--------------AC617754E4A0ACE1B2AD0EAA--
4 years, 2 months
Re: Regression after ITS#8427 fix with back-ldap
by ondra＠mistotebe.net
On Thu, Jun 27, 2019 at 08:08:19PM +0000, a.chelouah(a)gmail.com wrote:
> Hello,
>
> Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set up
> TLS settings on each reconnection) introduce a regression when the proxy
> connect to the**Backend ldap server via ldaps://
>
> The relevent part of my config is:
>
> dn: olcDatabase={2}ldap,cn=config
> objectClass: olcDatabaseConfig
> objectClass: olcLDAPConfig
> olcDatabase: {2}ldap
> olcSuffix: dc=local
> olcDbURI: ldaps://ldap.local
> olcDbChaseReferrals: TRUE
> olcDbRebindAsUser: TRUE
> olcDbIDAssertBind: bindmethod=none tls_cacert=/etc/pki/tls/certs/ca.crt
> olcDbIDAssertAuthzFrom: "*"
>
> (I also tried by setting LDAPTLS_CACERT env var when starting slapd)
>
> On backend ldap server logs, I get the message "TLS negociation failure"
I've set up a test script here
https://github.com/mistotebe/openldap/tree/its8427-regression
This runs without issues but if you replace olcDbStartTLS with an
analogous olcDbIDAssertBind in the configs, it seems the CA certificate
is not set for the connection.
I guess we've introduced a behaviour change with ITS#8427, not sure what
the documentation implies should happen in these cases, whether the new
behaviour is inconsistent with it or you've been relying on incorrect
behaviour that has since been corrected.
Regards,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
4 years, 2 months
Re: (ITS#9051) slapo-accesslog fails to log compare, search
by quanah＠symas.com
--On Monday, July 08, 2019 11:33 PM +0000 quanah(a)openldap.org wrote:
Note: compare operations are confirmed also to not log.
:~# ldapcompare -Y EXTERNAL -H ldapi:/// cn=admin,dc=rb,dc=symas,dc=net
cn:admin
TRUE
ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=accesslog -LLL
dn: cn=accesslog
objectClass: auditContainer
cn: accesslog
dn: reqStart=20190708222217.000000Z,cn=accesslog
objectClass: auditBind
reqStart: 20190708222217.000000Z
reqEnd: 20190708222217.000001Z
reqType: bind
reqSession: 1014
reqAuthzID:
reqDN: cn=admin,dc=rb,dc=symas,dc=net
reqResult: 0
reqVersion: 3
reqMethod: SIMPLE
dn: reqStart=20190709001033.000000Z,cn=accesslog
objectClass: auditBind
reqStart: 20190709001033.000000Z
reqEnd: 20190709001033.000001Z
reqType: bind
reqSession: 1019
reqAuthzID:
reqDN: cn=admin,dc=rb,dc=symas,dc=net
reqResult: 0
reqVersion: 3
reqMethod: SIMPLE
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4 years, 2 months
(ITS#9051) slapo-accesslog fails to log compare, search
by quanah＠openldap.org
Full_Name: Quanah Gibson-Mount
Version: 2.4.47
OS: N/A
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.128.44)
In testing out various logging scenarios with the accesslog overlay, it has been
found that it fails to log certain operations in the underlying accesslog DB.
Specifically, it fails to log "reads" or "compare" + "search". It does however
log "writes" or "bind".
Example configuration:
dn: olcDatabase={2}mdb,cn=config
objectClass: olcMdbConfig
objectClass: olcDatabaseConfig
olcDatabase: {2}mdb
olcDbDirectory: /var/lib/ldap/accesslog
olcAddContentAcl: FALSE
olcDbIndex: default eq
olcDbIndex: objectClass
olcDbIndex: entryUUID
olcDbIndex: entryCSN
olcDbIndex: reqStart
olcDbIndex: reqEnd
olcDbIndex: reqResult
olcDbIndex: reqDN
olcDbMaxReaders: 0
olcDbMaxSize: 5120000
olcDbMode: 0600
olcDbNoSync: FALSE
olcDbRtxnSize: 10000
olcDbSearchStack: 16
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcMonitoring: TRUE
olcReadOnly: FALSE
olcRootDN: cn=config
olcSuffix: cn=accesslog
olcSyncUseSubentry: FALSE
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=extern
al,cn=auth manage by * break
dn: olcOverlay={0}accesslog,olcDatabase={1}mdb,cn=config
objectClass: olcAccessLogConfig
objectClass: olcOverlayConfig
olcAccessLogDB: cn=accesslog
olcOverlay: {0}accesslog
olcAccessLogOps: reads
olcAccessLogOps: writes
olcAccessLogPurge: 1+00:00 1+00:00
olcAccessLogSuccess: TRUE
Performing a search in this scenario results in nothing logged.
Changing it to "reads" only (no writes), nothing logged
Changing it to "bind, search, compare", the bind is logged, but nothing else:
root@anvil3:~/accesslog-testing# ldapsearch -Y EXTERNAL -H ldapi:/// -b
cn=accesslog -LLL -Q
dn: cn=accesslog
objectClass: auditContainer
cn: accesslog
dn: reqStart=20190708222217.000000Z,cn=accesslog
objectClass: auditBind
reqStart: 20190708222217.000000Z
reqEnd: 20190708222217.000001Z
reqType: bind
reqSession: 1014
reqAuthzID:
reqDN: cn=admin,dc=rb,dc=symas,dc=net
reqResult: 0
reqVersion: 3
reqMethod: SIMPLE
Search is clearly logged at STATS level logging:
Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 fd=12 ACCEPT from IP=[::1]:51644
(IP=[::]:389)
Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=0 BIND
dn="cn=admin,dc=rb,dc=symas,dc=net" method=128
Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=0 BIND
dn="cn=admin,dc=rb,dc=symas,dc=net" mech=SIMPLE ssf=0
Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=0 RESULT tag=97 err=0 text=
Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=1 SRCH
base="dc=rb,dc=symas,dc=net" scope=2 deref=0 filter="(objectClass=*)"
Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=1 SEARCH RESULT tag=101 err=0
nentries=2 text=
Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 op=2 UNBIND
Jul 8 15:22:17 anvil3 slapd[12993]: conn=1014 fd=12 closed
4 years, 2 months
Re: (ITS#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
by henrik.bohnenkamp＠ionos.com
On Thu, Jun 27, 2019 at 10:34:19PM -0700, Quanah Gibson-Mount wrote:
> --On Sunday, April 07, 2019 10:15 AM +0000 henrik.bohnenkamp(a)ionos.com
> wrote:
>
> > On Thu, Apr 04, 2019 at 05:32:16PM +0100, Howard Chu wrote:
>
> Had a customer who was hitting this issue try out these patches -- It
> greatly decreases the search time (from unknown/infinite to 1 minute).
> Unfortunately slapd then segv's. Working on getting a test database to
> reproduce the issue with for a good backtrace.
oh, that's too bad. I'd be happy to participate in the bug hunt. May I
ask: which version did your customer use? I have modified the patch to
work with the recent changes on master, but I did not dig in very deep
to understand these changes. So I must admit that these modifications
to the patch are completely untested (except the tests in the tests
subdir).
Things might work better with the 2.4.46/47 patch, if that is an
option for your customer.
Wrt getting a test-tree, maybe the python script I have in the github
repo for the patch can provide
one. (https://github.com/hbo/openldap-mdb-deref-problem/blob/master/scripts/wri...)
I'm of course very interested to keep this patch alive, so if you have
details on the segv, please let me know.
Henrik
>
> --Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
--
Dr. rer. nat. Henrik Bohnenkamp
Senior Sysadmin
IT Operations Monitoring & Infrastructure
1&1 IONOS SE | Brauerstraße 48 | 76135 Karlsruhe | Germany
Phone: +49 721 91374 - 4159
E-mail: henrik.bohnenkamp(a)ionos.com | Web: www.ionos.de
Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498
Vorstand: Dr. Christian Böing, Hüseyin Dogan, Hans-Henning Kettler, Matthias Steinberg, Achim Weiß
Aufsichtsratsvorsitzender: Markus Kadelke
Member of United Internet
Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden.
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.
4 years, 2 months
Re: (ITS#8977) Make IDL sizes configurable in back-mdb
by quanah＠symas.com
--On Thursday, June 27, 2019 8:56 PM +0000 quanah(a)symas.com wrote:
> --On Thursday, June 27, 2019 8:35 PM +0000 hyc(a)symas.com wrote:
>
>> No, because order is irrelevant for these.
>
> Cool, thanks! I'll continue on with deeper testing then. :)
Given the current implementation of OpenLDAP, this feature is impossible to
use w/o recompiling OpenLDAP when a change to the IDL size is made. This
is because LDAP_PVT_THREAD_STACK_SIZE must be adjusted as well and that
requires a recompile.
The default size for LDAP_PVT_THREAD_STACK_SIZE is:
( 1 * 1024 * 1024 * sizeof(void *) )
which works for an IDL size of 16 (2^16) which is 65536.
If you change the IDL size, say to 22, then the new IDL size is: 4,194,304.
We then use this difference to find the offset we need to adjust
LDAP_PVT_THREAD_STACK_SIZE by:
4194304/65536 = 64
So it needs to be 64 time larger:
( 64 * 1024 * 1024 * sizeof(void *) )
Generally, this feature is simply unusuable (currently) as a tunable given
the requirement for recompiling OpenLDAP to use it.
--QUanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4 years, 2 months
Re: (ITS#9045) Crashes in cn=config (test050)
by ondra＠openldap.org
On Fri, Jun 28, 2019 at 09:49:51AM +0000, ondra(a)openldap.org wrote:
> Every so often (roughly once in a thousand runs or so it seems), a server will
> crash in test050 on master. This test replicates cn=config which is not
> officially supported yet.
>
> Some output from a gdb session from the core is uploaded here:
> ftp://ftp.openldap.org/incoming/test050-crash-master-20190628.txt
>
> It's not clear to me how attrs_dup has reached the attribute at 0x170b6a8 unless
> there was another thread messing with the same structure. str2entry2 is running
> in another thread, but I wouldn't think it runs on the same entry? Stuff is
> optimised out in this one.
Another crash, this time with better logs and an unoptimized binary:
ftp://ftp.openldap.org/incoming/test050-crash-20190702.txz
Again, attribute is being accessed that seems to have been cleaned and
released and another thread is running str2entry2 (on cn=config as well,
just with a different pointer), might still be a red herring.
Regards,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
4 years, 2 months
(ITS#9046) Regex Constraint Overlay Error
by mrojo＠gmv.com
Full_Name: Mar.a Rojo Gonz.lez
Version: 2.4.44
OS: CentOS Linux release 7.6.1810
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (212.0.110.2)
Hello,
We installed a fresh OpenLDAP server and created the following test backend:
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 a008278f
dn: olcDatabase={3}hdb
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {3}hdb
olcDbDirectory: /var/lib/ldap2
olcSuffix: dc=example,dc=org
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonym
ous auth by dn="cn=admin,dc=example,dc=org" write by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by self write by dn="cn=admin,dc=example,dc=org" write by
* read
olcLastMod: TRUE
olcRootDN: cn=admin,dc=example,dc=org
olcRootPW:: e1NTSEF9RnZwTERwWkFQRlhId012TnhBWXpkemY3b0JUN2tNR3M=
olcDbCheckpoint: 512 30
olcDbIndex: objectClass eq
structuralObjectClass: olcHdbConfig
entryUUID: 238efe88-303a-1039-97b5-d1f261d139b7
creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
createTimestamp: 20190701105301Z
entryCSN: 20190701105301.031755Z#000000#000#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
modifyTimestamp: 20190701105301Z
Then we added the following constraint using ldapadd:
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib64/openldap/
olcModuleLoad: constraint.la
dn: olcOverlay=constraint,olcDatabase={3}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcConstraintConfig
olcOverlay: constraint
olcConstraintAttribute: userPassword regex ^[^{].*
Finally, we tested some combinations of passwords and constraints (replacing the
previous olcConstraintAttribute) and these are the results:
# Operation Password Constraint Result
1 ldapmodify hola ^[^{].* err=0
2 ldapmodify {hola ^[^{].* err=19
3 ldappasswd hola ^[^{].* err=19
4 ldappasswd {hola ^[^{].* err=19
5 ldapmodify hola ^[^H].* err=0
6 ldapmodify Hola ^[^H].* err=19
7 ldappasswd hola ^[^H].* err=0
8 ldappasswd Hola ^[^H].* err=0
where the ldapmodify was executed as follows:
ldapmodify -x -D "cn=person1,ou=people,dc=example,dc=org" -W
Enter LDAP Password:
dn: cn=person1,ou=people,dc=example,dc=org
changetype: modify
replace: userPassword
userPassword: hola
modifying entry "cn=person1,ou=people,dc=example,dc=org"
and ldappasswd was run as such:
ldappasswd -x -D "cn=person1,ou=people,dc=example,dc=org" -w pass -a pass -s
hola
Result: Constraint violation (19)
The unexpected results were:
# Operation Password Constraint Result
3 ldappasswd hola ^[^{].* err=19
8 ldappasswd Hola ^[^H].* err=0
Here is some sample output from the slapd log files:
Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 fd=26 ACCEPT from
IP=[::1]:33328 (IP=[::]:389)
Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 op=0 BIND
dn="cn=person1,ou=people,dc=example,dc=org" method=128
Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 op=0 BIND
dn="cn=person1,ou=people,dc=example,dc=org" mech=SIMPLE ssf=0
Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 op=0 RESULT tag=97 err=0
text=
Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 op=1 EXT
oid=1.3.6.1.4.1.4203.1.11.1
Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 op=1 PASSMOD old new
Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 op=1 RESULT oid= err=19
text=(#001
Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 op=2 UNBIND
Jul 1 18:18:42 pruebasldap2 slapd[7160]: conn=1112 fd=26 closed
Note the strange text on the RESULT. We consistently found the same error text
when we executed executing test #3.
Do you know what may be causing this behaviour?
Thank you in advance.
4 years, 2 months
