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

[Matt H]

>> 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.

This is very useful information; thank you, Alan.

/mh

On Wed, Jul 9, 2025 at 4:25 AM Alan DeKok via Freeradius-Users <
freeradius-users at lists.freeradius.org> 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
>


-- 

Death before dishonour,
Nothing before coffee