[Pkg-freeradius-maintainers] Bug#842052: Bug#842052: freeradius-ldap: LDAP-Group escapes UserDN twice somehow and get no useful result then

[Michael Stapelberg]

control: tags -1 severity normal
control: tags -1 tags + help

On Tue, Oct 25, 2016 at 4:17 PM, Markus Wigge <markus at cultcom.de> wrote:

> 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.
>

Please see https://www.debian.org/Bugs/Developer#severities for how the
Debian bug severities are to be interpreted. “important” is explained as “a
bug which has a major effect on the usability of a package […]”, for which
I don’t see any evidence here — there seems to be a problem with an
individual setup in an individual module. Hence, downgrading to “normal”.


>
> 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.
>

I can’t spend any time on this issue. I’m focusing on getting version 3
into Debian. By the way, if you’re using the 3.0.12+dfsg-1 package, please
respond to my question in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797181#69

You might want to try reporting this issue upstream at
https://github.com/FreeRADIUS/freeradius-server/


>
> 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.
>
> _______________________________________________
> Pkg-freeradius-maintainers mailing list
> Pkg-freeradius-maintainers at lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-
> freeradius-maintainers
>



-- 
Best regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-freeradius-maintainers/attachments/20161025/20616d48/attachment.html>