Re: LDAP changes between 1.01 and 1.1.5
O/H Alan DeKok έγραψε:
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.
the problem is with the groupmembership_filter. It contains the
Ldap-UserDn attribute which gets xlated and 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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP changes between 1.01 and 1.1.5
the problem is with the groupmembership_filter. It contains the
Ldap-UserDn attribute which gets xlated and 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.
This is correct.
For info the python-ldap module contains a function:
def escape_filter_chars(assertion_value):
Replace all special characters found in assertion_value
by quoted notation
s = assertion_value.replace('\\', r'\5c')
s = s.replace(r'*', r'\2a')
s = s.replace(r'(', r'\28')
s = s.replace(r')', r'\29')
s = s.replace('\x00', r'\00')
return s
...implying that only \*()NUL need be escaped?
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
LDAP changes between 1.01 and 1.1.5
I've recently moved to 1.1.5, and went from a system that worked perfectly with MS LDAP to one that will no longer find the user groups, using the identical config. Anyone have any ideas? The obvious one is that 1.1.5throws in all kinds of escape characters, but i'm assuming that is output only. Ryan Kramer 1.0.1 output rlm_ldap: performing search in ou=DIVISION,dc=state,dc=company, with filter ((cn=DIVISION-WIFI)(|((objectClass=group)(member=CN=Kramer\\, Ryan M.,OU=USERS,OU=DIVISION,DC=state,DC=company))((objectClass=GroupOfUniqueNames)(uniquemember=CN=Kramer\\, Ryan M.,OU=USERS,OU=DIVISION,DC=state,DC=company rlm_ldap::ldap_groupcmp: User found in group DIVISION-WIFI 1.1.5 output rlm_ldap: performing search in ou=DIVISION,dc=state,dc=company, with filter ((cn=DIVISION-WIFI)(|((objectClass=group)(member=CN\3dKramer\5c\5c\2c Ryan M.\2cOU\3dUSERS\2cOU\3dDIVISION\2cDC\3dstate\2cDC\3dcompany))((objectClass=GroupOfUniqueNames)(uniquemember=CN\3dKramer\5c\5c\2c Ryan M.\2cOU\3dUSERS\2cOU\3dDIVISION\2cDC\3dstate\2cDC\3dcompany rlm_ldap: object not found or got ambiguous search result rlm_ldap::ldap_groupcmp: Group DIVISION-WIFI not found or user is not a member. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP changes between 1.01 and 1.1.5
Ryan Kramer wrote: I've recently moved to 1.1.5, and went from a system that worked perfectly with MS LDAP to one that will no longer find the user groups, using the identical config. Anyone have any ideas? The obvious one is that 1.1.5 throws in all kinds of escape characters, but i'm assuming that is output only. No. It's part of the LDAP query. In order to avoid external users logging in with names that are valid LDAP queries, the untrusted user input is escaped before it is passed to the LDAP module. See the *rest* of the debug output for the sequence of string expansions. It looks like you're calling the LDAP module twice, and using the output of the first query as part of the wuery string for the second query. 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
Re: LDAP changes between 1.01 and 1.1.5
No. It's part of the LDAP query. In order to avoid external users logging in with names that are valid LDAP queries, the untrusted user input is escaped before it is passed to the LDAP module. Apparently something in the ldap_escape_func is broken when talking to Microsoft AD. I replaced the code of that function with the much more lenient code of the 1.0.1 ldap_escape_func, and it works great with MS LDAP now! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP changes between 1.01 and 1.1.5
On Thu 12 Apr 2007, Ryan Kramer wrote: No. It's part of the LDAP query. In order to avoid external users logging in with names that are valid LDAP queries, the untrusted user input is escaped before it is passed to the LDAP module. Apparently something in the ldap_escape_func is broken when talking to Microsoft AD. I replaced the code of that function with the much more lenient code of the 1.0.1 ldap_escape_func, and it works great with MS LDAP now! Please open a bug report in the tracker... -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP changes between 1.01 and 1.1.5
Ryan Kramer wrote: Apparently something in the ldap_escape_func is broken when talking to Microsoft AD. The code does not distinguish between Microsoft AD and other LDAP servers. I replaced the code of that function with the much more lenient code of the 1.0.1 ldap_escape_func, and it works great with MS LDAP now! I'm curious to know what your queries are, and if you're doing the double queries I suspect. I think that the problem can better be solved by understanding it, rather than by removing the restrictions that prevent people from attacking your LDAP server. 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
Re: LDAP changes between 1.01 and 1.1.5
On 4/12/07, Alan DeKok [EMAIL PROTECTED] wrote: Ryan Kramer wrote: Apparently something in the ldap_escape_func is broken when talking to Microsoft AD. The code does not distinguish between Microsoft AD and other LDAP servers. Correct, it is very simple code and doesn't care. My guess is that it is Microsoft AD not acting like any other reasonable AD on the planet i suspect. I'll post my exact queries tomorrow, but as I mentioned, the only change was to revert that section of code back to the 1.0.1 version, recompile, and it works great. I hacked away at the configs for about 3 hours without any success using pretty much every trick I could think of to get it working. 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. Hopefully tomorrow I'll be able to get some logs from our server admins to see exactly what the queries they receive look like. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: LDAP changes between 1.01 and 1.1.5
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. 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
