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@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@deployingradius.com> wrote:
On Nov 8, 2024, at 2:16 AM, Joseph Allen <joseph.l.allen@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