https://bugs.openldap.org/show_bug.cgi?id=9719
Issue ID: 9719
Summary: refreshOnly sends empty cookie when client up to date
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Syncprov will send an empty cookie if the consumer has the same cookie as
provider. To the best of my knowledge this is not in line with RFC4533 and
consumers would effectively drop their cookie when the search finishes.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10065
Issue ID: 10065
Summary: slapd needs a config option for the ssf of an external
security proxy using "proxy protocol v2"
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: sean(a)teletech.com.au
Target Milestone: ---
Commit 146889f introduced support for the haproxy "proxy protocol v2". A very
welcome addition that allows an external security layer to be implemented. This
implementation is however somewhat hobbled.
Cyrus SASL uses "Security Strength Factors" or "ssf" to determine what
Authentication mechanisms to offer. slapd conveys the implicit security of UNIX
domain sockets to the SASL layer by specifying a non-zero ssf for these
connections. This can be configured with the "olcLocalSSF" config setting.
For implicit/explicit TLS connections, the "olcSecurity: tls=<n>" provides the
cryptographic strength of the TLS layer to the SASL layer.
For an external TLS-terminating proxy, there does not appear to be any way to
inform Cyrus SASL of the presence of TLS security on these proxied connections.
The outcome of this is that PLAIN and EXTERNAL authentication mechanisms are
not offered to clients connecting through the secure proxy.
This can be overcome by weakening the security properties of the SASL layer
with the olcSaslSecProps configuration option, but this weakening will apply to
all clients, not just clients connecting via the secure proxy.
What is required is some way to tell slapd and it's integrated SASL layer about
the presence of TLS encryption on the proxy's input. As a precaution, this
might be restricted to slapd connections in the 127.0.0.0/8 [IPv6:::] address
ranges.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9902
Issue ID: 9902
Summary: Make max index DBs for back-mdb configurable
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
From ITS#9895:
Currently there is a hardcoded limit of 128 index DBs in back-mdb. Some sites
want more than this (although there's no evidence they actually use more than
128 attributes in all of their applications' search filters).
For 2.5/2.6 we can simply double the constant. For 2.7 consider making it
configurable.
Note that increasing the number increases the size of an LMDB transaction
structure, and also increases the time needed to initialize it whenever
creating a transaction, so it's a bad idea to just set this to an arbitrarily
large number.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9829
Issue ID: 9829
Summary: set timeouts in remoteauth overlay
Product: OpenLDAP
Version: 2.5.11
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: david.coutadeur(a)gmail.com
Target Milestone: ---
Currently, it seems there is no way to configure timeouts in the remoteauth
overlay.
For example, if I define a remoteauth_mapping with a file containing a
list of hostnames, the first one is checked first.
After "remoteauth_retry_count" * "connect_timeout" seconds, (210s on my
system), remoteauth test the second server in the list.
In some circumstances, it could be nice to set the connect timeout lower
(or higher).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9677
Issue ID: 9677
Summary: Create "make install-strip” target
Product: OpenLDAP
Version: 2.5.7
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: dpa-openldap(a)aegee.org
Target Milestone: ---
All open source make-based projects shall follow the same naming and semantics
of targets, described at
https://www.gnu.org/prep/standards/html_node/Standard-Targets.html .
In particular “make install-strip” shall strip the binaries during the
installation, while “make install” shall not strip them.
In openldap currently “make install” does strip, which surprised me.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9612
Issue ID: 9612
Summary: Change index_hash64 default to on
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Change the default value of index_hash64. By default this means slapd won't
run on a 32-bit CPU (It will continue to work on 32-bit OSes running on 64-bit
CPUs).
If someone needs to run slapd on a 32-bit CPU they can turn this option off.
In the documentation, mark the option as deprecated for eventual removal in a
future release.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9580
Issue ID: 9580
Summary: Refresh vs. accesslog in delta-MPR
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: replication
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
A server consuming a plain syncrepl session (might be a delta-MMR refresh)
still has to log the entries into accesslog, however that accesslog stops being
capable of serving as a delta-sync source:
- operation entryCSNs will be out-of-order
- the changes logged will not be the intended modifications (e.g. if we fell
back after a conflict, the conflicting entry will be replaced with the other
version, other examples available)
We need to deal with that somehow, at the very least we need to make sure the
consumer will not take them at face value. We could record this in the
accesslog root entry if we can detect when this starts and match it up with the
final cookie, syncprov would still need some tweaks to understand it.
We could mark the entries received this way and make sure delta-consumers treat
them as "poison", as if they were running a plain syncrepl session themselves
(not update contextCSN until that's finished, mark its own accesslog entries
this way, ...). Anything like that needs guarantees that it will clean itself
up once all of the real plain sessions finish otherwise we've lost delta-sync
altogether.
A different approach might or might not be needed for live delta-persist
sessions replicating from a refreshing provider, but at least that syncprov has
a way of detecting this live if it chooses to.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9341
Issue ID: 9341
Summary: Delta-sync MPR needs to be stable regardless of
ordering
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: replication
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If two or more updates are spread across several providers before they have a
chance to learn about the others, all replicas need to arrive at the same
content regardless of the order in which they arrive.
One example that is broken at the moment:
- (csn a) server 1 accepts a modify
- (csn b) server 2 accepts a delete on the same DN
- (csn c) server 2 accepts an add on that DN again
If a replica receives the actions in the order bca vs. abc, the content of the
entry will be different even though the final CSN set is the same -> they will
never converge. The ordering 'bac' also needs to result in eventual
convergence, even if it means a refresh or replication from either provider
stalling temporarily?
Merge request with this test case (so far):
https://git.openldap.org/openldap/openldap/-/merge_requests/145
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9577
Issue ID: 9577
Summary: slapd -V should be deprecated
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: smckinney(a)symas.com
Target Milestone: ---
Sometimes a user's (present one included) ignorance gets them in trouble
unnecessarily. The -V option is an example...
Normally, when one wants to determine the version of a process, they use -V, or
perhaps -v. With slapd, the daemon actually continues to run, which can have
negative consequences.
The doc clearly states that -VV is probably what the user wants, but is
counter-intutive. Who RTFM's before checking the version?
-V print version info (-VV exit afterwards, -VVV print
info about static overlays and backends)
I propose we eliminate the option to allow slapd to continue running after
displaying the version. Perhaps we eliminate the -V option entirely, or just
make it work the same as -VV.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9547
Issue ID: 9547
Summary: OpenLDAP does not send port as SPN when authenticating
SASL GSSAPI
Product: OpenLDAP
Version: 2.4.44
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: robert.wilson1717(a)gmail.com
Target Milestone: ---
When trying to authenticate to an ADLDS server using kerberos and a MIT ccache,
OpenLdap only passes the hostname to the SASL mechanism, causing a mismatch
between the SPN in the client "ldap/adlds.my.domain" and the one registered in
AD "ldap/adlds.my.domain:50000"
Is there a way fo forcing OpenLDAP to pass the port as part of the SASL
request? Or is there a part of the OpenLDAP -> Cyprus-SASL -> MIT KRB5 chain
where this can be enabled?
--
You are receiving this mail because:
You are on the CC list for the issue.