If your users already live in an enterprise directory — Active Directory, OpenLDAP, Apache Directory, or FreeIPA — then the cleanest login for a self-hosted app is the account they already have. Nobody wants to remember a second password for an internal tool when they log into the company directory every morning.
SafeLine WAF speaks LDAP, so it can front your apps and let users sign in with their existing directory accounts. No directory code in your app, no separate user database. Here's the full configuration, straight from the docs.
How LDAP fits the picture
LDAP (Lightweight Directory Access Protocol) is the protocol for reading from a distributed directory service — the thing that stores user accounts, organizational structure, and permissions. It's also the foundation of most single-sign-on infrastructure: one set of credentials, many systems.
When a WAF fronts your app, it can query your directory during login, authenticate the user, and only then let them reach the origin. That means your enterprise directory becomes the login for everything the WAF protects.
Step 1: Open the LDAP configuration
In the SafeLine console, go to Auth → Settings, click Third-Party Login, and select LDAP.
You'll fill in five parameters:
| Parameter | Purpose |
|---|---|
| LDAP Server URL | Where the directory lives |
| Bind DN | The account used to connect to the directory |
| Bind Password | Password for that bind account |
| User baseDN | Where in the directory tree to start searching for users |
| Query Condition | The filter that matches a user entry |
Step 2: The parameters in detail
LDAP Server URL
Format is ldap://hostname:port or ldaps://hostname:port for SSL. Standard ports are 389 (plain) and 636 (SSL). For example:
ldap://ldap.example.com:389 # standard connection
ldaps://ldap.example.com:636 # SSL encrypted
Bind DN
The account used to bind to the LDAP server. It needs enough permission to query user information. A couple of reference shapes:
- Active Directory:
cn=Administrator,cn=Users,dc=domain,dc=com - OpenLDAP:
cn=admin,dc=example,dc=com
The docs recommend a dedicated service account with read-only permissions rather than a full administrator account.
User baseDN
This is the node in the directory tree where user searches begin — it affects both performance and search scope. Examples:
- Active Directory:
cn=Users,dc=domain,dc=com - OpenLDAP:
ou=People,dc=example,dc=com
Query Condition
A filter expression used to match user entries, where %s is a placeholder for the username the visitor types. The basic form:
(&(objectClass=person)(uid=%s))
This matches entries where objectClass is person and uid equals the entered username. If a user enters john, the filter becomes (&(objectClass=person)(uid=john)).
Step 3: Reference configs for common directories
The docs include ready-to-adapt examples:
Microsoft Active Directory
LDAP Server URL: ldap://ad.company.com:389
Bind DN: cn=LDAPService,cn=Users,dc=company,dc=com
Bind Password: (service account password)
User baseDN: cn=Users,dc=company,dc=com
Query Condition: (&(objectClass=user)(sAMAccountName=%s))
OpenLDAP
LDAP Server URL: ldap://openldap.company.com:389
Bind DN: cn=admin,dc=company,dc=com
Bind Password: (admin password)
User baseDN: ou=People,dc=company,dc=com
Query Condition: (&(objectClass=person)(uid=%s))
FreeIPA
LDAP Server URL: ldap://ipa.company.com:389
Bind DN: uid=admin,cn=users,cn=accounts,dc=company,dc=com
Bind Password: (admin password)
User baseDN: cn=users,cn=accounts,dc=company,dc=com
Query Condition: (&(objectClass=person)(uid=%s))
What the login flow looks like
After you enable LDAP for an application:
- Visitors are prompted to authenticate with their LDAP account.
- They log in with their directory credentials.
- New users need verification by a SafeLine administrator after their first authentication.
- Verified users are authorized and can log in on later visits without re-verification; unverified users are blocked.
FAQ
Users can't log in even though the connection works?
Check the User baseDN (does the user actually sit under it?) and the Query Condition — the %s placeholder, the attribute names (uid, sAMAccountName, etc.), and the outermost parentheses all need to be correct. Also confirm the account isn't locked or disabled in the directory.
Why is the connection failing?
Check the server URL format (protocol, hostname, port), that the SafeLine server can reach the LDAP server on the network, the bind account credentials, and — for ldaps:// — that the certificate is valid or trusted.
What does %s mean in the query condition?
It's replaced with the username entered at login. (&(objectClass=person)(uid=%s)) with input john becomes (&(objectClass=person)(uid=john)).
Can I filter by Active Directory security group?
Yes — add a membership condition, for example:
(&(objectClass=user)(sAMAccountName=%s)(memberOf=CN=AllowedGroup,OU=Groups,DC=company,DC=com))
My query condition has syntax errors — any tips?
LDAP filters use prefix notation, so make sure parentheses are matched and the attribute=value syntax is right. The docs suggest validating with an online LDAP filter syntax checker.
Do your internal apps already authenticate against your directory — or are users juggling a separate set of credentials for each tool?
Ready to protect your sites without paying for a cloud WAF?
- ⭐ SafeLine WAF on GitHub — give it a star if you find it useful
- 🔗 Official Docs — installation guide, configuration, and API reference
- 🧪 Live Demo — see the dashboard in action (no login required)
Top comments (0)