Help request: WPA Enterprise Authentication with UniFi equipment and Google Workspace LDAPS

[Alan DeKok]

On Jul 8, 2025, at 1:36 PM, Taylor Gorman <taylorgorman at thecampusway.com> wrote:
> Supplicant device:  2017 inch MacBook Air running macOS Monterey 12.7.6
> 
> Network equipment:  UAP-AC-PRO wireless access point and UDM-SE router
> 
> Directory server:  Google Workspace LDAPS
> 
> My Implementation:  Using official docker imagine "freeradius/freeradius-server" running on Google Compute Engine COS.
> 
> What am I trying to do:  WPA Enterprise Authentication (EAP-TTLS-PAP)
> 
> Why am I trying to do it:  To eliminate the security risk of pre-shared keys in a professional setting
> 
> What I expect the server to do:  Continue past authenticate and on to authorize.
> 
> What the server does:  Completes authenticate and fails on authorize

  That's all good information.

> Remarks:  I am a novice, but by my understanding, freeRADIUS is completing the authentication portion. This means that freeRADIUS connects to LDAPS and verifies the supplicant's username and password. So if all of this works, then why is freeRADIUS unable to proceed to authenticate? I suspect that there is some error with passing the supplicant user's password from the authenticate section to the authorize section.

  Nope.

> I apologize for not truncating the debug output. I am not sure which parts are relevant and which parts are not.

  Posting the full debug output is exactly the correct thing to do.

  The debug log shows the server starting up, and then packets 0..5 set up the TLS tunnel.  The connection continues with packet 6, which finally contains the users credentials from inside of the TLS tunnel.

> (6) Received Access-Request Id 13 from 71.59.46.3:50614 to 172.17.0.2:1812 length 344
...
> (6) eap_ttls: Got tunneled identity of radiustest at thecampusway.com
> (6) eap_ttls: Setting default EAP type for tunneled EAP session
> (6) eap_ttls: Sending tunneled request
> (6) Virtual server google-ldap-auth received request
> (6)   EAP-Message = 0x0200002001726164697573746573744074686563616d7075737761792e636f6d
> (6)   FreeRADIUS-Proxied-To = 127.0.0.1
> (6)   User-Name = "radiustest at thecampusway.com"

 This is the inner tunnel data.  Note that there's no User-Password, but only EAP-Message.

> ...
> (6)       if (&User-Password && !control:Auth-Type)  {
> (6)       if (&User-Password && !control:Auth-Type)   -> FALSE

  This section fails because there's no User-Password in the inner tunnel, only EAP-Message.

> (6)     } # authorize = updated
> (6)   ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject

  Since that "if" condition didn't match, the Auth-Type wasn't set, and the server can't authenticate the user.

  The problem is that the test isn't doing TTLS + PAP.  It's doing TTLS + some EAP method.  It's impossible to authenticate EAP with google LDAP.  You must use PAP.

  Reconfigure the test / client device to do TTLS + PAP, and it will work.

  Alan DeKok.