These illustrations show the security checks in a configured LDAP login. They distinguish host responsibilities from plugin behavior and show where an attempt stops.
Authentication / Security boundaries
How LDAP login is verified.
Directory authentication and WordPress authorization are separate checks. A valid LDAP password alone does not create a WordPress session.
LDAP password login
Free + ProShown with LDAP passwords required and StartTLS or LDAPS. Selected recovery accounts use a separate local login path.
On small screens, scroll horizontally or read the text steps below.
Read the password login steps
- Protect the browser request. Use HTTPS for the WordPress login page. Configure HTTPS at your host or reverse proxy; LDAP TLS does not provide it.
- Apply the recovery policy. A selected local recovery administrator uses core WordPress password checks and skips LDAP. For directory users, the LDAP client rejects empty credentials and null bytes.
- Open the secure directory connection. With StartTLS or LDAPS, the plugin requires a trusted certificate before sending credentials. A TLS failure can try another configured server with the same transport. There is no TLS-to-plaintext downgrade.
- Verify the exact directory account. OpenLDAP subfolder searches first locate a DN through a search account or permitted anonymous search. The directory then checks the user password. The plugin requires one matching user entry. AD also binds to that exact entry DN with the same password.
- Check access groups. A user must match at least one required group when a list is set. AD checks include nested and primary groups. A group denial blocks normal local password fallback.
- Load or create the WordPress account. Creation requires the account creation setting. A new account gets a random local password, not the LDAP password. Pro identity checks and enabled account updates can run at this point.
- Run WordPress checks. The plugin calls
wp_authenticate_user. Later authentication filters remain active. These checks can deny login after an account has been created or updated. - Start the session. WordPress creates a session only after the final authentication result succeeds.
Transport failure
No weaker connection.
A TLS failure stops that connection. The next configured server can be tried with the same transport. The plugin does not fall back from TLS to plaintext.
Access denial
No password bypass.
In LDAP-only mode, ordinary users cannot use core WordPress password fallback after LDAP failure. Group denial also blocks that fallback when LDAP-only mode is off.
Local recovery
A separate administrator path.
Selected recovery accounts use WordPress passwords and WordPress user checks. Keep a separate local administrator account and test this policy before enabling LDAP.
Server single sign-onPro
The web server proves the user identity. The plugin still verifies the directory account, access groups, and the final WordPress authentication result. Use a search account with only the read access needed for directory lookups.
Automatic SSO runs only on eligible browser GET requests. It skips wp-login.php, selected recovery accounts, and existing sessions. Missing or rejected server identity creates no SSO session. This does not block public pages or every other login method.
Credential handling
User passwords and search credentials have different roles.
- User LDAP password
- Used to verify the user through LDAP. It is not copied to the WordPress account password. New accounts get a random local password.
- Saved search account password
- A separate secret for directory lookups. Stored with AES-256-GCM encryption. The key comes from
SLL_ENCRYPTION_KEYor WordPress salts.
Use HTTPS and StartTLS or LDAPS together. Unencrypted LDAP remains an explicit administrator option; the secure diagrams above assume it is not selected. Login flow guide · Connection security · Recovery procedure