On Feb 25, 2023, at 9:12 AM, Davide G. M. Salvetti <salve@salvelab.it> wrote:
I'm trying to understand how to authenticate users with Google Secure LDAP service. I'm not sure I understood how to do it.
It's an LDAP server with very poor performance. :(
I perused and configured mods-available/ldap_google, tried to adapt sites-available/default as per instructions there, enabled mods cache_auth, ldap_google, enabled sites default and google-ldap-auth, disabled site inner-tunnel.
That should be OK.
Since sites-available/google-ldap-auth is declared designed to be used an inner virtual server, I renamed the virtual server as "inner-tunnel".
There's already an "inner-tunnel" virtual server. That should be used. You should edit the existing "inner-tunnel" file to have it use the google LDAP instead of the existing "ldap" module. i..e. that virtual server gives examples of using normal ldap. You can change that to use Google.
I'm not sure: did I understand it right? What's the proper way to enable google-ldap-auth? Am I supposed to set virtual-server in mod eap instead?
No. The existing "inner-tunnel" virtual server does a lot more than just LDAP. You'll need it to do EAP types like TTLS and PEAP.
Local radtests of the inner-tunnel seems to be successful (see log request (1)), but WiFi Enterprise EAP tests are not. I tried different protocols with a Windows laptop and an Android phone; please see the enclosed freeradius -X log, where I deleted with [...] some AP Access-Request with Service-Type = Call-Check which I think aren't relevant and anonymized test.user and my.domain.
I tried to read the log, but I'm not so fluent with FreeRADIUS; could you please point me my mistakes?
Look for "error" (24) eap_ttls: (TLS) EAP Done initial handshake (24) eap_ttls: (TLS) recv TLS 1.2 Alert, fatal unknown_ca (24) eap_ttls: (TLS) The client is informing us that it does not recognize the CA used to issue the server certificate. Please update the client so that it knows about the CA. You've also made a lot more changes: (10) cache_auth_reject: EXPAND %{md5:%{Calling-Station-Id}%{Stripped-User-Name}%{User-Password}} (10) cache_auth_reject: --> 121c59099e4669281d3507bece52be45 (10) cache_auth_reject: No cache entry found for "121c59099e4669281d3507bece52be45" (10) [cache_auth_reject] = notfound (10) if (ok) { (10) if (ok) -> FALSE (10) if (&User-Password && !control:Auth-Type) { (10) if (&User-Password && !control:Auth-Type) -> FALSE (10) } # authorize = updated (10) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject and then PEAP fails with: (11) eap_peap: Received EAP-TLV response (11) eap_peap: ERROR: The users session was previously rejected: returning reject (again.) (11) eap_peap: This means you need to read the PREVIOUS messages in the debug output (11) eap_peap: to find out the reason why the user was rejected (11) eap_peap: Look for "reject" or "fail". Those earlier messages will tell you (11) eap_peap: what went wrong, and how to fix the problem (11) eap: ERROR: Failed continuing EAP PEAP (25) session. EAP sub-module failed So you've made large and drastic changes to the configuration files, without really understanding what you're changing or why. Don't do that. Go back to the default configuration. It works. Debug one thing at a time. Read https://github.com/FreeRADIUS/freeradius-server/blob/master/doc/antora/modul... Add a user name and password in the "users" file (mods-config/files/authorize). Get TTLS / PEAP working. Ignore Google LDAP until TTLS and PEAP work with the users file. Only then should you go ahead to configuring Google LDAP. You can't debug a complex set of protocols by changing six things, and then hoping it works. The only way to do it is in pieces. Take a slow and methodical approach, and it will work. That way you can also ask questions about each individual thing, and not post a debug output with 5 different kinds of authentication... Alan DeKok.