https://bugs.openldap.org/show_bug.cgi?id=10133
Issue ID: 10133
Summary: We tried to use centralized authentication for the
root account, but it failed.
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: liubo335(a)huawei.com
Target Milestone: ---
When sssd+ldap is used for centralized authentication of Linux users, it is
found that only non-root users can be authenticated, but the root user cannot
be authenticated. Therefore, I would like to ask whether the authentication of
the root user is not supported. If yes, what additional configuration items do
you need to pay attention to when authenticating the root user? Looking forward
to your answer, thank you very much.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8890
--- Comment #15 from tg(a)debian.org <tg(a)debian.org> ---
FWIW, Debian is going to switch 32-bit ARM (with 32-bit long)
to 64-bit time_t and off_t soon, and others, even m68k, will
follow.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6097
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|2.7.0 |3.0.0
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6942
--- Comment #4 from OndÅ™ej KuznÃk <ondra(a)mistotebe.net> ---
Maybe putting updateref on the syncrepl consumer configuration is a way to deal
with this.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6198
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|enhancement |blocker
Priority|--- |Highest
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9009
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |blocker
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8890
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|Low |Normal
--
You are receiving this mail because:
You are on the CC list for the issue.
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.