Entra Id Auditing
You set up entra id auditing by turning on directory and sign-in logs. Then you send those records to a central storage workspace for review. Most teams start by collecting basic login events and group changes. Still, broad roles soon make it hard to track what users do next. A user might log in with one shared admin role. Once inside, directory logs stop showing their actual database queries or server commands. How native entra id auditing works in your directory The directory tracks three m
Microsoft Entra ID (Azure AD): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up entra id auditing by turning on directory and sign-in logs. Then you send those records to a central storage workspace for review. Most teams start by collecting basic login events and group changes. Still, broad roles soon make it hard to track what users do next. A user might log in with one shared admin role. Once inside, directory logs stop showing their actual database queries or server commands.
How native entra id auditing works in your directory
The directory tracks three main types of activity across your cloud tenant. First, sign-in logs record when a user or app tries to log in. These records show the person, the device, the network address, and the result. Second, directory audit logs record changes made to objects inside the system. When an admin creates a user or updates a group, the log captures it. Third, provisioning logs show when the directory syncs accounts to outside software.
By default, the cloud portal keeps these records for a short period. Teams that need long-term history route the logs to an external storage account. You can also send the event stream to a security analysis tool. Admins set up diagnostic rules to pick which log categories move to storage. Once the stream runs, security teams write alerts for risky login patterns. They also check the logs to see who granted high-level directory roles.
What directory logs solve and what they miss
Native directory logs do a great job of tracking the front door. They prove who logged in and when they passed multi-factor checks. They also show who changed a role or added an app registration. This helps teams pass basic audits for account lifecycle and login rules. If an attacker guesses a password, the sign-in log catches the failed tries.
Still, directory logs stop at the moment the login succeeds. They do not record what an engineer does inside a database or cluster. For example, a developer logs in through the directory to reach a database. The directory log shows one valid login event for that person. It does not show whether they ran a safe read or dropped a table. It also cannot rewrite sensitive fields like emails or card numbers in results.
Microsoft Entra ID (Azure AD): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Moving from login checks to action-level visibility
Relying only on directory logs leaves a large blind spot in production. Teams often assign broad roles so engineers can fix urgent issues fast. When everyone shares a broad role, directory logs only show the entry time. You still lack a record of each SQL query or shell command. Security teams cannot tell if a session pulled phone numbers or national IDs.
To close this gap, teams pair directory checks with command-level controls. You still use your directory as the single source of truth for identity. Then you add a step that checks and logs every single request in flight. This approach links each database statement or server command back to one user. It also lets you require quick peer reviews before someone runs a risky command.
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 difference between sign-in logs and directory audit logs?
Sign-in logs show when users and apps log in to get tokens. Directory audit logs show changes to users, groups, roles, and app settings.
Why do teams export directory logs to outside storage?
Built-in portal logs expire after a short window. Exporting them lets you keep history for months and run custom security alerts.
Do directory logs show the queries a user runs in a database?
No, directory logs only record the login step and directory role changes. You need query-level logging to see the actual statements a user runs.