Google LDAP Authentication for WIFI Setup issues

[Wessel Louwris]

Hi,

We got RADIUS + Google Workspace working after some experiments.
Due too google LDAP limitations only TTLS with inner PAP is possible indeed. Which you cannot select on MacOS + iOS

We use an MDM to provision these profiles but I think you can also use Apple Configurator to create such profiles

I used https://ermitacode.com/eaptest/ (commercial tool) to debug/test our configuration, from there we found out how to configure the needed profiles.	

regards, Wessel


> On 8 Nov 2024, at 18:48, Joseph Allen <joseph.l.allen at gmail.com> wrote:
> 
> Hey,
> 
> You're right I'm making changes I don't understand, but I'm learning as I'm
> going. This is my first try at using FreeRadius.
> 
> When I said I added the default server back in, I meant I added the base
> configuration of the default back in, without any changes to it.
> 
> Since last night, I did the same with the google_ldap virtual server and
> mods.
> 
> I then went in and updated EAP TTLS to point to the google_ldap, and set
> TTLS as the default in the eap file.
> 
> I still ran into issues with trying to connect my iPad, and that is where I
> realized it is the stupid iOS that's the problem. You said to make sure the
> client is TTLS, but iOS doesn't have a basic way to set the authentication
> to TTLS, it defaults to TLS. I switched to my android phone, and selected
> TTLS and boom, it worked right away.
> 
> I'm now investigating ways to get Apple to play nice, but I doubt I'll find
> anything there.
> 
> At least FreeRadius is working now, so thanks for all your help.
> 
> On Fri, Nov 8, 2024 at 2:14 AM Alan DeKok <aland at deployingradius.com> wrote:
> 
>> On Nov 8, 2024, at 2:16 AM, Joseph Allen <joseph.l.allen at gmail.com> wrote:
>>> Thanks, I feel like that got me moving in the right direction. My mistake
>>> before I removed the default was not recognizing/understanding the
>>> google-ldap-auth was a virtual server / tunnel.
>> 
>>  That file is in the directory for virtual servers, and starts with a
>> "server" block.  So,..
>> 
>>  Your previous message made it clear that your approach was to change all
>> kinds of things, without really being clear on how things worked, or what
>> was going on.  This approach is guaranteed to *increase* confusion, and to
>> cause problems.
>> 
>>> I put the default back in, and removed the "inner-tunnel" from the
>>> sites-enabled.
>> 
>>  Why?
>> 
>>  The concern here is that you're just making random changes without
>> understanding why you're making those changes, or what impact those changes
>> have.
>> 
>>> Then updated mods-enabled/eap virtual_server to point to
>> google-ldap-auth.
>>> I also renamed the virtual server to "google-ldap-auth" to match the file
>>> name...that one bugged me and made me spend 15 minutes chasing down why
>> it
>>> couldn't find the virtual server.
>> 
>>  Or just read the start of the file, where it says "server google-ldap",
>> but OK...
>> 
>>> I also updated the default->authorize->ldap section to this:
>>>       ldap_google
>>> 
>>>       #
>>>       #  If you're using Active Directory and PAP, then uncomment
>>>       #  the following lines, and the "Auth-Type LDAP" section below.
>>>       #
>>>       #  This will let you do PAP authentication to AD.
>>>       #
>>>       if ((ok || updated) && User-Password && !control:Auth-Type) {
>>>               update control {
>>>                       &Auth-Type := ldap
>>>               }
>>>       }
>> 
>>  Yeah, that won't work.
>> 
>>  Why?  You made a bunch of changes without understanding how EAP works.
>> You've also *not* done what Matthew suggested.
>> 
>>  When you make changes,, instead of making massive changes all at once,
>> make ONE change at a time.  A SMALL change.  Test it, and then move on to
>> the next change.
>> 
>>  This is the process which is recommended in the documentation.  See "man
>> users".
>> 
>>  When you change 15 things at the same time, and it breaks... you have no
>> idea what's broken,  This is a a guaranteed way to waste large amounts of
>> time.
>> 
>>> It's now doing a lot more, but still basically failing in the same spot
>> on
>>> the IF statement looking for a password. Here's the full log:
>> 
>>  Because the inner-tunnel for PEAP also uses EAP.  And you've "helpfully"
>> butchered the inner-tunnel configuration, so that it doesn't use the "eap"
>> module.  Which means that PEAP won't work.
>> 
>>  This is, in fact, exactly the same problem you had before.  Matthew
>> explained this.  Go back and read his message.
>> 
>> 
>>  But even fixing that issue won't help.
>> 
>>  Why?  Go read the top of the google-ldap-auth file.  It explains very
>> clearly that it's for EAP-TTLS with PAP.  If you're doing PEAP, then there
>> *is no password* in the inner tunnel.  Because PEAP doesn't send one to
>> FreeRADIUS.
>> 
>>  Which means that using PEAP with Google LDAP is impossible,  I could
>> explain, but there isn't much point.  It's impossible, and nothing you do
>> will make PEAP work with Google LDAP.
>> 
>>  Configure the client to use EAP-TTLS with PAP.  Then try configuring the
>> server to use google LDAP.
>> 
>>  Alan DeKok,.
>> 
>> -
>> List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
>> 
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html