Request Demo
Features Use Cases About Documentation Contact Request Demo

LDAP / Active Directory

Connect to your existing directory service - the most common identity provider setup

What's This For?

If your organization already has users in Active Directory or another LDAP-compatible directory, this is probably where you want to start. Warden connects directly to your directory server, so users authenticate with their existing credentials - no need to create or sync accounts separately.

Active Directory vs LDAP: Active Directory is LDAP (plus a bunch of Microsoft-specific extensions). The setup is almost identical - we'll point out the differences as we go.

Before You Start

Gather this information from your directory administrator:

  • Server hostname or IP - Where's your LDAP/AD server?
  • Port number - Usually 636 (LDAPS) or 389 (plain LDAP)
  • Service account credentials - Warden needs a user to search the directory
  • Base DN - Where are your users located in the directory tree?

Security first: Always use LDAPS (port 636) or StartTLS in production. Plain LDAP sends passwords in clear text over the network - not something you want.

Setting Up the Connection

Step 1: Add the Provider

  1. Go to My Providers
  2. Click Add Provider
  3. Select LDAP / Active Directory as the type
  4. Give it a name you'll recognize (e.g., "Corporate AD" or "OpenLDAP")

Step 2: Connection Settings

Tell Warden how to reach your directory server:

LDAP Server Host
Your directory server's hostname or IP address
Active Directory: Usually your domain controller - dc01.example.com
OpenLDAP: Your LDAP server hostname - ldap.example.com
Port
636 - LDAPS (encrypted, recommended)
389 - Plain LDAP or StartTLS
When in doubt, try 636 first. Most modern setups support it.
Use TLS/SSL
Enable for encrypted connections
Port 636: Enable this
Port 389 with StartTLS: Enable this too - it upgrades the connection
Port 389 without TLS: Only for testing, never in production

Step 3: Service Account (Bind Credentials)

Warden needs a service account to search your directory. This account doesn't need special privileges - just the ability to read user objects.

Bind DN
The full distinguished name of your service account
Active Directory:
CN=svc-warden,CN=Users,DC=example,DC=com
or use UPN format: svc-warden@example.com

OpenLDAP:
cn=warden-service,ou=ServiceAccounts,dc=example,dc=com
Bind Password
Password for the service account
Stored encrypted - we never display this in plain text.

Pro Tip: Create a dedicated service account for Warden. Don't use an admin account or a real person's account. This way, you can set a strong password that never expires and track Warden's directory access separately in your logs.

Step 4: User Search Settings

Tell Warden where to find users and how to identify them:

User Base DN
The starting point for user searches
Active Directory:
DC=example,DC=com (search entire domain)
OU=Employees,DC=example,DC=com (search specific OU)

OpenLDAP:
ou=users,dc=example,dc=com
User Search Filter
LDAP filter to identify valid user accounts
Active Directory:
(&(objectClass=user)(objectCategory=person))
This excludes computer accounts and other non-person objects

OpenLDAP:
(objectClass=inetOrgPerson)
Username Attribute
Which attribute contains the username people type when logging in
Active Directory: sAMAccountName (e.g., "jsmith")
OpenLDAP: uid

Testing Your Connection

Before putting this into production, verify everything works:

  1. Click Save to create the identity provider
  2. Click the menu (⋮) next to your new provider
  3. Select Test Connection
  4. Enter a real username and password from your directory
  5. Click Run Test

Success! You'll see the user's details pulled from the directory, including their DN, email, and group memberships. This confirms Warden can authenticate users and read their attributes.

Quick Reference Configs

Active Directory (Most Common)

Typical Active Directory Setup
Host: dc01.example.com
Port: 636
Use TLS/SSL: Yes
Bind DN: CN=svc-warden,CN=Users,DC=example,DC=com
User Base DN: DC=example,DC=com
User Filter: (&(objectClass=user)(objectCategory=person))
Username Attribute: sAMAccountName

OpenLDAP

Typical OpenLDAP Setup
Host: ldap.example.com
Port: 636
Use TLS/SSL: Yes
Bind DN: cn=warden,ou=services,dc=example,dc=com
User Base DN: ou=users,dc=example,dc=com
User Filter: (objectClass=inetOrgPerson)
Username Attribute: uid

389 Directory Server / FreeIPA

Typical 389DS / FreeIPA Setup
Host: ipa.example.com
Port: 636
Use TLS/SSL: Yes
Bind DN: uid=warden,cn=users,cn=accounts,dc=example,dc=com
User Base DN: cn=users,cn=accounts,dc=example,dc=com
User Filter: (objectClass=person)
Username Attribute: uid

Troubleshooting

Running into problems? Here are the most common issues and how to fix them:

Connection Timeout

What's happening: Warden can't reach your LDAP server.

Things to check:

  • Can you ping the LDAP server from Warden's host?
  • Is the firewall allowing traffic on port 636 (or 389)?
  • Is the LDAP service running on the server?
  • Try: telnet ldap-server 636 to test basic connectivity

Invalid Credentials / Bind Failed

What's happening: The service account credentials are wrong.

Things to check:

  • Is the Bind DN exactly right? Even small typos will fail.
  • Has the password expired or the account been locked?
  • For AD: Try the UPN format (user@domain.com) instead of DN
  • Test the credentials with ldapsearch or an LDAP browser

No Users Found

What's happening: Search works but returns empty results.

Things to check:

  • Is the User Base DN correct? It must be a valid path in your directory.
  • Does the service account have permission to read that part of the tree?
  • Is the search filter matching your users? Test in an LDAP browser.
  • For AD: Make sure you're not accidentally filtering out users with disabled accounts

Certificate Error / TLS Handshake Failed

What's happening: Warden doesn't trust the LDAP server's certificate.

Things to check:

  • Is the certificate self-signed? You may need to import the CA cert into Warden.
  • Has the certificate expired?
  • Does the certificate hostname match the server you're connecting to?
  • For testing only: You can temporarily disable certificate validation (not for production!)

User Authenticates But Groups Are Empty

What's happening: Authentication works, but Warden can't see group memberships.

Things to check:

  • Does the service account have permission to read group objects?
  • For AD: Check if you need to search for nested group memberships
  • Is the group Base DN configured correctly?

Security Best Practices

  • Always use LDAPS or StartTLS - Never send credentials over plain LDAP in production
  • Use a dedicated service account - Don't share accounts; create one specifically for Warden
  • Minimal permissions - The service account only needs read access to users and groups
  • Monitor the account - Watch for failed login attempts or unusual activity
  • Rotate the password periodically - Even for service accounts, regular rotation is good hygiene

What's Next?

Now that users can authenticate, you'll want to:

Back to Help Overview