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

[Taylor Gorman]

Mr. Alan,

Thank you very much for your assistance. With the information you 
provided to me, along with the kind support of another user, I was able 
to discover that MacOS does not support PAP authentication by default. I 
was able to resolve this client side issue by using an MDM profile.

Now, I will be moving on to learning how to configure freeradius to 
accept users from a primary domain and a subdomain. I will also be 
configuring freeradius to allow or deny access to multiple different 
SSIDs depending on the user's LDAP group membership.

If I run into any trouble, I will reach out again.

With all my thanks and gratitude,

Taylor Gorman

On Wed 09 Jul 25 07:17, Alan DeKok via Freeradius-Users wrote:
> 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.
> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html