Radius Authentication with Microsoft Entra Id
You set up radius authentication with microsoft entra id by pairing Network Policy Server with a cloud plugin. This setup forwards local network login checks to your cloud directory for user approval. Many IT teams use this flow to bring cloud multi-factor prompts to older routers and VPNs. Still, once a user passes that check, broad network roles often grant full internal reach. That wide reach lets an approved user run risky commands on databases without further checks. How radius authentica
Microsoft Entra ID (Azure AD) + Multi-Factor Authentication (MFA): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up radius authentication with microsoft entra id by pairing Network Policy Server with a cloud plugin. This setup forwards local network login checks to your cloud directory for user approval. Many IT teams use this flow to bring cloud multi-factor prompts to older routers and VPNs. Still, once a user passes that check, broad network roles often grant full internal reach. That wide reach lets an approved user run risky commands on databases without further checks.
How radius authentication with microsoft entra id works
Microsoft Entra ID does not speak the older RADIUS protocol on its own. Instead, you must run a local Windows Server that hosts the Network Policy Server role. This local server acts as a bridge between your network gear and the cloud directory. First, a user tries to log in to a VPN or network switch. The network device sends a standard RADIUS request to your local policy server. Next, the server checks the user password against your local Active Directory domain. If the password is good, an installed cloud plugin steps into the login flow. This plugin talks to Microsoft Entra ID over the web to trigger a second check. The user gets a push prompt or enters a code on their phone. Once the user approves the prompt, the cloud directory sends a success note back. Finally, the local policy server tells the VPN or switch to let the user in.
Why teams pair local servers with cloud directories
Teams build this bridge to keep one source of truth for user accounts. Nobody wants to manage separate password lists on fifty different switches and VPN boxes. By linking local RADIUS checks to the cloud, admins enforce one set of rules. When someone leaves the team, disabling one cloud account blocks their VPN login right away. It also brings modern phone prompts to older systems that only know legacy protocols. Admins can group users in the cloud and match those groups to network policies. This setup keeps login rules clean and cuts down on help desk password resets.
Where network login checks fall short
While this setup solves the initial login, it stops watching once the session starts. RADIUS only decides if a user can enter the network or open a console. It has no idea what the user does five minutes after logging in. Once on the network, an engineer still needs direct keys to reach databases or servers. Teams often share broad admin accounts for Postgres, MySQL, or Kubernetes to move fast. Network logs will show that an engineer joined the VPN at nine in the morning. Those logs will not show which SQL queries ran or which production tables changed. Plus, if a query pulls customer emails, phone numbers, or card numbers, raw data flows back. A network login check cannot rewrite sensitive fields in query results or block a bad drop command. To stay safe, teams need controls that work at the command and query level.
Microsoft Entra ID (Azure AD) + Multi-Factor Authentication (MFA): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
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
Does Microsoft Entra ID support RADIUS without extra servers?
No, the cloud directory does not listen for RADIUS traffic on its own. You must run a Windows Server with Network Policy Server and the official cloud plugin.
What login methods work with the NPS cloud plugin?
Push prompts and phone codes work well for most users during login. Text messages and some hardware tokens may have limits based on your local client app.
Can RADIUS control which SQL queries a user runs?
No, RADIUS only handles the initial network or device login check. It cannot read, filter, or mask database queries and server commands inside an active session.