https://bugs.openldap.org/show_bug.cgi?id=9487
Issue ID: 9487
Summary: Committed changes not saved to accesslog during
shutdown
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: ---
If there is inbound write traffic when slapd is asked to shut down, some of
these operations get written to the main database but accesslog might be
prevented from ADDing the log entry into its own database (presumably since
slapd is shutting down already).
This prevents these updates from being replicated in a deltasync scenario and
silently desync.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9540
Issue ID: 9540
Summary: userSMIMECertificate needs to be binary
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: openldap.ms(a)savignano.net
Target Milestone: ---
OpenLDAP uses inetOrgPerson.schema with the following note on
userSMIMECertificate attribute:
# userSMIMECertificate
# [...] Values for
# this attribute are to be stored and requested in binary form, as
# 'userSMIMECertificate;binary'. [...]
but a line is added saying specifically
## OpenLDAP note: ";binary" transfer should NOT be used as syntax is binary
This seems to make no sense. According to RFC 2798 which define inetOrgPerson
and the useSMIMECertificate (first comment is quoted from there), this
attribute must be stored and requested as userSMIMECertificate;binary. OpenLDAP
does not do so. I don't understand the explanation "as syntax is binary".
This leads to problems with clients following RFC 2798 and requesting the
attribute as userSMIMECertificate;binary because OpenLDAP does not send
userSMIMECertificate instead, but sends nothing at all (as if attribute would
not exist).
I think this is a bug. OpenLDAP does not follow RFC 2798 and this causes
compatibility problems.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9535
Issue ID: 9535
Summary: test078 fails on MacOS due to output formatting
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
On MacOSX the output of the "wc" command is right-justified. This causes a
mismatch against the reference data.
God only knows why...
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9532
Issue ID: 9532
Summary: homedir overlay fails as a static module
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
When built as a static module, the homedir overlay is unusable, breaking
test035:
testrun/slapd.1.conf: line 8 (pidfile
/home/build/git/ol25/ol25/tests/testrun/slapd.1.pid)
testrun/slapd.1.conf: line 9 (argsfile
/home/build/git/ol25/ol25/tests/testrun/slapd.1.args)
testrun/slapd.1.conf: line 13 (database mdb)
mdb_db_init: Initializing mdb database
testrun/slapd.1.conf: line 14 (suffix "dc=example,dc=com")
>>> dnPrettyNormal: <dc=example,dc=com>
<<< dnPrettyNormal: <dc=example,dc=com>, <dc=example,dc=com>
testrun/slapd.1.conf: line 15 (rootdn "cn=Manager,dc=example,dc=com")
>>> dnPrettyNormal: <cn=Manager,dc=example,dc=com>
<<< dnPrettyNormal: <cn=Manager,dc=example,dc=com>,
<cn=manager,dc=example,dc=com>
testrun/slapd.1.conf: line 16 (rootpw ***)
testrun/slapd.1.conf: line 17 (directory
/home/build/git/ol25/ol25/tests/testrun/db.1.a)
testrun/slapd.1.conf: line 18 (index objectClass eq)
index objectClass 0x0004
testrun/slapd.1.conf: line 19 (index cn,sn,uid pres,eq,sub)
index cn 0x0716
index sn 0x0716
index uid 0x0716
testrun/slapd.1.conf: line 20 (maxsize 33554432)
testrun/slapd.1.conf: line 22 (overlay homedir)
overlay "homedir" not found
testrun/slapd.1.conf: line 22: <overlay> handler exited with 1!
slaptest: bad configuration file!
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9527
Issue ID: 9527
Summary: typo in nssov/README at line 68 "olDatabase" should be
"olcDatabase"
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: rdubner(a)symas.com
Target Milestone: ---
At line 68 in nssov/README, the word olDatabase should be olcDatabase
If I could generate a merge request, I would point you to
https://git.openldap.org/rdubner/openldap origin/nssov-README-patch
But that seems overkill for adding a single character
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9525
Issue ID: 9525
Summary: Fix contrib modules to properly honor build flags
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Currently the contrib makefiles use a variable "OPT", instead they should be
fixed to correctly honor CFLAGS, CPPFLAGS, and LDFLAGS as appropriate
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9520
Issue ID: 9520
Summary: slapd should fail if linked with libsodium and
rgon2.so is load with parameter with p>=1
Product: OpenLDAP
Version: 2.4.58
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
IMHO slapd should simply fail to start in case
1. it is linked against libsodium
2. and argon2.so is load with parameter with p>=1
Because this is a config error it should log a clear error message at config
log level.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9519
Issue ID: 9519
Summary: Adopt the namedObject draft
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Lives here https://tools.ietf.org/html/draft-stroeder-namedobject
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9518
Issue ID: 9518
Summary: Configuration parameter to force TLSv1.2 (-no_tls1_3)
Product: OpenLDAP
Version: 2.4.50
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: tom.bosmans(a)be.ibm.com
Target Milestone: ---
Hi,
I'm running into a problem during creation of an Ansible playbook that uses the
community.general.ldap_entry module, which in turn depends on python-ldap ,
that uses the openldap libraries.
My (openldap) server is configured for TLS 1.2, but does not support TLS 1.3.
openssl version:
OpenSSL 1.1.1k (have tried 1.1.1g as well).
So the root cause is that openssl, if it's compiled with TLS v1.3 , will try
TLS v1.3. If that doesn't work because the server does not support it, it
just stops. This is madness.
openssl s_client -connect isva.test:636 -showcerts -state
CONNECTED(00000003)
SSL_connect:before SSL initialization
SSL_connect:SSLv3/TLS write client hello
SSL3 alert read:fatal:handshake failure
SSL_connect:error in error
Now within openssl , there's a parameter that you can set to skip tls 1.3.
Great. So this works.
openssl s_client -connect isva.test:636 -showcerts -state -no_tls1_3
CONNECTED(00000003)
SSL_connect:before SSL initialization
SSL_connect:SSLv3/TLS write client hello
SSL_connect:SSLv3/TLS write client hello
SSL_connect:SSLv3/TLS read server hello
depth=0 CN = isva.test
verify error:num=18:self signed certificate
verify return:1
depth=0 CN = isva.test
...
But with ldapsearch, there's no option to pass this .
I've tried changing the cipher suite in .ldaprc, but to no avail. The TLSv1.3
ciphers are always used.
[tbosmans@tbosmans-p73 ~]$ ldapsearch -x -H ldaps://isva.test -D
"cn=bind,o=whatever" -w "pasword" -b "o=test" -v -d1
ldap_url_parse_ext(ldaps://isva.test)
ldap_initialize( ldaps://isva.test:636/??base )
ldap_create
ldap_url_parse_ext(ldaps://isva.test:636/??base)
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP isva.test:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 192.168.42.135:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect:
connect success
TLS trace: SSL_connect:before SSL initialization
TLS trace: SSL_connect:SSLv3/TLS write client hello
TLS trace: SSL3 alert read:fatal:handshake failure
TLS trace: SSL_connect:error in error
TLS: can't connect: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert
handshake failure.
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
[tbosmans@tbosmans-p73 ~]$ cat .ldaprc
TLS_REQCERT never
TLS_ECNAME ECDHE
TLS_CIPHER_SUITE ECDHE-ECDSA-ARIA256-GCM-SHA384
So it would be great it there was an option equivalent to "-no_tls1_3" for the
openldap client tools (or there may be a way to achieve this that I've missed
so far).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9517
Issue ID: 9517
Summary: Documenting how to pass Argon2 configuration
parameters when loading the module
Product: OpenLDAP
Version: 2.4.58
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: gilbert.kowarzyk(a)servicenow.com
Target Milestone: ---
It is possible to pass the configuration parameters for the argon2 module when
loading the module in OpenLDAP, and they are properly employed when using
ldappasswd.
Nevertheless, it took me a considerable amount of time to find how to provide
the config when loading the module.
The way I was able to provide the argon2 configuration values was by adding the
following to the slaps.ldif file:
olcModuleload: argon2.so m=XXXX t=YYYY p=ZZZZZ
(where XXXX, YYYY, and ZZZZ are the configuration values).
The syntax was initially not clear to me, and required a lot of trial an error
(I was not able to find documentation that clearly explained this syntax).
Thanks in advance!
--
You are receiving this mail because:
You are on the CC list for the issue.