FS#1053 [LDAP] getUserData fails if no $conf[bindpw]

2007-01-24 stephane.chazelas

Hi,

When using the LDAP authentication, as you know, upon login, doku binds to the LDAP server to validate his passwd, and then doku may reuse that bound connection to retrieve informations regarding the logged in user (name, email address...).

However, when retrieving information about other users (such as when retrieving the email addresses of the subscribers), doku can only rebind to the LDAP server using the "superuser" credentials. If you don't have any such superuser credentials (that is you have for instance binddn=%{user} and no bindpw, then getUserData() fails and basically the email notifications don't work if the support doesn't agree to response to anonymous (unbound) requests.

Couldn't it be changed so that it binds as the currently logged in user instead. A dirty hack that consists in calling checkPass() from within getUserData() seems to work just fine.

2007-01-24 stephane.chazelas

By the way, some details about that dokuwiki installation:

the LDAP server is a Microsoft Active directory/Exchange server.

dokuwiki is running on Linux debian unstable.

apache2 2.2.3-3.2 Next generation, scalable, extendable web server
dokuwiki 0.0.20061106-1 a standards compliant simple to use wiki
libapache2-mod-php5 5.2.0-8 server-side, HTML-embedded scripting language (apache 2 module)
libldap2 2.1.30-13.2 OpenLDAP libraries
php5-ldap 5.2.0-8 LDAP module for php5

2008-02-13 jake

I'm new to DokuWiki, so I don't speak for the original authors of this code in any way, shape or form... but I did just spend a fair amount of time digging into this problem on my local (brand new) install.

The basic problem is, by the time DokuWiki is to the point of doing this call to getUserData to find the email addresses of people who are watching pages, the users password is long forgotten. For example, consider the following typical workflow:

1. I visit the main wiki page. I know I'm gonna do some edits, so I log in.
2. Username and Password sent to DokuWiki... ldap.class.php verifies me
3. I visit the page I want to edit
4. I click edit
5. I make my changes, DokuWiki looks up email addresses for anybody who's watching pages

In that scenario, the only HTTP connection that contains my password is 2. The cookie that identifies me in sessions 3-5 does not contain my password. This is a very conscious security choice and I don't see that changing (at least, I hope it doesn't). So when we get to session 5 and DokuWiki needs to once again make an LDAP connection, it no longer has my password to do it with; therefore, the LDAP connection fails, DokuWiki can't lookup email addresses of people watching the page I edited and the email notify silently fails.

There are basically two different ways to solve this problem (not including putting my password in the cookie, which is a bad idea):
1. Define a "superuser" (binddn and bindpw) in the DokuWiki config. This superuser doesn't need to be super as far as Active Directory is concerned. I have an account I've used for this type of purpose on my AD for quite some time. It basically just needs permissions to read the directory (which any normal user account does). It does not (and I'd recommend should not) have any sort of administrative privileges. Keep in mind that bindpw will be in plain text in a file on the web server.
2. Change DokuWiki so it has a cache of names/email addresses for every user that's logged into the server.

Advantages of method 1:
* Always the most current information.
* Works right now without any code modifications to DokuWiki (I just spend a decent amount of time figuring that out!).
* No chance of cache corruption or being out of date.

Advantages of method 2:
* Does not require any "superuser" type account. This may be AD specific as AD does not allow anonymous binds to search the directory.
* Keeps the password to a valid AD account out of the plain text config file.
* Reduces the load on the LDAP server.

2008-02-14 stephane.chazelas

Jacob Steenhagen (jake) - Wednesday, 13 February 2008, 21:26 GMT:
[...]
> The basic problem is, by the time DokuWiki is to the point of
> doing this call to getUserData to find the email addresses of
> people who are watching pages, the users password is long
> forgotten. For example, consider the following typical
> workflow:

Hi Jacob,

that is not true. The password is stored encrypted in the
session cookie and can be decrypted by dokuwiki.

That is why for instance if you change your password in the LDAP
directory, doku logs you out and you need to reenter your
password.

[...]
> There are basically two different ways to solve this problem
> (not including putting my password in the cookie, which is a
> bad idea): 1. Define a "superuser" (binddn and bindpw) in the
> DokuWiki config. This superuser doesn't need to be super as
> far as Active Directory is concerned. I have an account I've
> used for this type of purpose on my AD for quite some time. It
> basically just needs permissions to read the directory (which
> any normal user account does).
[...]

That typically doesn't work for me unfortunately. I'm using the
company's Microsoft LDAP directory which I am not the
administrator of. I could use my userid except that our company
enforces us changing our password every now and then which would
mean updating the dokuwiki config every time.

Adding the checkPass() in getUserData() really makes it for me:

--- /home/stephane/tmp/ldap.class.php~ 2008-02-14 08:37:33.403308000 +0000
+++ inc/auth/ldap.class.php 2008-02-14 08:37:33.408308000 +0000
@@ -142,10 +142,15 @@
*/
function getUserData($user) {
global $conf;
if(!$this->_openLDAP()) return false;

+ if ($this->bound == 0) {
+ $pass = PMA_blowfish_decrypt($_SESSION[DOKU_COOKIE]['auth']['pass'],auth_cookiesalt());
+ $this->checkPass($_SESSION[DOKU_COOKIE]['auth']['user'], $pass);
+ }
+
// force superuser bind if wanted and not bound as superuser yet
if($this->cnf['binddn'] && $this->cnf['bindpw'] && $this->bound < 2){
// use superuser credentials
if(!@ldap_bind($this->con,$this->cnf['binddn'],$this->cnf['bindpw'])){
if($this->cnf['debug'])

2008-02-15 andi

suggested rebind with current user implemented

FS#1053 [LDAP] getUserData fails if no $conf[bindpw]

ACL & Authentication