Active Directory Provisioning and Deprovisioning
Active directory provisioning and deprovisioning automates how teams create, update, and remove user accounts. You set up sync rules between human resources apps and directory groups to manage roles. Most teams map job titles to security groups so new hires get instant permissions. Still, broad group roles often give users far more database and server permissions than needed. How active directory provisioning and deprovisioning works in practice The workflow starts when human resources adds a
Active Directory + User Provisioning (SCIM): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Active directory provisioning and deprovisioning automates how teams create, update, and remove user accounts. You set up sync rules between human resources apps and directory groups to manage roles. Most teams map job titles to security groups so new hires get instant permissions. Still, broad group roles often give users far more database and server permissions than needed.
How active directory provisioning and deprovisioning works in practice
The workflow starts when human resources adds a new person to their core system. A sync engine reads this new record and creates a matching directory account. The system then checks attributes like department, location, and job title against preset rules. Based on these rules, the directory puts the user into specific security groups.
Downstream apps, servers, and databases read those security groups to grant login rights. When a person changes roles, the sync engine updates their group list right away. It adds new groups for the new role and removes old ones. When someone leaves the company, human resources marks their record as inactive. The sync engine then disables the directory account and strips all group memberships. This stops the former worker from logging into linked apps and servers.
Why teams struggle with role sprawl and orphan accounts
Over time, teams create hundreds of security groups to handle one-off permission requests. Managers often copy permissions from an existing worker to set up a new hire. This habit causes privilege creep because people keep old groups when they switch teams. Soon, standard engineering groups hold admin rights to production databases and cloud servers.
Local accounts on servers and databases also break the clean deprovisioning flow. Engineers often create direct database users or shared keys for quick debugging work. The directory sync engine does not know these local accounts exist. When an engineer leaves, the directory account closes, but the local database login stays active. Auditors then find active credentials months after a user has left the team.
What directory sync solves and the runtime gap it leaves
Directory sync solves the basic problem of who has an active account today. It cuts down manual ticket work for IT teams during hiring and firing. It also gives security teams a central place to view group memberships. If an account is disabled in the directory, federation logins stop working right away.
Active Directory + User Provisioning (SCIM): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Still, directory provisioning only decides who can log in at the front door. It does not check what commands or queries a user runs after logging in. Once a directory group grants database permissions, the user can run any allowed query. A valid user can still drop a table or pull a full customer list. The directory also cannot mask sensitive fields like emails, phone numbers, or card numbers. To control live queries and redact data in results, you need controls at runtime.
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 difference between provisioning and deprovisioning?
Provisioning creates a user account and assigns group roles when someone joins a team. Deprovisioning disables that account and removes all roles when the person leaves.
Why do deprovisioned users sometimes keep access to databases?
Teams often share static database passwords or create local accounts outside the directory. Closing the directory account does not revoke shared passwords or active database sessions.
How can teams reduce risk from broad Active Directory groups?
Teams should review group memberships often and stop copying roles between users. Adding runtime checks and data masking for emails and card numbers also limits risk.
Short role checks help teams work fast. Simple rules make each review clear. Good logs keep every team safe. Scoped keys stop bad changes early.