Kerberos Authentication on the Firewall
You set up kerberos authentication on the firewall by linking your firewall to a domain controller. The firewall then checks encrypted user tickets before it lets network traffic pass through. Network teams often use this setup to map IP addresses to directory users. Still, broad domain groups often give users reach into databases and servers they do not need. Once a packet passes the perimeter rule, the firewall cannot check what commands that user runs. How kerberos authentication on the fir
Single Sign-On (SSO) + Multi-Factor Authentication (MFA): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up kerberos authentication on the firewall by linking your firewall to a domain controller. The firewall then checks encrypted user tickets before it lets network traffic pass through. Network teams often use this setup to map IP addresses to directory users. Still, broad domain groups often give users reach into databases and servers they do not need. Once a packet passes the perimeter rule, the firewall cannot check what commands that user runs.
How kerberos authentication on the firewall works
This setup relies on three parts that talk to each other over your network. Those parts are the client machine, the Key Distribution Center, and the firewall itself. When an engineer logs into a workstation, the domain controller issues a Ticket Granting Ticket. This ticket proves who the user is without sending raw passwords over the wire.
When the user tries to reach a server behind the firewall, a new check starts. The workstation asks the Key Distribution Center for a service ticket for the firewall. The client then presents this encrypted service ticket to the firewall interface. The firewall uses its own local key table file to decrypt and read the ticket.
All three machines must keep their system clocks in sync for this check to work. If a clock drifts by a few minutes, the firewall rejects the ticket right away. Time sync prevents attackers from capturing old tickets and reusing them later. Admins also create a service principal name in the directory for the firewall appliance. They export a matching key file and load it onto the firewall.
Once the ticket passes the check, the firewall reads the group data inside the ticket. It matches the user to an active network rule and opens the requested port.
What network ticket checks solve and what they miss
Ticket checks at the perimeter solve the problem of anonymous IP rules. Without user checks, teams must write rules based on static IP addresses or subnets. If a user moves to a new desk, static IP rules break or allow the wrong person. Kerberos ties network rules to a real user identity instead of a machine address. It also stops clear text password theft on the local network.
Yet this network check leaves a major gap during daily work. A firewall only decides who can open a port to a target server. It does not understand the database query or shell command inside the encrypted traffic. If an engineer has permission to reach a Postgres port, the firewall lets all queries through. The firewall cannot stop a drop table statement or a bulk read of customer tables.
Single Sign-On (SSO) + Multi-Factor Authentication (MFA): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Network rules also cannot rewrite sensitive fields inside query results. If a table holds emails, phone numbers, card numbers, or national IDs, the user gets everything. Directory groups are too blunt to manage individual SQL statements or CLI commands. Teams also struggle when remote workers sit off the domain network and cannot reach the controller. When tickets fail to refresh, engineers fall back to shared local accounts that bypass user logs.
Managing server and database checks beyond the perimeter
To close this gap, teams must separate network reach from command control. The firewall should still block unknown traffic at the network edge. Still, teams need deeper checks at the command and query level for production systems.
Instead of trusting a domain ticket for everything, check every database statement or shell command in flight. Auditors need logs that show the exact query a user ran, not just an open port event. Masking rules should also rewrite card numbers and phone numbers in query results before they reach the screen. Moving control closer to the query gives security teams real safety without complex firewall rule sets.
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
Why do firewall ticket checks fail when clocks drift?
Ticket checks use timestamps to stop attackers from replaying old login requests. If the firewall clock and domain controller clock do not match, the firewall drops the request. Teams use a shared network time server on all devices to fix this issue.
Can a Kerberos firewall rule block a destructive SQL query?
No, the firewall only checks the user ticket and opens the network port. Once the session starts, especially over TLS, the firewall cannot read or block specific database statements.
What happens when a user changes domain groups while logged in?
The user keeps their old permissions until their current ticket expires and renews. The firewall reads group roles from the ticket itself rather than polling the directory on every packet.