Entra Admin Center
You manage user roles, groups, and cloud apps inside the entra admin center. Teams use this web portal to set up login rules and single sign-on. Most engineering teams start by creating broad security groups for their staff. They assign database and server roles to these groups to speed up onboarding. Over time, these broad group roles give engineers too much power in production. A user who needs to read one table gets full write rights instead. How the entra admin center manages roles and gro
Microsoft Entra ID (Azure AD) + GCP Security Command Center: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You manage user roles, groups, and cloud apps inside the entra admin center. Teams use this web portal to set up login rules and single sign-on. Most engineering teams start by creating broad security groups for their staff. They assign database and server roles to these groups to speed up onboarding. Over time, these broad group roles give engineers too much power in production. A user who needs to read one table gets full write rights instead.
How the entra admin center manages roles and groups
The portal acts as the main control plane for cloud identity and login rules. Admins create user accounts or sync them from an on-premises directory server. Next, they organize these users into security groups based on job titles. A backend team gets one group, and the data team gets another.
Admins then link third-party apps, cloud accounts, and databases to the directory. They map each security group to a specific role inside those target systems. When an engineer logs in, the directory checks their user account and device state. It also checks multi-factor rules and location rules before granting a login token.
If all checks pass, the system sends an identity token to the target app. This token tells the target system which group roles the user holds right now. Teams also use time-bound role rules to limit standing admin rights in the portal. An engineer requests a role, gets approval, and holds that role for a few hours. Once the timer ends, the directory removes the user from that active role group.
What identity portals solve and what they leave open
Central identity portals are great at deciding who can log into a system. They stop bad logins at the front door with strong multi-factor checks. They also give security teams one place to turn off access when someone leaves. If you disable a user in the portal, their single sign-on sessions end.
Still, the identity portal stops watching once the user logs into the target tool. It hands over a valid token, and the database or server takes over. The directory cannot see the individual queries or commands the user runs in flight. If an engineer has a read role, they can still pull a full table.
Microsoft Entra ID (Azure AD) + GCP Security Command Center: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
That table might hold raw customer emails, phone numbers, card numbers, or national IDs. The identity portal has no way to rewrite matched fields in query results. It also cannot pause a single risky delete command while letting safe reads pass. Group roles are too coarse to control actions at the command or query level. Even time-bound roles give the user full power for the whole window.
Designing safer workflows beyond directory roles
To fix this gap, teams must separate login checks from runtime command control. Keep using the central directory to verify user identities and manage basic group membership. Do not try to build hundreds of tiny directory groups for every database table. Role sprawl makes audits hard and slows down daily work for engineering teams.
Instead, focus on controlling what happens after the user logs into a session. Security teams need visibility into every query and command run against production data. They also need fine-grained approvals that check the exact action, not just the role. Adding data masking in the path rewrites sensitive fields like emails or card numbers. This approach keeps the directory clean while protecting live systems during every active session.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the main purpose of the entra admin center?
It gives admins one web portal to manage users, groups, devices, and login rules. Teams use it to control who can sign into cloud apps and internal tools.
Can directory groups restrict specific SQL queries or shell commands?
No, directory groups only pass role claims during the initial login check. The target database or server decides what commands that role can run after login.
Why do time-bound directory roles still leave data at risk?
Time-bound roles grant full group rights for a set number of hours. During that window, a user can still run destructive commands or pull sensitive data.