FS#1791 ad_auth - authentication caching does not work, too many ldap calls make wiki slow

ACL & Authentication

• 

  2009-11-01 Tomeks666

  I am using 2009.02.14 DokuWiki on Windows Server 2003 + IIS with acl, blog, comments etc. with AD passthrough authentication.
  
  I have configured AD integration using this http://www.dokuwiki.org/auth:ad manual. I noticed that Wiki become extremely slow. I captured TCP streams and I noticed excessive LDAP communication. I belong to 46 AD groups. ADldap was retrieving memberOf attribute for every of these groups and then their parent groups recursively. I had to block "recursive_groups" lookup to make performance usable. Even after this mod Wiki retrieves 170kB of data from AD server just to load the start page.
  
  I have found that both doku.php and indexer.php would do some ldap operations on each execution.
  
  Auth.php is included in doku.php and unconditinally creates ad_auth object. Constructor of ad_auth will open tcp connection to ldap server. This means that each pass of doku.php (and indexer.php) casues 1 tcp connection to ldap wheather it is needed or not:
  39      if (class_exists($auth_class)) {
  40        $auth = new $auth_class();
  
  Later in auth.php there is a series of conditional statements trying to reuse the previous authentication, but there is something wrong there. Each time the execution eventually goes to line 86:
  
  86  auth_login($_REQUEST['u'],$_REQUEST['p'],$_REQUEST['r'],$_REQUEST['http_credentials']);
  
  which causs user validation against ldap server and new attempt to set a cookie, as well as next user_info call that queries ldap for group membership - potentially slow. Even if the cookie contains information from the previous run the script keeps rewriting it.
  
  I guess there is something wrong with conditionals in auth.php intended for reusing previous login as well as there is an unnecessary creation of ldap on the beginning.
  
  The problem becomes really severe if I install plugins like "blog", "comment", "sidebar". Each plugin loads auth.php and number of unnecessary calls to ldap starts to grow rapidly (e.g. 2 additional calls for every comment, blog entry etc.)
  
  
  
• 

  2009-11-02 andi

  Quick question: are you using SSO with the auth AD backend?
• 

  2009-11-02 andi

  And another question: are you using a current devel release or the older auth_ad downloadable at http://www.dokuwiki.org/auth:ad ?
• 

  2009-11-02 Tomeks666

  I am using the older auth_ad from the link you mentioned. Yes - I do use SSO. No problem with password prompts, group information is processed, my full name is displayed. The problem was only with performance.
  
  I noticed that something bad is happening in the line :
  
  list($_SERVER['PHP_AUTH_USER'],$_SERVER['PHP_AUTH_PW']) =
  explode(':', base64_decode(substr($_SERVER['HTTP_AUTHORIZATION'], 6)));
  The parsed string is:
  NTLM TlRMTVNTUAADAAAAGAA ....(reminder deleted)
  Or
  Negotiate TlRMTVNTUAADAAAAGAA ....(reminder deleted)
  depending on IIS setting
  
  6 was not a good value to cut base64 encoded part. I tried changing substr$ argument to 5 or 10 and the result was some string beginning with NTLMSSP, but not User and Password.
  
  I still cannot see where exactly the decision should be made to rely on cookie/session instead of calling ldap.
  
  
• 

  2009-11-02 andi

  I updated the ad backend in the current devel version and also uploaded a new zip of it. It should fix at least some of the problems (unless I broke it completely - I couldn't test it because lack of an AD server).
  
  Could you please try with that?
• 

  2009-11-02 Tomeks666

  There is a visible change. It still recognizes my userid, but it does not connect to AD even once, does not get groups nor my real name. I think your change was too radical.
  
  Or I should replace auth.php with the newer version too?
• 

  2009-11-02 andi

  dang. will need to check tomorrow.
• 

  2009-11-03 andi

  Okay. Should be fixed now. I updated the download again. Could you try again please?
• 

  2009-11-03 Tomeks666

  Now it is behaving more or less like on the beginning. 2 connection per page view, some queries executed in each connection.
  
  Can you tell me which "if" in our scenarion should determine that cookie/session should be used and not external authentication? I have a functional debug with Eclipse/xdebug - I can look in there.
• 

  2009-11-03 andi

  The change now should make sure that simply instantiating the auth class will not open a connection to the AD server, so it should be a bit better already.
  
  The backend will be asked whenever $_REQUEST['u'] is set (means some non-empty string is passed to auth_login). Otherwise the cookie is read and checked against the stored session data.
  
  The AD backend checks if a COOKIE was previously set and will not set $_REQUEST['u'] to the SSO username then. So after the initial login everything should be cached for $conf['auth_security_timeout'] seconds.
  
  Note that I'm doing my tests with a current development version, maybe there was something changed that I forgot about, so it might be worth for you to try with a devel release.
• 

  2009-11-03 Tomeks666

  I have found that $_REQUEST['u'] is set to my userid in init.php line 216:
  $_REQUEST = array_merge($_GET,$_POST);
  is this something you would expect?
  
  I have added this statement in the next line:
  unset ($_REQUEST['u']);
  
  It behaves much better now. Uses the session. TCP connections are not created except the first load and in case of some pages e.g. the start page. I can take a look why.
  
  Is t
• 

  2009-11-03 Tomeks666

  The second LDAP call comes from helper.php. It does not case for the cookie and calls getUserData directly:
  438 $userdata = $auth->getUserData($user);
  
  
• 

  2009-11-04 andi

  Hmm I don't see why the 'u' field of $_POST or $_GET should be set unless you're actually doing a login. Especially since there is not much going on before init.php.
  
  Which helper.php are you talking about? Which plugin? You probably can not avoid these calls as they are probably used to fetch data for users different from the currently logged in on. But that needs to be checked for each plugin.
• 

  2009-11-04 Tomeks666

  This was coming from local.protected.php
  
  // Strip NT-domain from AUTH_USER, "DOMAIN\username" -> "username", before saving it.
  if (isset($_SERVER['AUTH_USER']) and !isset($_SESSION[$conf['title']]['auth']['info'])) {
   list($d, $username) = split("\\\\", strtolower($_SERVER['AUTH_USER']), 2);
   $_GET['u'] = $username;
  
  It is was lefover from a previous unsuccesful implementation of http://www.dokuwiki.org/install:iis_and_sso. I thing the article should be removed from wiki, because it is obsolete and puts people in trouble. Sorry for that. Anyway there is some optimization achived by eliminating unnecessaty ldap connection in auth_ad contructor.
  
  The other ldap calls were caused by Include plugin. Wiki was calling getUserData($user) circa 15 times to display the start page when sidebar and blog was present. I cured the problem with '//" in line 438. I have not discovered any side effects yet. Blog entries still have correct author information.
  
  Now wiki is lighting fast. Only one ldap connection per session with very little data dowloaded (about 9kB), not hundreds of kBs like before.
  
  
  
  

  • helper.php text/plain
• 

  2009-11-04 andi

  Ah good. I deleted the page.
  
  Regarding the include plugin, could you please open a bug report at github? Link should be at plugin:include