Google LDAP Authentication for WIFI Setup issues

[Alan DeKok]

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