google_ldap and google-ldap-auth
Hello I am trying to get google-ldap-auth working in conjuction with google-ldap. I have enabled the site and the module, also enabled cache-auth and ldap. Configured google-ldap with the right credentials. I changed as little as possible to the Google config (no groups, custom attributes, etc) freeradius -X starts without errors. I have not altered the default or inner-tunnel sites. I keep the example user 'bob" with password "hello" enabled to check if I did not mess anything up. radtest bob hello 127.0.0.1 0 testing123 is working. radtest mathias.maes@maerlantatheneum.be mypassword 127.0.0.1:18123 0 testing123 fails. It seems that "User-Name" is required for tunneled authentication. But on the second line of the logs, User-Name is available. and if(&User-Name) returns TRUE However, if (!&outer.request:User-Name || !&User-Name) returns TRUE, I'm not a software developer, but it seems that the User-Name is missing from the outer.request. So my question is, how to test the outer.request.User-name with radtest? Or if I understand the logs totally wrong: Any ideas on what might be happening? Thanks a bunch. Error log: (1) Received Access-Request Id 171 from 127.0.0.1:43929 to 127.0.0.1:18123 length 102 (1) User-Name = "mathias.maes@maerlantatheneum.be" (1) User-Password = "mypassword" (1) NAS-IP-Address = 127.0.1.1 (1) NAS-Port = 0 (1) Message-Authenticator = 0x50109b513ed143e12cacfa804d48b950 (1) # Executing section authorize from file /etc/freeradius/3.0/sites-enabled/google-ldap-auth (1) authorize { (1) policy filter_username { (1) if (&User-Name) { (1) if (&User-Name) -> TRUE (1) if (&User-Name) { (1) if (&User-Name =~ / /) { (1) if (&User-Name =~ / /) -> FALSE (1) if (&User-Name =~ /@[^@]*@/ ) { (1) if (&User-Name =~ /@[^@]*@/ ) -> FALSE (1) if (&User-Name =~ /\.\./ ) { (1) if (&User-Name =~ /\.\./ ) -> FALSE (1) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) { (1) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) -> FALSE (1) if (&User-Name =~ /\.$/) { (1) if (&User-Name =~ /\.$/) -> FALSE (1) if (&User-Name =~ /@\./) { (1) if (&User-Name =~ /@\./) -> FALSE (1) } # if (&User-Name) = notfound (1) } # policy filter_username = notfound (1) policy filter_inner_identity { (1) if (!&outer.request:User-Name || !&User-Name) { (1) if (!&outer.request:User-Name || !&User-Name) -> TRUE (1) if (!&outer.request:User-Name || !&User-Name) { (1) update request { (1) Module-Failure-Message = "User-Name is required for tunneled authentication" (1) } # update request = noop (1) [reject] = reject (1) } # if (!&outer.request:User-Name || !&User-Name) = reject (1) } # policy filter_inner_identity = reject (1) } # authorize = reject (1) Using Post-Auth-Type Reject (1) # Executing group from file /etc/freeradius/3.0/sites-enabled/google-ldap-auth (1) Post-Auth-Type REJECT { (1) attr_filter.access_reject: EXPAND %{User-Name} (1) attr_filter.access_reject: --> mathias.maes@maerlantatheneum.be (1) attr_filter.access_reject: Matched entry DEFAULT at line 11 (1) [attr_filter.access_reject] = updated (1) if (&control:Auth-Type == ldap) { (1) ERROR: Failed retrieving values required to evaluate condition (1) update control { (1) &Cache-TTL := 0 (1) } # update control = noop (1) cache_ldap_user_dn: EXPAND %{Stripped-User-Name} (1) cache_ldap_user_dn: --> (1) cache_ldap_user_dn: ERROR: Zero length key string is invalid (1) [cache_ldap_user_dn] = invalid (1) } # Post-Auth-Type REJECT = invalid (1) Delaying response for 1.000000 seconds Waking up in 0.3 seconds. Waking up in 0.6 seconds. (1) Sending delayed response (1) Sent Access-Reject Id 171 from 127.0.0.1:18123 to 127.0.0.1:43929 length 20 Met vriendelijke groet Mathias Maes ICT-Coördinator Maerlant Atheneum
On Jun 19, 2023, at 2:59 AM, Mathias Maes <mathias.maes@maerlantatheneum.be> wrote:
I am trying to get google-ldap-auth working in conjuction with google-ldap.
Be aware that the google systems are *slow*. i.e. they might take 1/2 second to respond. This is likely deliberate on their end.
I have enabled the site and the module, also enabled cache-auth and ldap. Configured google-ldap with the right credentials. I changed as little as possible to the Google config (no groups, custom attributes, etc) freeradius -X starts without errors.
That's good.
I have not altered the default or inner-tunnel sites. I keep the example user 'bob" with password "hello" enabled to check if I did not mess anything up.
radtest bob hello 127.0.0.1 0 testing123 is working.
That's good.
radtest mathias.maes@maerlantatheneum.be mypassword 127.0.0.1:18123 0 testing123 fails. It seems that "User-Name" is required for tunneled authentication.
You have enabled the "filter_inner_identity" policy. I don't know why. That filter is only for tunneled authentication methods like TTLS or PEAP. If you read the debug log, you'll see that it's already running the "filter_username" policy. So adding another filter isn't helpful. If you read the "filter_inner_tunnel" policy (raddb/policy.d/filter), you'll see how it operates. If you follow the documentation in "man radiusd", you should be using a slow and methodical approach to changing the configuration. In which case things would start breaking as soon as you added the the "filter_inner_identity" policy. At which point you know exactly what is wrong. Reading the documentation and configuration would then be useful. All of this is extensively documented, and the unlang policies are all available to be read.
So my question is, how to test the outer.request.User-name with radtest? Or if I understand the logs totally wrong: Any ideas on what might be happening?
Don't create a broken configuration. You can't just blindly follow some random third-party documentation. You have to understand what you're trying to do, and how the server works. I will also note that you didn't say which documentation you followed. It certainly wasn't any documentation we created. None of our documentation says to add "filter_inner_identity" to the "default" virtual server. There's no magic here. Just use the default configuration, enable the "ldap" module and point the ldap module to the google servers. It *will* work. If you're following "Official google" documentation on how to get this to work, then don't. Their documentation is garbage. I've been trying to get them to fix it for years, but why would they listen to me? They're google. They're so smart that they don't care about anyone else. Alan DeKok.
participants (2)
-
Alan DeKok -
Mathias Maes