How to Implement a Google Apps-Authenticated RADIUS Server for WiFi/VPN with 2FA Support


8 views

Integrating Google Apps credentials with RADIUS authentication presents several technical hurdles. The primary authentication protocols used in RADIUS (PAP, CHAP, MS-CHAPv2) don't natively support OAuth 2.0 or SAML flows that Google Apps typically uses. Additionally, when 2FA is enabled, the authentication flow becomes more complex.

Here are three viable approaches to solve this integration:

1. Google Apps RADIUS Proxy

The solution you referenced (layeh/google-apps-radius) is a Python-based RADIUS server that acts as a proxy to Google's authentication system. Here's a basic configuration example:


[server]
host = 0.0.0.0
auth_port = 1812
secret = your_shared_secret

[google]
client_id = your_client_id.apps.googleusercontent.com
client_secret = your_client_secret
domain = yourdomain.com

2. Third-Party Identity Brokers

Services like Okta, PingIdentity, or JumpCloud can act as intermediaries:

  • Configure Google Apps as identity provider in the broker
  • Set up RADIUS service in the broker
  • Point your network equipment to the broker's RADIUS endpoint

3. FreeRADIUS with LDAP Bridge

This method requires Google Cloud Directory Sync to mirror your Google users to an LDAP directory:


# freeradius/users configuration
DEFAULT Auth-Type := LDAP
    Fall-Through = 1

# freeradius/sites-enabled/default
authorize {
    preprocess
    auth_log
    ldap
    if (ok || updated) {
        update control {
            Auth-Type := LDAP
        }
    }
}

For 2FA scenarios, consider these approaches:

  1. Application-specific passwords (as you mentioned)
  2. Time-based one-time password (TOTP) integration
  3. Push notification workflows

UniFi devices can be particular about RADIUS implementations. Ensure:

  • RADIUS server is using standard attributes (Framed-IP-Address, etc.)
  • VLAN assignment attributes are properly formatted
  • Accounting packets are properly handled

For enterprise deployments, consider these hosted solutions:

Service 2FA Support Pricing Model
JumpCloud Yes Per user
Portnox Yes Per device
SecureW2 Yes Per user

The choice ultimately depends on your organization's size, existing infrastructure, and security requirements. Each approach has trade-offs between complexity, cost, and maintainability.


When implementing enterprise WiFi/VPN security, many organizations face the challenge of integrating RADIUS authentication with their Google Workspace (formerly G Suite) identities. The complexity increases when:

  • Two-factor authentication (2FA) is already enabled
  • Existing network infrastructure (like UniFi APs) must be supported
  • Security policies require minimal credential exposure

After testing various solutions, here are the most viable approaches:

Option 1: Google Apps RADIUS Proxy


# Sample configuration for google-apps-radius
[server]
listen = ":1812"
secret = "your_shared_secret"
domain = "yourdomain.com"

Pros:

  • Lightweight Go implementation
  • Direct integration with Google's API

Cons:

  • Limited 2FA support
  • May require application-specific passwords

Option 2: Federated RADIUS via SAML

Using a service like:


# Example FreeRADIUS + SAML config
modules {
    saml {
        certdir = ${confdir}/certs
        idp_metadata = "/path/to/google_metadata.xml"
    }
}

For organizations with strict 2FA requirements:

  • Implement time-based one-time passwords (TOTP) in RADIUS
  • Use push notifications through Duo Security integration
  • Create dedicated service accounts with limited privileges

When deploying in enterprise environments:


# High-availability RADIUS config example
realm googleapps.com {
    auth_pool = {
        primary = radius1.googleapps.com:1812
        secondary = radius2.googleapps.com:1812
        method = fail-over
    }
}

Monitor these key metrics:

  • Authentication latency
  • API quota usage
  • Failed attempt patterns

For UniFi AP integration problems:

  1. Verify EAP method compatibility (PEAP vs TTLS)
  2. Check certificate chain validation
  3. Test with radclient before AP deployment