question about google workspace with multiple domains

[Nick Porter]

On 20/03/2023 19:03, Wessel Louwris via Freeradius-Users wrote:
> But now for each domain freeradius will create a connection pool with some binds to google (start pool=5).	
> So my question is: will we run into issues for creating 5 * 30 connections to google in freeradius?

To avoid a hard dependency on the LDAP server being up / reachable for 
FreeRADIUS to start, it is often best to have

start = 0

in pool definitions - unless FreeRADIUS needs to read something from 
that source in order to start (typically SQL databases where the nas 
table is in use for clients lists)

This would stop FreeRADIUS from launching 5 x 30 connections at startup, 
but rather connections would ramp up as required.

> Maybe we are doing it all wrong and there's a much smarter configuration possible?
> I included the debug log below (with a domain1.nl <http://domain1.nl/>, domain2.com <http://domain2.com/> after some replacements).

If the server and admin authentication details are the same for all the 
domains then you could potentially have

base_dn = ''

at the top level, and then inside the user section have

base_dn = "cn=Users,%{Base-DN}"

Where Base-DN is a custom attribute you define in the local dictionary 
and then populate based on the user's realm.  The most efficient method 
to do that is likely to be an instance of the files module keyed off the 
realm, since that is a hash lookup, though you could do a bunch of if 
statements to test the principle.


If, however, any of the admin authentication details differ between the 
domains then you are stuck with having multiple instances of the ldap 
module.


> Slightly unrelated question: we now deploy the CA certificate via our mdm, as per the documentation as far as I understood, but the user still needs to approve the server certificate (which makes sense)
> Is it safe to deploy the server certificate also to make it easier for our users, or is this a very bad idea.

If the user is being prompted to accept the server certificate that 
suggests that something is not quite right about the deployment of the 
connection.

Ideally the deployment should plant on the client the trust anchor 
(typically whatever signed the server certificate) which it is to accept 
for the connection along with the association between that trust anchor 
and the connection.  Deploying the server certificate may cause issues 
when you need to re-issue the server certificate which is likely to be 
more often than the trust anchor.

-- 
Nick Porter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20230320/c34b55a6/attachment.sig>