Your message dated Mon, 10 Feb 2025 22:17:19 +0100
with message-id <[email protected]>
and subject line Closing obsolete FreeRADIUS bugs
has caused the Debian Bug report #842052,
regarding freeradius-ldap: LDAP-Group escapes UserDN twice somehow and get no
useful result then
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
842052: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842052
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: freeradius-ldap
Version: 2.2.5+dfsg-0.2
Severity: important
Tags: upstream
Dear Maintainer,
I encountered severe problems trying to match users to their LDAP Groups.
Within the inner-tunnel config I check the group ACL for a given user like
this:
if (LDAP-Group == "NET_eduroam") {
noop
}
else {
reject
}
Unfortunately the groups are nested so that I need to query the LDAP server
(Active Directory) like this:
groupmembership_filter =
"(&(objectClass=group)(member:1.2.840.113556.1.4.1941:=%{control:Ldap-UserDn}))"
That query is working fine with ldapsearch and well tested.
The rlm_ldap module needs to find the UserDN first to put it in this filter.
Here I guess lies some kind of bug. Some debug output:
....
[ldap] performing search in dc=XXX,dc=YY, with filter (sAMAccountName=foobar)
....
expand:
(&(objectClass=group)(member:1.2.840.113556.1.4.1941:=%{control:Ldap-UserDn}))
-> (&(objectClass=group)(member:1.2.840.113556.1.4.1941:=CN\3dBar\5c\5c\2c
Foo\2cOU\3dAccounts\2cDC\3dXXX\2cDC\3dYY))
rlm_ldap finds the correct user object and reads its DN. Then it places the
DN inside the group filter and escapes the whole string. But as it appears to
me the DN was already escaped beforehand and is now scaped twice.
See the "\5c\5c" part.
The CN of the User in the directory has the form:
CN: <surename>, <givenname>
Then DN is according to that
DN: CN=Bar\, Foo,OU=....
The very same request is working fine with "ldapsearch" when I remove the
second "\5c" occurance.
I assume this bug is important because it might lead to very unexpected
results.
On a second system I tried a backported version for freeradius 3.0.12 and
cannot reproduce the error. So I think this was fixed with the rewrite
of the rlm_ldap module.
Hopefully some of you are better in C and are able to produce a small
patch to fix this issue.
Regards,
Markus
-- System Information:
Debian Release: 8.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/16 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages freeradius-ldap depends on:
ii libc6 2.19-18+deb8u6
ii libldap-2.4-2 2.4.40+dfsg-1+deb8u2
ii freeradius 2.2.5+dfsg-0.2
ii freeradius-common 2.2.5+dfsg-0.2
ii freeradius-krb5 2.2.5+dfsg-0.2
ii freeradius-ldap 2.2.5+dfsg-0.2
ii freeradius-utils 2.2.5+dfsg-0.2
ii libfreeradius2 2.2.5+dfsg-0.2
freeradius-ldap recommends no packages.
freeradius-ldap suggests no packages.
--- End Message ---
--- Begin Message ---
Dear submitter,
thanks for submitting a bug report against the Debian FreeRADIUS
package. Your bug has been filed for an ancient version of FreeRADIUS
(in Debian) that has not been supported anymore for years. I'm sorry we
could not take care of it in time.
If you can still reproduce this problem on a current version (at least
in 3.2.1 shipped with Debian 12 aka bookworm), please reopen this bug.
Bernhard
--- End Message ---
