Want to learn the best practice for configuring Chromebooks with 802.1X authentication?

Sign up for a Webinar!

Drawbacks of NPS In A  Cloud Environment

Key Points
  • NPS is a native Windows server that can communicate with Active Directory and Security Account Manager to identify users before authentication.
  • However, NPS requires on-premise server maintenance, which is an ongoing expense. It is also vendor-locked and requires complex configuration and maintenance.
  • It lacks support for Cloud applications as it cannot communicate with Azure AD (Microsoft’s Cloud replacement for AD) for identity and access management.
  • A CloudRADIUS can synchronize with Azure AD for certificate-based authentication and management, making it more scalable to meet growing business needs.

Organizations want different technologies to work well together and integrate smoothly so they can be used more efficiently. The combination of Microsoft Azure and Network Policy Server (NPS) frequently generates interest and confusion simultaneously. While both are effective tools in their respective fields, it is crucial to recognize that they may not always be a good fit. In this article, we go into the complexities of integrating Azure with NPS service, highlighting details and possible risks that organizations should be aware of.

Click here to read this case study about a financial enterprise investing in Wi-Fi security with Cloud RADIUS.

Azure has become synonymous with modern business processes due to its extensive portfolio of cloud services. Network Policy Server, a component of Microsoft’s Windows Server operating system, is critical in administering and enforcing network access controls. While both groups contribute substantially to a strong IT infrastructure, attempting to integrate them might provide unexpected challenges.

Navigating Azure Integration Challenges with NPS Server

NPS is critical in deciding access to the business network by implementing regulations specified inside its server. Within a corporate setting, a computer’s request for internet access travels via the access point to NPS. This network policy server, sometimes called a Radius server, checks the request against company policies. These policies include ensuring user certificates are authentic, and that antivirus software is updated. However, a major surprise emerges: NPS, which was meant to interact smoothly with Active Directory, only sometimes extends its hand to Azure Active Directory (Azure AD). Despite Azure’s pervasiveness, bridging the gap between Azure and NPS necessitates careful evaluation of their respective features and limits.

One typical strategy is replicating Azure AD (EntraID) items into on-premises Active Directory, providing an Azure AD sync NPS mechanism. This process, frequently aided by Azure AD Connect NPS, enables organizations to employ NPS rules without requiring a direct connection to Azure AD. However, it is critical to recognize that AAD Connect largely supports replication from on-premises AD to Azure AD, and the opposite movement requires careful programming and thought. Throughout our journey, we are examining the problems provided by bidirectional replication and creating custom scripts to synchronize Azure AD users and groups with on-premises AD, overcoming Microsoft’s insistence on a one-way sync. While the replication technique creates complexity, particularly regarding password precedence, it serves as a bridge for organizations using NPS rules in combination with Azure AD.

Implementing RADIUS with NPS in Azure

A Network Policy Server (NPS) is Microsoft’s RADIUS server. NPS server can be configured to perform authentication, authorization, and accounting. Historically, NPS has been used on-premise and works with AD environments.

To state the obvious: Azure Directory (Microsoft Entra ID) doesn’t natively support RADIUS, so admins must find their own solutions for implementing RADIUS requests. Admins won’t be able to use their existing NPS configuration because NPS uses LDAP to communicate with AD, but Azure only supports SAML. Customers will either need to switch to EAP-TLS or find a RADIUS server that doesn’t rely on LDAP.

While this system works, and many admins have enabled RADIUS this way, building on-premise NPS servers is time-consuming and expensive. Plus, organizations looking to migrate to the cloud will still be stuck with on-prem hardware. Management and upkeep of the servers are dumped on the admins.

Implementing an on-prem NPS server requires an immense amount of time and resources. On-prem servers are expensive because there are so many components when building a RADIUS server; in this case, each comes with its own price tag. Services that organizations need to pay for include, but are not limited to:

⦁ Software acquisition
⦁ Licensing fees
⦁ Scalability for user growth
⦁ Hardware infrastructure
⦁ Creation and management of group policies
⦁ Certificate Revocation Lists management
⦁ Certificate lifecycle management
⦁ Personnel training
When all is said and done, organizations will end up paying hundreds of thousands of dollars for an on-prem NPS server.
Along with the massive price tag for organizations, all this setup and maintenance is left to the IT department. IT admins will spend countless hours reading forums and posts for implementation and maintenance issues. The implementation could take weeks or even months, which doesn’t include all the potential instances where the IT department is pulled away for other tasks.
Using on-prem NPS servers makes it harder for organizations to transition their networks to the cloud, leaving them with legacy servers from the very start.

Making the Switch from NPS to RADIUS Authentication in the Cloud

The transition from a traditional NPS (Network Policy Server) to a cloud-centric authentication system, such as SecureW2’s Cloud RADIUS, involves significant changes in approach. Cloud RADIUS is a full replacement for NPS rather than just a connecting tool. It works on the same principle as passwordless authentication but with the addition of digital certificates for further security. Because they exclusively broadcast their public keys, these certificates strictly comply with the Zero Trust Network Security principles, making them impervious to credential theft.

Integrating Cloud RADIUS with Azure AD (Microsoft Entra ID) is a significant advantage. It works with Azure AD to improve security and user experience by using current rules. The real-time user lookup tool against Azure AD guarantees that only authorized users may log in, making the system more secure overall.

Cloud RADIUS’ authentication features include Mobile Device Management (MDM) gateways and a robust access policy engine designed exclusively for Azure Active Directory. This all-encompassing technique conforms with current network security best practices and simplifies the deployment of certificate-based security, enabling a safe and secure transfer to the cloud.

SecureW2’s Cloud RADIUS includes all of the required Public Key Infrastructure (PKI) components, onboarding solutions for mobile device management (MDM) and bring your own device (BYOD), and a fully functional RADIUS server for enabling certificate-based authentication. This strategy assures that your cloud migration is secure and complies with current network security requirements, making the deployment of certificate-based security easier.

Authentication with Azure AD MFA and Azure MFA NPS Extension

NPS is frequently used in Microsoft environments looking to enable MFA (Multi-Factor Authentication) in Azure for secure authentication for web applications, Wi-Fi, VPNs, and others.
Microsoft admins who want to roll out Multifactor Authentication can use an Azure NPS extension. This option is great for organizations that want secure VPN access for users but don’t want to go through the hassle of setting up an Azure MFA server. Since Azure doesn’t have Group Policies (GPO), admins will need to install Azure Active Directory Domain Services (AAD DS), which allows machine access to users and to create custom group policies and Organizational Units (OU), which are subsets of users, devices, and groups in AD. Admins can administer group policies to specific OUs.

However, implementing and managing on-prem hardware is expensive for organizations and is a major configuration project for admins. It requires vast technical know-how and the right Azure NPS extension triggers to get AD and Azure AD to communicate efficiently. Plus, if your organization is not purely Windows, you will have difficulty setting up Azure Multifactor Authentication for IT tools that aren’t Microsoft. It’s important to note that shared secrets are a weak form of authentication security compared to certificates. Certificates are similarly easy to authorize. Add your access point certificate to the personal certification store on the Local Machine, then request and import the .p12 certificate to the NPS server.

Planning NPS as the RADIUS server is arduous, especially if you include AD CS to use certificates. Certificate authentication is worth the setup time unless you pick PEAP-MSCHAPv2 as the authentication protocol. PEAP only requires a server certificate for the RADIUS and client passwords. While the server certificate can verify the server, passwords are not an accurate identifier of clients as they can be easily shared or stolen. One person with the right software can perform a man-in-the-middle attack and convince the RADIUS server that they are an active client with a stolen password. EAP-TLS requires both the RADIUS client and RADIUS server to be enrolled with a certificate.

The Limitations of NPS MFA Extensions for Azure Active Directory

Although NPS extensions aim to facilitate the transition to Azure AD, they have certain limits. If an authentication request fails and there are issues with the user experience, the integration process can quickly become arduous. Envision a scenario where users are refused access services to vital resources or experience delays due to compatibility concerns.

It is possible that some RADIUS attributes set in the Network Access Policy do not transmit correctly to RADIUS Clients, such as the VPN Gateway. This might lead to users experiencing increased, decreased, or complete lack of access services to company resources. In such circumstances, it is necessary to execute a script as instructed by Microsoft to ensure the seamless functioning of MFA requests. However, this places an additional burden on administrators.

Irrespective of the authentication protocol used (PAP, CHAP, or EAP), if your multi-factor authentication (MFA) method relies on text-based verification (such as SMS, mobile app verification code, or OATH hardware token) and necessitates the user to input a code or text in the VPN client UI input box, the authentication flow may fail. However, any RADIUS attributes specified in the Network Access Policy are not sent to the RADIUS client, the Network Access Device, such as the VPN gateway. As a result, the VPN client may have greater or lesser access than desired or no access at all.

To address this issue, execute the CrpUsernameStuffing script to redirect RADIUS attributes set in the Network Access Policy and activate multifactor authentication (MFA) when the user’s authentication flow necessitates the use of a one-time password (OTP), such as SMS, a passcode from Microsoft Authenticator app, or a hardware FOB.

To selectively activate Multifactor Authentication for some RADIUS clients while excluding others, it is necessary to set up two NPS servers and install the NPS extension on only one. This imposes an additional onus on administrators. In addition, to activate a wide range of MFA methods, such as phone calls, one-way text message, mobile app notifications, OATH hardware tokens, and mobile app verification codes, one must choose PAP in their NPS settings. The PAP protocol is recognized as an archaic authentication method that transmits all authentication information in clear, unencrypted text. This unnecessarily exposes your network to the risk of Man-in-the-Middle (MITM) attacks, which can easily occur.

Integrating Azure with Cloud RADIUS

Instead of going the route of an on-prem NPS server, Azure admins can integrate SecureW2’s Cloud RADIUS into their environment with no forklift upgrades. In hours, organizations can securely authenticate users with Cloud RADIUS, which uses certificate-based EAP-TLS, one of the most secure authentication methods.
Here’s a high-level overview of how to integrate Cloud RADIUS with Azure for certificate authentication:
⦁ Create a SAML Application in Azure and add it to SecureW2 Management Portal

  • The SAML application is a crucial connection between the IDP and SecureW2. The SAML application allows users to enter their credentials, which are then passed to the IDP for verification. The IDP verifies the user’s details and then sends attributes to the SAML application, which then passes the attributes to SecureW2 for certificate issuance.

⦁ Configure Azure Policies in SecureW2

  • Configure the authentication and user role policies in SecureW2. SecureW2 issues certificates based on these conditional access policies, which determine a user’s access rights, network segments, etc.

Add Users to SAML Application in Azure

  • To test the SAML application, add Azure users to the application. It will show you the user onboarding process and determine if everything has been configured correctly. You should be taken to the Windows login screen.

Allow SAML App to Access Active Directory

  • The SAML App must have access to Active Directory so you can start adding attributes in SecureW2.

Configure Azure Attribute Mapping

  • Attribute mapping lays out the attributes returned by your IDP and is used to grant access to users. Once your IDP identifies a user, it sends the attributes to your SAML application and sends them to SecureW2. SecureW2 encodes these attributes in the certificate it issues. Attributes contain information about the user and which network resources they can access.
    Here’s how On-Premise NPS with Cloud facing architecture looks like –

Cloud RADIUS comes with SecureW2’s Managed Cloud PKI, a turnkey PKI solution that can integrate with Azure environments to deploy WPA2-Enterprise wireless security and certificate-based authentication. Our services eliminate the need for passwords to authenticate users, effectively eliminating over-the-air credential theft and password reset policies. Cloud RADIUS will fit right in with Azure since it’s on the cloud and not shackled to on-prem servers.

Elevate Your Network Security with Cloud RADIUS

Organizations confront obstacles when combining Azure AD with Network Policy Server (NPS) to strengthen network security. Legacy protocols and security flaws emphasize the need for a more cloud-centric strategy. Enter SecureW2’s Cloud RADIUS, a modern security beacon that advocates passwordless, certificate-based authentication, offering enhanced protection against credential theft.

Cloud RADIUS from SecureW2 surpasses limitations, saying goodbye to LDAP and AD servers. It redefines network authentication by providing real-time user lookup, device and user context, and an industry-exclusive access policy engine. Cloud RADIUS is key for organizations willing to embrace a future of enhanced security and simplified authentication. Contact us now to secure your network.

Tags: azure
Learn about this author

Anusha Harish

Anusha is a copywriter with a passion for telling stories through her writing. With a law degree and keen research skills, she writes articles to help customers make informed decisions. A movie buff and a bookworm, she can be found tucked away with a book and a cup of coffee mostly.

Drawbacks of NPS In A  Cloud Environment