Implementing RADIUS Authentication for WiFi: Domain Integration, Device Compatibility, and Captive Portal Considerations


2 views

In Microsoft-based educational environments like yours, RADIUS (Remote Authentication Dial-In User Service) provides centralized authentication for WiFi networks. When integrated with Active Directory, it offers significant advantages over static WPA keys:

  • Machine-based authentication: Domain-joined Windows PCs can authenticate automatically using computer accounts
  • User-based authentication: Staff can authenticate with their AD credentials on any device
  • Granular access control: Different policies can be applied to different AD groups
# Example NPS (Network Policy Server) configuration snippet
# for mixed machine/user authentication on Windows Server

New-NpsRadiusClient -Name "Cisco-WAP" -Address "10.0.1.100" -SharedSecret "YourComplexSecret"
    
$machinePolicy = New-NpsPolicy -Name "DomainMachines" -Condition "NASPortType == 'Wireless - IEEE 802.11'"
Add-NpsPolicyCondition -Name "DomainMachines" -Condition "WindowsGroups == 'DOMAIN\\Domain Computers'"
Set-NpsPolicy -Name "DomainMachines" -AccessAllowed $true

While RADIUS works seamlessly with domain-joined Windows devices, mobile devices require special consideration:

  • PSP/iPod Touch: Limited to WPA2-Enterprise with PEAP-MSCHAPv2
  • Android/iOS: Supports modern EAP methods (TLS, TTLS)
  • Legacy devices: May require fallback to less secure methods

Here's how to configure a Cisco WLC for mixed device support:

config wlan security wpa akm dot1x enable 
config wlan security wpa akm psk enable 
config wlan security wpa akm psk set-key ascii  
config wlan security wpa akm psk set-key-format ascii 

For your requirement to segment WiFi traffic without MAC exceptions:

  1. Create a separate VLAN for wireless clients
  2. Use DHCP options to provide different configurations:
    dhcpd.conf:
    subnet 10.0.2.0 netmask 255.255.255.0 {
      option routers 10.0.2.1;
      option domain-name-servers 10.0.1.10;
      range 10.0.2.100 10.0.2.200;
      option captive-portal "https://portal.yourschool.edu";
    }
  3. Implement firewall rules to redirect unauthenticated traffic

For a school with 150+ devices, I recommend this hybrid approach:

  • Domain devices: RADIUS authentication via NPS
  • Personal devices: Captive portal with AD integration
  • Segregation: Different VLANs with controlled routing

Here's a basic FreeRADIUS configuration for mixed authentication:

# /etc/freeradius/3.0/sites-available/school-wifi
authorize {
    if (NAS-IP-Address == 10.0.1.100) {
        update control {
            Cleartext-Password := "%{mschap:User-Password}"
        }
        mschap
    }
    else {
        ldap
    }
}

authenticate {
    Auth-Type LDAP {
        ldap
    }
    Auth-Type MS-CHAP {
        mschap
    }
}

Remember to test thoroughly with different device types before full deployment. The combination of RADIUS for domain devices and captive portal for guests provides both security and flexibility.


When implementing RADIUS authentication in your educational network environment, there are several technical considerations to address. Here's how RADIUS authentication works in practice with Microsoft environments:

# Example NPS (Network Policy Server) configuration for Windows Server
# This creates a RADIUS client for your access points
New-NpsRadiusClient -Name "SchoolWAPs" -Address "192.168.1.0/24" -SharedSecret "YourComplexSecretHere" -VendorName "RADIUS Standard"

For domain-joined machines, you can enable automatic authentication using machine credentials:

# Group Policy configuration for automatic WiFi authentication
# Computer Configuration > Policies > Windows Settings > Security Settings > Wireless Network Policies
# Enable "Use Windows WLAN AutoConfig service for clients"
# Add your SSID with authentication method set to WPA2-Enterprise

For non-domain devices like mobile phones and tablets, you'll need to implement user-based authentication. This requires:

  1. Certificate-based authentication (preferred)
  2. PEAP-MSCHAPv2 fallback (less secure)

For devices that don't support enterprise authentication, a captive portal can be implemented. Here's how to segregate WiFi traffic:

# Example DHCP scope configuration for WiFi devices
# This would be on your Windows DHCP server
Add-DhcpServerv4Scope -Name "WiFi-Captive" -StartRange 192.168.2.100 -EndRange 192.168.2.200 -SubnetMask 255.255.255.0
Set-DhcpServerv4OptionValue -ScopeId 192.168.2.0 -Router 192.168.2.1 -DnsServer 192.168.1.10

To properly implement captive portals without affecting wired clients:

# Example pfSense captive portal configuration (if using separate firewall)
# Interfaces > LAN > Enable captive portal
# Allowed IP addresses: 192.168.2.0/24
# Authentication: Local user manager or RADIUS backend
# Portal page contents: Custom login page with school branding

Here's what works with different device types:

Device Type RADIUS Support Captive Portal Support
Windows Domain PCs Full (machine auth) Not needed
MacOS Full (user auth) Fallback
iOS PEAP support Full
Android Varies by version Full
Game Consoles Limited Browser-based

For optimal security in your environment:

# PowerShell to enforce strong RADIUS policies
Set-NpsNetworkPolicy -Name "StudentAccess" -AccessPermission "GrantAccess" -AuthenticationType "PAP,MS-CHAPv2" -EncryptionType "Strongest"
Set-NpsNetworkPolicy -Name "StaffAccess" -AccessPermission "GrantAccess" -AuthenticationType "EAP" -EncryptionType "Strongest"

Remember to implement proper logging and monitoring:

# Enable NPS logging
Set-NpsRadiusAccounting -EnableAccounting $true -LogFilePath "C:\RadiusLogs\" -LogPeriod "Weekly"