(ITS#8555) slapo-pcache forgets credentials for binddn
by quanah＠openldap.org
Full_Name: Quanah Gibson-Mount
Version: 2.4.44
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.148.26)
When slapo-pcache is set up to use the user credentials for binding, the first
bind will succeed accordingly, but subsequent binds will fall back to anonymous,
as slapd logs that the credentials are not found:
58645256 conn=1024 op=1 ldap_back_dobind_int: DN="cn=james a jones 1,ou=alumni
association,ou=people,dc=example,dc=com" without creds, binding
anonymouslyldap_sasl_bind
This is trivial to reproduce by making a slight modification to
test020-proxycache:
index f4e5cb7..105b911 100755
--- a/tests/scripts/test020-proxycache
+++ b/tests/scripts/test020-proxycache
@@ -645,6 +645,22 @@ if test $RC != 4 ; then
test $KILLSERVERS != no && kill -HUP $KILLPIDS && wait
exit 1
fi
+
+CNT=`expr $CNT + 1`
+FILTER="(sn=Jon)"
+ATTRS="cn mail telephonenumber"
+echo "Query $CNT: (Result should not be cached)"
+echo "# Query $CNT: (Result should not be cached)" >> $SEARCHOUT
+$LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT2 \
+ -D "$USERDN" -w "$UPASSWD" "$FILTER" $ATTRS >> $SEARCHOUT 2>> $TESTOUT
+RC=$?
+
+if test $RC != 0 ; then
+ echo "ldapsearch failed ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
The error test case isn't useful here, but slapd.2.log can be examined to see
the behavior.
It appears that there's a problem with this block of code in back-ldap/bind.c,
that starts at line 2489 in RE24:
if ( rc == LDAP_SUCCESS ) {
/* set rebind stuff in case of successful proxyAuthz bind,
* so that referral chasing is attempted using the right
* identity */
LDAP_BACK_CONN_ISBOUND_SET( lc );
if ( !BER_BVISNULL( binddn ) ) {
ber_bvreplace( &lc->lc_bound_ndn, binddn );
}
if ( !BER_BVISNULL( &lc->lc_cred ) ) {
memset( lc->lc_cred.bv_val, 0,
lc->lc_cred.bv_len );
}
if ( LDAP_BACK_SAVECRED( li ) ) {
if ( !BER_BVISNULL( bindcred ) ) {
ber_bvreplace( &lc->lc_cred, bindcred );
ldap_set_rebind_proc( lc->lc_ld,
li->li_rebind%2, lc );
}
} else {
lc->lc_cred.bv_len = 0;
}
}
6 years, 11 months
(ITS#8554) lmdb build failure on GNU/kFreeBSD
by ryan＠openldap.org
Full_Name: Ryan Tandy
Version: 2.4.44
OS: Debian GNU/kFreeBSD
URL:
Submission from: (NULL) (24.68.41.160)
Forwarded from https://bugs.debian.org/845394:
lmdb fails to build on Debian GNU/kFreeBSD.
https://buildd.debian.org/status/fetch.php?pkg=openldap&arch=kfreebsd-amd...
mdb.c: In function mdb_env_setup_locks:
mdb.c:4625:13: warning: implicit declaration of function
pthread_mutexattr_setrobust [-Wimplicit-function-declaration]
|| (rc = pthread_mutexattr_setrobust(&mattr, PTHREAD_MUTEX_ROBUST))
^~~~~~~~~~~~~~~~~~~~~~~~~~~
mdb:4A4625:49: error: PTHREAD_MUTEX_ROBUST undeclared (first use in this
function)
|| (rc = pthread_mutexattr_setrobust(&mattr, PTHREAD_MUTEX_ROBUST))
^~~~~~~~~~~~~~~~~~~~
mdb.c:4625:%3: note: each undeclared identifier is reported only once for each
function it appears in
mdb.c: In function mdb_mutex_failed:
mdb.c:351:37: warning: implicit declaration of function
pthread_mutex_consistent [-Wimplicit-function-declaration]
#define mdb_mutex_consistent(mutex) pthread_mutex_consistent(mutex)
^
mdb.c:10002:10: note: in expansion of macro mdb_mutex_consistent
rc2 = mdb_mutex_consistent(mutex);
^~~~~~~~~~~~~~~~~~~~
The patch applied by Ondřej Surý to the Debian lmdb package fixes this,
please consider applying it.
http://sources.debian.net/data/main/l/lmdb/0.9.18-5/debian/patches/0003-U...
6 years, 11 months
Re: (ITS#8444) Out-of-sync issue with memberOf overlay, Delta-syncrepl MMR and >2 nodes
by henson＠acm.org
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...
6 years, 11 months
(ITS#8553) LMDB Windows UWP Patch
by smlu＠s5.net
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
6 years, 11 months
(ITS#8552) Strange behaviour of attribute using password policy overlay
by a.rossini＠cineca.it
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.
6 years, 11 months
Re: (ITS#8551) allow bind_anon_cred in slapd.conf does not work
by quanah＠symas.com
--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>
6 years, 11 months
(ITS#8551) allow bind_anon_cred in slapd.conf does not work
by yelin＠venustech.com.cn
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
6 years, 11 months
Re: (ITS#8543) CVE-2015-3276: incorrect multi-keyword mode cipherstring parsing
by he＠NetBSD.org
>> 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
6 years, 11 months
(ITS#8545) Undesired timeout when polling for results
by shalopo＠gmail.com
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.
6 years, 11 months
