Azure Ad Activity Logs
You view azure ad activity logs in the directory portal to track logins and changes. You can also send these records to an external storage account for long-term retention. Most teams set up a reader role so security staff can check these events. When teams grant broad directory roles, users gain too much power over cloud apps. A wide role lets someone read sensitive settings or change rules across the whole tenant. How azure ad activity logs work in your directory The cloud directory splits
Azure RBAC + Database Activity Monitoring: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You view azure ad activity logs in the directory portal to track logins and changes. You can also send these records to an external storage account for long-term retention. Most teams set up a reader role so security staff can check these events. When teams grant broad directory roles, users gain too much power over cloud apps. A wide role lets someone read sensitive settings or change rules across the whole tenant.
How azure ad activity logs work in your directory
The cloud directory splits its event records into three main categories for your team. Audit logs show changes made to users, groups, apps, and roles in the tenant. Sign-in logs track when a user or service account logs in to an app. Provisioning logs record when the system creates or updates accounts in external tools.
You need a specific security or reader role to view these records. Admins assign the lowest role needed so staff can read events without changing rules. Since the native portal keeps events for a short window, teams export them early. You can route the log stream to a cloud storage bucket or monitoring workspace. You can also push events to an external event hub for security analysis.
What native identity logs solve and what they miss
Native directory logs tell you who logged in and when that login happened. They also record which admin changed a group rule or added a new key. This data helps your team spot strange login locations or failed password checks. It proves that your login rules work as expected at the front door.
Still, directory logs stop tracking the user right after the login step finishes. They show that an engineer opened a database tool or a cloud console. They do not show what SQL statements or shell commands ran inside that session. Once a user passes the login check, the directory has no visibility into queries.
If an engineer runs a broad query, the login log shows a normal event. It cannot redact emails, phone numbers, card numbers, or national IDs in query results. It also cannot ask a manager to approve a risky delete command in flight. To control actions inside the session, you must check each command as it runs.
Azure RBAC + Database Activity Monitoring: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
How to tighten role rules for log reviewers
Start by removing global admin roles from people who only read event logs. Give your security analysts a read-only role scoped just to directory reports. Check your audit logs each week to see if anyone added new admin roles. Set up alerts when a user logs in from an unknown country or device.
Next, separate your login checks from your database and server command checks. Use your directory logs to watch account changes and login health across the team. Pair those records with command-level logs for every database and server you run. That way, you know both who logged in and what commands they ran.
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 sits inline in the protocol beside each supported service as an open-source proxy, a sidecar for your database or API. For every query or command an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human approval.
First, hoop.dev guardrails block banned queries before they run or hold risky ones for review, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What are the main types of records in azure ad activity logs?
The system records three main log types for your security team. These are sign-in logs, directory audit logs, and account provisioning logs.
Why do teams export directory logs to external storage?
The built-in portal only keeps activity records for a limited number of days. Exporting them to cloud storage lets you keep audit trails for many months.
Do azure ad activity logs show database queries after login?
No, directory logs only record the login event and changes to user accounts. They do not record the SQL queries or shell commands run during a session.