How to Integrate MediaWiki with LDAP for Single Sign‑On

Authenticating MediaWiki against Active Directory or any LDAP directory gives users a single set of credentials — and, with group mapping, automates their wiki permissions. The standard approach is the LDAP stack: PluggableAuth as the auth framework, plus LDAPProvider, LDAPAuthentication2, LDAPAuthorization, LDAPUserInfo and LDAPGroups. All six extensions must come from the same release series (matching your MediaWiki version), and PHP needs the LDAP extension (php-ldap).

Prerequisites

• PHP with ldap module (php -m | grep ldap)
• MediaWiki version matching the LDAP stack relnotes (current LTS lines are supported; check the extension pages)
• A service account for the wiki: read access to user and group objects (e.g. CN=MediawikiAuthenticator,OU=Service,DC=corp,DC=example,DC=com)
• Network reachability: port 389 (LDAP) or 636 (LDAPS) from the web server
• The domain name that users will type at login — typically the AD domain

Installation

Download the extensions (Extension Distributor) into extensions/ and load them in order:

wfLoadExtension( 'PluggableAuth' );
wfLoadExtension( 'LDAPProvider' );
wfLoadExtension( 'LDAPAuthentication2' );
wfLoadExtension( 'LDAPAuthorization' );
wfLoadExtension( 'LDAPUserInfo' );
wfLoadExtension( 'LDAPGroups' );

Configuration: ldap.json

The stack reads one JSON document per domain — the domain config — referenced in LocalSettings.php:

$wgLDAPProviderDomainConfigs = [ 'LDAP' => '/etc/mediawiki/ldap.json' ];

The file lives outside the web root. A minimal Active Directory config:

{
  "corp.example.com": {
    "connection": {
      "server": "dc.corp.example.com",
      "port": 636,
      "use-tls": true,
      "user": "CN=MediawikiAuthenticator,OU=Service,DC=corp,DC=example,DC=com",
      "pass": "PASSWORD"
    },
    "basedn": "DC=corp,DC=example,DC=com",
    "user": {
      "basedn": "OU=Users",
      "search-string": "sAMAccountName={0}",
      "username-attribute": "sAMAccountName"
    },
    "group": {
      "basedn": "OU=Groups",
      "search-string": "sAMAccountName={0}",
      "username-attribute": "sAMAccountName"
    }
  }
}

Key fields: server/port/use-tls (LDAPS is strongly recommended — credentials traverse the connection), the basedn for searches, and the search-string pattern by which a login name is resolved to a directory entry ({0} is the typed username — with sAMAccountName for AD, or uid={0} for OpenLDAP).

Behavior settings

// Disable local login; all authentication through LDAP
$wgPluggableAuth_EnableLocalLogin = false;

// Allow accounts to be created automatically on first LDAP login
$wgGroupPermissions['*']['autocreateaccount'] = true;

LDAPAuthorization maps directory groups to wiki groups:

$wgLDAPAuthorization_...  // group → 'sysop' mappings live in domain config

Group membership comes through LDAPGroups/LDAPAuthorization: users whose AD groups match configured patterns receive the corresponding wiki groups, so admin rights follow directory membership instead of manual assignments.

Troubleshooting

• Login fails with no error — check the wiki's $wgShowExceptionDetails log or enable LDAP debug ($wgLDAPDebug = 2;); the most common causes are a wrong search-string pattern and a service account without read rights
• Wrong user directory scope — user.basedn relative to the domain basedn; if users sit in a different OU, adjust it
• Groups not applied — groups resolve through group.search-string; AD nested groups are handled by LDAPGroups settings — verify one group mapping before enabling all of them
• TLS certificate errors — with use-tls: true the server certificate must be trusted by the PHP LDAP client (add your CA); otherwise connections silently fail or downgrade

Two-factor and SSO beyond LDAP (SAML/OIDC) are covered by other PluggableAuth providers; the LDAP stack remains the right choice for directories. The LDAP Stack hub page links each extension's full configuration reference.