LDAP Account Policies
You set up ldap account policies by adding rule objects to your directory server. These rules control password age, lockouts, and login times for each user entry. Most teams apply one default policy to all users and add stricter rules for admins. When directory roles are too broad, one stolen password exposes many internal systems at once. How ldap account policies work in your directory A directory server stores user records in a tree structure. Each user record holds attributes like a usern
Cross-Account Access Delegation + LDAP Directory Services: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up ldap account policies by adding rule objects to your directory server. These rules control password age, lockouts, and login times for each user entry. Most teams apply one default policy to all users and add stricter rules for admins. When directory roles are too broad, one stolen password exposes many internal systems at once.
How ldap account policies work in your directory
A directory server stores user records in a tree structure. Each user record holds attributes like a username, mail address, and password hash. When you set up ldap account policies, you attach rule attributes to these records. The directory checks these rules every time a person or app tries to log in.
First, a client sends a bind request to the directory server. The server looks up the user entry and checks the linked policy object. It verifies if the account is active or locked out due to bad attempts. Next, it checks if the password has passed its max age limit.
If the password is valid and the account is open, the bind succeeds. If a user types the wrong password, the server adds to a failure counter. Once that counter hits the limit, the server locks the account for a set time. Admins can also force users to pick a new password on their first login.
How group rules and password rules interact
Most teams do not assign rules to one user at a time. Instead, they group users by job role inside the directory tree. Engineers go into one group, while finance staff go into another group. The directory links a specific policy object to each group entry.
When a user belongs to two groups, priority numbers decide which rule wins. A lower number often means a higher priority for that user record. Service accounts for apps often need special rules because password rotation can break background jobs. Teams put these app accounts in a separate branch with long password lifetimes. Still, long lifetimes create a big risk if an engineer copies that key.
Cross-Account Access Delegation + LDAP Directory Services: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What directory rules solve and what they miss
Directory policies do a great job of stopping brute force login attacks. They force people to rotate old passwords and stop reuse of past keys. They also give admins one central place to disable an account when someone leaves. Once you lock the directory record, that person cannot start new logins.
Still, directory rules only check who can log in at the start. Once a database or server accepts the login, the directory steps out of the way. The directory cannot see what SQL queries or shell commands the user runs next. A user with valid credentials can still drop a table or read production data.
Directory logs also miss the details of what happens inside an active session. They record the bind time and the user name, not the data returned. If a query pulls emails, phone numbers, card numbers, or national IDs, LDAP knows nothing. Masking that rewrites matched fields in results must happen at the session level instead. To control real actions, teams must inspect commands and queries while they run in flight.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the difference between an LDAP group and an account policy?
A group lists which users share a role for access checks. An account policy sets the rules for passwords, lockouts, and login failures.
Do ldap account policies cut off active database sessions when a user is locked?
No, locking a directory account only blocks new bind requests at login time. Open database or server sessions stay active until they time out or close.
How should teams handle policies for shared service accounts?
Teams should place service accounts in a separate branch with strict IP checks. You should also audit every command those accounts run on target systems.