[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[suse-security] Suse 9.0->apache2->mod_auth_ldap->bug ? When the fix will be available ?

Hello All,

I have a strange behavior of the module mod_auth_ldap in apache2 in suse 9.0:

when configuring basic authentication like that:

<VirtualHost *:80>
    ServerName default.domain.com
    DocumentRoot /www/default/htdocs
    <Directory /www/default/htdocs>
        order allow,deny
        AllowOverride All
        allow from
AuthLDAPUrl ldap://ldap.domain.com:389/dc=domain,dc=com?uid?sub?
AuthLDAPBindDN cn=server,ou=services,dc=domain,dc=com
AuthLDAPBindPassword password
AuthType Basic
AuthName "LDAP-Protected resource"
require valid-user
Satisfy any

when accessing not from trusted IP the following thing 
1. a password dialog opens, to enable user to provide a correct password - 
good thing
2. intentionaly type INCORRECT user/password combination, submit. Get access 
denied with another dialog opening - good thing
3. Now type CORRECT user/password combination, still get access denied - not a 
good thing, probably bug ???!!!???

Note1: if you type in the first attempt correct user/password combination - no 
bad thing happen.
Note2: could not find anything related explainig to that behavior in bug 
reports of apache, however that problem is fixed in the most recent release 
(see below)
Note3: Nothing bad is seen in apache's log files after a failure.

I use default version of apache2 package shipped with Suse 9.0: 
apache2-2.0.47-63 with prefork package. Update to the latest apache2 package 
available by the moment at ftp.suse.com (apache2-2.0.48-139) - does not help. 
Tests were made on two separate installations of Suse 9.0 system.

The problem is fixed when building apache2-2.0.51 from sources, but the 
question is WHEN the fixed version will be available in updated at 
ftp.suse.com ? I really need it :)

Best Regards,
Novosjolov Dmitry

Check the headers for your unsubscription address
For additional commands, e-mail: suse-security-help@xxxxxxxx
Security-related bug reports go to security@xxxxxxx, not here