This auth backend allows DokuWiki to authenticate against an Active Directory Server.

While Active Directory authentication can be set up with the bundled authLDAP plugin, it should be easier to do with this dedicated AD auth plugin. It makes use of the excellent adLDAP library and is based on the work by James Van Lommel. You do not need to download the adLDAP library yourself, it is included with DokuWiki.

In addition it allows the use of NTLM and Kerberos based Single-Sign-On .

Before this plugin can be used, you need to setup some settings:

1. Prepare your AD server, see also server configuration below.
2. Activate the authad plugin in the Extension Manager.
3. Define connection details in the Configuration Manager
4. Switch on this Auth plugin via the configuration option authtype by selecting authad.

Save the configuration settings to the conf/local.protected.php file to protect the settings against changes via Config Manager.

Modification of users and its groups can be done in the User manager. Only modifications are possible, adding new users is not possible with authAD. Also self registration by users is disabled by the authAD plugin. At the moment the wiki cannot check Active Directory password policy, so better you disable the action password reset resendpwd or if possible modify your AD password policy.

Your server configuration must meet the requirements of the adLDAP PHP library.

If you're using Apache on Ubuntu or Debian, just install the php-ldap package. If you're using Apache on another distro, follow this guide¹⁾. Installing php5-ldap also works on SLES. If you're using Arch Linux, install the php-ldap package with pacman.

For MS IIS7 server php-ldap and php-openssl extensions needs to be installed (the second one only when SSL support required). For php-openssl dependency dlls ssleay32.dll and libeay32.dll needs to be available in your system too, you will need to make sure they are in a folder that is in the system path or just drop them off in the windows\system32 folder. When accessing AD using SSL, you must create file ldap.conf in C:\OpenLDAP\sysconf with line TLS_REQCERT never. which disables AD certificate checking when making LDAP call.
WARNING! This could lead to Man-In-The-Middle attacks, so probably better solution is configure valid certificate using this file (more on http://linux.die.net/man/5/ldap.conf).

If you're using Debian, just install the php5-ldap package.

Installing under Nginx on Ubuntu 14 requires php5-ldap. Follow the Nginx php setup instructions here: Dokuwiki Nginx Config. The user needs only to set account_suffix, base_dn, and domain_controllers. For domain controller, ldaps:<server> and ldap:<server> work. These modifications were made in local.php than moved to local.protected.php ex:

  $conf['plugin']['authad']['account_suffix'] = '@ad.something.edu';
  $conf['plugin']['authad']['base_dn'] = 'dc=ad,dc=something,dc=edu';
  $conf['plugin']['authad']['domain_controllers'] = 'ldaps://ad.something.edu';

If you're using a web server other than Apache, Nginx, or IIS7, you have to figure it out yourself. :( Please update this article if you succeed.

The backend will be enabled with the authtype configuration option by selecting authad which is part of “Authentication Settings” in the Configuration Manager, or you could add a corresponding line to the conf/local.protected.php file to save the setting protected for changes.

In the “Plugin Settings” are settings for the authAD plugin. Here you define your AD server and connection details.

There are more general authentication related settings available too.

You can use the Configuration Manager to configure the plugin. However to avoid having them overridden by the config manager it is recommended to place the configuration in conf/local.protected.php.

You probably want to set at least these options:

conf/local.protected.php

  <?php
  // general DokuWiki options
  $conf['useacl']         = 1;
  $conf['authtype']       = 'authad';
 
  // configure your Active Directory data here
  $conf['plugin']['authad']['account_suffix']     = '@my.domain.org';
  $conf['plugin']['authad']['base_dn']            = 'DC=my,DC=domain,DC=org';
  $conf['plugin']['authad']['domain_controllers'] = 'srv1.domain.org, srv2.domain.org'; //multiple can be given

Optionally the following parameters can be given:

  $conf['plugin']['authad']['admin_username']        = 'root';
  $conf['plugin']['authad']['admin_password']        = 'pass';
  $conf['plugin']['authad']['sso']                = 1;
  $conf['plugin']['authad']['real_primarygroup']  = 1;
  $conf['plugin']['authad']['use_ssl']            = 1; // Don't have ssl/tls options enabled at the same time. 
  $conf['plugin']['authad']['use_tls']            = 1; // Only one of them.
  $conf['plugin']['authad']['debug']              = 1;
  $conf['plugin']['authad']['recursive_groups']   = 1; // If number of groups in AD is large switching to 0 will improve performance, but indirect membership will not work
  $conf['plugin']['authad']['additional']         = 'department,office'; // additional attributes to fetch
  // warn user about expiring password this many days in advance (in version 2012-03-10 and higher):
  $conf['plugin']['authad']['expirywarn']         = 5;

admin_username and admin_password are e.g. required to enable user email subscriptions. This account binds to the AD for querying user details.

Use this code snippet in local.protected.php to set superuser rights:

$conf['manager']   = '@LDAPGROUPNAME';
$conf['superuser'] = '@LDAPGROUPNAME';

AD group names should be preceded with “@” and all spaces should be replaced with underscores. For example, if my AD group is called “Internal DokuWiki Admins”, it should be “@Internal_DokuWiki_Admins” in DokuWiki. Any additional LDAP syntax is unneeded (e.g. all “CN=”, “DN=”, etc.). Only the name of the group is needed.

Any other options given in $conf['plugin']['authad'] are directly passed to the adldap library. Please refer to the adLDAP documentation²⁾ for a detailed description of what other options might be available.

In combination with Single-Sign-On, you can also add Windows domain specific setups. E.g. to authenticate against different Active Directory Servers depending on the NTLM or Kerberos Domain of a given user. The (lowercased) Domain just has to be used as a subkey to the $conf['plugin']['authad'] setting. E.g. to identify all users coming from the Foobar Windows Domain using a non-default AD Server and user just put the following additional lines into your config:

  $conf['plugin']['authad']['foobar']['account_suffix']     = '@foobar.domain.org';
  $conf['plugin']['authad']['foobar']['base_dn']            = 'DC=foobar,DC=domain,DC=org';
  $conf['plugin']['authad']['foobar']['domain_controllers'] = 'otherad.domain.org';
  $conf['plugin']['authad']['foobar']['admin_username']        = 'otherroot';
  $conf['plugin']['authad']['foobar']['admin_password']        = 'otherpass';

Please note that the subkey is only needed for the second and following domains. The first domain needs to be specified without a subkey. Otherwise the domain selector won't show up.

You can set a default domain as option, used as fallback when no domain is given:

  $conf['plugin']['authad']['domain'] = 'foobar';

When you configure more than one domain, a domain selection is shown in the login form.

If you have an organisation with multiple DCs under a single parent, you may need to connect to port 3268, rather than the default port 389. Otherwise, users from the remote DC may not show up as members of any groups. The easiest way to do this is to add the following parameter to your local.protected.php

conf/local.protected.php

$conf['plugin']['authad']['ad_port'] = 3268;

• account suffix is always added to admin username, even when it already contains @ character
• different suffix for admin and normal accounts is not supported
• empty account suffix, that is entering usernames with suffix, is not supported

Users can change their user details (name, email and passwords) using the profile button. This may require to set up a privileged user through the admin_username and admin_password options. Password changing is only supported via SSL or TLS. See LDAP over SSL³⁾ in the adLDAP documentation.

Please note that DokuWiki's auto generated passwords do not match with the Active Directory default password policy. Either adjust your AD password policy or disable the “Forget Password” option using the disableactions config option.

Group and user names are cleaned up internally so they might differ from what is configured in your Active Directory server. Spaces are replaced with underscore and backslashes and hash symbols are removed.

Example: Domain Users becomes Domain_Users in DokuWiki. When you edit your ACLs manually, remember the correct encoding: Domain%5fUsers. The “%5f” represents an underscore.

Keep this in mind when specifying users and groups in ACL setup or configuration.

Single Sign On (SSO) means that DokuWiki will use your Windows login name to identify you without the need for you to log in. This relies on the server setting the REMOTE_USER environment variable. The ad backend then will use this username to fetch additional data like your group membership.

To make this work you need to enable the sso setting in local.protected.php and most probably also need to setup a management account with enough permissions to fetch the user info:

$conf['plugin']['authad']['sso'] = 1;
$conf['plugin']['authad']['admin_username'] = 'MyManager';
$conf['plugin']['authad']['admin_password'] = 'ManagerPass';

Additonally some settings have to be made for your server and the used Browser.

1. Open the IIS configuration console (Start → Internet Information Services (IIS) Manager)
2. Click on the site or virtual directory
3. Double-click on IIS → Authentication
4. Click “Anonymous Authentication” and disable it
5. Click “Windows Authentication” and enable it (Note: If you do not see Windows Authentication, you need to install it via “Turn Windows features on or off” in Control Panel )
6. Right-click “Windows Authentication”, select “Providers…” and ensure “NTLM” is the first listed provider.

Note: Once Windows Authentication is enabled, all write and read access is done as the authenticated users which requires either very permissive permissions on the filesystem or another setting in IIS. The latter is recommended. Simpley switch system.webServer/serverRuntime/authenticatedUserOverride to UseWorkerProcessUser in the IIS Configuration Editor as oulined as Option #4 in this Blog Post.

First configure IIS to use the Windows Logon for authentication (see screenshots):

1. Open the IIS configuration console using “Start” → “Run” → inetmgr
2. Right click on the “Default Web Site” entry and choose “Properties”
3. Switch to the “Directory Security” tab
4. Click the “Edit” button on “Anonymous access and authentication control”.
5. Disable “Anonymous access”
6. Enable “Integrated Windows Authentication”

Then make sure NTLM is used as authentication protocol. This has to be done on the commandline:

1. Open a command line: “Start” → “Run” → cmd
2. Change to the admin script directory: cd \Inetpub\Adminscripts
3. Check the current protocol: cscript adsutil.vbs get w3svc/NTAuthenticationProviders
4. if it doesn't say NTLM, set it: cscript adsutil.vbs set w3svc/NTAuthenticationProviders “NTLM”
5. Now restart IIS.

1. Download http://sourceforge.net/projects/mod-auth-sspi/
2. Copy the mod_auth_sspi.so file into your apache modules directory.
3. Add into httpd.conf:

   LoadModule sspi_auth_module modules/mod_auth_sspi.so 
   
   <Directory "c:/wamp/www/">
       AuthName "My Intranet"
       AuthType SSPI
       SSPIAuth On
       SSPIAuthoritative On
   
       require valid-user
   
   </Directory>

4. Now restart Apache

1. Download https://www.apachehaus.net/modules/mod_authnz_sspi/
2. Copy the mod_authnz_sspi.so file into your apache modules directory.
3. Add into httpd.conf:

   LoadModule sspi_auth_module modules/mod_auth_sspi.so 
   
   <Directory "c:/wamp/www/">
       AuthName "My Intranet"
       AuthType SSPI
       SSPIAuth On
       SSPIAuthoritative On
   
       require valid-sspi-user
   </Directory>

4. Now restart Apache

1. Install mod_python, sudo apt-get install libapache2-mod-python
2. Get PyAuthenNTLM2, wget https://github.com/Legrandin/PyAuthenNTLM2/zipball/master
3. Rename to PyAuthenNTLM2.zip
4. Unzip
5. cd to new dir
6. Install, sudo python setup.py install
7. Add config to Apache2:

   <Directory /var/lib/some_directory>
   AuthType NTLM
   AuthName !!DOMAIN!!
   require valid-user
   PythonAuthenHandler pyntlm
   PythonOption Domain !!DOMAIN!!
   PythonOption PDC !!PRIMARY_DOMAIN_CONTROLLER!!
   PythonOption BDC !!BACKUP_DOMAIN_CONTROLLER!!
   </Directory>

Reference NTLM2 on Linux

Note: ap_requires is deprecated in Apache 2.4, this NTLM method no longer works as described.

This setup enables an Apache Server on Linux to verify Kerberos Tickets against an Active Directory server.

Good references for Apache/Kerberos can be found at

• http://www.grolmsnet.de/kerbtut/
• http://www.itefix.no/i2/node/11683

Microsoft has a good (albeit somewhat outdated) article series here.

The following examples assume your wiki to be running on dokuwiki.yourdomain.com, with your Active Directory server running at dc1.yourdomain.com;

Note: Kerberos is case sensitive, if it is all caps - it should be!

1. Install Kerberos client⁴⁾
2. Install mod_auth_kerb⁵⁾
3. Configure Kerberos if necessary, sample /etc/krb5.conf:

   [logging]
    default = FILE:/var/log/krb5libs.log
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmind.log
   
   [libdefaults]
    default_realm = YOURDOMAIN.COM
    ticket_lifetime = 24h
    forwardable = yes
   
   [realms]
    YOURDOMAIN.COM = {
     kdc = dc1.yourdomain.com
     admin_server = dc1.yourdomain.com
     default_domain = yourdomain.com
    }
   
   [domain_realm]
    dokuwiki.yourdomain.com = YOURDOMAIN.COM
    .yourdomain.com = YOURDOMAIN.COM
    yourdomain.com = YOURDOMAIN.COM
   
   [appdefaults]
    pam = {
     debug = false
      ticket_lifetime = 36000
      renew_lifetime = 36000
      forwardable = true
      krb4_convert = false
    }

4. Verify that the time on the DokuWiki server is within 5 minutes of the Active Directory server. Otherwise Kerberos will not authenticate.
5. Verify that the Kerberos environment is working by running:

   kinit username@YOURDOMAIN.COM
   klist
   kdestroy

   If you get any errors here, make sure your DNS setup is working and you wrote all marked as “YOURDOMAIN.COM” hosts in uppercase in your krb5.conf. Try resolve every hostname manually.

6. Create a keytab file for your DokuWiki server. Make sure you have created a non-admin user in Active Directory with no password expiration. Run this as a Domain Admin on a Windows server with Support Tools installed:

   ktpass -princ HTTP/dokuwiki.yourdomain.com@YOURDOMAIN.COM -mapuser name_of_ad_user_you_have_created@yourdomain.com -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -pass the_ad_users_password -out dokuwiki.HTTP.keytab 

7. If no errors occurred, copy the keytab file to /etc/httpd/conf/.
8. Check if authentication via the keytab file works

   kinit -k -t /etc/httpd/confo/dokuwiki.HTTP.keytab HTTP/dokuwiki.yourdomain.com
   kdestroy

   If this doesn't work, there is no need to continue. Fix this first.

9. Create /etc/httpd/conf.d/dokuwiki.conf:

   <Directory "/var/www/html/dokuwiki">
           # Kerberos Auth
           AuthType Kerberos
           KrbAuthRealms YOURDOMAIN.COM
           KrbServiceName HTTP/dokuwiki.yourdomain.com
           Krb5Keytab /etc/httpd/conf/dokuwiki.HTTP.keytab
           KrbMethodNegotiate on
           KrbMethodK5Passwd on
           require valid-user
   </Directory>

10. (Re)start Apache: service httpd restart.

• Restart Apache. Web server config changes won't apply until restarted.
• Try using the FQDN of the DokuWiki server, i.e. http://dokuwiki.yourdomain.com/dokuwiki.
• If you are presented with a login window, do not enter domain/realm info, just user name and password.
• Verify that the time on the DokuWiki server is within 5 minutes of the Active Directory server. Otherwise Kerberos will not authenticate.
• If your web browser tries to send NTLM authentication, verify that the browser is correctly configured (see below) and verify that there aren't duplicate SPN:s registered for the Dokuwiki server. Run this command:

  setspn -X

  Remove any duplicates found.

• Check all Kerberos files for case inconsistencies.
• Review this instruction from start to end. See reference links where possible.

Your browser needs to be setup to forward authentication info to the Webserver.

Activate SPNEGO in Internet Explorer by:

1. Adding dokuwiki server to the Local Intranet zone. It might be a good idea to add both host name and FQDN. See https://msdn.microsoft.com/en-us/library/ms995329.aspx.
2. Enabling authentication forwarding (Windows Integrated Authentication). Restart your browser to complete the change. IE 8 shown here:

1. Open Firefox and type about:config in the address bar.
2. In the ‘Filter’ field type one of the following (depending if you're using NTLM or Kerberos) network.automatic-ntlm-auth.trusted-uris or network.negotiate-auth.trusted-uris
3. Double click the name of the preference that we just searched for
4. Enter the URLs of the sites you wish to pass NTLM auth info to in the form of:

    http://intranet.company.com,http://email.company.lan

Notice that you can use a comma separated list in this field.

Some plug-ins may not gracefully work once you've switched over to the ad auth backend. Specifically, pulling the user's display name will not work if you don't provide valid authentication information. One such plugin is WikiStatistics, where a simple workaround to only display the username can be employed.

Due to missing support for paged queries in PHP's LDAP extension⁶⁾, plugins that try to get all users from the auth backend will fail if you use authAD plugin and have more than 1000 objects in Active Directory. One example is the IssueTracker plugin.