LDAP Proxy MFA
You set up ldap proxy mfa by placing a relay server in front of your directory. This relay checks the password first and triggers a second factor before login finishes. Most teams use this setup for old apps that only understand simple bind requests. These apps lack modern login screens for push alerts or one-time codes. Still, directory groups often give broad database or server roles once a user logs in. How an ldap proxy mfa workflow operates Legacy directory binds only carry a username an
Database Proxy (ProxySQL, PgBouncer) + LDAP Directory Services: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up ldap proxy mfa by placing a relay server in front of your directory. This relay checks the password first and triggers a second factor before login finishes. Most teams use this setup for old apps that only understand simple bind requests. These apps lack modern login screens for push alerts or one-time codes. Still, directory groups often give broad database or server roles once a user logs in.
How an ldap proxy mfa workflow operates
Legacy directory binds only carry a username and a password in a single network request. The client app sends this bind request and waits for a simple pass or fail answer. Because the protocol lacks a second prompt screen, the relay server pauses the bind reply. First, the relay forwards the username and password to the main directory server to check them.
If the password matches, the relay holds the login open and calls your MFA service. The user then gets a push alert on their phone to approve the login attempt. For one-time codes, teams often tell users to type the code right after their password. The relay splits the password and the six-digit code before checking each part with its source. Only when both checks pass does the relay send a success message back to the app.
Network timeouts create the biggest hurdle during this two-step login check. Old apps and database clients expect a directory answer in just a few seconds. When a user takes ten seconds to tap a phone prompt, the client app may drop. Admins must raise the client timeout rules so the app waits for the push approval. Teams also set up bypass groups for service accounts that run automated jobs without a phone.
What directory login checks solve and what they leave open
Adding a second factor to directory binds stops attackers who steal or guess user passwords. It brings phone approval to legacy database tools, VPN concentrators, and internal admin apps. Security teams can meet audit rules for multi-factor login without rewriting old software. Every human login must pass both the directory check and the mobile check to start.
Database Proxy (ProxySQL, PgBouncer) + LDAP Directory Services: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Still, directory checks only govern the moment a user logs in to a system. Once the bind succeeds, the directory steps out of the way for the whole session. The user receives whatever broad role or group rights exist in that target database or server. Directory MFA cannot see which SQL queries run or which shell commands execute after login.
If an engineer runs a broad delete statement, the directory will not stop or log it. If a query pulls thousands of emails, phone numbers, or card numbers, raw data comes back. Standard directory tools do not rewrite matched fields in results or ask for command approval. Teams need controls that inspect live actions in flight rather than just checking initial logins.
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
How do users enter one-time codes if the app has no second input box?
Teams usually use password concatenation for apps without a second prompt. The user types their normal password followed by a comma and the six-digit code. The relay server splits that string and checks each piece with the right system.
Why do LDAP logins fail even when the user approves the push alert?
The client app often times out before the user taps approve on their phone. Standard LDAP bind timeouts are very short because normal password checks take milliseconds. You must raise the timeout window on the client app to thirty or sixty seconds.
How should teams handle automated service accounts that cannot use a phone?
Service accounts cannot approve push alerts or type one-time codes during background jobs. Teams put these machine accounts in a specific directory group that skips the second factor check. You should restrict those accounts by source IP address and rotate their keys often.