https://bugs.openldap.org/show_bug.cgi?id=9220
Bug ID: 9220
Summary: Rewrite Bind and Exop result handling
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Bind and Exop result handling needs a rewrite so it is no longer a special case
for overlays.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9717
Issue ID: 9717
Summary: The RADIUSOV overlay can be incorporated into OpenLDAP
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: rdubner(a)symas.com
Target Milestone: ---
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10383
Issue ID: 10383
Summary: slapd-meta ignores olcDbIDAssertBind if olcDbURI
defined after it
Product: OpenLDAP
Version: 2.6.9
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: david.frickert(a)protonmail.com
Target Milestone: ---
Hi,
We are using slapd-meta to connect an OpenLDAP server to another external LDAP
server and it works well on first configuration.
However, if we want to update any info, e.g. the external LDAP URI, we must
replace the olcDbURI attribute. This means that the ordering of the attributes
change and this attribute is now defined after olcDbIDAssertBind.
Didn't think this would be important, but after this change the "meta"
connection stops working and upon enabling debugging i can see that the
external LDAP server is responding with:
"ldap_bind: Inappropriate authentication (48)
additional info: Anonymous Simple Bind Disabled"
This seems to imply that the olcDbIDAssertBind attribute is being ignored,
likely due to being defined before olcDbURI (my assumption).
Is this intended? If so, what can we do to mitigate this problem?
Do we need to perform a replace on all attributes of the object to ensure
correct ordering, or is there any way to perform an in-place attribute
modification without making it shift its position in the object?
Example:
First configuration (OK):
# {0}uri, {2}meta, config
dn: olcMetaSub={0}uri,olcDatabase={2}meta,cn=config
objectClass: olcMetaTargetConfig
olcMetaSub: {0}uri
--> olcDbURI: ldap://REDACTED/ou=users,REDACTED
olcDbIDAssertBind: bindmethod=simple starttls=yes tls_reqcert=demand
binddn="REDACTED" credentials="REDACTED"
olcDbRewrite: {0}suffixmassage REDACTED REDACTED
olcDbKeepalive: 0:0:0
olcDbBindTimeout: 100000
olcDbCancel: abandon
After URI update (NOK):
# {0}uri, {2}meta, config
dn: olcMetaSub={0}uri,olcDatabase={2}meta,cn=config
objectClass: olcMetaTargetConfig
olcMetaSub: {0}uri
olcDbIDAssertBind: bindmethod=simple starttls=yes tls_reqcert=demand
binddn="REDACTED" credentials="REDACTED"
olcDbRewrite: {0}suffixmassage REDACTED REDACTED
olcDbKeepalive: 0:0:0
olcDbBindTimeout: 100000
olcDbCancel: abandon
--> olcDbURI: ldap://REDACTED/ou=users,REDACTED
The olcDbURI attribute is shifted to the bottom after a modify operation, and
seems to cause these issues.
Best Regards,
David
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10329
Issue ID: 10329
Summary: Additional issues with pcache, and a test
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: aweits(a)rit.edu
Target Milestone: ---
Created attachment 1062
--> https://bugs.openldap.org/attachment.cgi?id=1062&action=edit
test & patches
Hello again!
Further testing revealed some more issues in pcache [re: ITS#10270]. I've
attached an update to test020-proxycache as well. These are based off the
current git HEAD.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9731
Issue ID: 9731
Summary: startup messages still go to syslog when logfile-only
is on
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
When setting logfile-only on, slapd still logs its startup message to syslog:
Oct 29 21:07:47 u18test slapd[18534]: @(#) $OpenLDAP: slapd 2.6.0 (Oct 29 2021
05:12:17) $#012#011openldap
This is useful information to have consolidated into the specified logfile.
Note that:
617c62a3.16f03fdb 0x7f9325ed67c0 slapd starting
does make it to the logfile. However, it would be useful to have the build
date and version in the specified logfile.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10380
Issue ID: 10380
Summary: file logger doesn't emit slapd startup/version info
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
When using syslog, a startup message is emitted which is useful in many
different contexts:
- signals a slapd restart to the admin
- shows the actual version used
- if a crash happened just before, there is no "stopped" message, this is a
hint to anyone looking that something was not right and the slapd is not the
same process
- people writing log processing scripts (incident response) know when it's
necessary to reset their state, again as it's a new process
Because of the above, it feels like a regression to me.
I guess we can just emit this info on logfile config handlers? This means
startups and logfile switches are still handled as they used to in syslog and
log rotation doesn't emit anything (making it easy and safe to just concatenate
files).
Yes, slapd logs its PID in most formats so restarts can be detected that way,
but that's considerably harder to search for.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9726
Issue ID: 9726
Summary: Admin guide and man pages need better documentation on
disabling syslog
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
2.6.0 added the new feature allowing using a logfile for all debug/loglevel
messages and bypassing syslog entirely. However, there is no documentation on
the new settings or examples of how to do this in the admin guide, and the man
page sections on the new parameters for the logfile side do not note at
when/how they enable bypassing syslog.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10313
Issue ID: 10313
Summary: 3-way multimaster oathHOTPCounter attribute update
code missing
Product: OpenLDAP
Version: 2.6.6
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: agrru01(a)gmail.com
Target Milestone: ---
I posted on openldap technical mail list and got a response saying I should
file a feature request.
I am using a 3-way multimaster syncrepl setup with the slapo-otp module. My
problem is that when authenticating with a user using HOTP, the attribute
oathHOTPCounter only updates the value on the target ldap instance. This means
the other two ldap instances do not get the updated HOTP-counter value and
therefore will allow authentication using the same HOTP code.
Interestingly enough, if I manually edit the oathHOTPCounter value it
synchronizes with the other masters.
Please see the technical mail list discussion:
https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10353
Issue ID: 10353
Summary: No TLS connection on Windows because of missing
ENOTCONN in socket.h
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: julien.wadel(a)belledonne-communications.com
Target Milestone: ---
On Windows, the TLS connection cannot be done and we get the connection error:
Can't contact LDAP server.
=> Connections are done with WSAGetLastError().
After getting WSAEWOULDBLOCK, the connection is not restart because of the
state WSAENOTCONN that is not known.
OpenLDAP use ENOTCONN that is set to 126 by "ucrt/errno.h" while WSAENOTCONN
is 10057L.
Adding #define ENOTCONN WSAENOTCONN
like for EWOULDBLOCK resolve the issue.
Reference commit on external project:
https://gitlab.linphone.org/BC/public/external/openldap/-/commit/62fbfb12e8…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10381
Issue ID: 10381
Summary: Logformat config is broken
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
After ITS#10140, logformat config parsing and emitting is broken. Some formats
don't emit in cn=config, some abort. On Windows, log prefix is corrupted.
Patch is being tested.
--
You are receiving this mail because:
You are on the CC list for the issue.