Entra Signin Logs
You review and export entra signin logs by assigning a security reader role and routing events to a central log store. These records show who logged in, which app they opened, and whether multi-factor checks passed. Most teams start by viewing events inside the main identity portal during an incident. Still, portal storage expires fast, and broad admin roles often let too many people read sensitive login history. How entra signin logs work in your identity setup Every time a user or service t
Microsoft Entra ID (Azure AD) + Kubernetes Audit Logs: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You review and export entra signin logs by assigning a security reader role and routing events to a central log store. These records show who logged in, which app they opened, and whether multi-factor checks passed. Most teams start by viewing events inside the main identity portal during an incident. Still, portal storage expires fast, and broad admin roles often let too many people read sensitive login history.
How entra signin logs work in your identity setup
Every time a user or service tries to log in, the identity provider creates an event record. Reviewing entra signin logs gives your team a clear view of these login attempts across four separate streams. Interactive logs show human users who type credentials or complete a multi-factor prompt. Non-interactive logs track background apps and tools that refresh tokens on their own without human input. Service principal logs record when automated workloads or scripts log in using their own keys or secrets. Managed identity logs capture cloud resources that talk to other cloud services inside the same provider.
Each log entry holds key facts about the login attempt. You can see the user identity, the target app, the device state, and the source network address. The record also shows which conditional rules ran and why a login passed or failed. To keep these records past the default short window, teams set up diagnostic routing. This setup sends the log streams to a storage account, an event hub, or a log analytics workspace. Security teams then query that workspace to spot strange login patterns or failed token requests.
How to set up roles and log routing safely
Good log management starts with tight role assignments inside your identity directory. You should never grant global admin rights just so an engineer can read login history. Instead, assign a dedicated reader role that only grants view rights to monitoring data. When you route logs to an external workspace, lock down that workspace with its own strict role rules. Only your security team and audit staff should have the rights to query raw login records.
You should also send all four log streams to your external store from day one. Many teams only export interactive user logins and forget about background app traffic and service principals. Attackers often steal a service key or refresh token to bypass interactive prompts. If you do not export non-interactive and service principal streams, you will miss those silent logins during an audit. Filtering noisy system events at the destination workspace helps control storage costs without dropping vital security records.
Microsoft Entra ID (Azure AD) + Kubernetes Audit Logs: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What identity logs solve and what they miss
Identity sign-in records solve the first half of the access puzzle. They tell you who proved their identity and when they got a valid session token. They also help you test new conditional rules before you enforce them across the whole company. If a legitimate user gets blocked, the log shows the exact rule that stopped the login.
Still, sign-in logs stop at the front door of your databases, servers, and internal tools. Once a user or script logs in and connects to a database, the identity log goes quiet. It cannot tell you which SQL queries ran or which shell commands an engineer typed. It also cannot mask sensitive fields like emails, phone numbers, card numbers, or national IDs in query results. To control and audit what happens inside a session, you need controls that inspect each command in flight.
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 is the difference between interactive and non-interactive sign-in logs?
Interactive logs record logins where a person enters a password or approves a prompt. Non-interactive logs record background token checks made by apps on behalf of a user.
How long do sign-in logs stay in the default portal?
The native portal keeps sign-in records for a short period based on your license tier. For long-term retention, you must route the logs to an external storage workspace.
Do sign-in logs show what a user did inside a database?
No, sign-in logs only show that the user authenticated and received a token. They do not record database queries, shell commands, or data returned during the session.