FS#2781 No access to content with authad but login works

2013-05-16 dmcgroup

We are having issues with the rights management after authanticating against Active Directory. Login works as usual, but you can't see the content because access is denied.

This happens since upgrading from Weatherwax RC1 to Weatherwax stable. When rolling back to RC1 everything works fine.

Our configuration (local.protected.php) looks like:

// general DokuWiki options
$conf['useacl'] = 1;
$conf['disableactions'] = 'register';
$conf['authtype'] = 'authad';

// configure your Active Directory data here
$conf['auth']['ad']['account_suffix'] = '@example.lan';
$conf['auth']['ad']['base_dn'] = 'DC=EXAMPLE,DC=LAN';
$conf['auth']['ad']['domain_controllers'] = 'example.lan'; //multiple can be given
$conf['manager'] = '@Internal_DokuWiki_Admins';
$conf['superuser'] = '@Internal_DokuWiki_Admins';

ACL rules are:
* for @ALL = None
* for @user = Delete

(This is a bug report out of https://forum.dokuwiki.org/post/38589)

Cheers
Karl

2013-05-19 ChrisS

As well as changing the $conf['authtype'] value to 'authad', the individual auth settings need to be changed from ['ad'] to ['authad']. More details are given in the comments of lib/plugins/authad/auth.php.

Please advise if this resolves the problem or not - so we can either investigate further or close this bug report.

2013-05-20 dokufan66

Confirm have save issue from previous version to Weatherwax (not from RC1).

Your suggestion did not solve the problem, but broke it further, no log-in possible.

// configure your Active Directory data here
$conf['auth']['authad']['account_suffix'] = '@example.lan';
$conf['auth']['authad']['base_dn'] = 'DC=EXAMPLE,DC=LAN';
$conf['auth']['authad']['domain_controllers'] = 'example.lan'; //multiple can be given

The group membership part is what is broken. If the user is an admin (superuser) they can access the wiki.

EDIT: some settings still need to use 'ad'
$conf['auth']['authad']['debug'] = 1; //does not work
$conf['auth']['ad']['debug'] = 1; //works

EDIT2: previously did not require an LDAP account to connect to LDAP to authenticate and authorize users. Now we get an error:
AD Auth: Bind to Active Directory failed. Check the login credentials and/or server details. AD said: Can't contact LDAP server

EDIT3: Reverting to Adora Belle, unable to resolve for my 20 users.

2013-05-21 marcel_e

Hello,

i have the same issue. In my php Error file, I see the following errors after a successful loging:

[Thu May 16 16:20:45 2013] [error] [client xxxxx] PHP Warning: ldap_get_entries() expects parameter 2 to be resource, boolean given in /srv/www/dokuwiki.verbund.local/lib/plugins/authad/adLDAP/classes/adLDAPUsers.php on line 239, referer: http://dokuwiki.verbund.local/doku.php?id=start&do=login
[Thu May 16 16:20:45 2013] [error] [client xxxxx] PHP Warning: ldap_search(): Search: Operations error in /srv/www/dokuwiki.verbund.local/lib/plugins/authad/adLDAP/classes/adLDAPUsers.php on line 238, referer: http://dokuwiki.verbund.local/doku.php?id=start&do=login

The loging ist ok, but the memberships are missing.

2013-05-21 mwollny

I have the same issue, login itself is working, but does not lead to any group authorization. Same PHP error messages:

[Tue May 21 13:51:00 2013] [error] [client 192.168.8.13] PHP Warning: ldap_search(): Search: Operations error in /var/www/webserver/my.dokuwiki.site/lib/plugins/authad/adLDAP/classes/adLDAPUsers.php on line 238, referer: https://my.dokuwiki.site/doku.php?id=start&do=login&sectok=sometoken
[Tue May 21 13:51:00 2013] [error] [client 192.168.8.13] PHP Warning: ldap_get_entries() expects parameter 2 to be resource, boolean given in /var/www/webserver/my.dokuwiki.site/lib/plugins/authad/adLDAP/classes/adLDAPUsers.php on line 239, referer: https://dmy.dokuwiki.site/doku.php?id=start&do=login&sectok=sometoken

Options uses as specified in the docs:
$conf['useacl'] = 1;
$conf['disableactions'] = 'register';
$conf['authtype'] = 'authad';
$conf['plugin']['authad']['account_suffix'] = '@my.domain';
$conf['plugin']['authad']['base_dn'] = 'DC=my,DC=domain';

$conf['plugin']['authad']['domain_controllers'] = 'dc.my.domain';
$conf['manager'] = 'My.Name';
$conf['superuser'] = '@Superuser-Group';

The actual settings are working fine in the $conf['auth']['ad'] configuration of Adora Belle. After changing to authad while retaining the settings, authorization no longer works (though authentication does).

We're reverting to Adora Belle for the time being.

2013-05-22 status

I can definitly confirm this issue. Have a running production installation with Adora Belle stable and did an upgrade to Weatherwax stable on a copy of production.

Result: login with ad accounts is working fine but no group memberships are detected.
Checking with '...?do=check' will show up no group memberships for account logged in.

2013-05-24 millsdude

I was using WeatherWax RC1 and upgraded to version 40. At that point the authentication was not getting the groups. Adding my username (instead of my AD admin group name) to the superuser entry got me back into the system. I copied the authad plugin from the RC1 backup over the version 40 and things went back to normal.

Looking through the code I tried to spot the bug, but I could not find it.

2013-05-24 lvlaaron

I had the same problem after upgrading to Weatherwax. I feel like the problem is that it's not able to use groups (@Internal_DokuWiki_Admins in this case) - I had to specify individual users to get mine working.

2013-05-29 XyFreak

Hi,

this Problem is definitely present in "Weatherwax". The cause is a change made to the adLDAP.php (Line 642) which changed '$this->adminUsername != NULL && $this->adminPassword != NULL' from previous Versions to '$this->adminUsername !== NULL && $this->adminPassword !== NULL'. The code will now enter the if branch if $this->adminUsername and $this->adminPassword are empty strings - which is the case if the default value DokuWiki provides is being used.

If you do not set
$conf['auth']['ad']['admin_username'] = NULL;
$conf['auth']['ad']['admin_password'] = NULL;
in your DokuWiki config file OR change the default settings for authad (/lib/plugins/authad/conf/default.php) to
$conf['admin_username'] = NULL;
$conf['admin_password'] = NULL;

the plugin will attempt to bind the LDAP connection to an anonymous user before attempting to rebind it later on the an actual user. The rebinding however will not elevate the session to the actual user on windows servers and thus the connection will stay anonymous. Now on most configurations anonymous connections can't query any user data and you get the 'Operations error'.

To make it short:

changing the default configuration of the authad-plugin should be the way to go for now and this NEEDS to be included in the next release of DokuWiki.

This Bug was a bitch to find....

Have a nice day
-XyFreak

2013-05-29 marcel_e

Hi Tobias Kux,

thank you very much to find the bug und show us to solve the problem.

Have a nice day, too.

2013-05-29 status

Three cheers for Tobias. You did it!
Setting the plugin conf as described will work definitly. :-)

Danke und Gruß
Stefan

2013-05-31 mwollny

Thank you Tobias,

I can confirm that adding the two NULL-assignment lines to the configuration solves the problem.

Kind regards

Markus

2013-06-03 dokufan66

Confirmed on a test machine (Uniserver running Apache on Windows) and on production (RHEL 6) that the old change needed to be made to local.protected.php are:
$conf['authtype'] = 'authad';
$conf['auth']['ad']['admin_username'] = NULL;
$conf['auth']['ad']['admin_password'] = NULL;

Thanks all

2013-06-03 dmcgroup

Thank you guys!
Added the two lines for admin_username and admin_password in the config file and now it works.

Cheers
Karl

2013-06-07 andi

12d195ab should fix this problem, can anyone of you please confirm this?

2013-06-10 dokufan66

Andreas, confirmed that fix works. Thanks!

FS#2781 No access to content with authad but login works

ACL & Authentication