# Bem-vindo à Base de Conhecimento do UserAuth Este é o Manual On-line do Administrador UserAuth. Se você já é usuário ou quer conhecer mais sobre a nossa solução, este é o lugar certo. O [**UserAuth**](https://conexti.com.br/userauth) é um pacote exclusivo desenvolvido pela [**ConexTI**](https://conexti.com.br) que pode ser utilizado em qualquer servidor (físico ou virtual) rodando a plataforma de [Firewall pfSense® CE](https://pfsense.org). Ele é distribuído por meio de uma [Licença Anual de Uso](/primeiros-passos/licenciamento) que inclui **suporte técnico** sob o escopo da ferramenta e **garantia de continuidade (atualizações)** durante a sua vigência. O UserAuth possui recursos avançados de autenticação e controle de usuários da rede local, incluindo [autenticação transparente com PDC](/configurando-o-seu-userauth/escolha-as-suas-autenticacoes/integrando-userauth-com-dc-ad-windows) (Active Directory ou SAMBA), [Social Login (Facebook e Google)](/configurando-o-seu-userauth/escolha-as-suas-autenticacoes/opcoes-de-autenticacoes-avancadas/social-login-com-o-facebook) para redes públicas, [Auto-Cadastro para redes Wi-Fi](/configurando-o-seu-userauth/escolha-as-suas-autenticacoes/autenticacao-com-recurso-de-auto-cadastro), e [**muito mais...**](/configurando-o-seu-userauth/escolha-as-suas-autenticacoes) Na camada de controle, Firewalls com o UserAuth podem filtrar, bloquear ou permitir conexões à internet diretamente, **sem a necessidade de um proxy** intermediário. Graças ao seu inovador [Filtro DNS](/configurando-o-seu-userauth/escolha-o-seu-filtro-de-acesso/filtro-dns-com-bind) e a possibilidade de criar [Regras Avançadas de Firewall](/regras-de-firewall/regras-com-grupos-de-usuarios-do-userauth), nunca foi tão **simples** e **eficiente** aplicar políticas de acesso a aplicativos como Netflix, YouTube, WhatsApp, Conteúdo Adulto, etc.. Além disso, aprimoramos significativamente a funcionalidade de [Logs de Firewall](/configurando-o-seu-userauth/escolha-o-seu-filtro-de-acesso/filtro-dns-com-bind/relatorios-de-acesso-do-userauth/relatorios-de-acessos) como *feature* do UserAuth. Agora, os administradores podem obter registros detalhados de usuários autenticados, incluindo conexões estabelecidas ou negadas, em tempo real. **Sem se limitar as conexões HTTP/HTTPS**, este recurso proporciona uma visão abrangente do comportamento dos usuários na Internet. # Boas práticas de hardware e software Para a implementação da ferramenta UserAuth sugerimos que sejam seguidas algumas boas práticas no ambiente pfSense®. São configurações e parametrizações para que a ferramenta tenha o melhor desempenho em todos os seus recursos. **ZFS:** É um sistema de arquivos muito mais sofisticado usado pelo pfSense®, que proporciona maior performance para o UserAuth, já que a ferramenta não utiliza banco de dados e grava **tudo em arquivos (inodes) em disco**.

**Discos sólidos (SSD e M.2):** Quando implementada a feature de webfilter num servidor pfSense®, você invariavelmente vai ter muitos processos de escrita e leitura (I/O) ocorrendo simultaneamente. São arquivos de logs e listas negras ou customizadas que precisam ser manipuladas a todo instante. Justamente por isso, utilizar discos SSDs ou ainda outros dispositivos de alta performance (como mSata, por exemplo) faz uma grande diferença na percepção de performance do server como um todo. **Tunings:** Quando você utiliza servidores genéricos para o pfSense® (sejam de fabricantes usuais como HPE, DELL, IBM, Lenovo dentre outros ou ainda hardwares x86 ‘montados’) muitas vezes é necessário efetuar alguns tunings sugeridos pela própria Netgate® e que estão na [documentação oficial do pfSense®](https://docs.netgate.com/pfsense/en/latest/book/hardware/hardware-tuning-and-troubleshooting.html) basta consultar os que se aplicam respectivamente ao seu cenário. # Licenciamento O UserAuth é um software comercial distribuído sob uma licença anual de uso, com exceção da versão community (gratuita para uso em cenários com até 8 conexões/usuários simultâneos). Todos os direitos são reservados a [ConexTI®](https://conexti.com.br/). A contabilização de licenças se dá pelo **NÚMERO DE DISPOSITIVOS SIMULTANEAMENTE AUTENTICADOS** no UserAuth. **Exemplo 01:** Uma rede em que temos 10 usuários e cada um deles utiliza apenas 1 dispositivo (seu notebook): Vamos precisar de 10 licenças do UserAuth; **Exemplo 02:** Uma rede em que temos 10 usuários e cada um deles utiliza apenas 2 dispositivos (seu notebook e celular): Vamos precisar de 20 licenças do UserAuth; **Exemplo 03:** Uma rede em que temos 10 usuários, dos quais 3 usam 2 dispositivos (seu notebook e celular) e os demais usam apenas um dispositivo: Vamos precisar de 13 licenças do UserAuth; **Exemplo 04:** Uma rede em que temos 20 usuários, cada um utiliza apenas seu PC, mas se dividem em 2 turnos, ou seja, 10 usuários durante o dia e 10 usuários durante a noite: Vamos precisar de 10 licenças do UserAuth (pq simultaneamente temos apenas 10 usuários em cada turno). **NOTA:** Todos os demais softwares citados neste documento, seguem suas próprias licenças de uso e distribuição. Para saber mais sobre cada um deles, visite os respectivos sites. # Instalando o UserAuth no pfSense® O UserAuth é um pacote extraoficial (não presente na árvore nativa de pacotes do pfSense®) que para ser instalado no servidor precisa de algumas dependências. Não se preocupe, nosso time deixou o processo de instalação bem simplificado e didático. Preparamos patchs e demais pacotes auxiliares para facilitar o trabalho do administrador de redes. Você só precisa se atentar para a cronologia das instalações, que DEVE OBRIGATORIAMENTE SEGUIR a seguinte ordem: 1. Executar o script: Automatiza a preparação do ambiente para os pacotes ConexTI® e já faz a instalação automaticamente. ## **Executando Script ConexTI®.** Este script automatiza a configuração inicial do ambiente (aplicando patch, adicionando repositórios adicionais), deixando todo o ambiente pronto para receber as ferramentas da ConexTI®. ``` fetch -q -o - "https://e-sac.websiteseguro.com/wmi/cnti_setup.txt" | sh ``` Basta executa-lo na própria shell (Opção 8) do pfSense® ou através do menu **Command Prompt (Diagnostic -> Command Prompt)** da interface web. É necessário aguardar cerca de 3 minutos (tempo aproximado até finalizar o processo de instalação automática em background).

O script instalará todos os pacotes necessários para a sua completa utilização. Para verificar, basta acessar o menu: "**System -> Package Manager -> Installed Packages".** Podemos observar nas imagens abaixo os pacotes instalados.

Caso esteja faltando algum pacote das imagens acima, você pode instalar de forma manual seguindo o padrão feito normalmente no pfSense®. Basta se dirigir até o menu "**System *****->***** Package Manager *****->***** Available Packages"** e selecionar os pacotes faltantes

Após realizar os passos acima o ambiente estará pronto você desfrutar de todas as funcionalidades do UserAuth e demais pacotes auxiliares no seu servidor pfSense®, é possível observar o rol de ferramentas que já fazem parte do seu ambiente. Basta acessar: "**System *****->***** Package Manager *****->***** Installed Packages"** # Ativação da ferramenta UserAuth ## **ConexTI License Manager** O CLM (ConexTI License Manager) é o equivalente a “central do assinante” para os clientes que adquiriram licenças dos pacotes desenvolvidos pela ConexTI®. Ele tem por objetivo centralizar todas as informações sobre o licenciamento dos pacotes, bem como, a validação do e-mail corporativo de contato. A partir do ConexTI License Manager é possível requisitar o TRIAL (versão ilimitada para período de testes) de quaisquer uma das ferramentas, visualizar o status do licenciamento e eventuais logs resultantes deste processo. **IMPORTANTE:** O endereço eletrônico precisa ser um e-mail corporativo (não gratuito, como Gmail ou Hotmail, por exemplo). **O funcionamento e a ativação são muito SIMPLES:** * **1) Informe os dados** da sua instituição. * **2)** Clique em **"save".** * **3)** Volte ao formulário e clique em **"Validate E-mail".** ConexTI License Manager

Em seguida será encaminhado um e-mail automático para validação das informações. Basta acessar a sua caixa de correio (observe a caixa de SPAM também) e clicar sobre o link encaminhado. Isso irá validar os dados que você forneceu na etapa anterior.

Após acessar o link encaminhado: * **Clique em:** Refresh ConexTI License Info O ConexTI License Manager mudará automaticamente seu status para **"E-mail Verificado"**, exibindo as informações da instituição e endereço eletrônico configurado

Uma vez que o seu e-mail corporativo esteja validado, você poderá requisitar a versão TRIAL do(s) respectivo(s) pacote(s). Esta é também a indicação para clientes que adquiriram sua **Licença Anual** e desejam ativá-la de forma definitiva. Basta requisitar a versão TRIAL do pacote e depois contatar nosso time pelo e-mail **** fornecendo o Netgate ID do servidor pfSense®.

#### **Opções Avançadas** Em cenários onde eventualmente a estabilidade ou a taxa de transmissão dos links WAN estejam degradados por quaisquer motivos é muito possível que tenhamos problemas com tempo de resposta do servidor de licenciamento. Isso pode gerar erros na ativação dos produtos. Para resolver esta questão, as opções abaixo permitem ajustes finos no tempo limite para as conexões.

## **Importante:** Em ambientes onde o Firewall é instalado em virtualizadores (ESXi, HyperV, Proxmox e entre outros), é importante se ater à eventuais mudanças na máquina virtual (mover a VM para outro host ou trocar a placa de rede virtual, por exemplo), pois esta ação poderá resultar na alteração do Netgate ID do pfSense®. Isso afetará o licenciamento dos pacotes com Licença Anual ou ativados no modo TRIAL, já que o processo de ativação é baseado neste código único. Nesta situação não se preocupe, basta entrar em contato conosco pelo e-mail **** informando seus dados e seu Netgate ID anterior, que iremos efetuar os devidos ajustes. # Alteração do NetGate ID do Seu Equipamento Essa página foi criada para explicar qual o procedimento padrão **quando você já possui o UserAuth ativo com a sua licença**, mas por algum motivo o **"Netgate Device ID"** do seu equipamento sofreu uma alteração. A ativação do UserAuth é feita com base no **"Netgate Device ID"** do equipamento, conforme o exemplo:

## Verificação do Cadastro 1. Siga até a página de licenciamento do UserAuth: **Services -> ConexTI license package -> General** 2. Verifique se os dados estão corretos, importante não adicionar caracteres especiais/acentuação, somente números e letras, a exemplo da imagem abaixo:

## Solicitando a Versão Trial da Ferramenta Seguindo as opções abaixo temos **"UserAuth Package Status"** Nesse ponto basta clicar em **"Request UserAuth Trial"**

**Repita o mesmo procedimento acima, mas agora para o NGRules.** **Caso tenha outras licenças,** como por exemplo a VPN2FA, **também ative a versão trial.** **Pronto**, agora o seu **UserAuth/NGRules/VPN2FA** estão ativados de **forma TRIAL** ilimitada por 15 dias, portanto todas as funcionalidades voltaram ao pleno funcionamento. ## Solicitando a Ativação da Sua Licença **Somente após a ativação da versão trial será possível deixar a sua ferramenta com a licença adquirida.** Após a ativaçã acima descrita, envie o quanto antes um e-mail para **""** informando que o seu equipamento teve uma alteração no **"Netgate Device ID".**

**Pronto**, **agora é só aguardar** o retorno da nossa equipe informando que o seu equipamento foi **ativado com a sua licença**. # Configuração Padrão # Habilitando UserAuth Agora vamos iniciar a configuração do seu UserAuth, importante salientar que a ordem das configurações não são lineares, mas não se preocupe com isso, você será direcionado(a) a cada passo. Acesse o UserAuth e siga até a aba **"General": Services -> UserAuth Integration -> General** **Enable:** Inicialmente vamos marcar essa opção para ativar a ferramenta. **Idle Timeout:** Nesse campo vamos habilitar o tempo em que o usuário vai permanecer autenticado, após passar a quantidade informada o UserAuth fará uma nova checagem para identificar se o usuário ainda está ativo na rede ou não: * Caso ainda esteja, uma nova autenticação vai ocorrer, permanecendo assim por mais "4h" horas. * Caso não, o usuário será desconectado, liberando assim uma licença. Observação: Por padrão deixamos em 4 horas, mas pode ser definido conforme a necessidade de sua empresa.

## **Configurações de Captive Portal** O UserAuth possui um captive portal integrado, ele é configurado na guia **"Captive portal integration mode"**, pode ser definido o modo de integração utilizando as seguintes opções: * ***None:*** C*aso você possua uma lista de AD, e as maquinas não identificadas ficam com uma configuração básica.* * **Forward:** Essa opção utiliza o **captive portal** do próprio UserAuth, que é o **padrão mais usado na integração com o BIND ou E2GUARDIAN**, para que caso ele não consiga identificar o dispositivo, ele gere um **portal captive**, dessa forma o usuário pode digitar o seu login de acesso (Definido nos próximos passos deste manual) * **Pull and Push:** Quando selecionada, integra-se com a instância do Captive Portal nativo do pfSense®.

## **Configuração CP UserAuth** No final da página temos as seguintes modificações a serem aplicadas ainda nesse módulo: * **Captive portal source:** Caso utilizado a opção "Pull from pfSense captive portal" deve ser selecionado o portal nativo já configurado em seu pfSense que será exibido na lista. * **Captive url Prefix:** Quando configurado **no modo *****Forward***, é necessário efetuar a configuração do local onde estará encaminhando o trafego, nesse caso será o próprio IP da LAN (pfSense®). * **Redirect page:** Após o usuário realizar o seu login utilizando o **captive portal do UserAuth,** podemos configurar um redirecionamento de uma página para este primeiro acesso, podendo ser o site da instituição.

# Métodos de Autenticação Ainda na aba General do UserAuth: **Services -> UserAuth Integration -> General** A ferramenta possui diversas formas de autenticação de usuários. Podemos realizar isso de forma independente com uma base local, bases externas e LDAP, ou através de integração com outras plataformas, conforme a necessidade. Escolha e marque quais tipos de autenticação você gostaria de utilizar.

**Aqui temos os três modelos de autenticação mais utilizados e recomendados:** * **Local - Pfsense GUI Authentication:** Autenticação de usuários locais do pfSense®. * **Local - UserAuth Local Users Authentication:** Autenticação de uma [base local](/configurando-o-seu-userauth/escolha-as-suas-autenticacoes/autenticacao-com-base-de-usuarios-locais-do-userauth) de usuários criados diretamente no UserAuth. * **Local/LDAP - PfSense Configured Local/Ldap login Server(s):** Autenticação de usuários de uma base LDAP, pode ser configurado no campo de "*Backend for local/ldap authentication"*. **Tipos avançados de autenticação:** * **OpenVPN - OpenVPN authenticated users/common names:** [Autenticação de usuários de tuneis VPN](/configurando-o-seu-userauth/escolha-as-suas-autenticacoes/autenticando-usuarios-vpn) dentro do pfSense®. * **WMI to Client - Send a wmi request to client:** Autenticação de usuários utilizando o método [WMI de consulta](/configurando-o-seu-userauth/escolha-as-suas-autenticacoes/opcoes-de-autenticacoes-avancadas/configuracao-do-wmi-no-userauth). * **URL - Autenticate users on external url:** Autenticação de uma [base externa](/configurando-o-seu-userauth/escolha-as-suas-autenticacoes/opcoes-de-autenticacoes-avancadas/autenticacao-em-banco-de-dados-corporativos-atraves-de-url-webservice). * **Oauth2 - Autenticate users whith OAuth:** Autenticação utilizando a integração com o padrão do protocolo [OAuth 2.0](/configurando-o-seu-userauth/escolha-as-suas-autenticacoes/opcoes-de-autenticacoes-avancadas/integrando-com-o-padrao-oauth2). * **Facebook - Autenticate users Facebook:** Integração com o [Facebook](/configurando-o-seu-userauth/escolha-as-suas-autenticacoes/opcoes-de-autenticacoes-avancadas/social-login-com-o-facebook) para autenticação com usuários da plataforma. * **Google - Autenticate users Google:** Integração com o [Google](/configurando-o-seu-userauth/escolha-as-suas-autenticacoes/opcoes-de-autenticacoes-avancadas/social-login-com-o-google) para autenticação com usuários da plataforma. * **Packet Fance - Integrate Whith Opensource NAC:** Integração com uma base NAC. # Personalização do Captive Portal do UserAuth ## Configurando o Captive Portal do seu jeito A tela de Captive Portal do UserAuth onde o usuário fará a autenticação é totalmente personalizável, de acordo com o seu ambiente e necessidade, nela é possível adicionar a logo da instituição, mudar o título da página, tamanho da imagem, entre outros. Para realizar essa personalização, basta acessar a página principal de configuração do UserAuth pelo caminho: **Services -> UserAuth Integration -> General -> Captive portal page customizations**

Nos campos acima é possível aplicar a personalização dos seguintes itens do Captive Portal da ferramenta UserAuth: * **Título da Página (Page Title):** Título que será mostrado na aba do navegador quando aberto o Captive Portal; * **Tamanho da Imagem (Image Size):** Tamanho do ícone que será utilizado na tela do Captive Portal; * **Mensagem de Login (Login Message):** Mensagem que poderá ser utilizada para informar o que poderá ser utilizado para efetuar login através do Captivel Portal. Ex: “Entre com suas credenciais de aluno”; * **Exibir informações de Licenças (Show License info):** Aqui, poderá ser escolhido entre exibir ou não a licença da ferramenta UserAuth atribuida a instituição; * **Logo Personalizada (Custom logo):** Para adicionar a imagem da logo do Captive Portal, basta adicionar o código base64 (método de codificação para transferências na internet, utilizando apenas texto), conforme [RFC4648](https://tools.ietf.org/html/rfc4648). Para facilitar na descrição do campo adicionamos o link de um conversor online; * **Fundo Personalizado (Custom Backgroud):** Personalização do fundo de tela do Captivel Portal da ferramenta. Esta imagem deve ser adicionada em formato base64(método de codificação para transferências na internet, utilizando apenas texto), conforme [RFC4648](https://tools.ietf.org/html/rfc4648). Para facilitar na descrição do campo adicionamos o link de um conversor online; * **Ícone Personalizado (Custon Icon):** Personalização de um ícone para a aba do navegador que esta sendo utilizado para abrir o CP. Novamente esta imagem deve ser adicionada em formato base64(método de codificação para transferências na internet, utilizando apenas texto), conforme [RFC4648](https://tools.ietf.org/html/rfc4648). Para facilitar na descrição do campo adicionamos o link de um conversor online; * **Login Text:** Altera a informação do campo interno, onde o usuário digita o seu login; * **Desativar direitos Autorais (Disable Copyright):** Desabilitar as informações de autoria da pagina do Captive Portal; * **Cor do Texto (Text Color):** Personalização de cor no texto do Captive Portal; * **Custom Multiple CP:** É possível criar multiplos Captive Portals de forma personalizada para redes diferentes, utilizando a integração com wispr. Para mais detalhes sobre a configuração acesso o link clicando [aqui](https://conexti-com-br.gitbook.io/userauth/configurando-o-seu-userauth/escolha-as-suas-autenticacoes/opcoes-de-autenticacoes-avancadas/multiplos-captive-portal). ## Captive Portal do UserAuth personalizado Ao aplicar essas configurações, o Captive Portal da ferramenta UserAuth exibirá a personalização desejada quando acessado pelos usuários.

# Termo de acesso ## Termo no captive portal do UserAuth Continuamos na aba "General" do UserAuth: **Services -> UserAuth Integration -> General** É possível exibir um termo para acesso a rede, sem o aceite do usuário ele não poderá fazer o login. **Enable**: Marque essa opção para ativar.

Esse termo, caso configurado, estará disponível para todos os usuários que se autenticarem pelo **captive portal do UserAuth**.

# Configurando origem de grupos Continuando na configuração do modo *Forward*, temos a opção "***Integration source settings"*****.** Nestas opções, serão definidas as configurações de grupo onde os usuários serão alocados após a autenticação. * **User's group(s) location:** Define qual a origem dos grupos. * **Local Userauth groups (default):** Quando será utilizado os grupos do UserAuth. * **Active Directory groups + E2guardian:** Configuração aplicada quando o UserAuth esta integrado com o AD buscando os grupos de lá e integrado com o serviço de proxy E2Guardian. * **Active Directory groups + Local Userauth groups:** Configuração aplicada quando utilizado grupos do AD e grupos do UserAuth. * **E2guardian groups:** Quando integrado com E2guardian e alimento os grupos diretamente no proxy. * **LDAP groups + E2guardian:** Opção utilizada na utilização na integração de um DC Samba e serviço de proxy E2guardian. * **LDAP groups + Local Userauth groups:** Configuração quando a consulta deve acontecer em grupo de um DC Samba e integrado apenas com UserAuth.

OBS: Quando o nome dos grupos definidos ultrapassar 15 caracteres é recomendado a utilização da descrição para identifica-los, para isso poderá ser necessário alterar a configuração dos campos: * **Group name source:** Esta opção determina onde procurar o nome do grupo AD. Útil quando os nomes de grupos do Active Directory têm mais de 15 caracteres. * **Alias name source:** Esta opção determina onde procurar o nome do grupo AD. Útil quando os nomes de grupos do Active Directory têm mais de 15 caracteres ou possuem caracteres não permitidos no nome alternativo. Imagem com as opções já alteradas para busca via "descrição"

# Escolha as Suas Autenticações # Autenticação com base de usuários locais do UserAuth Esta funcionalidade na ferramenta UserAuth possibilita a autenticação de usuários cadastrados na própria ferramenta, sendo vantajosa para ambientes onde não se encaixam em outras formas de autenticação, como Active Directory ou qualquer base LDAP/Externa. Para que essa base local seja consultada, você precisa selecionar na aba "Gerenal" do UserAuth em “**Autentication source”** a opção **"Local – UserAuth Local Users Authentication".** [**Saiba mais clicando aqui**](/configurando-o-seu-userauth/configuracao-padrao/metodos-de-autenticacao)

## **Cadastrando os Usuários Locais** Para iniciar navegue até: **Services -> UserAuth Integration -> Local Users** **Add:** Para criar um novo usuário é muito simples, basta clicar na opção "add" conforme a imagem abaixo.

Preencha os campos solicitados conforme a descrição de cada um: Importante não utilizar caracteres especiais.

Primeiramente, é necessário ativar o usuário, selecionando a opção "Enable". * **Username**: Identificador dos usuários dentro da ferramenta. * **Full Name**: Nome completo/descrição do usuário. * **Email**: Endereço de e-mail deste usuário, este campo é opcional para a configuração. * **Password**: Senha utilizada para este usuário se autenticar pelo Captive Portal do UserAuth. * **User Cel Phone Number:** Esse campo é utilizado para autenticação via SMS * **Enable MFA authentication:** Determina se o usuário precisa realizar o MFA ao autenticar utilizando SMS ou Voucher. **OBS**: O segundo fator de autenticação quando ativo será exigido somente para usuários que sejam de auto cadastro. * **Expire date**: Possibilidade de adicionar uma data limite em que este usuário ficará ativo. Após a data mencionada, ele não validará a autenticação. * **Extra fields:** Campos a mais para o usuário ter a opção de cadastro na hora do Captive Portal. * **User Type**: Refere-se à forma de cadastro de usuários. * *Normal User*: Usuários criados manualmente por um cadastro simples feito pelo administrador da rede. * *Self Registration User*: Usuários criados pelo formulário de "Auto cadastro" disponível na rede. * **Enable Mac Authentication**: Quando ativada esta funcionalidade, permite a autenticação do usuário de forma automática sem a utilização do Captive Portal, apenas cadastrando o MAC address dos dispositivos daquele usuário. * **MAC Addresses**: Campo para cadastro dos respectivos endereços MAC do usuário, possibilita a adição de vários, sempre um por linha.

**Exportar Usuários Cadastrados** Usuários cadastrados localmente na ferramenta têm a opção de exportar a lista em formato CSV. Para isso, basta acessar a guia **"General"** do **UserAuth**, descer até a opção "**Local login Options"** e clicar em **"*****Export local Users Info to CSV"***.

## Testando o Seu Novo Usuário Local do UserAuth. **IMPORTANTE:** Para dar início ao teste do usuário criado é importante já ter feito os passos acima explicados nessa página, bem como todas as ativações e registros referente ao UserAuth. Com o usuário já criado conforme a imagem, vamos conectar na rede onde o Captive Portal está ativo:

Nesse ponto vamos inserir o usuário e senha criado, e clicar em **"Aceitar os termos e continuar"**

Após a validação do usuário o mesmo será autenticado e você será direcionado para a página configurada anteriormente no UserAuth, nas opções de [personalização do Captive Portal](/configurando-o-seu-userauth/configuracao-padrao/personalizacao-do-captive-portal-do-userauth).

Podemos acessar a aba **"Active Sessions"** do UserAuth para visualizar o usuário autenticado.

Pronto, toda a configuração necessária foi feita e temos o usuário criado/autenticado. # Autenticação com Recurso de Auto Cadastro A feature de Auto Cadastro do Captive Portal do UserAuth foi desenvolvida para que os usuários da rede possam ter autonomia de se auto cadastrarem no servidor pfSense®, com base no seu CPF, por exemplo, sem qualquer necessidade de interação com o administrador do firewall. Ela possibilita aplicarmos parâmetros que identificam os usuários na rede, conforme preconizam as boas práticas em segurança da informação e os marcos regulatórios **(Marco Civil da Internet e LGPD)**, bem como, aplicam políticas específicas de acesso à Internet a este perfil de utilizador **(Através de ACLs do Webproxy e/ou regras de firewall)**.

## Ativando a Função Auto Cadastro Para que esta funcionalidade seja ativada no seu ambiente basta navegar na dashboard principal do UserAuth e ir até: **Services -> UserAuth Integration -> General -> Captive portal Self Registration.** **Self Registration:** Selecione a opção **"Allow local userauth login self registration".**

Agora que temos a função do auto cadastro ativa, vamos iniciar a personalização, possibilitando cada instituição modelar conforme sua necessidade e vontade. **Self Registration user type**: Define qual a forma de autenticação você poderá ser utilizar no ambiente. ***CPF Only:*** Login utilizando unicamente o CPF ***Any word, name, latter ou digit sequence:** A*utenticação aberta, portanto pode ser utilizado nome, palavras aleatórias ou números.

**Self Password reset**: Opção utilizada para possibilitar a redefinição da senha cadastrada pelo usuário. Ela diz se o usuário poderá redefinir sua senha previamente cadastrada e qual a forma de fazer isso (um link é encaminhado para o e-mail informado no auto cadastro).

**Password reset temp group**: Essa opção deve conter um grupo do E2Guardian criado onde terá permissão suficiente para acessar site de serviços de e-mail, assim possibilitando que o mesmo consiga ler a nova senha que recebeu. Na prática, quando a pessoal clica em "resetar" ela se autentica com usuário temporário por alguns minutos para conseguir a senha. Importante ter um grupo [previamente criado](/configurando-o-seu-userauth/escolha-o-seu-filtro-de-acesso/filtro-dns-com-bind/grupos-de-acesso-do-userauth) para poder utilizar essa opção.

**Restrict Alias**: Esta opção pode ser utilizada caso queira restringir a funcionalidade de Auto Cadastro do Captive Portal do UserAuth para algumas redes específicas do seu ambiente. Para isso, essa opção deve conter um Alias com os ranges IPs das redes que o auto cadastro de usuários é permitido no seu ambiente.

**Restrict logon**: Uma vez que os usuários tenham se auto cadastrado em uma ou mais das redes permitidas (Restrict Alias), você pode seguir com a restrição de logon (login pelo Captive Portal do UserAuth) a essas mesmas redes. Isso evita que um usuário auto cadastrado na rede "visitantes", por exemplo, possa se logar (se autenticar) na rede "administrativa".

**Force group**: Nesta opção, você força o usuário do auto cadastrado, uma vez logado no Captive Portal do UserAuth a ingressar em um grupo específico. Isso permite definir ACLs padrões (listas de acesso à web) para qualquer usuário pertencente a este perfil (que tenha se auto cadastrado).

**Self registration MAC address**: Quando ativada, esta opção permite que a ferramenta registre o endereço MAC do dispositivo que fez o cadastro. Isso fará com que, em um próximo acesso nesta rede, este dispositivo se autentique de forma transparente/automática com o CPF cadastrado anteriormente.

**Expire Days**: Possibilita a configuração de número de dias que o usuário auto cadastrado ficará ativo/configurado no firewall. Este tempo de expiração é atualizado a cada nova autenticação na ferramenta.

**Remove Self registration**: Opção para remoção de usuário auto cadastrado de acordo com o tempo configurado no campo *Expire Days*.

**Extra Fields**: Aqui você pode adicionar novos campos que gostaria de ter ativo na opção de auto cadastro. * **Field name**: É o texto que será exibido no campo; * **Field description**: É o ID do campo, não pode ser usado letras maiúsculas e nem espaço entre as palavras. * **Requeired**: Se o campo é de preenchimento obrigatório. * **Input type**: Se o campo deve possuir tratamento, sendo os tratamento para somente permitir preenchimento de números, somente de letras ou sem nenhum tratamento.

# Integrando o pfSense® com base LDAP do AD Utilizando essa integração você será capaz de autenticar o usuário criado no **"Active Directory (AD)"** diretamente no "**captive portal"** do UserAuth. ## Configuração inicial Navegue até: **System -> User Manager -> Authentication Servers** Nesse local vamos adicionar uma nova configuração, clique em **"Add"**

Adicione um nome que você consiga identificar no futuro que é relacionado a integração, cuidando apenas para não ter caracteres especiais.

**Hostname or IP address:** Adicione o endereço IP do seu Servidor AD.

Na próxima imagem temos mais alguns ajustes: **Base DN:** Inicialmente adicionamos a árvore inteira, com a nossa base local, que é o lab.local. **Authentication containers:** Os containers adicionamos apenas os usuários "CN=Users".

**Bind anonymous:** Deixamos essa opção desmarcada, pois vamos utilizar as credenciais do AD**.** **Bind credentials:** Adicione o login do AD que contenha as permissões de administrador. **Exemplo:** lab.local\administrador ou **Initial Template:** Marcar a opção "Microsoft AD" para a integração.

Agora vamos clicar na opção **"Select a container"**.

Várias opções serão exibidas na tela, aqui será necessário selecionar/marcar onde estão alocados os seus usuários. **Observação importante:** Caso você deixe de selecionar uma **"OU - Unidade Organizacional"** e nela um usuário está alocado, o mesmo não poderá fazer **login no "Captive Portal"** utilizando seu cadastro no AD.

Após preencher os dados acima citados, configuramos os parâmetros UTF-8 e salvamos

## Habilitar servidor para consultas Agora vamos realizar um teste, siga para aba ao lado em "Settings" ou "Configuração" (Depende do idioma) e selecione o servidor de autenticação que acabamos de criar, nesse caso da imagem "AD". Clique em **"salvar e testar"** ou **"Save & Test".**

Com toda a configuração correta, o teste exibirá as informações das OUs do seu servidor AD.

## Executando testes Vamos efetuar o teste agora com uma maquina virtual Linux, nesse ponto temos em mente que as configurações acima já estão testadas e portanto corretas. Lembrando que na tela da autenticação do UserAuth, configuramos: [**"Captive portal Setting":**](/configurando-o-seu-userauth/configuracao-padrao/habilitando-userauth) Forward - Send Unidentified users to UserAuth Captive Portal

[**"Authentication source":**](/configurando-o-seu-userauth/configuracao-padrao/metodos-de-autenticacao) Marcamos o LDAP - pfSense Configured Local/Ldap login server(s)

[**"Backend of local/ldap authentication":**](/configurando-o-seu-userauth/configuracao-padrao/metodos-de-autenticacao) Selecionamos a base LDAP configurada anteriormente para buscar as autenticações

Verificados os parâmetros, podemos efetuar o teste acessando a máquina virtual que está fora do AD. Percebemos então que, mesmo com as configurações locais do AD, ele abre a tela da autenticação.

Utilizamos para fazer login um usuário de teste criado no AD "luoliveira"

Autenticou e liberou o acesso a internet conforme esperado.

# Integrando UserAuth com DC AD Windows ## **Configurando o UserAuth com AD e domínio** ### Pré-requisitos Para que a integração do UserAuth com o AD funcione corretamente deve-se tomar alguns cuidados principalmente referente ao logs. **O AD deve estar gerando corretamente** os eventos de **ID 4624, 4634 e 4769**, para verificar isso você deve acessar o **"Visualizador de Eventos do Windows"**, na aba segurança e pesquisar os eventos acima citados.

Também deve-se verificar se os serviços de logs do servidor estão rodando. Para isso basta acessar a tela de Serviços e verificar:

Com relação aos grupos de acessos criados para acesso a internet, o escopo do grupo deve ser **"Global"** ou **"Universal"**, caso seja criado como **"Dominio Local"** a ferramenta não conseguirá identifica-lo na integração.

## Adicionando integração com Active Directory Agora vamos efetuar a configuração dos acessos através do Active Directory do Windows. Inicialmente ativamos o server de domínio, e verificamos suas configurações para poder atribui-lo nas configurações do UserAuth.

Em seguida basta acessar a aba de ***Domains*** no UserAuth e adicionar as configurações do controlador de domínio.

Atribuímos então a configuração do nosso server de domínios no domínio do UserAuth.

## Integração utilizando o Cliente ConexTI [A partir de 14 de março de 2023, as atualizações do Windows Server](https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c) não permitirão mais consultas externas via WMI. Portanto, em sistemas que possuam os patches mais recentes do Windows, será necessário instalar o cliente ConexTI para garantir a integração e autenticação transparente dos usuários que ingressam no domínio. O processo é simples: primeiro, altere a opção **WMI client version** nas opções avançadas da ferramenta para ***User WMI Remote Agent*** , clique em salvar.

Em seguida faça download do cliente no seu servidor Windows que roda a feature de Active Directory utilizando o botão **"*****Download windows Client"*** presente na aba de **Opções Avançadas** na aba **General** do UserAuth.

Para realizar a instalação, comece descompactando o arquivo **".zip"** e, em seguida, execute o arquivo **"ConexTI\_Integration\_Service.exe"**. Assim que o cliente for iniciado, avance para a primeira tela de introdução.

Após isso, será exibida a tela de configuração do **IPv4 do Firewall pfSense®**. É para este IP que o cliente ConexTI vai encaminhar os logs de autenticação dos usuários do Active Directory. Tenha certeza sobre qual é o IP do seu Firewall pfSense para que a integração entre o seu Microsoft AD e o Proxy rodando no pfSense aconteça de forma correta.

Após inserir o endereço IP do pfSense®, clique em **"Gravar Configuração"** para que o instalador inicie o processo de instalação do cliente e a configuração inicial. Após alguns segundos, o processo será concluído e você será solicitado a finalizar a instalação.

**`IMPORTANTE:`**` ``Quando configurado o CIS (ConexTI Integration Service) no servidor AD, é importante que o serviço WPAD esteja rodando no servidor pfSense®. Caso contrario, serão exibidos logs de TimeOut POST por conta da validação de acesso que o CIS executa. Além disso, após a instalação e configuração do CIS no seu Active Directory, será necessário realizar o restart do PHP no servidor pfSense® (utilizando a opção 16 da Shell).` `Outra situação importante é garantir que haja uma regra de firewall no seu servidor pfSense® aceitando conexões destinadas à ele mesmo vindas do Active Directory que possui o CIS instalado.` ## Configurando Origem dos Grupos Para que a ferramenta UserAuth pesquise os usuários e alimente os grupos de forma automatizada com base no AD, basta selecionar no campo ***User's group(s) location*** a opção **"Active Directory groups"**.

## Verificando integração Podemos verificar que já está comunicando com o server e o UserAuth através da aba logs, verificando que nenhum membro de cliente foi encontrado, e que o usuário Administrador já está logado.

## Bloqueando Logs Como o UserAuth efetuará uma busca no AD a cada 10 minutos, conforme nós configuramos, os logs de acesso do administrador tendem a se repetir, toda vez que a mesma é efetuada, dessa forma, nós podemos bloquear estes logs com a configuração na aba "**Exception**" adicionando o usuário no campo de "**Ignore accounts**".

## Grupos dentro do AD Criamos grupos e usuários dentro do AD.

Podemos verificar que os usuários já aparecem como encontrados nos logs do UserAuth.

Também na guia Active Session podemos verificar que os usuários já aparecem ativos e que o usuário admin criando anteriormente e o marcelloc estavam ainda ativos, visto que cada sessão dura 4 horas.

## Desconectando Usuários Então vamos forçar a desconexão das sessões.

## Fazendo logon dentro do dominio Agora vamos forçar o logon da conta do Marcelloc no domínio.

Podemos verificar que assim que logado, dentro dos logs do UserAuth já aparece as informações de logon.

Também nas sessões ativas ele já trouxe a sessão de Marcelloc como ativa novamente.

Efetuando o teste de navegação podemos verificar que o mesmo continua navegando.

## Aplicando aliases Agora vamos duplicar a regra de acesso para avaliar trafego, antes configuramos um alias de portas para auxiliar.

Duplicamos a regra e configuramos como operação agora, dando acesso somente ao nosso alias web.

E duplicamos a regra novamente, liberando o trafego agora de ICMP, unicamente para verificarmos o trafego.

E então colocamos nossa máquina virtual para pingar e vamos analisar o trafego.

## Testando acessos Como meu perfil do AD está em ambos os grupos, está gerando trafego somente no suporte (por a regra estar por primeiro solicitando a utilização).

Mesmo com a regra liberando a conexão através do grupo suporte, os acessos são concedidos através da ordem de configuração do E2Guardian, validando somente o primeiro grupo configurado, nesse nosso caso o operacao, grupo mais limitado.

Como os nossos grupos estão sem o filtro de autenticação SSL liberado, verificamos que o site retorna em erro.

E tentando acessar um site sem certificação SSL, podemos perceber que ele retorna com a tela de bloqueio (por estar reconhecendo o grupo operação).

## Ativando interceptação SSL Agora vamos liberar o filtro SSL para o grupo.

E vamos liberar o acesso aos sites no e2guardian.

Tentando acessar o site com certificado, ele já solicita a instalação do certificado.

Agora podemos acessar o firewall para efetuar a liberação do certificado, este que podemos acessar agora da própria VM.

Liberado e baixado o mesmo, podemos importar para o browser.

Agora ele já reconheceu o certificado instalado e está indo para a tela de bloqueio.

Como possuímos somente o site da ConexTI® e as mídias sociais, podemos efetuar o teste, verificando que ele está acessando e gerando o certificado.

# Autenticando usuários VPN ## Pré-requisitos Inicialmente precisamos que as conexões passem pelo firewall, para isso é preciso configurar o servidor VPN para que force a saída para a internet pelo firewall.

## Configurando Interface É preciso assinar uma interface para a conexão VPN. Esta interface deve estar ativa e com regras de acesso configuradas conforme qualquer outra interface.

## Configuração no UserAuth Para que o UserAuth entenda essa autenticação é necessário selecionar o método na página inicial de configuração da ferramenta.

Com esta opção ativa o UserAuth fará a leitura dos usuários ativos no servidor VPN e alocará os mesmo nos seus respectivos grupos.
# Opções de Autenticações Avançadas Aqui disponibilizamos algumas autenticações que são avançadas e necessitam de uma atenção e diversos pré-requisitos! Importante ter o máximo de cuidado antes de adentrar a essas opções. # Autenticação em banco de dados corporativos atraves de URL/webservice ## Selecionando metodo de autenticação Inicialmente efetua-se a alteração do método de autenticação do captive portal na guia do UserAuth, adicionando a autenticação externa através de URL.

## Adicionando URL para consulta Também nessa mesma guia, adiciona-se o local da URL externa e o método de envio da senha a essa URL, podendo ser texto puro, ou qualquer hash que comunique com o PHP do server. Inicialmente vamos fazer o teste com texto puro.

## Criando codigo PHP para consulta de usuários No nosso primeiro acesso estamos colocando um portal muito simples em php, com apenas alguns dados de usuários crus mesmo, diretamente na ferramenta, sem conexão ao banco de dados.

## Testando codigo PHP como base de consulta Ao atualizarmos nossa máquina virtual, ele já solicita o novo usuário e senha. Vamos testar com a maria.andrade que se encontra no array do nosso PHP.

O nosso teste autenticou.

Autenticado, já podemos avaliar nas conexões ativas que a usuária "maria.andrade" já está conectada.

Vamos desconectar essa conta e fazer mais um teste com outra conta.

Testamos agora com o usuário **joao.silva**.

O mesmo autenticou perfeitamente também.

Nas sessões ativas, podemos verificar que o joao.silva também já está conectado.

## Integrando banco de dados externo com usuários Agora vamos efetuar a autenticação em um php integrado a um banco de dados **mysql** Inicialmente vou alterar o local da minha página php, e colocar a senha como MD5, formato que ficou na comunicação com o banco.

## Criando banco de dados Nesse mysql criamos um banco simples, com uma tabela de usuários, e a senha em md5.

## Código PHP para integração Para o código .php da página, utilizamos o exemplo pronto no site do próprio php. Efetuando somente os ajustes de conexão necessários.

No nosso caso, estamos utilizando o banco no próprio servidor apache, então configuramos como uma conexão local, que seleciona o banco “hotel”, e fazendo a query com o usuário e senha da tabela cp, retornando somente um ok, para caso ele valide corretamente, e erro para caso não valide.

## Testando autenticação com banco de dados externo Efetuamos o teste com o usuário salvo no nosso banco.

Ele autenticou.

A sessão já está ativa, com essa conexão completa, o funcionamento de todas as outras funções continua exatamente da mesma forma, como a configuração de grupo pelo e2guardian, ou a criação de regras de acesso pelo firewall.

Podemos efetuar, por exemplo, a adição do usuário em um grupo especifico, já criado e configurado com alguns limites de acesso.

Dessa forma, forçando a reinicialização da conexão, podemos avaliar nos logs que o usuário já efetua a conexão dentro do grupo “suporte”, ao qual o adicionamos.

# Autenticação usando redes Sociais ## **Requisitos** Para realizar a integração da ferramenta UserAuth com as redes sociais (Facebook e Google) se faz necessário algumas configurações extras no ambiente. É necessário a utilização de uma URL válida na internet sendo HTTPs, ou seja, é preciso a utilização de um certificado para o domínio. ## Criando um endereço valido na internet. Primeiramente deve-se fazer o pfSense® responder a um domínio valido na internet, criando um redirecionando DNS para seu IP público.\ **OBS: Nesse caso, o uso de DDNS free, não irá funcionar, pois o próprio Facebook não aceite o domínio ao inserir nas configurações do aplicativo a ser criado.** ## Criando e aplicando certificado com ACME Após a criação de um redirecionamento e o seu pfSense® responde corretamente é necessário a criação de um certificado para declarar o Captive Portal em HTTPs. Para isso é necessário instalar o ACME.

## Ativando ACME Primeiramente devemos ativar o ACME.

## Criando chave Processo passo é criar uma chave e registra-la.

## Criando o certificado A partir de então precisamos criar o certificado, para isso, vamos na aba “Certificates” preenchemos os dados, apontamos para nossa chave, criada no passo anterior, adicionamos a URL do Captive Portal.

Aplicamos o comando necessário para que ele reinicie o serviço sempre que o certificado for renovado.

Após isso clique em **“Issue/Renew”**

## Aplicando certificado no pfSense® Acessamos o menu **“System-> Advanced”** e aplicamos o certificado recém criado.

Ao acessar o firewall ou a página de autenticação do UserAuth o mesmo já aparece em HTTPs.

# Social Login com o Facebook ## Selecionando método de autenticação Inicialmente na guia de configuração do UserAuth, devemos configurar o acesso através do Facebook.

## Adicionamos o app ID do Facebook Também abaixo na configuração, definimos um Facebook ID, que pode ser obtido no link de developers do Facebook.

## Configurando app ID no Facebook Na página dos developers, podemos seguir um modelo de configuração comum, utilizado normalmente na web, não esquecendo de configurar as URLs de política de privacidade e de termos de serviço. Ambas as URLs devem ser validas.

E definir a URL do site, essa que deve ser a URL do captive portal.

## Criando liberações de acesso para autenticação Em seguida, podemos criar um grupo de pré-autenticação, onde teremos uma política de acesso a esse grupo já pré-definidas, onde será possível efetuar a autenticação sem problemas, basta clicar no botão indicado como na imagem abaixo:

Podemos também estabelecer um tempo limite para os usuários temporários **(Byspass conn time)**, os quais serão gerados para que possam se autenticar nas redes sociais, junto a política já pré-definida. Ainda será possível ou não, aplicar um grupo após sua autenticação **(Force E2Guardian group)**, com políticas de acessos de sua preferência, ou seja, após esta autenticação bem sucedida, poderemos dizer que este usuários autenticado por redes sociais pertencem a um determinado grupo do webproxy. Como podemos observar, ao clicar na opção acima, automaticamente é criado um grupo e uma ACL no E2Guardian.

Assim é liberado automaticamente os endereços necessários para que seja realizado a autenticação pelas redes sociais. ## Testes com autenticação com Facebook Após configurado, podemos tentar efetuar uma conexão na web através de nossa máquina virtual. Podemos perceber que o mesmo já aparece a opção do Facebook acima.

Quando algum dispositivo tentar realizar a autenticação pelo Facebook ele criará um usuário temporário para que haja conectividade parcial do dispositivo, aplicando as politicas de acesso do grupo criado com botão **“*****Create Social login group and ACL*****”**, liberando apenas o necessário para autenticação.

Esse usuário ficará ativo até o fim da autenticação ou o tempo limite configurado na opção **“*****bypass conn limit*****”** se exceder. Após a autenticação, ele já disponibilizará o acesso através do perfil do Facebook, substituindo o usuário temporário pelo perfil da rede social.

Na guia de conexões ativas, podemos verificar que ele já efetua a conexão do usuário, e quando executada a conexão, a ferramenta, pega o nome e sobrenome do usuário no Facebook, e substitui o espaço por ponto, dessa forma, facilita a criação de regras sobre os usuários que estão conectados.

Também na ferramenta, possuímos a opção de bloquear todos os sites antes da pessoa se autenticar, mesmo que necessite do Facebook para essa autenticação, pois a ferramenta compreende que a conexão está sendo realizada por fora do próprio captive portal. Porém algumas vezes, a liberação por login social acaba dando a liberdade de acesso a rede para muitos usuários desconhecidos, e caso a sua organização seja grande, acaba se tornando inviável avaliar todos os Facebooks e adicioná-los a um grupo, visto que, se a pessoa alterar o nome do Facebook, perde a conexão. Dessa forma foi implementada a opção de moderate login social, dentro do UserAuth.

Assim, quando efetuada a conexão através do "login social", a solicitação de conexão será encaminhada para uma aba de "login social moderation", onde um funcionário, por exemplo, pode efetuar a liberação a partir da solicitação de conexão, dessa forma, a liberação só é efetuada após alguém liberar.

Então vamos testar. Tentando acessar de um site qualquer, já caímos na tela de login pelo Facebook. Ao efetuar a conexão pelo Facebook, ele já efetua a autenticação, e joga para uma tela de aguarde.

Na guia do admin, já recebemos a solicitação de liberação. Vamos efetuar o primeiro teste rejeitando a conexão através.

Com a conexão rejeitada podemos verificar que o site já efetua o retorno a página inicial, informando que ouve a rejeição a conexão.

Dessa forma, ao atualizar a página, ela já nos disponibiliza a conexão novamente. Novamente o social é encaminhado ao moderador, vamos desta vez efetuar a liberação.

Assim que liberado, o usuário já passa a acessar a rede normalmente.

Assim que conectado, o mesmo já aparece nas conexões ativas.

## Banindo usuários por MAC Agora, supondo que você não deseje que haja mais esta solicitação dessa pessoa, depois de várias solicitações negadas, vamos recarregar a nossa conexão e efetuar o banimento da mesma.

Assim que adicionado ao banned, o próprio UserAuth reconhece o MAC Address que está tentando efetuar a conexão e adiciona a guia Banned, essa que libera a opção de banir um MAC ou adicionar algumas contas com o **"nome.sobrenome\@redesocial"**. Por enquanto o pacote possui apenas o Facebook, mas assim que ela possuir outras, as mesmas já podem ser adicionadas.

Assim que banido, a tela do usuário já recebe essa informação. ## Banindo usuários por nome Vamos efetuar a remoção do MAC address da regra de banimento, e agora bloquear o nosso usuário.

Na tela do usuário a opção de acessar com a media social já é disponibilizada, mas quando tentado acessar, o mesmo retorna com o erro, social account banned.

# Social Login com o Google ## Selecionando metodo de autenticação Para a conexão através do login social do Google, deve ser marcada a opção Google da autenticação dos usuários.

## Adicionando Google client ID Também devemos incluir o Google client ID, disponível no console de developers da Google.

Quando adicionado para o acesso através do Google, ele obriga a inserir o "captive url" como "fqdn" (nome do host), e não mais por IP.

## Configuração do App Google Na página dos developers do [**google**](https://console.developers.google.com/apis), podemos seguir um modelo de configuração comum, utilizado normalmente na web, configurando um novo app.

Adicionando as devidas permissões para integração e autorizando a URL do UserAuth e direcionamento para seu CP onde será realizado a autenticação.

Assim que adicionado ele já aparece na opção de login.

Algumas outras opções foram implementadas, como a tradução do menu automático conforme a configuração do SO, por exemplo, na imagem anterior estava sendo utilizado uma SO em inglês, alterando para uma interface em português as opções alteram, deixando somente o botão do Google, que deve ser configurado manualmente na plataforma, e o nome da empresa. ### Criando liberações de acesso para autenticação Em seguida, podemos criar um grupo de pré-autenticação, onde teremos uma política de acesso a esse grupo já pré-definidas, onde será possível efetuar a autenticação sem problemas, basta clicar no botão indicado como na imagem abaixo:

Podemos também estabelecer um tempo limite para os usuários temporários (Byspass conn time), os quais serão gerados para que possam se autenticar nas redes sociais, junto a política já pré-definida. Ainda será possível ou não, aplicar um grupo após sua autenticação, com políticas de acessos de sua preferência, ou seja, após esta autenticação bem sucedida, poderemos dizer que este usuários autenticado por redes sociais pertencem a um determinado grupo do webproxy. Como podemos observar, ao clicar na opção acima, automaticamente é criado um grupo e uma ACL no E2Guardian.

Assim é liberado automaticamente os endereços necessários para que seja realizado a autenticação pelas redes sociais. ### Testando autenticação com o Google Quando algum dispositivo tentar realizar a autenticação pelo Facebook ele criará um usuário temporário para que haja conectividade parcial do dispositivo, aplicando as politicas de acesso do grupo criado com botão **“*****Create Social login group and ACL*****”**, liberando apenas o necessário para autenticação.

Esse usuário ficará ativo até o fim da autenticação ou o tempo limite configurado na opção “*bypass conn limit*” se exceder. Após a autenticação, ele já disponibiliza o acesso através do perfil do Google, substituindo o usuário temporário pelo perfil da rede social. Como estamos com a moderação ativa, ele informa ao moderador.

No portal de moderação ele já informa, da mesma forma que o Google, com nome, sobrenome como perfil do usuário, e solicita a aprovação do usuário.

# Configuração do WMI no UserAuth ## Selecionando método de autenticação no UserAuth Primeiramente deve-se prepara o UserAuth para capturar os usuários WMI e integrar com o proxy, aqui será utilizado o usuário Administrador local para fazer essa integração das maquinas com o UserAuth, para isso ele deverá estar ativo na máquina cliente.

Quando configuramos o método WMI, também podemos definir um tempo que ele aguardará pela resposta do cliente. ## Verificando serviço WMI nas estações Windows Nas estações Windows da rede (Win7, 8 ou 10), é necessário apenas habilitar o serviço nativo WMI, para isso basta acessar e aplicar o devido permissionamento.

Também é necessário efetuar a liberação via firewall do sistema operacional da conexão remota ao serviço. Tudo isso pode ser feito com um simples e único comando, no prompt do MS-DOS: ``` c:\> netsh firewall set service remoteadmin enable custom 192.168.12.1 ``` Onde **“192.168.12.1”** deve ser substituído pelo IP do pfSense®. Isso vai efetuar a liberação do recurso WMI nas estações para consulta remota apenas pelo firewall (o que aumenta o nível de segurança do processo).
# Integrando UserAuth com DC Samba ## **Integração com Controlador de domínio SAMBA** ### Pré-requisitos Para autenticar usuários previamente cadastrados num Servidor PDC SAMBA (com o recurso de **Controlador de Domínio** ativado) no pfSense® com o UserAuth, faz-se necessários alguns pré-requisitos. A maioria das configurações são implementadas no lado do próprio Servidor SAMBA. Abaixo, descreveremos um passo a passo a ser seguido: ### **PASSO 1** O primeiro pré-requisito para usarmos autenticação de usuários no UserAuth através de servidor SAMBA, é verificar a versão do pacote no seu servidor Linux. O formato do arquivo de Log interpretado pelo UserAuth só está disponível a partir do SAMBA 4.10, [conforme documentação oficial](https://www.samba.org/samba/history/samba-4.10.0.html)

Para verificar a versão do pacote SAMBA instalada no seu servidor Linux, basta executar o seguinte comando (logado como root): ``` smbd --version ```

### **PASSO 2** O primeiro passo é verificar no servidor SAMBA se a versão do serviço “smbd” já possui suporte a JSON. Para validar este ponto, basta executar o comando abaixo, conforme a [documentação oficial do próprio SAMBA disponível na internet](https://wiki.samba.org/index.php/Setting_up_Audit_Logging).

``` smbd -b | grep HAVE_JSON_OBJECT ``` Após verificar se o suporte ao JSON está ativado, é necessário ativar o recurso de log incluindo a linha abaixo no arquivo *smb.conf* e reiniciar o serviço do SAMBA.

### **PASSO 3** Neste segundo passo iremos possibilitar ao pfSense® ler os logs do servidor SAMBA. Neste sentido, iremos utilizar o **NFS** – um recurso bem conhecido em servidores Unix-Like. Neste ponto, o pré-requisito é a instalação de alguns pacotes no seu Servidor SAMBA. O exemplo abaixo aborda um exemplo de comando em servidores Debian/Ubuntu Linux: ``` apt install nfs-util nfs-kernel-server ``` **OBS:** O nome dos pacotes pode variar de acordo com versão da distribuição Linux que vocês está utilizando. Após a instalação deve-se parametrizar o arquivo ***/etc/exports***. Esta configuração irá implementar uma ACL permitindo a leitura dos logs somente por intermédio do IP do seu servidor pfSense®.

Neste exemplo o IP “192.168.65.1” é o IP do Firewall pfSense® onde o UserAuth está instalado. Após o procedimento o serviço “NFS” precisa ser reiniciado no seu Servidor SAMBA. Ainda, pode ser necessário (dependendo da configuração atual do SAMBA) alterar a permissão da pasta de logs. ``` chmod +rx /var/log/samba chmod -R +r /var/log/samba ``` **Arquivo de log** O arquivo que é lido pela UserAuth para identificar os eventos de autenticação dos usuários no dominio é o ***/var/log/samba/log.smbd***, caso o samba não esteja encaminhando o log dos eventos para este arquivo deve-se aplicar este parâmetro no arquivo de configuração do serviço e reinicia-lo. ``` log file = /var/log/samba/log.smbd ```

Alem disso, os log gerados pela autenticação podem ser conferidos neste arquivo a cada autenticação. ``` tail -f /var/log/samba/log.smbd ```

## Configurando Integração com SAMBA Com todos os pré-requisitos satisfeitos, basta configurar a integração no UserAuth com o Servidor PDC SAMBA. Acesse a aba *Domains* da ferramenta e adicionar uma nova configuração, preenchendo as informações conforme descrição de cada campo.

Feita a configuração, pode-se acompanhar o status da integração na aba “Logs”. A ferramenta mostrará que foi capaz de montar a unidade remota (NFS) para leitura dos logs. Neste momento, o UserAuth será capaz de identificar automaticamente os usuários que fizerem login nas estações ingressadas no **PDC SAMBA**, da mesma forma como procede com um Servidor Windows Active Directory.

## Alterando origem dos grupos Para configurar/alterar a pesquisa dos grupos de origem dos usuários para o Servidor SAMBA, basta acessar a dashboard inicial da ferramenta UserAurh e selecionar a opção: “*Samba LDAP groups*”.

Leitura dos usuários nos grupos configurados.

# Integrando o pfSense® com base LDAP do Google O serviço LDAP do Google Cloud pode ser usado para autenticar usuários no pfSense®. Para isso, são necessários alguns passos dentro da plataforma afim de habilitar e configurar a função. ## Configurar o aplicativo LDAP no portal do administrador do G Suite. As instruções oficiais podem ser verificadas dentro da [documentação oficial do Google](https://support.google.com/cloudidentity/answer/9048516) ou seguindo os passos abaixo. **OBS: VOCÊ SÓ NOTARÁ A OPÇÃO DE CONFIGURAÇÃO "LDAP" NO SEU PAINEL ADMINISTRATIVO DO GOOGLE, SE A SUA ASSINATURA DO SERVIÇO POSSUIR ESTE RECURSO. CASO CONTRÁRIO, ESTA INTEGRAÇÃO NÃO SERÁ POSSÍVEL.** ### **1. Configuração da chave para integração.** Acessando o painel administrativo da plataforma, basta navegar em **“*****Visão Geral -> LDAP -> Adicionar Cliente*****”**

### **2. Crie o cliente.**

Atribua as permissões necessárias para que a integração seja capaz de ler os usuários, grupos e unidade organizacionais cadastrados no serviço do Google. Após o procedimento clique em **“Salvar”**.

Em seguida será exibido na tela o certificado necessário para a integração com o pfSense. Basta baixa-lo e na sequência adiciona-lo no pfSense (detalhes abaixo). Depois disso, clique em **“Continuar para detalhes do Cliente”**.

Em seguida será necessário adicionar um usuário para integração entre o G-Suite e o pfSense. Para isso, basta clicar em “Certificados” e na sequencia “Gerar novas credenciais”.

O próprio Google gerará um usuário e senha.

## **3. Ativando a configuração para integração.**

Uma vez aplicadas todas estas configurações no G-Suite, podemos nos concentrar nas configurações do pfSense. ## Configuração no pfSense®. Este conteúdo também pode ser encontrado na [documentação oficial do pfSense®](https://docs.netgate.com/pfsense/en/latest/recipes/auth-google-gsuite.html). **Importando o certificado criado no Google** Para adicionar o certificado exportado da plataforma do Google basta acessar “**System -> Cert. Manager -> Certificates**” e clique em adicionar um novo certificado. Informe que o mesmo já existe e gostaria apenas de importa-lo.

Descompacte o arquivo baixado e abra-o com algum editor de texto do seu computador.

Copie o conteúdo do arquivo .crt (certificado) e cole no campo certificado.

Em seguida copie o conteúdo do segundo arquivo .key (Chave) e cole no campo “key data”.

## Instalação e configuração do STUNNEL O Stunnel é um pacote no pfSense® que adiciona uma camada de criptografia à conexões através de recursos do OpenSSL e SSLeay. Este pacote esta nos repositórios oficiais do pfsense, para instalar o pacote basta acessar **“*****System -> Package Manager -> Available Packages*****”**, procure o pacote e efetuar a instalação.

A configuração do pacote é muito simples. Basta acessar **“Services -> STunnel”** e adicionar uma nova configuração: * **Client Mode:** Informando que é um cliente. * **Listen on IP:** IP que fará a conexão. * **Listen on Port:** Porta local. * **Certificate:** Certificado da plataforma do Google e importado no pfSense®. * **Redirects to IP:** IP/hostname da plataforma do Google. * **Redirects to Port:** Porta da plataforma Google LDAPS.

## Configuração da base de consulta LDAP. Para adicionar uma nova base de consulta basta navegar em **“*****System -> User Manager -> Authentication Server*****”** e adicionar uma nova base, aplicando as devidas configurações.

Após a inclusão da base, basta aplicar a configuração de autenticação conforme a base desejada.

# Integrando com o padrão OAuth2 Esta é uma forma de autenticação **para quem já possui o padrão OAuth2** definido para autorização. Como Configuração inicial, basta selecionar dentro do campo *Autentication Source* a opção de **OAuth2 - Autenticate users with OAuth2**.

Em seguida podemos prosseguir com a configuração das opções necessarias para integração.

## Detalhes das opções: **OAuth2 Client Secret:** É uma chave secreta conhecida apenas pelo cliente e pelo servidor de autorização. Esta chave é usada para autenticar o cliente junto ao servidor de autorização durante o processo de obtenção de tokens de acesso. É importante mantê-la segura, já que permite ao cliente provar sua identidade perante o servidor. **OAuth2 external authentication url:** URL onde os usuários são direcionados para inserir suas credenciais e conceder permissão para que um aplicativo acesse seus recursos protegidos. Este é o local onde a autenticação do usuário ocorre. **OAuth2 external validation url:** Será o URL que, após o usuário conceder permissão ao cliente, o servidor de autorização pode redirecionar o usuário de volta para o cliente com um código de autorização. Este código geralmente é trocado por um token de acesso no servidor de autorização. O processo de troca do código por um token geralmente não é chamado de "validação externa", mas sim de troca de código de autorização por um token de acesso. **OAuth2 external token param in redirect url:** URL de redirecionamento do cliente após a autorização bem-sucedida. No fluxo de autorização, após o usuário conceder permissão, o servidor de autorização redireciona o usuário de volta para o cliente com informações como um código de autorização ou um token de acesso anexado à URL de redirecionamento como parâmetros. **OAuth2 Login Identifier:** Qual campo poderá ser utilizado como identificação do usuário dentro da ferramenta. **Force E2guardian group:** Nesta opção, você força o usuário autenticado a ingressar num grupo específico do proxy E2guardian. Isso permite definir ACLs padrões (listas de acesso à web) para qualquer usuário pertencente a este perfil (que tenha se autenticado automaticamente). **Restrict Alias:** Esta opção pode ser utilizada caso queira restringir a autenticação utilizando OAuth 2.0 pelo Captive Portal do UserAuth para algumas redes específicas do seu ambiente. Para isso, essa opção deve conter um Alias com os ranges IPs das redes permitidas no seu ambiente. # Integração com ambientes WTS Ao usar o serviço de área de trabalho remota(RDP), uma instância do sistema operacional do servidor pode servir vários usuários com suas próprias sessões. Como todos os usuários estarão compartilhando a mesma instancia do sistema operacional do servidor, por consequência todos estarão compartilhando o mesmo IP de origem. Nestes casos são necessários efetuar alguns ajustes, de forma que o UserAuth consiga identificar individualmente cada usuário e de fato seja possível aplicar políticas de acesso diferentes. ## Pré-Requisitos Como premissa básica, o sistema operacional que tenha instalado o serviço de área de trabalho remota deve ser 2008 R2 ou superior, pois foi a partir desta versão que a Microsoft implementou o recurso de virtualização de IP. **Ativar a virtualização de IP no servidor WTS** Para ativar este recurso, basta modificar as políticas locais do servidor onde o serviço WTS está ativo. * Abra gpedit.msc * Navegue até "**Configurações do Computador -> Modelos Administrativos -> Componentes do Windows -> Serviço de Área de trabalho Remota -> Host de Sessão da Área de Trabalho Remota -> Compartilhamento de Aplicativos".** Na política **“*****Selecionar o adaptador de rede a ser usado na Virtualização de IP de Área de Trabalho Remota*****”** configure o IP do servidor WTS.

Em seguida configure o recurso **“Ativar Virtualização de IP da Área de Trabalho Remota”**, selecionando “**Por Sessão**”.

Após aplicar, force a atualização das políticas locais utilizando o executar (Sistema+R). ``` gpudate /force ``` Com isso cada sessão remota logada, irá receber um IP diferente obtido pelo DHCP. ## **Adicionando a chave de registro para os LOGs** Para que o UserAuth consiga identificar os eventos dos usuários logados com o recurso de IP virtual é preciso adicionar uma chave de registro no Windows.

**\[HKEY\_LOCAL\_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Microsoft-Windows-TerminalServices-TSAppSrv-TSVIP/Admin]** ### Configurando servidor WTS Com os pré-requisitos cumpridos, basta informar qual servidor WTS será utilizado junto a integração com o AD no UserAuth. Isso pode ser feito através da aba “*Domains*”.

# Múltiplos Captive Portal Caso esteja utilizando a integração com controladoras usando o Wispr você pode estar utilizando a opção de múltiplos captive portals para redes diferentes, cada um com a sua personalização. Navegue até: **Services -> UserAuth Integration -> General -> Captive portal page customizations** **Clique na opção "Goto Configuration"**

Nesse momento você será levado até a página específica para criação do CP.

Para criar basta clicar em **"Add"** **Aqui temos as definições iniciais:**

* **Descrição:** Nome para identificar esse CP * **Filter Type:** Onde será exibido esse CP * **Based on client IP (CDIR):** Utilize o IP de cada dispositivo

* **Bases on URL request Field:** Utilize o MAC do dispositivo

Agora vamos para a personalização exclusiva desse CP, as opções são as mesmas do Captive Portal padrão, para saber mais [**clique aqui**](/configurando-o-seu-userauth/configuracao-padrao/personalizacao-do-captive-portal-do-userauth)

Após o termino da configuração acima citada, clique em **"Save"** e inicie o cadastro do próximo CP utilizando os mesmos passos.

# Integrando com o AD para autenticação via Captive Portal do pfSense ## Selecionando tipo de integração A primeira alteração que devemos fazer é a troca da interação do captive portal com o portal da própria ferramenta (forward), para o pull and push, que é a comunicação com o portal do pfSense® (na questão de interação, principalmente para quem usa AD, a melhor opção é o forward, por ter a possibilidade de efetuar a autenticação por LDAP).

Na verdade ao tentar colocar o pull and push, ele obriga a ter um captive portal do pfSense® configurado.

## Criamos um captive portal

Configuramos ele na LAN

## Tipos de autenticação do Captive Portal Configuramos a autenticação por usuários locais ou voucher, e salvamos, efetuando uma configuração bem simples nele.

## Configurando UserAuth para Captive portal do pfSense® Agora sim, podemos configurar o UserAuth como pull and push, e selecionamos o Captive portal LAB.

## Efetuando testes Agora para efetuarmos os testes vamos matar as conexões existentes dentro do UserAuth, e efetuar um logoff/logon das maquinas virtuais.

Efetuamos o acesso novamente da máquina virtual.

E podemos verificar que nos logs do UserAuth ele já aparece como usuário adicionado e redirecionando para o portal captive do pfSense®

Também no status do captive portal, podemos verificar que o usuário já aparece como logado.

Podemos verificar que como está logado, as páginas já estão carregando.

Já com a máquina virtual Linux, que não está no AD, ao atualizar a página, já é redirecionado para o captive portal do pfSense®.

Para não ter de adicionar os usuários no grupo do captive portal do pfSense®, vamos nas configurações do mesmo e remover a opção que obriga ao usuário estar adicionado, e salvamos.

Agora, com a configuração de acesso de admin do pfSense®, já conseguimos efetuar o acesso.

Verificando no status do Captive portal, já podemos verificar o novo acesso, e como não foi feito pelo AD, ele importa até as informações do MAC Address (em redes grandes, com muitos equipamentos de distribuição de rede, muitas vezes os dados do MAC não são importados).

Verificando nas sessões ativas do UserAuth, podemos verificar que que ambas as conexões estão ativas, e funcionais.

# Integrando com o Wispr O WISPr (Wireless Internet Service Provider roaming) é um protocolo desenvolvido para permitir o roaming de usuários de serviços de internet sem fio. Ele facilita a autenticação e a gestão de conexões em redes Wi-Fi, especialmente em ambientes onde múltiplos provedores de serviços de internet (ISP) estão disponíveis. Para configuração da integração acesse **General -> Wispr integration options.**

Primeiramente, é necessário ativar selecionando a opção "Enable". * **Wispr url fields:** Deve ser informado os campos retornados na requisição do protocolo, em caso de duvidas deve ser consultado o manual do equipamento. * **Force client recoonect after first access:** Em alguns casos, o equipamento exige uma reconexão após a autenticação para liberar a navegação. * **Wifi controller api username/password**: Dados de login para consulta de dados no equipamento. * **Wifi controller api token refresh**: Tempo de refresh para o token de consulta no equipamento. * **Keep mac authentication after session timeout:** Após o timeout, o mac do usuários poderá ser removido da base RADIUS. ## Configurando o RADIUS Para integração entre um equipamento usando Wispr com o UserAuth é necessario instalar e configurar o RADIUS.

Após instalado, acesso pelo menu Services -> FreeRADIUS, acesso o meno NAS/Clients e para configurar clique em ADD.

Para configuração deve informar o IP, username e senha configurados no equipamento.

Em Interfaces, é necessario criar as configurações para as portas usadas para comunicação.

A porta 1812 será usada para autenticação.

A porta 1813 será usado para comunicação.

Realizado esta configurações, as comunicação será realizada e o usuários autenticado no userauth. # Escolha o Seu Filtro de Acesso Nesse ponto precisamos escolher o tipo de filtro a ser utilizado. Importante entender que após a escolha, os caminhos serão diferentes e portanto seguem as suas devidas configurações. # Filtro DNS com Bind # Ativando Filtro DNS com Bind O UserAuth possui a possibilidade de integração com o Bind9, uma ferramenta poderosa para resolução de nomes na internet. Podemos aplicar filtros na camada de DNS, implementando políticas de acesso para [grupos específicos](/configurando-o-seu-userauth/escolha-o-seu-filtro-de-acesso/filtro-dns-com-bind/grupos-de-acesso-do-userauth) configurados no UserAuth. ## Configuração Inicial Para configurar essa integração, basta acessar: **Services -> UserAuth Integration -> General** Navegue até a opção "**Dns/Bind9 Integration Settings"**. **Integrate with Bind9 dns:** Agora vamos ativar a integração, marque a opção **"Enable - Integrate userauth to bind9 package".**

Desça até fim da página e salve as alterações.

Após realizar os passos acima, vamos voltar para o mesmo local e clicar em: **"configure bind package"** Isso aplicará uma configuração básica na ferramenta e ativará de fato a integração.

**Forward blocked sites to:** Configuração para retorno de acesso bloqueado, sempre deve ser mantido o **0.0.0.0**, ou seja o próprio firewall. **Subdomains as wildcard:** Nesse campo você pode indicar o nível de subdomínios que serão verificados. Por padrão, sempre será aplicado o valor 3, que corresponde por exemplo a "**conexti.com.br**", ao selecionar 3, identificará também acessos do nível 2, como por exemplo, **"conexti.com"**.

Logo abaixo, temos alguns atalhos: **Goto DNS Logs**: Se desejar verificar os logs do Bind; **Goto Bind DNS Config**: Verificar a configuração aplicada dentro do Bind. ## Ajustes no Bind Agora vamos realizar alguns pequenos ajustes, navegue até: **Services -> Bind -> Settings** **Altere somente as opções informadas:** **IP Version:** Manter selecionada a opção **"IPv4"**

Agora vamos até o fim da página **DNSSEC Validation:** Manter selecionada a opção OFF. Deixamos em "OFF" para ativar o perfeito sincronismo entre os dispositivos ingressados no domínio e o seu servidor AD, ou seja, em caso de encaminhamentos/consultas de GPO e afins.

Após realizar os ajustes acima clique em **"Save"** # Integração AD ## Configuração do DNS no AD Para a integração de um dominio com o Userauth, deve ser realizado a configuração do DNS no AD. Nesta configuração, deve ser indicado o IP da interface do firewall como DNS principal do AD, conforme a imagem abaixo.

## Configuração do Forward Agora vamos criar uma regra para efetivar o sincronismo entre os dispositivos e o AD. Navegue até: **Services -> Bind -> Zones**

Clique em **"+ Add"** **Zone Name:** Nome do domínio que será realizado a integração; **Description:** Descrição para identificação da regra; **Zone Type:** Marque a opção "Forward"; **View:** Marque a opção Localnets.

Logo abaixo temos a opção **"Forward Zone Configuration"** **Forwarders:** Adicione o endereço IP do seu AD, caso tenha mais de um AD, adicione **;** entre os IPs.

Após realizar os ajustes, pode salvar.

# Apontamentos DNS Internos com BIND ## Criando a regra Vamos criar uma regra nas "Zonas" do Bind para apontamentos internos. Navegue até: **Services -> Bind -> Zones**

Clique em **"+ Add"**

**Zone Name:** Nome para identificação da regra, mas nesse caso é importante adicionar **".rpz"** no final; **Description:** Descrição para identificação da regra; **Zone Type:** Marque a opção "Master"; **View:** Marque a opção Localnets.

**Response Policy Zone:** Marque apenas essa opção para ativar a regra com o mecanismo de "Política de resposta",

**Name Server:** Adicione um domínio interno que fará parte da regra;

**Allow-query:** marque a opção **"localnets"**

Nesse momento você pode criar os apontamentos internos que você necessita, criamos como exemplo alguns modelos. Um adento importante: Você vai criar aqui todos os DOMÍNIOS, cada um com o seu apontamento.

Após realizar todos os seus apontamentos INTERNOS, pode salvar.

## Ativando os apontamentos para os grupos Após criar a regra acima descrita, precisamos informar ao UserAuth que esses apontamentos serão necessários para determinados grupos. Navegue até: **Services -> UserAuth Integration -> Local Groups** Edite o grupo escolhido, caso você ainda não tem grupo, pode ser criado [clicando aqui](/configurando-o-seu-userauth/escolha-o-seu-filtro-de-acesso/filtro-dns-com-bind/grupos-de-acesso-do-userauth)

Já dentro do grupo, vamos ter a opção: **Aditional Bind Zones:** Ao marcar um apontamento interno criado no Bind, **o UserAuth vai ativar a verificação** para todos os usuários **pertencentes nesse grupo.** **IMPORTANTE:** **Não ativar** apontamentos **externos**, **somente os internos**, nesse caso da imagem **"local.rpz".**

Após isso pode salvar.

# Configuração WPAD ## Ajustes Essa configuração é exclusiva para utilização com o filtro DNS em conjunto com o Bind. Acesse a aba "General" do UserAuth: **Services *****->***** UserAuth Integration *****->***** General** Siga as configurações conforme a numeração abaixo. 1. **Captive portal Interfaces(s):** Selecione a interface onde será aplicado o filtro. 2. **Captive portal bypass:** Por padrão, a ferramenta alimenta como *No bypass*. Neste campo, poderá ser selecionado qualquer alias com IPs das interfaces selecionadas no campo de *Captive portal interfaces* para não exigirão autenticação, e consequentemente não serão filtrados. 3. **Wpad configuration:** Com os parâmetros acima devidamente selecionados e salvos, a configuração da instância WPAD já pode ser automatizada. Clique no botão **"Create wpad Configuration"**

Ao executá-lo, será automaticamente criada uma instância no serviço WPAD. **OBS:** Como sugerido na descrição do campo, deverá ser alterado a porta de gerencia do firewall.

# Grupos de acesso do UserAuth ## **Configuração de Grupos do UserAuth** Esta é a configuração utilizada para aplicar listas para controle de acesso (ACLs) à internet para os usuários. Vamos utilizar os grupos **criados no UserAuth,** **somente quando** estamos com a integração com **"Filtro DNS"**, portanto **não pode ser utilizado** em conjunto com o **Proxy E2guardian**. ## Criando os grupos Navegue até: **Services -> UserAuth Integration -> Local Groups** Clique em **"+Add"** para criar um novo grupo local no UserAuth.

**Group Name:** Nome do grupo, importante lembrar que não deve ser utilizado **caracteres especiais,** além disso manter no **máximo 15 caracteres.** **Group Description:** Descrição do grupo. **IMPORTANTE:** o **nomes precisam** ser idênticos aos criados dentro do "DC Active Diretory", "DC Samba" ou "E2guardian", dependendo da origem dos grupos marcados na opção de [Source Groups.](/configurando-o-seu-userauth/configuracao-padrao/configurando-origem-de-grupos)

* **Group Users:** Os usuários pertencentes ao grupo em questão, só serão alimentados em caso de uma configuração local, nos demais casos, a informação será consultada na integração (AD, Samba e etc); * **Group Cdir:** Existe a possibilidade de configurar um intervalo de rede específico para este grupo. Todos os usuários com IPs dentro desta faixa terão a política deste grupo aplicada.

## **Opções de filtro DNS para o grupo** Nestes parâmetros, serão atribuídas as política de acesso designadas para este grupo. Inicialmente vamos precisar selecionar a opção que será a base de funcionamento para o grupo, no caso qual será o filtro principal, essa definição é escolhida em: "***Forward to"***.

Dentre as opções, temos como base as seguintes opções: * **Cloudflare** * **Quad9** * **OpenDNS** Basicamente são utilizados para os filtros de bloqueio direto a **"malwares"** e "**conteúdo adulto"**. Ainda em **"*****Forward to"*** temos: * **No Redirection or restrictions:** Será respeitado o DNS configurado na estação, portando não será redirecionado para nenhum serviço externo **(Cloudfare, Opendns e etc).** no entando as listas customizadas de bloqueio serão atendidas. * **Restrict mode - Permit only sites listed on domains list:** Essa opção é utilizada para "**bloqueio total"**, liberando acesso somente à listas adicionadas nos parâmetros **(ConexTI lists e Domains).**

## Opções de listas * **ConexTI list:** Listas disponibilizadas pela ConexTI, que são frequentemente utilizadas para definir o bloqueio ou liberação de categorias de forma simples, dependendo claro da seleção da funcionalidade básica em "***Forward to"*****.** * **Exclude from CNTI List:** uma lista de exceção, caso deseje bloquear uma categoria de maneira geral e liberar apenas um domínio dentro da categoria.

* **Safe Search:** Nesse campo podemos marcar a integração com os mecanismos de busca e provedores de conteúdo online, estes por sua vez podem filtrar e remover resultados de pesquisa que possam conter material considerado inadequado ou explícito, como pornografia, violência ou linguagem ofensiva. * **Aditional Bind Zones:** Aqui pode ser ativada a verificação nos apontamentos internos criados no BIND. **IMPORTANTE:** Somente selecionar nessa opção os apontamentos "locais".

**AD Queries Forward:** Quando integrado com o AD, este campo será utilizado para encaminhar qualquer consulta de domínio para os respectivos controladores configurados na guia **"domains"** da ferramenta. **Domains:** Lista de domínios adicionados manualmente, que poderá ser utilizada tanto para bloqueio como para liberação, dependendo do que for selecionado no campo Forward to. ## Criando aliases para os grupos Para cada grupo criado, vamos precisar de um alias com o mesmo nome. Navegue até: **Firewall -> Aliases -> IP** Clique em **"+Add"**

Adicione o nome e a descrição idênticos ao grupo criado nos passos acima.

Após isso pode salvar e criar o restantes dos **"Aliases"**, seguindo a quantidade de grupos que você possui. # Relatórios de acesso do UserAuth ## Configuração dos logs UserAuth Na versão 4 do UserAuth foi aberta a possibilidade de gerar relatórios dos acessos, utilizando os domínios e FQDNs que são identificados quando se utiliza a integração com filtro DNS. Para ativar essa funcionalidade, basta navegar até a opção "**Logs"** na guia **General** do UserAuth. Será necessário configurar a integração com o serviço DNS e paramentos de logs do pfSense®. Configurados na pagina inicial do UserAuth, configuração de **Logs**. * **Integrate userauth authenticated user to pfSense logs:** Adiciona o nome do usuario aos registros do log**.** * **Add fqdn to destination:** Adicionará o fqdn nos logs gerados pelo UserAuth, sendo um requisito ter o NGRules ativo; * **Add rule description:** Adicionará nos logs a descrição da regra criada para identificar o acesso; Ao selecionar está opçõa, se faz necessario adicionar a descrição ao configurar a regra.

* **Add DNS/bind9 resolution logs:** Inclui os logs de DNS; * **Logs Volumetry:** Adiciona volumetria aos logs; * **Remote syslog:** Integração de um servidor de Greylog externo; * **Parallel log monitor:** Configuração de quantidade processos máximo para processamento dos logs.

**Patch Configuration:** Aqui temos duas opções: * **Enable userauth in Sarg:** Nessa opção podemos realizar a integração dos logs entre o UserAuth e o Sarg, permitindo assim uma opção a mais para o gerenciamento dos relatórios; * **Remove log duplicate:** Essa função foi criada para melhorar os logs do próprio pfSense, que trás por padrão informações de acessos duplicadas.

**Send logons to syslog:** Neste campo pode ser configurado um servidor de logs externos, como por exemplo um Greylog, basta adicionar o IP dele e a ferramenta fará o envio das informações de acesso. **Logons Log Retention Count:** Se trata do número de dias que os arquivos de logs de login serão retidos antes que a cópia mais antiga seja removida durante a rotação. **Shipping Format send logons:** Formato que o log pode ser encaminhado para um servidor externo.

## Configuração dos logs no pfSense® Será necessário, inicialmente, aplicar uma configuração dentro dos logs do pfSense® ***"Status -> System Logs -> Settings"***, visto que a ferramenta apenas visualiza o que o pfSense® gera. Nesta mesma tela de configuração existe a possibilidade de seguir diretamente para a tela de configuração, basta clicar em "**Goto pfSense system log config page".**

**Agora siga a ordem de ajustes abaixo:** * **Log firewall default block:** Vamos desabilitar os logs padrão de bloqueio. * **Forward/Reverse Display:** Vamos ativar essa opção de exibição

* **Log Rotation Size:** Altere o tamanho do arquivo de Logs, lembrando que o tamanho é definido por (Bytes), importante tomar cuidado na hora da conversão. Na imagem abaixo temos como exemplo "512000000 KB" convertendo isso para MB da um total de "500MB"

## Relatórios de acessos Após realizar todas as configurações acima citadas, será possível consultar e exportar os logs dos acessos. Basta acessar a guia **"Logs"** do UserAuth.

Dentro da guia "Logs" temos 3 opções que podem ser vistar na imagem acima: * **Firewall:** Essa opção trás os logs dos acessos do usuários; * **UserAuth:** Nessa opção é possível visualizar os logs do próprio UserAuth; * **User History:** Histórico de login e logoff dos usuários. ## Logs -> Firewall Nessa tela será possível visualizar os logs dos acessos, para tal, você pode utilizar algumas opções de filtros: * **Max lines:** Quantidade de linhas apresentadas em tela; * **Firewall Logs Files:** Selecione quais arquivos de banco de dados você deseja usar em sua pesquisa, sendo possível mais de um para exibição; * **Update Interval:** Com que frequência as entradas de log são atualizadas; * **String Filter:** Filtro de informações no log, ao clicar em obter ajuda serão apresentadas algumas opções de filtros, para a descrição destas opções avançadas de filtro acesse nesse manual "**Opções avançadas para filtro de logs"**; * **String Filter Limit:** Tamanho máximo para o conteúdo filtrado; * **Export Logs:** É possível exportar os registros exibidos na tela utilizando as opções de CSV e HTML. Ao selecionar a opção "Arquivo Completo", será realizado o download do arquivo completo do dia, porém sem formatação.

Nos registros deste log, que serão exibidos em tempo real, serão informados o país de origem e destino da conexão, através da bandeira. Ao clicar no IP de destino ou origem, duas abas serão exibidas logo acima, informando em qual tabela/alias o IP clicado está presente e a quais regras ele pertence. Para entender como utilizar filtros avançados, clique [aqui](/configurando-o-seu-userauth/escolha-o-seu-filtro-de-acesso/filtro-dns-com-bind/relatorios-de-acesso-do-userauth/utilizacao-avancada-relatorio-com-userauth). ## **Logs -> UserAuth** **Aqui temos algumas opções de filtros, mas são basicamente os mesmo acima informados.**

### Firewall logs Nos campos abaixo temos os registros com as informações relacionadas a licenças do pacote, vencimento, além da quantidade de usuários conectados. Caso você tenha integração com o AD, serão exibidas informações relacionadas a sincronização e eventos locais, bem como IP e usuário de acesso.

## **Logs -> User History** Nessa aba, vamos ter também as mesmas opções de filtros já repassados no início dessa página.

### Firewall logs Nos logs vamos ter as informações de login e logoff de cada usuário, além dos eventos relacionadas a data, grupo pertencente, endereço IP, endereço MAC e onde foi feita autenticação (AD, CP ou MAC)

# Relatórios de acessos Após realizar todas as configurações acima citadas, será possível consultar e exportar os logs dos acessos. Basta acessar a guia **"Logs"** do UserAuth.

Dentro da guia "Logs" temos 3 opções que podem ser vistar na imagem acima: * **Firewall:** Essa opção trás os logs dos acessos do usuários; * **UserAuth:** Nessa opção é possível visualizar os logs do próprio UserAuth; * **User History:** Histórico de login e logoff dos usuários. ## Firewall Nessa tela será possível visualizar os logs dos acessos, para tal, você pode utilizar algumas opções de filtros: * **Max lines:** Quantidade de linhas apresentadas em tela; * **Firewall Logs Files:** Selecione quais arquivos de banco de dados você deseja usar em sua pesquisa, sendo possível mais de um para exibição; * **Update Interval:** Com que frequência as entradas de log são atualizadas; * **String Filter:** Filtro de informações no log, ao clicar em obter ajuda serão apresentadas algumas opções de filtros, para a descrição destas opções avançadas de filtro acesse nesse manual "**Opções avançadas para filtro de logs"**; * **String Filter Limit:** Tamanho máximo para o conteúdo filtrado; * **Export Logs:** É possível exportar os registros exibidos na tela utilizando as opções de CSV e HTML. Ao selecionar a opção "Arquivo Completo", será realizado o download do arquivo completo do dia, porém sem formatação.

Nos registros deste log, que serão exibidos em tempo real, serão informados o país de origem e destino da conexão, através da bandeira.

Ao clicar no IP de destino ou origem, duas abas serão exibidas logo acima, informando em qual tabela/alias o IP clicado está presente e a quais regras ele pertence.

## **UserAuth** **Aqui temos algumas opções de filtros, mas são basicamente os mesmo acima informados.**

## **User History** Nessa aba, vamos ter também as mesmas opções de filtros já repassados no início dessa página.

sss # Utilização Avançada Relatório com UserAuth Os filtros do Firewall Logs são feitos com base no comando GREP, permitindo filtrar os principais campos, tais como: * **Date**: Possível pesquisa por data/hora do registro. * **Iface**: Interface de onde se originou o registro. * **Action**: Opção se regra está permitindo ou bloqueando, sendo possível as pesquisas por: pass, block ou blocked. * **Protocol**: Qual protocolo está sendo usado, possível pesquisar por: TCP, UDP, DNS, ICMP, IGMP... * **Source**: De onde se origina a conexão, possível pesquisa pelo IP (IPv4 ou IPv6) do usuário ou o nome do próprio usuário. * **Destination**: Para onde está indo a conexão, possível pesquisar pelo IP (IPv4 ou IPv6) ou o FQDN do site visitado. * **Source/Destination Port:** Portas usadas para conexão. * **Description**: Descrição da regra quando é criada. * **OBS**: Para pesquisa não é necessário mencionar qual o nome do campo, pode ser apenas mencionado o que será pesquisado. *Exemplo:* Para pesquisa de usuário, podemos apenas informar o nome do usuário. ``` Ederson ```

Como o comando grep é uma forma de pesquisa para “contendo” a informação, para pesquisas mais específicas é necessário adicionar “,”. Vamos pesquisar pela porta: ``` 53, ```

O asterisco (.\*) no comando grep é usado como um curinga para representar zero ou mais caracteres. Quando você utiliza o asterisco em uma expressão de pesquisa, o grep irá encontrar todas as ocorrências que correspondam à parte da expressão que está antes do asterisco, seguida por zero ou mais caracteres que correspondam à parte da expressão que está depois do asterisco. Por exemplo, ao pesquisar por hora, ação e usuário, você pode usar o seguinte padrão: ``` 14:10.*pass.*ederson Ou seja: Hora.*ação.*usuário ```

# Filtro Web com E2guardian # Configuração E2Guardian Quando observamos critérios técnicos entre os pacotes que realizam filtro web disponíveis para o pfSense®, é possível notar muito mais desempenho quando utilizando E2Guardian, sem contar que com ele é possível ter um número maior de funcionalidade quando integrado com o UserAuth. ## Instalando E2guardian Primeiramente será necessário instalar o pacote, navegue até **"System *****->***** Package Manager *****->***** Available Packages"** Pesquise por ele e faça a devida instalação clicando em "Install":

## Ativando E2Guardian Inicialmente deve-se ativar a ferramenta e selecionar as interfaces de origem que serão auditadas pela ferramenta. Selecionando o modo de trabalho como transparente ou não e a porta que o serviço será iniciada.

Além destas configurações básicas, deve-se tomar muito cuidado com o campo de **“Http workers”**, pois ele interfere de forma direta o desempenho do proxy.

Nele deve ser informa o número de conexões simultâneas, número que deve ser observado em cada ambiente. ## Filtro de páginas HTTPs Para realizar o filtro de páginas HTTPs também com o E2Guardian deve-se criar uma CA no pfSense® e ativar o recurso na ferramenta selecionando a autoridade certificadora criada, caso contrário só será filtrado páginas HTTP. **Criando a Autoridade Certificadora** Para criar a CA, basta acessar dentro do pfSense® o menu **"*****System -> Certificate Manager -> CAs"*** e adicionar uma nova CA e preencher as informações solicitadas.

Para selecionar a CA e ativar o recurso no pacote, basta acessar a dashboard principal do E2guardian e selecionar o campo **“*****Enable SSL support*****”** e selecionar autoridade criada.

## Integrando o tipo de autenticação Para integrar o E2guardian com o UserAuth deve ser selecionado o **“*****Auth Plugins*****”** como **DNS,** dessa forma ele estará preparado para identificar o nome de cada usuário já tratado pela ferramenta de autenticação UserAuth.

### Configuração de níveis de acesso Dentro da aba “*Groups*” é possível criar os níveis de acesso para os respectivos usuários do ambiente. OBS: para o correto funcionamento do pacote é recomendado que nunca seja excluído ou alterado de ordem o grupo “*default*”, ele serve como index de partida para os demais grupos.

A configuração deste novo grupo exige uma serie de configuração indexadas da aba “*ACL*” que podem ou não ser criadas antes do grupo.

## Atribuindo usuários aos grupos Para alocar os usuários aos seus devidos grupos, basta adicioná-los no grupo desejado na aba “*Users*”.

OBS: Essa “**configuração manual dos usuários em seus grupos**” é utilizada quando a origem dos grupos na ferramenta UserAuth é marcada como **“*****E2guardian Groups*****”**, conforme explicado, quando ativada a ferramenta, caso contrário, deve manter os campos vazios, pois o UserAuth alocará os usuários dinamicamente conforme AD.

## Configurando log Nas opções da aba **“Report and Log”** é possível configurar a tela de erro que será exibida, optando pela tela padrão ou personalizando a página conforme a necessidade.

Ainda nesta aba, podemos alterar o formato do log que é uma configuração essencial para leitura correta dessas informações pelo Sarg (pacote integrado para leitura e geração dos relatórios de acesso). O Sarg entende logs apenas o padrão Squid, por isso é necessário mudar esta opção para “*Squid Log File Format*”, consulte o capítulo sobre relatórios o Sarg [clicando aqui.](/opcoes-avancadas-do-userauth/filtro-de-logs-com-sarg/sarg-com-e2guardian)

Caso queira entender mais sobre a ferramenta, o time da ConexTI elaborou um treinamento exclusivo [sobre o pacote E2Guardian ministrado](https://sys-squad.com/produto/e2guardian/) pelo próprio desenvolvedor da ferramenta, disponível na plataforma de ensino [Sys-Squad](https://sys-squad.com/).
# Regras de Firewall # Regras com grupos de usuários do UserAuth Uma das funcionalidade do UserAuth é possibilitar a aplicação de regras de firewall no pfSense "Firewall ***->*** Rules ***->*** LAN" por grupos de usuários previamente autenticados pela ferramenta. Isso é possível por que o UserAuth alimenta dinamicamente aliases com os IPs dos dispositivos que estão em uso pelos respectivos usuários. Assim, é possível aplicar regras de firewall para liberar ou bloquear acessos da rede local à Internet para outros serviços além da navegação web (HTTP/HTTPS) . Por exemplo: Liberar acesso remoto a servidores Windows (TCP/3389) apenas para os colaboradores que fazem parte do grupo "TI" no Microsoft AD (independentemente de que dispositivos estão sendo usados por estes usuários). ## Criando Aliases Crie um Alias com o mesmo nome do grupo de acesso oriundo de um AD ou do cadastrado no próprio UserAuth, por exemplo. A descrição do Alias deve ser a mesma do seu nome e ele precisa ser do tipo "Host". Os demais campos de configuração do Alias devem ficar em branco, pois eles serão alimentados dinamicamente conforme o UserAuth for lendo as origens configuradas.

## Criando as regras Configurado os devidos aliases desejados dos grupos, você poderá aplicar as regras liberando portas e destinos específicos.

No exemplo da imagem acima, podemos observar que temos tráfego identificado nas respectivas regras criadas. Você pode consultar os IPs dos dispositivos que foram adicionados dinamicamente a este Alias, visualizando sua tabela (conforme imagem abaixo).

# Filtro de Logs com SARG # Sarg com UserAuth Agora temos uma opção de integração direta entre o UserAuth e o SARG, portanto você pode utilizar essa função para verificação dos Logs. ## Instalando o SARG Navegue até: **System -> Package Manager -> Available Packages** * Busque pelo SARG * Clique em "Install"

## Configurando a integração UserAuth com Sarg Navegue até: Services -> UserAuth Integration -> General Na aba Logs, vamos ter algumas opções, podemos deixar conforme a imagem abaixo.

**Log volumetry:** Aqui vamos marcar a opção de volumetria no log; **Log volumetry Interfaces:** Selecionar as interface a ser auditada; **Patch Configuration:** Clique na opção **"Enable userAuth Inf Sarg".**

## Configurando o Sarg Após realizar todos os passos acima, podemos iniciar os ajustes. Navegue até: **Status -> Sarg Settings -> General**

**Proxy Server:** Marque a opção "Userauth"; **Resport Options:** Por padrão marque essas opções abaixo.

**Report To Generate:** Mantenha o padrão deixando todas as opções.

Date Format: Selecione a opção: **European dd/mm/yy**

**Days Limits:** Por padrão deixamos com 90 dias. Caso seja deixando em branco, não haverá exclusão automática, portanto existe a possibilidade de acabar o espaço de armazenamento (Disco, SSD e afins), caso não haja um gerenciamento para isso.

**Exclude Hosts:** Aqui você pode adicionar endereços que não gostaria de mostrar nos logs, por padrão deixamos apenas: **127.0.0.1**

Após realizar todas as alterações, pode salvar.

## Criando um Schedule Na aba "S**chedule"** você pode definir quanto tempo será gerado o relatório. Podemos criar várias opções com tempos diferentes, conforme o desejo. Clique em **"Add"**

Nesse exemplo vamos criar um relatório do dia atual, atualizando a cada 1hrs. **Enable:** Ativar essa schedule **Description:** Adicione uma descrição de fácil identificação **Sarg Args:** Aqui vamos definir o tempo de cada arquivo de log.

Frequency: Tempo de atualização dos logs, por padrão mantemos em 1h. Após isso pode salvar.

## Verificação dos logs Na aba "View Report", temos o acesso ao logs gerados.

O relatórios são separados por **ano, mês e dia**.

Após escolher a data, você terá acesso separado por usuário/IP.

Caso queira exportar, pode clicar nas opções abaixo conforme a imagem.

# Sarg com E2guardian Para gerar relatórios mostrando usuários autenticados, quantidade de acesso, sites bloqueados e acessados, é necessario a utilização do Sarg, quando utilizado com o UserAuth automaticamente é instalado um plugin que faz a repaginação da ferramenta, deixando a interface mais agradável e intuitiva. Nesse capítulo abordaremos o mesmo procedimento efetuado no vídeo que pode ser acesso clicando aqui: [vídeo-tutorial no canal da ConexTI® no Youtube](https://www.youtube.com/watch?v=ERJJCeX-n0g). ## Pré-requisitos Antes de de configurar o SARG deve-se verificar qual o formato dos logs do E2guardian. Isso pode ser verificado acessando o E2guardian, aba `Report and Log` na opção "**Log File Format"**, deve esta em formato: ## Instalando o SARG Com os repositórios extraoficiais instalados, basta pesquisar pelo pacote em **"Available Packages"**.

## Configurando o SARG Depois de instalado, é possível acessa-lo pelo menu: **Status -> Sarg Reports -> General**.

Selecione qual o proxy que está sendo utilizado, nesse caso "E2guardian". Marque as opções de report abaixo.

Nessa aba também é necessário selecionar o formato da data lido nos logs: **European dd/mm/yy**

E selecionar o numero de dias que os arquivos serão armazenados. Caso seja deixando em branco, não haverá exclusão automática, portanto existe a possibilidade de acabar o espaço de armazenamento (Disco, SSD e afins), caso não haja um gerenciamento para isso. **Days Limits:** Por padrão deixamos com 90 dias.

**Exclude Hosts:** Aqui você pode adicionar endereços que não gostaria de mostrar nos logs, por padrão deixamos apenas: **127.0.0.1**

Após realizar todas as alterações, pode salvar.

## Criando um “Schedule” Nas schedules é definido a cada quanto tempo será gerado o relatório. Podemos definir várias com tempos diferentes, conforme o desejo.

Nesse primeiro exemplo vamos criar um relatório do dia atual, atualizando a cada 4hrs.

Quando acessamos a aba **“View Report”**, podemos verificar os acessos ordenados por usuários.

No segundo exemplo criamos uma schedule mensal do mês atual.

## Exportando relatórios Para exportar os relatórios, basta acessar o relatório desejado, selecionar o usuário e escolhe o formato do arquivo para exportação.

# Page # Aplicando exceção com UserAuth Essa função no UserAuth, foi criada para aqueles que utilizam ADs enormes e não querem que todos os grupos sejam autenticados pelo UserAuth, uma maneira de facilitar o controle e consequentemente excluindo a leitura indesejada de outros grupos autenticados no AD. Ela pode ser acessada no guia **Exceptions** no UserAuth e é válida tanto para quem utilizar grupos locais como grupos do AD.

## Importando apenas usuários dos grupos selecionados Por default essa opção vem desativa e todos os usuários configurados poderão se autenticar, agora quando é selecionado a opção “**Import only users on selected group**”, você esta dizendo para o UserAuth autenticará somente usuários dos grupos selecionados no campo abaixo.

Neste caso, no exemplo acima, somente usuários do grupo "suporte" poderão efetuar autenticação. Quando um usuário realiza login, e ele, não esta no grupo selecionado podemos observar que o UserAuth ignora a autenticação, informando que o usuário está em um grupo não autorizado para navegar.

Caso queira verificar nas sessões ativas, pode-se constatar que o usuário não foi autenticado e não esta ativo.

## Ignorar usuários do grupo selecionado Quando trocamos a opção para “**Ignore users on selected group**”, o UserAuth fará totalmente o oposto da opção anterior, agora ignorando usuários que pertencem ao grupo selecionado.

Se tentarmos a autenticação com o mesmo usuário “carlos” do exemplo anterior, cuja o qual pertence ao grupo "operacao", o mesmo desta vez autenticará.

Agora, ao efetuar o login com usuário que pertence ao grupo “suporte”, o usuário será ignorado e não conseguirá navegar para a internet.

## Filtro de redes/hosts A ferramenta UserAuth, também possibilida o filtro de redes a serem aplicadas a autenticação ou não, para ambientes onde não há uma separação lógica. Esta configuração se aplica de duas formas: * **Autenticação Local:** Quando a autenticação dos usuários acontece utilizando o Captive Portal da ferremanta ou MAC Address, de ser configurado na dashboard principal da ferramenta no campo **Local login options**, onde deve ser selecionado o aliases com as redes/hosts que **deverá** ser aplicado autenticação.

* **Autenticação AD:** Quando a autenticação dos usuários acontece transparentemente utilizando um controlador de domínio, nesse caso a configuração das redes/host que serão autenticadas é aplicada na integração da ferramenta com o AD, selecionando no campo o aliases com as redes/host já cadastrados.

# Alterações UserAuth ## Limpeza de Cache O UserAuth é uma ferramenta extremamente robusta e amplamente testada em uma variedade de ambientes. No entanto, algumas situações inerentes à ferramenta, como falhas ou instabilidade nos servidores que contêm as bases de usuários (por exemplo, Microsoft AD), podem exigir a limpeza de dados salvos provenientes dessas fontes no UserAuth. Em outras situações, pode ser interessante forçar uma atualização de dados recém-obtidos a partir dos servidores que contêm a base de usuários. Para essas situações, contamos com "**opções avançadas"** no pacote:

As ações para a resolução de problemas apresentadas nessa tela é a limpeza de cache e a limpeza da integração com o Active Directory. ## Versão do WMI Esta é uma opção para manter equalização do UserAuth com eventuais ambientes legados, especialmente quando da autenticação junto a servidores Active Directory que rodam sob sistema operacional Windows Server 2019 ou anteriores. A opção padrão é usar o WMI 1.4 (funcional com todas as versões de Windows Server suportadas atualmente pela Microsoft). Altere para WMI 1.3 apenas para casos específicos em que um modelo de integração WMI legado é exigido.

Além disso, é possível selecionar a opção **Use WMI Remote Agent**, a qual foi desenvolvida para a utilização em sistemas operacionais Windows Servers após março de 2023. Para mais informações sobre como utilizar o cliente, você pode verificar no capítulo de [integração com o AD](http://20.25.124.119:8000/Configurando_o_UserAuth_com_AD_e_dominio/). ## Opções de memória

* **memory cache:** Cria um espaço alocado no disco para a utilização de algumas funções da ferramenta. * **memory lifetime:** Tempo de vida do cache alocado, onde irá apagando cache mais antigos baseado no tempo estipulado. ## Limpeza de Cache (Clear all cache data) Como o nome sugere, efetua a limpeza de todos os dados em cache da ferramenta (usuários autenticados, grupos, aliases dinamicamente alimentados pela ferramenta).

**OBS:** Ao executar esta ação, todos os usuários autenticados na ferramenta serão desconectados e terão que realizar a autenticação por algum método selecionado novamente. ## Limpeza da integração com o AD (Clear active directory poiter data) Essa função recria o arquivo de configuração responsável por manter as informações da última consulta ao AD. Esse arquivo pode armazenar informações equivocadas encaminhadas pelo servidor AD e com isso prejudicar a autenticação transparente de usuários durante a navegação web (ou aplicação de regras de firewall por grupos de usuários).

\
# Perguntas Frequentes Esta página relaciona as respostas às dúvidas mais frequentes encaminhadas por usuários e clientes do nosso pacote EXCLUSIVO [UserAuth](https://conexti.com.br/userauth/). Se mesmo depois de ler os pontos levantados aqui você ainda tiver dúvidas sobre o funcionamento ou modelo comercial do UserAuth, [entre em contato com o nosso time](https://conexti.com.br/fale-conosco/). * **Onde consigo mais informações sobre o UserAuth?** Todas as informações que necessita e as atualizações do UserAuth estão disponíveis no hotsite do: [conexti.com.br/userauth](https://conexti.com.br/userauth). * **Tenho todo o suporte para instalação e configuração?** Para que não tenha gastos extras, todas as instruções para instalação e ativação do produto serão encaminhadas para seu e-mail assim que confirmada a assinatura. * **Caso necessitar de ajuda para a instalação e a configuração, como faço?** Caso tenha problemas na instalação ou configuração do UserAuth, a ConexTI® fornece, opcionalmente, para a sua empresa o serviço de instalação e configuração do produto para o seu cenário junto ao nosso time técnico. Para isso, [basta entrar em contato conosco](https://conexti.com.br/fale-conosco). * **Caso contratar a instalação, terei a tutoria de configuração do Userauth?** A nossa equipe vai configurar para a sua empresa, conforme a sua necessidade, mas em função da operacionalidade NÃO será disponibilizado nenhum tipo de tutoria. * **Como faço para acessar o vídeo de demonstração do produto?** A ConexTI® disponibiliza um [vídeo contendo todo o processo de instalação e demonstração do produto](https://www.youtube.com/watch?v=r9NnmdL2PcU\&feature=youtu.be). Nele, você encontrará a demonstração de como implementar todas as principais features do módulo na prática. * **Como faço backup das configurações do UserAuth?** Todas as configurações do UserAuth e suas integrações são inseridas no backup padrão do pfSense®. Em caso de necessidade de reinstalação do servidor, basta adicionar primeiro o REPOSITÓRIO EXTRAOFICIAL do produto e então executar a restauração padrão do XML. # Changelog UserAuth Confira abaixo a lista de atualizações do pacote **UserAuth**. Para saber mais sobre o módulo extra que implementa recursos avançados de autenticação de usuários no pfSense®, acesse o [site oficial da ferramenta](https://conexti.com.br/userauth). ## Atualizações ### (22/01/2024) UserAuth 4 ###

# Considerações finais **IMPORTANTE: Os módulos desenvolvidos pela ConexTI®, que adicionam funcionalidades extras ao pfSense® SÃO EXTRAOFICIAIS, ou seja, não são suportados ou homologados pela ESF/Netgate (pfSense Patrons). Todo o desenvolvimento, política de distribuição, continuidade e suporte técnico são de responsabilidade exclusiva da ConexTI®.** **“pfSense® é uma marca registrada da Electric Sheep Fencing, LLC”** # Bem-vindo à Base de Conhecimento do NGRules O NGRules é uma ferramenta poderosa que permite criar Regras de Firewall com base em Wildcards (.whatsapp.net, por exemplo) no pfSense®️. Ele é capaz de executar filtros baseados em consultas DNS e verificação de certificados SSL/TLS do destinatário, sem a necessidade de liberação prévia de conexões da LAN para WAN. Contando com recursos avançados, como o cache de consultas anteriores que aumenta sensivelmente a performance do pacote, o NGRules também pode ser integrado facilmente ao [UserAuth](https://conexti.com.br/userauth/). Desta forma, você pode transformar seu servidor pfSense®️ numa poderosa solução de proteção e auditoria de acessos à Internet - incluindo autenticação por usuários com o [UserAuth](https://conexti.com.br/userauth/). Em outras palavras, agora você define que tipo de aplicações/sites/serviços (WhatsApp, Youtube, Netflix, Sites do Governo, etc..) podem ser ACESSADOS ou NÃO na Internet pelos seus colaboradores, com ou sem webfilter (Squid ou E2Guardian), e sem a necessidade de infinitas horas tentando descobrir as redes IPs que hospedam estes serviços. Tudo simples, seguro e efetivo. “pfSense® é uma marca registrada da Electric Sheep Fencing, LLC” # Licenciamento O NGRules é um software comercial distribuído sob uma licença anual de uso por servidor pfSense®. Há também a possibildiade de ativar a versão trial da ferramenta (sem limitações para uso durante 15 dias). Todos os direitos são reservados a [ConexTI®](https://conexti.com.br/). Se você deseja saber mais sobre o modelo comercial do NGRules e condições especiais para aquisições por volume (acima de 10 licenças por lote), entre em contato conosco através do . Todos os demais softwares citados neste documento, seguem suas próprias licenças de uso e distribuição. Para saber mais sobre cada um deles, visite os respectivos sites. # Instalando o NGRules no pfSense® A instalação do NGRules foi tratada nesse manual no seguinte link: [Clique aqui](/primeiros-passos/instalando-o-userauth-no-pfsense-r) # Configurando NGRules # Primeiros passos Ativando a ferramenta Navegue até: Services -> NGrules Integration -> General. Enable: Marcando essa opção a ferramenta será ativada. Listen Interface(s): Agora marque as interfaces que serão filtradas pela ferramenta, apenas marque as opções onde a conexão é originada: Exemplo: LAN

Schedule frequency: Aqui podemos informar a frequência com que os processos do NGRules são reiniciados, isso previne um elevado consumo de memória.

Monitor mode: Aqui será ajustado o modo de operação do NGRules, como a ferramenta monitora as conexões e utiliza os recursos do hardware: **Defaulf:** Selecione para ambientes com tráfego moderado; **High traffic server:** Se o seu ambiente estiver passando por um tráfico mais intenso e existe um número considerável de dispositivos simultâneos, será importante utilizar essa opção; **Low traffic server:** Essa opção serve para ambientes menores, onde existe poucos dispositivos e o tráfego na rede é baixo.

License info: Aqui será exibida a informação da licença.

## Checagem de Aliases Check Alias: Essa opção é a frequência que os aliases serão alimentados e verificados sobre novas atualizações. Check frequency: Tempo em minutos que será feita a atualização acima.

# Opções Avançadas Quic protocol: Por padrão, o NGRules já faz o bloqueio do tráfego do protocolo Quic (UDP 80 e 443) de forma automatizada, garantindo assim, que certos serviços respeitem as regras impostas futuramente, por padrão deixamos essa opção ativa Promiscuous mode: No modo padrão de implementação, deixamos essa opção desativada.

Additional ports: Toda a inteligência de descoberta de redes IPs das aplicações e sites na Internet no NGRules está alicerçada sob análise das requisições DNS (além de verificações em nível de certificado digital - SSL e TLS). Em outras palavras, a porta lógica mais importante para que o NGRules faça seu trabalho é a UDP/53 (porta default que não necessita de configuração adicional neste campo). A opção de listar portas adicionais só deve ser utilizada em casos muito específicos como filtrar conexões do aplicativo WhatsApp, por exemplo. O WhatsApp utiliza tráfego NÃO traduzível por DNS/SSL para envio de mensagens e mídias entre usuários e, portanto, faz-se necessário configurar o NGRules para auditar um intervalo de portas adicionais como: TCP/5222-5228. IMPORTANTE : Jamais utilize esta opção de forma aleatória como filtrar conexões HTTPS (TCP/443). Isso além de ser INEFICIENTE no trabalho realizado pelo NGRules, potencialmente fará com que seu servidor tenha problemas com o consumo de memória e CPU. Por padrão, adicionamos apenas essas portas: 5222-5228,8721,4567

Check Certificates: Essa opção possibilita a verificação dos certificados SSL dos servidores quando em conexões "HTTPS/SSL" e atualizar as regras com base nas informaões encontradas. Por padrão marcamos a opção: Update on any cert, except self signed certificates

Check ip updates: Modo de checagem/atualização dos IPs feitos pelo NGRules

Cache maintenance: Esta opção, como o próprio nome sugere, executa uma limpeza em todos os arquivos de cache e temporários gerados pelo NGRules. Ela pode ser utilizada sempre que você desejar reiniciar os algoritmos de identificação e registro das redes IPs das aplicações identificadas sem restartar o serviço do NGRules. CUIDADO : Ao limpar todo o cache do NGRules, você reinicia o processo de descoberta das redes das aplicações na Internet. Isso pode fazer com que seja necessário esperar novamente o tempo mínimo de reconhecimento para obter os resultados desejados em relação aos bloqueios ou liberações executados nas respectivas regras de firewall.