Entra Id Radius Server
Microsoft does not offer a built-in entra id radius server in the cloud. Teams set up a Windows server or a cloud service to bridge this gap. Network teams often use this setup for Wi-Fi and VPN logins. They link cloud users to legacy network gear that needs RADIUS checks. Still, once a user logs in, broad network permissions let them reach many systems. A basic login check does not control what commands they run next. How an entra id radius server setup works Legacy network hardware cannot r
Microsoft Entra ID (Azure AD) + Kubernetes API Server Access: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Microsoft does not offer a built-in entra id radius server in the cloud. Teams set up a Windows server or a cloud service to bridge this gap. Network teams often use this setup for Wi-Fi and VPN logins. They link cloud users to legacy network gear that needs RADIUS checks. Still, once a user logs in, broad network permissions let them reach many systems. A basic login check does not control what commands they run next.
How an entra id radius server setup works
Legacy network hardware cannot read modern web login tokens on its own. Wi-Fi points and VPN boxes speak the older RADIUS protocol instead. Cloud directories use modern web protocols to check user names and passwords. To link them, admins must put a translator service in the middle.
Many teams run Windows Network Policy Server on a local virtual machine. They add the Microsoft extension for multi-factor checks to this local server. First, a user tries to log in to the VPN or network. The VPN device sends a RADIUS message to the local Windows server. The server checks the password against a synced local domain controller. Next, the extension asks the cloud directory to send a phone prompt. The user approves the prompt, and the server approves the network login.
Other teams use a managed cloud RADIUS service to skip local servers. In that design, the cloud RADIUS tool syncs user groups through web APIs. It checks passwords or client certificates and then grants network entry.
Why network login checks leave a control gap
Setting up RADIUS with your cloud directory solves the first login step. It stops unknown users from joining the Wi-Fi or the corporate VPN. It also forces people to pass a multi-factor check before they enter. Central teams can turn off a user account in one single place.
Yet this network setup stops working right after the login succeeds. RADIUS only says yes or no when the session starts. Once inside the network, the user gets an IP address and broad routing. The RADIUS server does not see what databases or servers they touch next. It cannot read the SQL queries or shell commands that an engineer runs.
Microsoft Entra ID (Azure AD) + Kubernetes API Server Access: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Shared database passwords and static server keys remain in use inside the network. If an engineer runs a bad query, the RADIUS log shows nothing. If a query returns emails or card numbers, RADIUS cannot rewrite those fields. Audits become hard because network logs only show when a VPN session started.
Moving from perimeter checks to command-level rules
Security teams need more than a front door check for modern engineering work. Relying on a VPN and a RADIUS bridge puts too much trust in the network. Engineers need direct, controlled ways to run queries and commands on servers. Teams get better safety when they check identity on every single action. Instead of opening a broad network pipe, controls should inspect requests in flight. Masking rules can also rewrite phone numbers or national IDs in query results. This approach keeps data safe even after a user passes the first login.
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 offer a native cloud RADIUS service?
No, the cloud directory does not include a built-in RADIUS server endpoint. You must run Windows Network Policy Server with an extension or use a third-party service.
Do I need a local domain controller for the Windows NPS extension?
Yes, the Windows NPS setup needs a synced domain controller to check passwords first. After the password check passes, the extension triggers the cloud multi-factor prompt.
Can RADIUS logs show what database queries a user ran?
No, RADIUS logs only record when a user logs in to the network. They do not track database queries, server commands, or data read during the session.