RE: Antw: Re: [patch]2 : mod_auth_ldap doesn't effectively use thecache withrequire user User1 User2 .. dir
Andre Schild [EMAIL PROTECTED] wrote: Better when we find a in the line, use those as quotes. If no are found, then use the blanks as separarators. (And this automatically disallows usernames with blanks in them.) I agree, that will be clear. BTW, how the other apache authentication modules treat this situation? Good question The only advantage a negative caching would provide is (slightly) a better handling of DOS attacks. Of course a DOS attack is still possible when requestings user1, user2 user9 Of course a negative cache should have a short cache lifetime. 3-5 minutes or so. I somehow doesn't catch the negative cache problem, we don't put in the cache any negative responces, do we? -- Yavor Trapkov, MSc. Sen. Unix Systems Admin WIPO, Geneva 1211, CH __ Try AOL and get 1045 hours FREE for 45 days! http://free.aol.com/tryaolfree/index.adp?375380 Get AOL Instant Messenger 5.1 for FREE! Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promos=380455
[patch]2 : mod_auth_ldap doesn't effectively use the cache with requireuser User1 User2 .. directives]
I have posted this patch proposal a week ago and since I got only one reply - how to
get round of the problem, and not any discussins about the problem itself or if my
proposal is reasonable or not for the module development,
I follow the instruction on the DEV page to repost it again.
The LDAP authentication has an important place, especially for big organizations with
a complex web environment. Since the mod_auth_ldap is an experimental module with
apache 2.0.x it it not part of some big distributions (an example - RH 8.0).
I think the mod_auth_ldap shoud be developed and supported as a standard apache modile.
--
Yavor Trapkov
__
Try AOL and get 1045 hours FREE for 45 days!
http://free.aol.com/tryaolfree/index.adp?375380
Get AOL Instant Messenger 5.1 for FREE! Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promos=380455
---BeginMessage---
mod_auth_ldap doesn't effectively use the cache with require user User1
User2
.. directives
What the module does:
- firstly, it checks if the whole string User1 User2 .. matches the
CN of the
authenticated user and as this is a very rear situation it almost always
fails so each time we request a page, the WEB server sends a LDAP
query as this
is never cached as a negative result
- secondly, there is a loop that checks if every single entry in the list
matches the CN of the authenticated user
= it checks if this is a cached positive result
= and if not it sends a LDAP query
= this happens until it finds a match or the list finishes
if the authenticated user is the 100th one into the require user User1
User2
.. list we are going to have 99 LDAP requests sent and then the cache will
return the positive answer.
In practise we don't really use the cache here, and such kind of
require user
User1 User2 .. UserN directives can send hundreds of LDAP queries
each time we load a web page if the list is long enough! This seems to
be able
to disable some LDAP servers (at least I've experienced this with NW
one). The
real trouble is when we use products like DreamWeaver with WebDAV aceess to
the web site - when opens the site, it makes an inventory sending
PROPFIND to
every object on the site, in such a cases even two UserNames into the
list are
enough to flood the LDAP server.
What I propose to be changed:
- firstly, to check all words into the list only against the cache and
not send
LDAP queries
- secondly, if a match is not found then check all words into the list
sending LDAP queries to the server
- at last, to check for the whole string user1 user2 .. as this is very
rear case and in almost all cases gives a negative result
(even more sophisticated idea could be to assemble a single OR
query and send
to the server)
this requires spitting the util_ldap_cache_compare:
util_ldap_cache_only_compare - checks for a cache match
util_ldap_server_only_compare - sends a request to the LDAP server
A proposed patch follows, I haven't compiled it with httpd2.0, but I
successfully applied a similar one with the auth_ldap module for apache 1.3.
Best Regards
Yavor Trapkov
--- mod_auth_ldap.c.org 2003-03-09 08:15:12.0 +0100
+++ mod_auth_ldap.c 2003-03-09 10:34:57.0 +0100
@@ -548,30 +548,35 @@
return sec-auth_authoritative? HTTP_UNAUTHORIZED :
DECLINED;
}
/*
- * First do a whole-line compare, in case it's something like
- * require user Babs Jensen
+ * Now break apart the line and compare each word on it
against the cache
*/
-result = util_ldap_cache_compare(r, ldc, sec-url, req-dn,
sec-attribute, t);
-switch(result) {
-case LDAP_COMPARE_TRUE: {
-ap_log_rerror(APLOG_MARK,
APLOG_DEBUG|APLOG_NOERRNO, 0, r,
- [%d] auth_ldap authorise:
- require user: authorisation
successful, getpid());
-return OK;
-}
-default: {
-ap_log_rerror(APLOG_MARK,
APLOG_DEBUG|APLOG_NOERRNO, 0, r,
- [%d] auth_ldap authorise: require
user:
- authorisation failed [%s][%s],
getpid(),
- ldc-reason, ldap_err2string(result));
+while (t[0]) {
+w = ap_getword_conf(r-pool, t);
+result = util_ldap_cache_only_compare(r, ldc, sec-url,
req-dn, sec-attribute, w);
+switch(result) {
+case LDAP_COMPARE_TRUE: {
+ap_log_rerror(APLOG_MARK,
APLOG_DEBUG|APLOG_NOERRNO, 0, r,
+ [%d] auth_ldap authorise:
+ require user: authorisation
successful, getpid());
+return OK
Re: [patch]2 : mod_auth_ldap doesn't effectively use the cache withrequire user User1 User2 .. directives]
Graham Leggett [EMAIL PROTECTED] wrote: Yavor Trapkov wrote: - firstly, it checks if the whole string User1 User2 .. matches the CN of the authenticated user and as this is a very rear situation it almost always fails so each time we request a page, the WEB server sends a LDAP query as this is never cached as a negative result We have to check this case first, otherwise we could have false positives. A better workaround for this is to insist that all the tokens in the require list be surrounded with 's if there are spaces involved in the search pattern. Then we can drop the whole line search entirely. You are right, we can have false positives, i.e. positive match for Firstname when we want to look for Firstname Secondname, but this logic can be applied in reverse order, i.e. positive match for Firstname Secondname when we want to look for Firstname. Then your idea to use 's and have only one check is probably a solution or we can have an extra option to specify how this require user User1 User2 .. to be interpreted - as a single value or as a list of values. BTW, how the other apache authentication modules treat this situation? - secondly, there is a loop that checks if every single entry in the list matches the CN of the authenticated user = it checks if this is a cached positive result = and if not it sends a LDAP query = this happens until it finds a match or the list finishes If you have a need for more than one user on a require user line, then you really should be using LDAP groups. LDAP groups are far more managable anyway. Directives as require user User1 User2 .. are very commonly used with apache (and very convenient) and in this style, I think, many users might prefer to use that with LDAP authentication as well. - firstly, to check all words into the list only against the cache and not send LDAP queries What you are asking for is negative caching, which I am not 100% comfortable with. If a login fails due to some error (eg wrong password), and the error is subsequently fixed in the directory, the next time the query is tried with the correct password the comparison will fail until the negative cache has timed out. This will not be immediately obvious to the user, and will probably be reported as a bug. The problem here is that we never use the cache with such a directive, like the module works now, and if it's used (wrongly or not), it can generate many requests to the LDAP server. If first all values are checked against the cache and then if we don't find a match we go to the LDAP - this will make the cache used properly - no ldap requests sent if we have cached the positive result, the negative results are not cached anyway. I don't see negative cacheing. - at last, to check for the whole string user1 user2 .. as this is very rear case and in almost all cases gives a negative result It is not a rare case - if you match against cn (as iPlant directory server does by default) you will almost always use this case. Firstname Secondname is probably not so commonly used username (having ) Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... Regards -- Yavor Trapkov __ Try AOL and get 1045 hours FREE for 45 days! http://free.aol.com/tryaolfree/index.adp?375380 Get AOL Instant Messenger 5.1 for FREE! Download Now! http://aim.aol.com/aimnew/Aim/register.adp?promos=380455
Re: [patch] mod_auth_ldap doesn't effectively use the cache withrequire user User1 User2 .. directives
require group works and can replace require user User1 User2 ... if one knows about the problem, but there are at least three things here: - require user User1 User2 ... is a supported option and it has to work properly with the cache - the directive is very convinient and makes the web site (administrator) independant of any LDAP interventions (creating/modifying of additional groups) which is not always easy in a please where we have many subsites that require authentication - I don't know how others use this option but I think it's in common use, and not having the cache here the access to web site becomes much slower. The change I propose is rather semantical and should be easy implemented. Regards Yavor Trapkov Graham Leggett [EMAIL PROTECTED] wrote: Yavor Trapkov wrote: mod_auth_ldap doesn't effectively use the cache with require user User1 User2 .. directives Why not just use require group? Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... -- Yavor Trapkov __ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/
[patch] mod_auth_ldap doesn't effectively use the cache with requireuser User1 User2 .. directives
mod_auth_ldap doesn't effectively use the cache with require user User1
User2
.. directives
What the module does:
- firstly, it checks if the whole string User1 User2 .. matches the
CN of the
authenticated user and as this is a very rear situation it almost always
fails so each time we request a page, the WEB server sends a LDAP
query as this
is never cached as a negative result
- secondly, there is a loop that checks if every single entry in the list
matches the CN of the authenticated user
= it checks if this is a cached positive result
= and if not it sends a LDAP query
= this happens until it finds a match or the list finishes
if the authenticated user is the 100th one into the require user User1
User2
.. list we are going to have 99 LDAP requests sent and then the cache will
return the positive answer.
In practise we don't really use the cache here, and such kind of
require user
User1 User2 .. UserN directives can send hundreds of LDAP queries
each time we load a web page if the list is long enough! This seems to
be able
to disable some LDAP servers (at least I've experienced this with NW
one). The
real trouble is when we use products like DreamWeaver with WebDAV aceess to
the web site - when opens the site, it makes an inventory sending
PROPFIND to
every object on the site, in such a cases even two UserNames into the
list are
enough to flood the LDAP server.
What I propose to be changed:
- firstly, to check all words into the list only against the cache and
not send
LDAP queries
- secondly, if a match is not found then check all words into the list
sending LDAP queries to the server
- at last, to check for the whole string user1 user2 .. as this is very
rear case and in almost all cases gives a negative result
(even more sophisticated idea could be to assemble a single OR
query and send
to the server)
this requires spitting the util_ldap_cache_compare:
util_ldap_cache_only_compare - checks for a cache match
util_ldap_server_only_compare - sends a request to the LDAP server
A proposed patch follows, I haven't compiled it with httpd2.0, but I
successfully applied a similar one with the auth_ldap module for apache 1.3.
Best Regards
Yavor Trapkov
--- mod_auth_ldap.c.org 2003-03-09 08:15:12.0 +0100
+++ mod_auth_ldap.c 2003-03-09 10:34:57.0 +0100
@@ -548,30 +548,35 @@
return sec-auth_authoritative? HTTP_UNAUTHORIZED :
DECLINED;
}
/*
- * First do a whole-line compare, in case it's something like
- * require user Babs Jensen
+ * Now break apart the line and compare each word on it
against the cache
*/
-result = util_ldap_cache_compare(r, ldc, sec-url, req-dn,
sec-attribute, t);
-switch(result) {
-case LDAP_COMPARE_TRUE: {
-ap_log_rerror(APLOG_MARK,
APLOG_DEBUG|APLOG_NOERRNO, 0, r,
- [%d] auth_ldap authorise:
- require user: authorisation
successful, getpid());
-return OK;
-}
-default: {
-ap_log_rerror(APLOG_MARK,
APLOG_DEBUG|APLOG_NOERRNO, 0, r,
- [%d] auth_ldap authorise: require
user:
- authorisation failed [%s][%s],
getpid(),
- ldc-reason, ldap_err2string(result));
+while (t[0]) {
+w = ap_getword_conf(r-pool, t);
+result = util_ldap_cache_only_compare(r, ldc, sec-url,
req-dn, sec-attribute, w);
+switch(result) {
+case LDAP_COMPARE_TRUE: {
+ap_log_rerror(APLOG_MARK,
APLOG_DEBUG|APLOG_NOERRNO, 0, r,
+ [%d] auth_ldap authorise:
+ require user: authorisation
successful, getpid());
+return OK;
+}
+default: {
+ap_log_rerror(APLOG_MARK,
APLOG_DEBUG|APLOG_NOERRNO, 0, r,
+ [%d] auth_ldap authorise:
+ require user: authorisation
failed [%s][%s],
+ getpid(), ldc-reason,
ldap_err2string(result));
+}
}
}
/*
- * Now break apart the line and compare each word on it
+ * Now break apart the line and compare each word on it
against the LDAP server
*/
+ t = reqs[x].requirement;
+ w = ap_getword(r-pool, t, ' ');
+
while (t[0]) {
w = ap_getword_conf(r-pool, t);
-result = util_ldap_cache_compare(r, ldc, sec-url,
req-dn, sec-attribute, w);
+result = util_ldap_server_only_compare(r, ldc,
sec-url, req-dn
