Tag: workspace

Sendo uma alternativa ao ambiente Microsoft, o Google Workspace também conta com um serviço de diretório. O LDAP seguro pode ser usado para autorização e autenticação de usuários. O FreeRADIUS foi usado para implementar autenticação WPA2-Enterprise na rede Wi-Fi, com um detalhe: a autenticação precisava funcionar para 2 domínios de e-mail diferentes, de dois ambientes Google Workspace independentes.

Enquanto a autenticação com AD no FreeRADIUS é feita através do método de desafio e resposta, MSCHAPv2, o LDAP seguro do Google não implementa esse protocolo e precisa que a senha do usuário seja enviada em texto pleno dentro de um túnel SSL. Isso pode ser feito com a combinação de protocolos EAP-TTLS/PAP. Diferente do EAP-TLS, que exige o par de certificado/chave tanto do cliente quanto do servidor, o EAP-TTLS exige o par apenas do servidor.

O servidor utilizado foi o Ubuntu 24.04 mas o processo serve também para outras versões. Primeiro passo é criar o cliente LDAP no Google Workspace. No console de administrador, vá em Apps > LDAP > Adicionar Cliente

Atribua as permissões necessárias para o cliente:

Em seguida, baixe os certificados e ative o serviço.

Agora, preparando o servidor FreeRADIUS:

# apt install freeradius freeradius-ldap

Diferente do CentOS, o Ubuntu já gera os certificados pro TLS automaticamente no processo de instalação.

Diferentes clientes podem ser adicionados no arquivo /etc/freeradius/3.0/clients.conf em blocos do tipo:

client roteador0 {
	ipaddr = 56.125.2.213
	secret = senhaNoPost-it
	require_message_authenticator = yes
	shortname = rt0
}

Transfira o par de certificado/chave baixado do Google Workspace para o servidor, armazenando-os em /etc/freeradius/3.0/certs/google/, onde já é esperado pelo FreeRADIUS nas configurações a se seguir.

Partindo para os arquivos de configuração, a começar pelo LDAP, fazendo uma cópia do arquivo para cada ambiente Workspace:

# cp -a /etc/freeradius/3.0/mods-available/{ldap_google,ldap_workspace0}
# cp -a /etc/freeradius/3.0/mods-available/{ldap_google,ldap_workspace1}

Edite o arquivo, adicionando ou alterando as linhas:

ldap ldap_workspace0 {
    identity = 'nomeDeClienteObtidoNoGoogleWorkspace'
    password = 'senhaDeClienteObtidaNoGoogleWorkspace'
    base_dn = 'dc=dominio0,dc=com'
    user {
        filter = "(mail=%{%{Stripped-User-Name}:-%{User-Name}})"
    }
    certificate_file = /caminho/do/cert/cliente/ldap
    private_key_file = /caminho/da/chave/cliente/ldap
}

Faça o mesmo para ldap_workspace1. Habilite os módulos com:

# ln -s /etc/freeradius/3.0/mods-available/ldap_workspace0 /etc/freeradius/3.0/mods-enabled/

No arquivo /etc/freeradius/3.0/mods-enabled/eap, adicione ou altere as seguintes configurações:

eap {
  default_eap_type = ttls
  ttls {
    default_eap_type = pap
  }
}

Caso tenha alterado os certificados a serem usados, você também vai precisar editar as configurações referentes a isso no bloco de configurações comuns de TLS.

Você pode comentar outros módulos não utilizados, como TLS, PEAP e MSCHAPv2, deixando apenas as configurações comuns de TLS e o bloco do TTLS.

O arquivo /etc/freeradius/3.0/sites-enabled/default tem diversas opções, muitas podem (e devem) ser desabilitadas. Edite os blocos authorize e authenticate para que fiquem como abaixo:

server default {
  authorize {
    filter_username
    preprocess
    eap
    expiration
    logintime
  }
  authenticate {
    eap
  }
}

No arquivo /etc/freeradius/3.0/sites-enabled/inner-tunnel, edite os mesmos blocos, adicionando a condicional para os dois domínios:

server inner-tunnel {

  authorize {
    filter_username

    if ("%{User-Name}" =~ /@dominio0\.com$/) {
      ldap_workspace0
      update control {
        Auth-Type := ldap_workspace0
      }
    } elsif ("%{User-Name}" =~ /@dominio1\.com$/) {
      ldap_workspace1
      update control {
        Auth-Type := ldap_workspace1
      }
    } else {
      reject
    }

    expiration
    logintime
  }

  authenticate {
    Auth-Type ldap_workspace0 {
      ldap_workspace0
    }
    Auth-Type ldap_workspace1 {
      ldap_workspace1
    }
    Auth-Type PAP {
      pap
    }
  }

}

Terminando a edição dos arquivos, você deve reiniciar o serviço para que as configurações tenham efeito, garantindo antes que todos os arquivos pertencem ao usuário e grupo freerad.

# chown -hR freerad:freerad /etc/freeradius
# systemctl restart freeradius.service

Caso necessário, você pode testar o FreeRADIUS em modo debug parando o serviço e executando-o manualmente da seguinte forma:

# freeradius -X

Uma funcionalidade interessante é a de atribuir uma VLAN específica dependendo da unidade organizacional do usuário no Google Workspace.

Para isso, basta utilizar blocos desse tipo dentro do bloco de post-auth:

if (&Client-Shortname == "rt0" && &User-Name =~ /@dominio0\.com$/i) {

    if (&control:LDAP-UserDN =~ /ou=RECURSOS HUMANOS/i) {
        update outer.session-state {
            Tunnel-Type := VLAN
            Tunnel-Medium-Type := IEEE-802
            Tunnel-Private-Group-Id := "2"
        }
    }
}

Nesse caso, a melhor abordagem foi usar a condicional considerando o cliente do RADIUS e o ambiente Workspace porque os dois ambientes podem ter UOs diferentes e VLANs com IDs diferentes.

Como se pode ver pelo sinal =~ a checagem da UO não é exata e o mesmo nome poderia ser encontrado em outra UO, o que pode fazer com que a VLAN errada seja atribuída a um usuário.

Uma forma mais adequada de atribuir uma VLAN seria, ao invés de usar as unidades organizacionais do Workspace para determinar a VLAN diretamente, usar as unidades organizacionais para atribuir usuários a grupos dinâmicos como rh-wifi@dominio0.com que então vão ser verificados pelo FreeRADIUS da seguinte forma:

if (LDAP-Group == "cn=rh-wifi,ou=Groups,dc=dominio0,dc=com") {
    update outer.session-state {
        Tunnel-Type := VLAN
        Tunnel-Medium-Type := IEEE-802
        Tunnel-Private-Group-Id := "2"
    }
}