O/H Alan DeKok έγραψε:
the problem is with the groupmembership_filter. It contains the Ldap-UserDn attribute which gets xlated and escaped:Ryan Kramer wrote:I SUSPECT something might not be escaped in a manner the MS AD server likes, or maybe just the fact it has any escape sequences built in at all is what is causing it to toss it.No. As I have said already, the problem is that the LDAP queries are being escaped. Please pay attention to what I'm saying, it might help you solve the problem. The default install does not do this. The default configuration does not do this. Other people have not run into this problem. The problem is almost definitely the way you are building the queries. i.e. the LDAP queries are built up as: <text from config file> ldap_escape(other text) <text from config ...> The text that you, as administrator entered into the configuration file is NEVER escaped. The text that a random user enters as a User-Name is ALWAYS escaped.
"(|(&(objectClass=GroupOfNames)(member=%{Ldap-UserDn}))(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn})))"
A DN usually contains commas which get escaped and break the ldap
search. I am not so sure why we should escape ',' in the first place.
That way we break any ldap searches for attribute values holding DN's.
If you're putting queries into an attribute, and then later using that attribute as part of another query, that text WILL be escaped. The server has no way of telling where that text came from, so it's untrusted. The solution is to carefully examine how you build the queries. There may be simpler ways of doing it, which avoids the double escaping issue. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html