Entra Id Radius
You set up an entra id radius workflow by pairing Windows Server Network Policy Server with Microsoft's MFA extension. This bridge links legacy network gear to your cloud directory for user logins. Teams use this design to check user identities on VPNs and routers. Still, network entry grants broad reach across internal subnets once a user logs in. Broad network roles let users reach sensitive databases and servers without granular command checks. How an entra id radius workflow operates Micr
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 an entra id radius workflow by pairing Windows Server Network Policy Server with Microsoft's MFA extension. This bridge links legacy network gear to your cloud directory for user logins. Teams use this design to check user identities on VPNs and routers. Still, network entry grants broad reach across internal subnets once a user logs in. Broad network roles let users reach sensitive databases and servers without granular command checks.
How an entra id radius workflow operates
Microsoft Entra ID does not run a native RADIUS listener in the cloud. Instead, you must run a local Windows Server with the Network Policy Server role. You then install the Microsoft Entra MFA extension on that local Windows Server. When a user tries to log in, the VPN or switch sends a RADIUS request. The local Network Policy Server reads this request and checks Active Directory first. It verifies the user's primary password against your local domain controller.
Next, the MFA extension sends the login request to the cloud directory. The cloud service sends a push alert or code request to the user's phone. Once the user approves the prompt, the cloud service tells the local server. The Network Policy Server then sends an accept packet back to the network device. This flow adds two-factor checks to hardware that only speaks the older RADIUS protocol. Your team keeps a single cloud identity source while supporting older network gear.
Why teams pair RADIUS with directory groups
Teams often link RADIUS policies to directory groups to separate network segments. A network rule checks if the user belongs to an engineering or finance group. If the check passes, the VPN assigns the user to a specific subnet. This setup blocks unauthorized staff from reaching private internal IP ranges from home. It also centralizes password resets and multi-factor rules inside one admin portal.
Before this extension existed, admins had to maintain separate token servers for VPN logins. Removing someone from the team meant deleting accounts in multiple isolated systems. Tying the local RADIUS server to the cloud directory fixes that account cleanup problem. When HR disables a cloud profile, the next RADIUS login attempt fails right away. This link helps security teams pass basic login audits for remote network entry.
Microsoft Entra ID (Azure AD) + Blast Radius Reduction: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What network entry solves and what it misses
An entra id radius setup solves the problem of who can join your network. It stops attackers who steal a password but lack the user's second factor. It also logs the exact time a user starts a VPN or Wi-Fi session. Still, RADIUS stops working the moment the network session opens. It has no awareness of what happens inside database queries or server shells.
Once on the subnet, an engineer still needs direct keys for Postgres or Kubernetes. Teams often hand out shared database passwords because the VPN already checked the user. If an engineer runs a destructive drop table query, RADIUS logs show nothing. The network server only sees that the user joined the VPN at nine. Also, raw query results return sensitive fields like emails, phone numbers, and card numbers. Network login checks cannot rewrite those matched fields in results or block bad commands. Security teams need command-level controls that check every query and action in flight.
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
Does Microsoft Entra ID include a built-in cloud RADIUS server?
No, it does not offer a direct cloud endpoint for RADIUS traffic. You must deploy Windows Server Network Policy Server with the official MFA extension.
Can this setup support one-time passcodes for legacy VPN clients?
Yes, the MFA extension supports push prompts and one-time passcodes for user logins. Older VPN clients without text boxes often work best with phone push alerts.
Does RADIUS log the database queries a user runs over the VPN?
No, RADIUS only checks and logs the initial network login event. It cannot read, log, or filter SQL statements or shell commands after login.