Ad Authentication Protocol
You set up an ad authentication protocol by linking apps to your domain server. The server checks user identities with Kerberos tickets or LDAP binds before login. Most teams start by mapping domain groups to broad server or database roles. When those roles are too wide, any logged-in user can run risky commands. A single stolen account can then read or change sensitive data across systems. How the ad authentication protocol works in practice Active Directory relies on two main methods to che
Multi-Factor Authentication (MFA) + Model Context Protocol (MCP) Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up an ad authentication protocol by linking apps to your domain server. The server checks user identities with Kerberos tickets or LDAP binds before login. Most teams start by mapping domain groups to broad server or database roles. When those roles are too wide, any logged-in user can run risky commands. A single stolen account can then read or change sensitive data across systems.
How the ad authentication protocol works in practice
Active Directory relies on two main methods to check user identities on networks. Kerberos is the primary method for internal computers and servers joined to domains. When a user logs in, the domain server sends a ticket-granting ticket. The user machine trades this ticket for a service ticket to open apps. Passwords do not travel across the network during this ticket exchange.
LDAP is the second method and works well for web apps and scripts. The app sends a bind request to the directory to check user details. Teams secure this step by turning on TLS encryption for all network traffic. Old systems sometimes fall back to NTLM when Kerberos cannot find a host. Security teams disable NTLM where possible because attackers can replay those password hashes. After the login step succeeds, the target server checks the user group list. The target system then grants a local role based on that group match.
Comparing Kerberos and LDAP for directory logins
Choosing between Kerberos and LDAP depends on how your apps run and scale. Kerberos works best when client machines and servers belong to the same domain. It cuts down on password prompts and uses strong encryption for every ticket. Still, Kerberos needs strict clock sync and clean DNS records to work well. If a server clock drifts too far, the domain controller rejects the ticket.
LDAP is much simpler for Linux servers, cloud apps, and third-party tools. These systems often sit outside the main Windows domain and lack ticket support. With LDAP, the app asks the directory to check a username and password. While easy to set up, LDAP sends credentials to the app before checking. Teams must guard the app server well so attackers do not receive unmasked those keys.
Multi-Factor Authentication (MFA) + Model Context Protocol (MCP) Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What directory login solves and what it leaves open
Directory protocols solve the problem of scattered user lists across many servers. When a worker leaves the team, admins disable one account in the directory. That single change blocks new logins across every linked app and database. Central directories also enforce password rules and lock out accounts after failed tries.
Yet the directory only checks who can log in at the front door. Once a session starts, the directory steps back and stops watching the user. It cannot see which SQL queries run or which shell commands execute next. To share access, admins often put whole teams into one high-level directory group. Every person in that group gets the same broad rights inside the database. If an engineer runs a bad delete query, the directory cannot stop it. Also, raw emails, phone numbers, card numbers, and national IDs return in plain text. Masking rewrites matched fields in results, which basic directory groups cannot do alone.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the default protocol used in Active Directory?
Kerberos is the default method for checking identities in Active Directory domains. It uses encrypted tickets to verify users and computers without sending plain passwords.
When should a team use LDAPS instead of Kerberos?
Teams use LDAPS when apps cannot join the domain or read Kerberos tickets. LDAPS wraps standard directory checks inside TLS encryption to keep network traffic safe.
Does Active Directory log database queries or shell commands?
No, the directory only logs the initial login request and ticket grant events. It does not track or control what commands a user runs after login.