https://bugs.openldap.org/show_bug.cgi?id=10206
Issue ID: 10206
Summary: smbk5pwd.c: implicit declaration of function
'kadm5_s_init_with_password_ctx'
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
smbk5pwd.c: In function ‘smbk5pwd_modules_init’:
smbk5pwd.c:917:23: warning: implicit declaration of function
‘kadm5_s_init_with_password_ctx’; did you mean ‘kadm5_init_with_password_ctx’?
[-Wimplicit-function-declaration]
917 | ret = kadm5_s_init_with_password_ctx( context,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| kadm5_init_with_password_ctx
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10165
Issue ID: 10165
Summary: back-meta fails to bind to target when proxying an
internal operation
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
When the target is configured as follows:
idassert-bind bindmethod=sasl saslmech=EXTERNAL authz=proxyauthz flags=override
and an overlay issues an internal operation, back-meta attempts to open a new
connection to the target, but the bind fails, so the internal operation cannot
be executed.
The target server returns the following error (as logged by back-meta):
<unauthenticated bind (DN with no password) disallowed>
Example configuration of the target server:
authz-regexp gidNumber=.*\+uidNumber=.*,cn=peercred,cn=external,cn=auth
cn=config
logfile ./main.log
database config
database mdb
directory ./main
rootdn cn=config
suffix o=example.com
overlay accesslog
logdb cn=log
logops writes
logsuccess true
database mdb
suffix cn=log
directory ./log
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10173
Issue ID: 10173
Summary: Accesslog bootstrap doesn't populate minCSN internally
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: ---
When a new accesslog DB is being set up from zero but a main DB exists, the
correct minCSN is pushed into the auditContainer entry but li_mincsn et al are
not set up internally. Fix is coming.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10211
Issue ID: 10211
Summary: uid or gid >= 2^31 can crash slapd when performing
peercred auth
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: nick(a)portercomputing.co.uk
Target Milestone: ---
Created attachment 1018
--> https://bugs.openldap.org/attachment.cgi?id=1018&action=edit
Patch to resolve issue
If a user with uid or gid >= 2^31 performs peercred authentication, slapd can
crash due to incorrect formatting of uid and gid when producing the authid
string.
uid and gid are unsigned int values, but are currently cast to int and printed
with %d. This results in values >= 2^31 being printed as negatives, which is
wrong, and for some values that will result in a string longer than the space
which has been allocated due to the addition of the leading '-'.
The issue can be reproduced by attempting a peercred auth from a user with uid
and gid 2649996510 - which will currently be printed as -1644970786.
Attached is a patch which rectifies this.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10209
Issue ID: 10209
Summary: OpenBSD Build failure (2.6.8 (RE26)
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: Other
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: brett(a)gladserv.com
Target Milestone: ---
Build failure on OpenBSD 7.2. NB: OpenBSD uses LibreSSL, not OpenSSL, and I
have no idea if that's supported, but configure should at least pick that up I
think.
libtool: compile: cc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c
tls_o.c -fPIC -DPIC -o .libs/tls_o.o
tls_o.c:228:19: error: use of undeclared identifier 'OPENSSL_INIT_NO_ATEXIT'
OPENSSL_init_ssl(OPENSSL_INIT_NO_ATEXIT, NULL);
^
1 error generated.
*** Error 1 in libraries/libldap (Makefile:432 'tls_o.lo')
*** Error 2 in libraries (Makefile:317 'all-common': @for i in liblutil
liblber liblunicode libldap librewrite ; do echo " Entering
...)
*** Error 2 in /home/bacs/openldap-OPENLDAP_REL_ENG_2_6 (Makefile:325
'all-common': @for i in include libraries clients servers tests doc ; ...)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10208
Issue ID: 10208
Summary: build test failure: test076-authid-rewrite (2.6.8
(RE26)
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: brett(a)gladserv.com
Target Milestone: ---
Testing RE26 on Gentoo Linux. Test 076 fails with "generic failure: internal
error: failed to init cipher 'rc4'"
>>>>> 00:07:19 Starting test076-authid-rewrite for mdb...
running defines.sh
Starting slapd on TCP/IP port 9011...
/home/bacs/src/openldap-OPENLDAP_REL_ENG_2_6/tests
Using ldapsearch to check that slapd is running...
Checking whether DIGEST-MD5 is supported...
Adding schema and database...
Using ldapadd to populate the database...
Adding olcAuthzRegexp rule for static mapping...
Testing ldapwhoami as Manager...
ldap_sasl_interactive_bind: Local error (-2)
additional info: SASL(-1): generic failure: internal error: failed to
init cipher 'rc4'
ldapwhoami failed (254)!
>>>>> 00:07:20 Failed test076-authid-rewrite for mdb after 1 seconds
(exit 254)
make[2]: *** [Makefile:320: mdb-yes] Error 254
make[2]: Leaving directory '/home/bacs/src/openldap-OPENLDAP_REL_ENG_2_6/tests'
make[1]: *** [Makefile:287: test] Error 2
make[1]: Leaving directory '/home/bacs/src/openldap-OPENLDAP_REL_ENG_2_6/tests'
make: *** [Makefile:298: test] Error 2
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10214
Issue ID: 10214
Summary: Reduce library dependencies
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hamano(a)osstech.co.jp
Target Milestone: ---
Currently, slapd links libsystemd to notify service state to systemd.
However, libsystemd link several unnecessary libraries, which increases
security risks.
The systemd documentation provides a method to send state notifications to
systemd using a simple protocol without the need to link against libsystemd.
https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html
I propose removing libsystemd and its depended libraries, similar to the
approach taken by OpenSSH.
Applying this fix reduced the following ten dependencies in the RHEL 8
environment.
- libsystemd.so.0
- libblkid.so.1
- libcap.so.2
- libgcc_s.so.1
- libgcrypt.so.20
- libgpg-error.so.0
- liblz4.so.1
- liblzma.so.5
- libmount.so.1
- librt.so.1
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10179
Issue ID: 10179
Summary: back-asyncmeta(5) man page incorrectly mentions
"rewrite"
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
Man page for back-asyncmeta mentions the rewrite options, yet asyncmeta does
not support the rewrite engine at the moment.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10216
Issue ID: 10216
Summary: Channel binding enforced on AD with AD cert using
EDCSA-SHA384 fails
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: simon.pichugin(a)gmail.com
Target Milestone: ---
Secure LDAP connections to the target Windows server 2019 DC began failing
after the Windows Server DC certificate was updated to an Elliptic Curve Public
Key (384 bits) with the sha384ECDSA signature algorithm and sha384 signature
hash algorithm specified.
The connections were previously successful when the Windows server DC
certificate specified an RSA Public Key certificate with signature algorithm
sha256RSA and signature hash algorithm sha256 specified.
Once the Windows server domain controller certificate is upgraded to the ECC
public key, subsequent secure ldap connection attempts fail.
If channel binding is turned off on the Windows AD target server, secure ldap
connections will succeed using starttls.
If Windows server domain controller certificate is upgraded to ECC public key
and ldap channel binding is enforced, subsequent secure ldap connection
attempts fail with this error message:
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: 80090346: LdapErr: DSID-0C09070F, comment:
AcceptSecurityContext error, data 80090346, v4563
Expected results:
Kerberos SASL should work with STARTTLS even when AD certificate is ECC and
SASL_CBINDING is set to "tls-endpoint"
Actual results:
Kerberos SASL only works with STARTTLS even when AD certificate is RSA and
SASL_CBINDING is set to "tls-endpoint"; it fails when AD certificate is ECC
Additional information:
According to the OpenSSL maintainer, there might be a bug in the OpenLDAP code:
it uses EVP_get_digestbynid() to find a digest algorithm based on the signature
algorithm, but there might be no such mapping in EC compared to the RSA case.
OpenLDAP needs to use OBJ_find_sigid_algs() to find the right algorithm.
Possibly, this is the failing code:
https://git.openldap.org/openldap/openldap/-/blob/master/libraries/libldap/…
Instead of X509_get_signature_nid() OpenLDAP code probably should call
something like OBJ_find_sigid_algs(X509_get_signature_nid(cert), &md_nid,
&pk_nid).
The former only supports mapping for a few known signature algorithms, but
everything did work, most likely due to a fallback to sha256 in case the digest
wasn't really found.
Judging by https://github.com/openssl/openssl/issues/14278 and
https://github.com/openssl/openssl/issues/14467, a better API is coming but not
currently available (and as it was in the state for a few years, it probably
won't be coming soon)
--
You are receiving this mail because:
You are on the CC list for the issue.