openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#8444) Out-of-sync issue with memberOf overlay, Delta-syncrepl MMR and >2 nodes
by henson＠acm.org 22 Dec '16

22 Dec '16

I sent this to the mailing list and was advised to add it to ITS 8444, so here it is: I recently updated to openldap 2.4.44 with the patch for ITS 8432. I'd been holding off in hopes of a new release with that patch included and for some update on ITS 8444, but decided to go ahead and push it through during the holiday break. I installed it on my dev environment and was unable to replicate the issues reported in ITS 8444 so went ahead and rolled into production. However, now that I'm in production, I'm seeing different issues with the memberOf overlay. It seems for some reason group membership deletions are getting replicated multiple times? In the logs, I will see something like the following: Dec 21 04:16:59 themis slapd[2607]: conn=364875 op=227806 MOD dn="uid=members,ou=group,dc=cpp,dc=edu" Dec 21 04:16:59 themis slapd[2607]: conn=364875 op=227806 MOD attr=member My identity management system connected and removed some members from this group. Next, there will be a number of lines like this: Dec 21 04:17:15 themis slapd[2607]: conn=-1 op=0: memberof_value_modify DN="uid=prsloan,ou=user,dc=cpp,dc=edu" delete memberOf="uid=members,ou=group,dc=cpp,dc=edu" failed err=16 Dec 21 04:17:16 themis slapd[2607]: conn=-1 op=0: memberof_value_modify DN="uid=prsloan,ou=user,dc=cpp,dc=edu" delete memberOf="uid=members,ou=group,dc=cpp,dc=edu" failed err=16 Dec 21 04:17:17 themis slapd[2607]: conn=-1 op=0: memberof_value_modify DN="uid=prsloan,ou=user,dc=cpp,dc=edu" delete memberOf="uid=members,ou=group,dc=cpp,dc=edu" failed err=16 Dec 21 04:17:18 themis slapd[2607]: conn=-1 op=0: memberof_value_modify DN="uid=prsloan,ou=user,dc=cpp,dc=edu" delete memberOf="uid=members,ou=group,dc=cpp,dc=edu" failed err=16 Dec 21 04:17:18 themis slapd[2607]: conn=-1 op=0: memberof_value_modify DN="uid=prsloan,ou=user,dc=cpp,dc=edu" delete memberOf="uid=members,ou=group,dc=cpp,dc=edu" failed err=16 Dec 21 04:17:18 themis slapd[2607]: conn=-1 op=0: memberof_value_modify DN="uid=prsloan,ou=user,dc=c Where the memberOf overlay is complaining that it can't remove the corresponding memberOf attribute from the user. Reviewing the accesslog, we see: dn: reqStart=20161221121659.000002Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121659.000002Z reqEnd: 20161221121706.000000Z reqType: modify reqSession: 364875 reqAuthzID: cn=idmgmt,ou=user,ou=service,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu The initial tranaction from my client, authenticated as cn=idmgmt. This one is successful and the overlay deletes the memberOf attribute. However, there are then *six* more instances of the same transaction: dn: reqStart=20161221121714.000001Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121714.000001Z reqEnd: 20161221121715.000000Z reqType: modify reqSession: 3 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu dn: reqStart=20161221121716.000001Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121716.000001Z reqEnd: 20161221121716.000002Z reqType: modify reqSession: 1 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu dn: reqStart=20161221121716.000004Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121716.000004Z reqEnd: 20161221121717.000002Z reqType: modify reqSession: 1 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu dn: reqStart=20161221121717.000001Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121717.000001Z reqEnd: 20161221121718.000000Z reqType: modify reqSession: 2 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu dn: reqStart=20161221121718.000001Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121718.000001Z reqEnd: 20161221121718.000002Z reqType: modify reqSession: 2 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu dn: reqStart=20161221121718.000003Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121718.000003Z reqEnd: 20161221121718.000004Z reqType: modify reqSession: 2 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu These are are performed by cn=ldaproot, and correspond to the six error messages from the overlay about failing to remove the attribute (which was already removed). Similarly, on a replica: Dec 21 04:17:16 coeus slapd[2841]: conn=-1 op=0: memberof_value_modify DN="uid=prsloan,ou=user,dc=cpp,dc=edu" delete memberOf="uid=members,ou=group,dc=cpp,dc=edu" failed err=16 There is one error, because there are two copies of the transaction: dn: reqStart=20161221121706.000001Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121706.000001Z reqEnd: 20161221121716.000000Z reqType: modify reqSession: 1 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu dn: reqStart=20161221121714.000002Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20161221121714.000002Z reqEnd: 20161221121716.000001Z reqType: modify reqSession: 3 reqAuthzID: cn=ldaproot,dc=cpp,dc=edu reqDN: uid=members,ou=group,dc=cpp,dc=edu reqResult: 0 reqMod: member:- uid=jjtringali,ou=user,dc=cpp,dc=edu reqMod: member:- uid=kaijulee,ou=user,dc=cpp,dc=edu reqMod: member:- uid=srknight,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ppimentel,ou=user,dc=cpp,dc=edu reqMod: member:- uid=epdetering,ou=user,dc=cpp,dc=edu reqMod: member:- uid=ktran,ou=user,dc=cpp,dc=edu [...] reqMod: member:- uid=prsloan,ou=user,dc=cpp,dc=edu So far, I've only seem this behavior for group membership removals. Adds don't seem to cause a problem, nor do create/delete of groups or users as far as I can tell. Any thoughts on what's going on here? It's not causing any failures yet, as removing members multiple times results in the same end state and the multiple replication seems to have a fairly low upper bound. But it would be nice to fix it :). Thanks...

1 0

(ITS#8553) LMDB Windows UWP Patch
by smlu＠s5.net 22 Dec '16

22 Dec '16

Full_Name: Crt Vavros Version: 0.9.70 OS: Windows 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.142.169.104) This patch updates LMDB library code to compile under windows UWP platform. The patch was made against mdb.master branch [4bc270a2c] (21.12.2016). Note that the code was not modified much, merely additional code was added to existing one. The code had to be adapted to compile under C++ standards (LMDB lib cannot be compiled as C code under UWP platform). This is handled via "TC" macro which casts "raw type" to appropriate type when compiling library under C++, it should do nothing when compiling as C code. The test github repo can be found at https://github.com/ZeroPass/lmdb (Note that this port is not made aginst the latest commit) Patch was uploaded to ftp.openldap.org/incoming

1 0

(ITS#8552) Strange behaviour of attribute using password policy overlay
by a.rossini＠cineca.it 19 Dec '16

19 Dec '16

Full_Name: Angelo Rossini Version: OpenLDAP-LTB 2.4.44.1 OS: Debian 8 x86-64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.186.19.204) Hi, I'm using the password policy overlay with this configuration: pwdAttribute: userPassword pwdAllowUserChange: TRUE pwdCheckModule: /usr/local/openldap/lib64/check_password.so pwdCheckQuality: 2 pwdExpireWarning: 432000 pwdFailureCountInterval: 300 pwdGraceAuthNLimit: 0 pwdInHistory: 5 pwdLockout: TRUE pwdLockoutDuration: 120 pwdMaxAge: 63072000 pwdMaxFailure: 5 pwdMinAge: 0 pwdMinLength: 8 pwdMustChange: TRUE pwdSafeModify: TRUE When I try to change the password and the password is one of the last five in history I find that attributes pwdChangedTime and modifyTimestamp have changed their values. I think that this behaviour is quite strange, because I haven't changed anything on the entry. Can someone explain me if is possible to avoid this behaviour? Regards, Angelo.

1 0

Re: (ITS#8551) allow bind_anon_cred in slapd.conf does not work
by quanah＠symas.com 15 Dec '16

15 Dec '16

--On Thursday, December 15, 2016 9:37 PM +0000 yelin(a)venustech.com.cn wrote: > To be specific, "allow bind_anon_cred" in slapd.conf does not work as Hello, This report is invalid. The documentation clearly states: bind_anon_cred allows anonymous bind when credentials are not empty (e.g. when DN is empty). I.e., bind_anon_cred allows you to bind with a ldapsearch -W or -w flag, but no -D flag provided. You may be looking for: bind_anon_dn allows unauthenticated (anonymous) bind when DN is not empty. Which allows one to bind anonymously rather than as a user, if the DN is specified. I.e., if using ldapsearch, ldapsearch -D DN without a -W or -w would allow the bind to occur as an anonymous connection. 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

(ITS#8551) allow bind_anon_cred in slapd.conf does not work
by yelin＠venustech.com.cn 15 Dec '16

15 Dec '16

Full_Name: yelin Version: 2.4.44 OS: win7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (106.37.236.166) Hello, This is yelin from venusTech.inc reporting OpenLDAP server configure file issue. To be specific, "allow bind_anon_cred" in slapd.conf does not work as expected. Please help to look at the issue and help my business application move on. "Unauthenticated bind mechanism" is specified in LDAP RFC 4153. My application has the business logic requires "Unauthenticated bind mechanism". And my application depends on OpenLDAP Sever. OpenLDAP claims to support it by specifying "allow bind_anon_cred" in slapd.conf. (http://www.openldap.org/doc/admin24/security.html) But the "allow bind_anon_cred" in slapd.conf does not work as expected. Enviroment: OpenLDAP version 2.4.44 OS: Win7 Detail Steps: 1. Install OpenLDAP server with all default settings. 2. Create a new myuser/mypwd. 2.1 Test bind "myuser"/"mypwd" completes as expected. 2.2 Test bind "myuser"/"" to see the Exception as expected. connection.bind( "uid=myuser,ou=people,dc=maxcrc,dc=com", "" ); unauthenticeded bind (DN with no password) disallowed 3. Modify slapd.conf, add a line "allow bind_anon_cred", save it. 4. Restart the server. 5. Test "myuser"/"" 6. Unexpected Result. There is unauthenticated bind disallowed Exception. Could you please help fix the issue? My business application can not run well without OpenLDAP "Unauthenticated bind mechanism". Thanks, yelin

1 0

(ITS#8550) aa
by aa＠aa.com 15 Dec '16

15 Dec '16

Full_Name: aa Version: 2.4.44 OS: win7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (106.37.236.166) aa

1 0

Re: (ITS#8543) CVE-2015-3276: incorrect multi-keyword mode cipherstring parsing
by he＠NetBSD.org 14 Dec '16

14 Dec '16

>> CVE-2015-3276 appears to be unfixed in 2.4.44, and from several >> attempts at finding the bug reported in your mailing list archive >> I came up empty. So ... The best I've found from this CVE is >> RedHat's bugzilla entry at >> >> https://bugzilla.redhat.com/show_bug.cgi?id=3D1238322 >> >> which contains a (suggested) patch. > > We can integrate a suggested fix if the patch author submits their > patch to our ITS directly. Due to IPR concerns we don't accept or act= > on 3rd party patch submissions. Hm, ok. I've submitted an update to the above bug entry petitioning for them to release the fix. We'll see if they act on it. Regards, - H=E5vard

1 0

(ITS#8545) Undesired timeout when polling for results
by shalopo＠gmail.com 14 Dec '16

14 Dec '16

Full_Name: Shahar Lupu Version: 2.4.44 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.218.29.26) When calling ldap_result with a timeout={0,0} (polling), it returns LDAP_TIMEOUT even though there are available messages in the socket. This occurs when calling ldap_results with all=true and a multi-message response has arrived. In this case, if the client has already received on the socket every message for the response, it is desirable that all the messages are collected within this ldap_result call. Instead of only polling for the specified timeout, ldap_result applies the timeout (zero when polling) on the wait4msg loop. Consequently, ldap_result returns LDAP_TIMEOUT after the first message if the response is composed of more than one message. While it may be a good idea to apply a timeout for the wai4msg loop (rather than only the polling on the socket), it is undesirable in some cases and should at least be configurable. Or perhaps timeout=polling should never be applied on the wait4msg loop.

1 0

Re: (ITS#8543) CVE-2015-3276: incorrect multi-keyword mode cipherstring parsing
by quanah＠symas.com 13 Dec '16

13 Dec '16

--On Tuesday, December 13, 2016 10:44 AM +0000 hyc(a)symas.com wrote: > he(a)NetBSD.org wrote: >> Full_Name: Havard Eidnes >> Version: 2.4.44 >> OS: NetBSD >> URL: >> Submission from: (NULL) (2001:700:1:0:eeb1:d7ff:fe59:fbaa) >> >> >> Hi, >> >> CVE-2015-3276 appears to be unfixed in 2.4.44, and from several >> attempts at finding the bug reported in your mailing list archive >> I came up empty. So ... The best I've found from this CVE is >> RedHat's bugzilla entry at >> >> https://bugzilla.redhat.com/show_bug.cgi?id=3D1238322 >> >> which contains a (suggested) patch. > > We can integrate a suggested fix if the patch author submits their patch = > to=20 > our ITS directly. Due to IPR concerns we don't accept or act on 3rd party= > =20 > patch submissions. I would also note that MozNSS is not an officially supported TLS library for OpenLDAP, and the hack that was added for 2.4 will be removed in the future (likely OpenLDAP 2.5 and later). End administrators should generally avoid MozNSS entirely. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8544) manpage fixes
by sca+openldap＠andreasschulze.de 13 Dec '16

13 Dec '16

Full_Name: Andreas Schulze Version: git OS: linux URL: ftp://ftp.openldap.org/incoming/andreas-schulze-161213.patch Submission from: (NULL) (2001:a60:f0b4:e502::152) I uploaded a patch to polish some manpages. All changes are suggested by debian lintian - phrase "allows one to" instead of "allows to" - some occurences of -foo have to be written as \-foo in a manpage Andreas

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs