Microsoft Entra Basic
You set up microsoft entra basic by adding users and groups in your cloud directory. Then you link those groups to your apps for single sign-on and password resets. Most teams start by putting developers into a few shared role groups. When those groups have broad roles, every member gets full control over production systems. One bad query or command can then change or delete live data. How microsoft entra basic works for user login This base identity tier acts as the central directory for you
Microsoft Entra ID (Azure AD): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up microsoft entra basic by adding users and groups in your cloud directory. Then you link those groups to your apps for single sign-on and password resets. Most teams start by putting developers into a few shared role groups. When those groups have broad roles, every member gets full control over production systems. One bad query or command can then change or delete live data.
How microsoft entra basic works for user login
This base identity tier acts as the central directory for your company. Admins create user accounts and sort them into simple groups. When a worker opens a linked app, the directory checks their password and second factor. If the check passes, the directory sends a token back to the app. The app reads the group list inside that token to pick a local role.
Teams also use this tier to let workers reset their own passwords. This cuts down on help desk tickets across the company. Admins can also assign cloud app access to a whole group at once. When a new engineer joins the team, you add them to the group. They get access to all linked tools right away. When they leave, removing them from the directory stops future logins.
Why directory groups fall short for production systems
Directory groups solve the problem of who can log in to a tool. They give your team one place to manage accounts and passwords. They also keep former workers from signing in after they leave. For basic web apps, this login check is often enough.
The gap appears when engineers connect to databases, servers, or cloud consoles. A directory check only happens at the start of a session. Once the database or server accepts the login, the directory steps out of the way. It cannot see what queries or commands the engineer runs next. It only knows that the user logged in earlier.
Because group roles are static, engineers keep their access all day long. A developer who needs to read one table often gets a broad read-write role. That role stays active even when they do not have an open ticket. If someone runs a destructive command by mistake, the directory cannot block it.
Microsoft Entra ID (Azure AD): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Directory logs also miss what happens inside the session. They record the time of the login and the app name. They do not log the actual SQL statements or shell commands that ran. If a query returns sensitive fields like emails, phone numbers, or card numbers, the directory does not rewrite them. Data masking must happen in the path of the query results, not at login.
Managing day-to-day database and server roles
To reduce risk with basic directory groups, teams often split roles by task. They create separate groups for read-only users and write users. They also split groups by staging and production systems. This helps limit how many people hold high privileges at the same time.
Still, managing dozens of fine-grained groups takes a lot of manual work. Admins must add and remove users every time someone needs to fix a bug. People often forget to remove a user after the fix is done. Over time, privileges pile up again across the engineering team. Controlling what happens during the live session requires checks at the command level.
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 does Microsoft Entra Basic include for teams?
It provides cloud user accounts, group management, single sign-on for apps, and self-service password reset. It focuses on core login checks for company workers.
Can directory groups control individual SQL queries?
No, directory groups only decide who can log in and which role they get. Once the session starts, the database handles all queries based on that static role.
How can teams protect sensitive data like emails or card numbers during queries?
Login directories do not inspect database traffic or results. Teams need a runtime control that inspects query results and rewrites matched fields like emails or phone numbers.