On Premise Active Directory
An on premise active directory runs on local servers to manage user logins and roles. You set it up by installing domain controllers and organizing users into security groups. Many teams use this system to control who can log in to local servers. When teams grant broad group permissions, one stolen password can expose many internal systems. Attackers often target these broad roles to move across the local network. How an on premise active directory manages logins and roles A local directory s
Active Directory + Single Sign-On (SSO): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
An on premise active directory runs on local servers to manage user logins and roles. You set it up by installing domain controllers and organizing users into security groups. Many teams use this system to control who can log in to local servers. When teams grant broad group permissions, one stolen password can expose many internal systems. Attackers often target these broad roles to move across the local network.
How an on premise active directory manages logins and roles
A local directory stores user accounts, computer records, and group memberships in one database. Domain controllers run on your own servers and check every login request. When a user logs in, the domain controller checks their password and issues a ticket. This ticket proves who the user is to other servers on the network.
Admins organize users into organizational units and security groups to keep permissions tidy. Instead of giving access to one person, admins assign permissions to a group. Database servers and Linux hosts check these group memberships when a user connects. If the user belongs to the right group, the server opens a session.
Teams also use group policies to push security rules to joined Windows machines. These rules control password length, lock screens, and local admin rights across the company. Many companies link their local directory to a cloud identity tool for web apps. Even with cloud sync, the local domain controller often holds the core user groups.
Why directory roles leave gaps during active sessions
An on premise active directory does a great job of checking who can log in. Central groups make it easy to cut off access when someone leaves the team. Disabling one account stops that person from starting new sessions on linked servers.
Still, directory groups only make a decision at the start of a session. Once the database or server accepts the login, the directory steps out of the way. The directory does not see what queries a developer runs inside a database. It cannot stop an engineer from running a drop table command by mistake.
Active Directory + Single Sign-On (SSO): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Broad group roles also create problems when teams need temporary access for a quick fix. Admins add a user to a powerful group to fix a broken production server. People often forget to remove the user from that group after the fix finishes. Over time, too many engineers hold permanent admin rights across critical databases and hosts.
Directory logs also miss the details of what happens inside a session. You can see when a user logged in and which server they reached. You cannot see which customer rows they read or which shell commands they ran. Also, directory groups cannot rewrite sensitive fields like emails, phone numbers, or card numbers in query results.
Ways to tighten local directory security
Teams can reduce risk by splitting admin accounts from daily user accounts. Engineers use a standard account for email and a separate account for server work. Admins should also review group memberships every month to remove extra permissions. Even with clean groups, teams still need controls that watch commands during the session.
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 main difference between local directories and cloud identity tools?
A local directory runs on servers that your team manages inside your own network. It uses tickets and local network protocols to log users into servers and computers. Cloud identity tools run as a service and focus on web apps and APIs.
Can local directory groups control individual SQL queries?
No, directory groups only control who can log in and which database role they get. Once the session starts, the database engine handles all permissions for tables and queries. The directory cannot block a risky update statement or mask national IDs in results.
How do teams connect modern tools to an older local directory?
Most teams sync their local directory groups to a modern identity provider. The sync tool copies user accounts and group names up to the cloud provider. Modern tools then read those synced groups to check user roles during login.