https://bugs.openldap.org/show_bug.cgi?id=9817
Issue ID: 9817
Summary: rwm overlay : Issue with DN containing special
characters
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: thierry.pubellier(a)paris.fr
Target Milestone: ---
Hi,
I'm using rwn to select the database useg for bind operations based on the
result of a rewriteMap requets.
Sample configuration in global section :
#Rewrite Map to request a remote server
rwm-rewriteMap ldap checkEntry
"ldap://10.1.2.3/ou=users,dc=paris,dc=local?dn?sub"
binddn="cn=myuser,ou=users,dc=paris,dc=local" credentials="XXX"
# Backing up original DN
rwm-rewriteRule ".+" "${&binddn($0)}$0" ":"
# Contructing LDAP Filter for remote search. Combined with a rewrite Map,
the requested DN is returned if there is a match.
rwm-rewriteRule ".+" "(&(!(description=TEST))(distinguishedName=$0))"
":"
# If filter matches, end of rewriting. Going to 'dc=paris,dc=local'
database
rwm-rewriteRule ".+" "${checkIfPasswordExpiredDN($0)}" ":@I"
# Otherwise, restoring the original DN.
rwm-rewriteRule ".+" "${*binddn}" ":"
# And final DN massaging from "dc=paris,dc=local" to "dc=paris,dc=local2"
database
rwm-rewriteRule "(.+,)?ou=users,dc=paris,dc=local$"
"$1ou=users,dc=paris,dc=local2" ":@"
Everything goes fine until I use DN with special characters, like ',' or '['.
For example : 'cn=Pubellier\, Thierry (TEST),ou=users,dc=paris,dc=local'
In this case, the rwm-rewriteRule contructs a LDAP filter with incorrect
syntax, as special caracters are not being escaped.
I have to use some ugly tricks to escape these caracters, as shown below :
#Rewrite Map to request a remote server
rwm-rewriteMap ldap checkEntry
"ldap://10.1.2.3/ou=users,dc=paris,dc=local?dn?sub"
binddn="cn=myuser,ou=users,dc=paris,dc=local" credentials="XXX"
# Backing up original DN
rwm-rewriteRule ".+" "${&binddn($0)}$0" ":"
# Rewriting for ','
rwm-rewriteRule "(.+).\2C(.+)" "$1\\,$2"
# Adding a special '#' (asserting it in none of my DNs) suffix for special
characters, in order to escape them without looping forever
rwm-rewriteRule "(.*)([)*(\\])([^#].*|$)" "$1$2#$3"
# Escaping of special characters with dedicated '#' suffix, avoiding
infinite loops
rwm-rewriteRule "(.*)([)*(\\])#(.*)" "$1\\$2$3"
# Contructing LDAP Filter for remote search. Combined with a rewrite Map,
the requested DN is returned if there is a match.
rwm-rewriteRule ".+" "(&(!(description=TEST))(distinguishedName=$0))"
":"
# If filter matches, end of rewriting. Going to 'dc=paris,dc=local'
database
rwm-rewriteRule ".+" "${checkIfPasswordExpiredDN($0)}" ":@I"
# Otherwise, restoring the original DN.
rwm-rewriteRule ".+" "${*binddn}" ":"
# And final DN massaging from "dc=paris,dc=local" to "dc=paris,dc=local2"
database
rwm-rewriteRule "(.+,)?ou=users,dc=paris,dc=local$"
"$1ou=users,dc=paris,dc=local2" ":@"
Could there be a way to integrate the ldap escape mechanism when making an
variable assignment (like using a '#' character in place of the usual '&') ?
Thanks by advance,
Best regards,
Thierry
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9438
Issue ID: 9438
Summary: Add remoteauth overlay to core
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: ---
Symas will contribute its remoteauth overlay for OpenLDAP 2.5 as a core overlay
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9358
Issue ID: 9358
Summary: back-mdb may return accesslog entries out of order
Product: OpenLDAP
Version: 2.4.53
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
back-mdb will usually return search entries in entryID order, but may do a dn
traversal instead if the count of children is smaller than the count of search
filter candidates. The RDNs are sorted in length order, not lexical order. For
accesslog, all RDNs are of equal length but if they have trailing zeroes, the
generalizedTime normalizer truncates them. Changing their lengths causes
accesslog's timestamp-based RDNs to sort in the wrong order.
The least intrusive fix is to override the syntax/normalizer for reqStart and
reqEnd attributes to not truncate trailing zeroes.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9516
Issue ID: 9516
Summary: Argon2 configuration parameters with slappasswd
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 currently possible to generate an Argon2 hash using slappasswd as
follows:
slappasswd -h {ARGON2} -o module-load=pw-argon2
However, I believe that it is currently not possible to provide Argon2
configuration values for parameters "m", "t", and "p" when using slappasswd.
If it is currently possible to provide these config parameters when using
slappasswd, please add documentation for how to do so.
Thanks in advance!
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9873
Issue ID: 9873
Summary: idle timeout by backends close connections
Product: OpenLDAP
Version: 2.6.2
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ettorevi(a)gmail.com
Target Milestone: ---
Hi,
making searches through lloadd to a bunch of backends returns weird results
Sometimes I get:
| ldap_bind: Other (e.g., implementation specific) error (80)
| additional info: connection to the remote server has been severed
Others
ldap_result: Can't contact LDAP server (-1)
due to an idle_timeout from the backend in the middle of the search, in a non
deterministic way.
If I search directly on the backends everything works
ldapsearch -x -Hldaps://lloadd.server 'objectClass=*' -w pwd
[...]
# numResponses: 9620
# numEntries: 9620
ldap_result: Can't contact LDAP server (-1)
lloadd compiled standalone from 2.6.2 with:
--enable-balancer=yes --enable-syslog --enable-debug --enable-slapd=no
Backends are older, 2.4.49+dfsg-2ubuntu1.9 from Ubuntu 20.04
Any hints?
Thank you
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9846
Issue ID: 9846
Summary: Provide ppm v2.2
Product: OpenLDAP
Version: 2.6.2
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: david.coutadeur(a)gmail.com
Target Milestone: ---
Provide the new release of ppm: v2.2:
- implement a maximum number of characters for each class #18
- upgrade documentation for new olcPPolicyCheckModule in OpenLDAP 2.6 #30
- Make one unique code of development for 2.5 and 2.6 OpenLDAP versions #35
- fix segmentation fault in ppm_test #36
- various minor fixes and optimizations
See: https://github.com/ltb-project/ppm/milestone/5
I am going to propose a MR soon.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9856
Issue ID: 9856
Summary: Lloadd doesn't tag Notice of Disconnection
responseName
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
The responseName field in Notice of Disconnection is being tagged as a generic
octet string, where RFC4511 marks it with "responseValue [11] OCTET STRING
OPTIONAL". 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=9858
Issue ID: 9858
Summary: cn=config replication refresh breaks mdb database
Product: OpenLDAP
Version: 2.6.2
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: ---
working in an environment with the following layout:
Config node -> This node contains the cn=config databases for consumers in one
tree and providers in another tree.
provider nodes -> Pull their configuration from the config node via standard
syncrepl
consumer nodes -> Pull their configuration from the config node via standard
syncrepl
This worked fine with OpenLDAP 2.4.
With 2.6, using the same cn=config configuration, slapd will segfault if the
cn=config db is put through a REFRESH sequence. I've ruled out syncprov as an
issue as I removed the syncprov configuration from the consumer nodes entirely
and it still occurs (I was thinking perhaps it was the syncprov checkpoint at
shutdown). At this point I can reproduce this trivially 100% of the time
simply by having a node REFRESH cn=config.
Once the REFRESH has occurred, slapd will continue running. However the next
time it is stopped/started it will SEGV on startup. It is usually possible to
use slapcat to extract the MDB database and rebuild it, at which point slapd
will start again. A couple of times I was only able to extract a portion of
the database using slapcat (70MB of 650MB).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9855
Issue ID: 9855
Summary: Implement a module to enable case-insensitive Boolean
values
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
The module, when loaded from slapd.conf, will allow for values such as true,
false and True, False, to be accepted by the server
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9850
Issue ID: 9850
Summary: slapd-watcher ignores sids when only 1 server is
specified
Product: OpenLDAP
Version: 2.5.12
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
When only 1 URL is provided, it always uses only a contextCSN with sid=0.
--
You are receiving this mail because:
You are on the CC list for the issue.