control: tags -1 severity normal control: tags -1 tags + help On Tue, Oct 25, 2016 at 4:17 PM, Markus Wigge <mar...@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-maintain...@lists.alioth.debian.org > https://lists.alioth.debian.org/mailman/listinfo/pkg- > freeradius-maintainers > -- Best regards, Michael