On Jul 8, 2025, at 1:36 PM, Taylor Gorman <taylorgorman@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@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@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.