google_ldap and google-ldap-auth

[Wessel Louwris]

Hi,

We also have a google workspace with a lot domains, although not several levels. The problem is (I think) that you need to bind with LDAP with the right base domain, otherwise ldap gives the wrong results.
You can test that with command line ldapsearch. Not sure if that’s caused by google’s implementation of LDAP or that’s a general thing.

If you search in the mailing groups around march 22 this year you will find some questions by me answered by Nick.
With his suggestions I ended up with the following config:


root at freeradius01:/etc/freeradius# cat mods-config/domains/domains
d1.nl     Base-DN1 := “d1", Base-DN2 := "nl"
d2.nl  Base-DN1 := “d2", Base-DN2 := "nl"
d3.com     Base-DN1 := “d3", Base-DN2 := “com”
…

root at freeradius01:/etc/freeradius# cat mods-enabled/domains
files domains {
        # Search for files in a subdirectory of mods-config which
        # matches this instance of the files module.
        moddir = ${modconfdir}/${.:instance}

        # The default key attribute to use for matches.  The content
        # of this attribute is used to match the "name" of the
        # entry.
        key = "%{Stripped-User-domain}"

        filename = ${moddir}/domains
}


in my inner tunnel (based on the google ldap sample file) I used:

	domains # in the authorize section
	if (&User-Password && !control:Auth-Type) { 
		 update control { 
			 Auth-Type = ldap_google 
		 } 
		 update request { 
			 &Base-DN1 := control:Base-DN1 
			 &Base-DN2 := control:Base-DN2 
		 }


and my ldap google module file is based on the caching version has something like this:

        user {
                #  The typical Google LDAP configuration has users under "ou=Users..."
                #base_dn = "ou=Users,${..base_dn}"
                base_dn = "ou=Users,dc=%{Base-DN1},dc=%{Base-DN2}"

                filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})"

                scope = 'sub'
        }


Hope this helps. If needed I can send you our config.

(We are currently still testing with the enrollment of the wifi. For MacOS for example you need to enroll a profile, because the GUI does not support TTLS+PAP (see the notes in the start of the google ldap module file).
But when that’s done it seems to work fine till now.)

We did not implement custom parameters yet. 

regards, Wessel
	

> Op 19 jun. 2023, om 18:21 heeft Federico Santulli <federico.santulli at nhm.it> het volgende geschreven:
> 
> Hi Alan,
> 
> i've the need to recover a custom parameter from Google LDAP to be given back in the request accept.
> 
> How could i achieve this?
> 
> Also, is it possible to dynamically authenticate multiple 3rd level dc's with just one google_ldap_module configuration?
> 
> I mean, is it possible to authenticate both
> 
> test.domain
> ext.test.domain
> 
> Kind regards.
> 
> Federico
> 
> Il 19/06/23 16:34, Alan DeKok ha scritto:
>> On Jun 19, 2023, at 8:45 AM, Mathias Maes <mathias.maes at maerlantatheneum.be> wrote:
>>> Thanks for your reply. Disabling the "filter_inner_tunnel' policy does
>>> indeed work.
>>   That's good.
>> 
>>> I am rather sure I didn't deliberately enable it and rechecked. But It was
>>> enabled in the example configuration script, check here on Github:
>>> https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/raddb/sites-available/google-ldap-auth
>>   That file says it's meant for the inner-tunnel authentication.  i.e. for TTLS or PEAP.  So it should be used as-is with minor edits, rather than copying bits and pieces of it to another virtual server.
>> 
>>   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