On-premise Active Directory
You set up an on premise active directory by running domain controllers on your servers. These servers store user accounts, groups, and security rules in one central place. Teams often create broad admin groups to move fast during setup. When roles are too wide, one stolen password can expose every server and database. Attackers use that single account to move across your network and read data. How on premise active directory works in your network A local directory groups users, computers, an
Active Directory + Single Sign-On (SSO): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up an on premise active directory by running domain controllers on your servers. These servers store user accounts, groups, and security rules in one central place. Teams often create broad admin groups to move fast during setup. When roles are too wide, one stolen password can expose every server and database. Attackers use that single account to move across your network and read data.
How on premise active directory works in your network
A local directory groups users, computers, and servers into logical domains and forests. Domain controllers hold the master database and check user passwords during every log in. When a worker logs in, the server checks their password and issues a ticket. The user device shows that ticket to open file shares or internal apps. This Kerberos ticket workflow keeps raw passwords off the network wire after login.
Admins use group policies to push security rules to every joined machine. You can lock screens, set password rules, and block bad software from one console. Teams also group users by job role and link those groups to server permissions. A database admin group gets full rights on SQL servers through these group links. When someone leaves the team, removing their account from the directory stops their logins.
Why teams connect local directories to cloud apps
Most companies run both local servers and modern cloud tools at the same time. Managing separate accounts for local servers and cloud apps creates extra work and mistakes. Teams often sync their local directory to a cloud identity provider to fix this. A sync tool copies user names and group memberships up to the cloud directory. Users can then log in to web apps with their normal work credentials.
Syncing accounts makes life easier for the team, but it also spreads risk. If an on-site group has too many rights, those wide permissions move to the cloud. Admins must clean up old groups before they link local directories to outside tools. Regular checks help you find stale accounts and remove unused admin rights early.
Active Directory + Single Sign-On (SSO): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What directory groups solve and what they miss
An on premise active directory is great at checking who can log in. It proves who a user is and checks which server groups they belong to. It also gives you a central place to turn off an account right away. This setup stops strangers from logging in to your internal systems and databases.
Still, directory groups only check identity at the door when a session starts. Once a user logs in to a database or server, the directory steps back. The directory cannot see which SQL queries or shell commands the user runs next. It cannot stop an engineer from dropping a table or reading every row. It also cannot rewrite sensitive fields like emails, phone numbers, or card numbers in results. To control live queries and mask data in flight, you need controls beyond login checks.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What is the main difference between local and cloud directories?
A local directory runs on your own servers and uses Kerberos and LDAP protocols. A cloud directory runs as a web service and uses modern web login protocols.
How do you limit lateral movement in a local domain?
Split admin accounts into separate tiers for workstations, servers, and domain controllers. Never log in to a standard user workstation with a high-level domain admin account.
Why do directory logs miss database query details?
Domain controllers only log ticket requests and login events at the start of a session. They never inspect the database traffic or commands that happen after a user logs in.