Entra Radius
You set up entra radius by linking an on-premises network server to Microsoft Entra ID. This setup lets legacy network gear check user logins against your cloud directory. Teams often use this bridge to secure virtual private networks and Wi-Fi access. Still, granting broad network entry often gives users full reach to internal servers. Once inside the network, broad roles let anyone run risky commands without oversight. How an entra radius architecture works in practice Microsoft Entra ID do
Microsoft Entra ID (Azure AD) + Blast Radius Reduction: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up entra radius by linking an on-premises network server to Microsoft Entra ID. This setup lets legacy network gear check user logins against your cloud directory. Teams often use this bridge to secure virtual private networks and Wi-Fi access. Still, granting broad network entry often gives users full reach to internal servers. Once inside the network, broad roles let anyone run risky commands without oversight.
How an entra radius architecture works in practice
Microsoft Entra ID does not speak the RADIUS protocol on its own. It uses modern web standards like SAML and OpenID Connect for cloud apps. Legacy routers, firewalls, and VPN concentrators still rely on older RADIUS packets. To bridge this gap, teams deploy a local network policy server. They also install a Microsoft multi-factor extension on that same Windows server.
When a user tries to log in, the network device sends a packet. The local policy server receives this request and checks the primary password first. It validates the user against the local Active Directory domain right away. Next, the extension reaches out to the Microsoft cloud for a second check. The user gets a push prompt or enters a code on their phone. Once the cloud approves the check, the local server sends an accept packet. The network appliance then opens the tunnel or grants Wi-Fi network entry.
Some teams skip the local Windows server and use a cloud RADIUS service. In that model, the network gear sends packets straight to the third-party vendor. That service then talks to Microsoft Entra ID through standard cloud APIs. Both paths aim to unify user accounts under one central cloud directory.
Why network login checks leave a gap inside your stack
Centralizing network login checks solves a real problem for IT and security teams. When someone leaves the company, you disable one cloud account to block entry. You also enforce two-factor checks on older appliances that lack modern login screens. This stops stolen passwords from giving attackers an easy path onto your network.
Still, RADIUS only decides who gets onto the network at the front door. It has zero visibility into what an engineer does after the tunnel opens. Once the session starts, the user sits on the internal network with raw reach. They can connect straight to production databases, Kubernetes clusters, or cloud servers. Network logs only show that a user joined the VPN at a given time. They never show which SQL queries ran or which shell commands changed a server.
Microsoft Entra ID (Azure AD) + Blast Radius Reduction: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Shared database passwords and static keys make this blind spot even worse. If five engineers use the same database role over the VPN, audit logs blur. You cannot tie a specific data read or table drop to one person. Network admission control also cannot mask sensitive fields like emails or card numbers. If a user runs a broad select query, raw customer data returns in full. True security requires checking and logging every single command and query in flight.
Moving from network perimeters to request-level controls
Modern engineering teams need controls that work at the database and server level. Instead of trusting a flat network tunnel, teams must verify every single action. Each query or command should carry the exact cloud identity of the caller. Security rules can then block risky actions or require peer approval before execution. Masking rules can also rewrite sensitive fields like phone numbers or national IDs. This approach turns identity from a one-time door check into a continuous guardrail.
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 runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Does Microsoft Entra ID support RADIUS natively without extra servers?
No, Microsoft Entra ID does not include a built-in RADIUS listener service. You must run a local Windows server with the cloud extension or use a third-party service.
Can entra radius control which SQL queries a developer runs?
No, RADIUS only handles the initial network or VPN login check. It cannot inspect, log, or block database queries or server commands after login.
What happens to active sessions if a user fails a RADIUS check?
A failed check blocks the new network connection from starting at all. For active sessions, the network gear keeps the tunnel open until the session timer expires.