MÓDULO PFSENSE® – USERAUTH

MANUAL DO ADMINISTRADOR

CONEXTI – SOLUÇÕES EM TI LTDA

RUA DO COMÉRCIO, 525, EDIFÍCIO ÂNGELO SPRICIGO – SALA 301
CONCÓRDIA-SC – CEP: 89700-000
+55 (49) 3442-3747
conexti.com.br
sys-squad.com
goxdrive.com.br

22/11/2018
Sumário

1 – Introdução............................................................................................................................................ 3
2 – Habilitação e instalação dos pacotes não oficiais. .................................................................................... 4
3 – Configuração inicial do UserAuth. .......................................................................................................... 7
4 – Configuração com grupos E2guardian. ................................................................................................... 9
5 – Configurando o E2guardian ................................................................................................................. 14
6 – Configurando WPAD. .......................................................................................................................... 16
7 – Testando a configuração inicial ............................................................................................................ 20
8 - Configurando o UserAuth com AD e domínio. ........................................................................................ 25
9 – Integração da autenticação AD com o Captive Portal local. .................................................................... 37
10 – Integração da autenticação com o captive portal do pfSense®. ............................................................. 44
11 - Autenticação em banco de dados corporativos através de URL/webservice ............................................ 48
12 – Autenticação por MAC Address.......................................................................................................... 54
13 – Autenticação pelas redes sociais (Facebook). ..................................................................................... 60
14 - Login Social com o Google. ................................................................................................................ 68

2
1 – Introdução

O UserAuth é um pacote extraoficial de integração de autenticação do pfSense® 2.4, este é uma evolução do antigo
pacote de integração do squid WMI. Ele funciona tanto em bases locais, como em ambientes Active Directory.
Utilizando recursos avançados de integração de autenticação sem hacks do código ou fork do projeto original, o
UserAuth possui a possibilidade de criar regras de firewall por grupos de usuários, autenticação transparente para estações
Windows e redirecionamento automático ao recurso de Captive Portal para dispositivos móveis ou máquinas fora do Microsoft
AD, além de uma integração nativa com E2guardian.

3
2 – Habilitação e instalação dos pacotes não oficiais.
2.1 – Inicialmente deve-se habilitar o pacote extraoficial na aba de Command prompt, inserindo o comando:
fetch -q -o /usr/local/etc/pkg/repos/Unofficial.conf https://raw.githubusercontent.com/marcelloc/Unofficial-pfSense-
packages/master/Unofficial.conf

2.2 – Após isso deve-se habilitar o repositório do UserAuth com o comando:

fetch -q -o /usr/local/etc/pkg/repos/wmi.conf https://e-sac.websiteseguro.com/wmi/wmi.txt

4
2.3 – Agora devemos instalar os pacotes essenciais para o correto funcionamento. Esses pacotes podem ser adicionados
por comandos únicos através da interface, mas existe a facilidade de efetuar pela console web pesquisando os mesmos na
guia available packages, iniciaremos efetuando a instalação do Wpad.

2.4 – O source guardian, para a execução de código protegido.

5
2.5 - O E2guardian

2.6 – E o próprio UserAuth.

6
2.7 – Após instalados os pacotes podem ser avaliados através da aba installed packages.

3 – Configuração inicial do UserAuth.

3.1 – Agora iniciamos a configuração do UserAuth, habilitando o pacote e adicionando o tempo máximo de que a informação
de autenticação ira ficar no cache (nesse caso colocamos 4 horas, mas pode ser definido conforme a necessidade de sua
empresa). Logo abaixo também, tem a opção de Register/Trial, onde possibilita um teste gratuito por 30 dias.

3.2 – Como o UserAuth possui o captive portal integrado, ele é configurado na guia Captive portal integration mode – definindo
o modo de integração do captive portal, esse pode ser como “none” caso você possua uma lista de AD, e as maquinas não
identificadas ficam com uma configuração básica, ou, tenha sua conexão negada, conforme configurado no e2guardian.

3.3 – Ela também pode ser Forward, que encaminha para o captive portal do próprio UserAuth, integrado com o e2guardian,
para que caso ele não consiga identificar essa máquina, ele gera um portal captive, podendo então nesse portal, habilitar a
autenticação. Manteremos como Forward, efetuando então a configuração da autenticação. Esta autenticação pode ser
efetuada de diversos modos, um deles é o local, utilizando os usuários e senhas do pfSense® para conectar. Outra opção é

7
a conexão WMI, com um usuário e senha pré-definidos, logo abaixo da configuração. Também pode ser feita por LDAP que
é a mesma configurada no pfSense® para atribuir um grupo à utilizar a interface do pfSense®. (Os outros modos serão
abordados depois). A princípio vamos deixar local e LDAP.

3.4 – Quando configurado no modo forward, é necessário efetuar a configuração do local onde estará encaminhando o
trafego, nesse caso será o próprio pfSense®.

3.5 – Seguindo na configuração do modo forward, temos a opção Integration source settings, aonde define-se a localização
do grupo de usuários, selecionando se ele estará no E2guardian, ou no AD. E no group name source e alias name source,
você define se deve ser localizado pelo nome ou pela descrição, o grupo no AD, utiliza-se a descrição quando o nome do
grupo ultrapassa os 15 caracteres. A princípio vamos configurar com os grupos do E2guardian, mais a frente verificaremos
com o AD.

8
4 – Configuração com grupos E2guardian.
4.1 – Seguiremos com a configuração do grupo para a utilização com E2guardian, criando então alguns grupos locais.

4.2 – O primeiro grupo que vamos configurar será denominado “suporte” com a configuração padrão básica em todos os
itens, e a configuração normal no tipo do grupo e nos acessos (Essa que possui várias configurações especificas, sendo
efetuada conforme a demanda do grupo).

9
4.3 – Criamos um segundo grupo “operacao”, com uma configuração mais limitada, alterando o tipo do grupo de normal para
Exception Sites Only.

10
4.4 – Criamos então alguns usuários em cada grupo, para poder efetuar o controle a partir do E2guard. (Caso a configuração
do user group location esteja como AD, aqui não tem necessidade de adesão visto que ele importara do próprio AD, porém
os nomes dos grupos daqui devem ser os mesmos que no AD).

4.5 – Voltando ao UserAuth, temos a segunda aba, que é onde se efetua a integração de domínios, no momento não
efetuaremos essa configuração.

4.6 – Na guia usuários locais, é possibilitada a criação dos usuários locais para o UserAuth, mas também não criaremos
esses usuários.

11
4.7 – Na aba Active Session, é onde aparecem os usuários que estão ativos, neste caso ainda não possuímos nenhuma
conexão ativa. Também existem as guias “social login moderation” e “banned”, mas elas serão verificadas depois.

4.8 - Na aba logs ficam registrados os logs do UserAuth, bem como a configuração dos logs do mesmo.

4.9 – Configuramos os aliases para gerarmos as regras de análise de trafego.

12
4.10 – Gerando um alias para cada grupo que possuímos.

13
5 – Configurando o E2guardian
5.1 – Configuramos o E2guardian para comunicar no grupo local, com configuração (opcional) em modo transparent, para
não aparecer os dados para o cliente.

5.2 – Após configurar e aplicar, deve-se gerar uma CA também.

14
5.3 – Efetuamos a configuração básica de um CA.

5.4 – Após criado a CA, adiciona-se ela também na configuração do e2guardian.

15
5.5 – Ainda na configuração do E2guardian, é necessário habilitar a autenticação DNS para poder interagir com o pacote de
autenticação.

6 – Configurando WPAD.
6.1 – O WPAD, é um pacote opcional, que permite ter o captive portal em http, enquanto a interface do pfSense® permanece
em https. Inicialmente certifique-se de que as regras do firewall estão configuradas para o funcionamento da rede, no nosso
exemplo deixamos as regras padrões para liberação geral.

6.2 – Desative o WebGUI Redirect no Admin Access, pois o WPAD solicita essa desativação.

16
6.3 – Vamos então as configurações do WPAD.

6.4 – Na nossa configuração colocamos em loopback para comunicação pela VM com a porta configurada em NAT e
direcionada pra localhost, mas a configuração pode ser direcionando para cada uma das interfaces.

6.5 – Quando criado o WPAD ele gera um script automático, quando salvo e clicado em editar.

17
6.6 – Então vamos alterar o proxy, para caso alguma maquina solicitar o WPAD no nosso DNS, ele vai retornar para o proxy
local, no nosso caso 192.168.25.1 na porta 8080.

6.7 – Com o WPAD configurado, vamos de volta para a configuração do UserAuth, e mandamos ele salvar novamente, para
ele verificar a presença do WPAD configurado e efetuar os ajustes necessários para a página do captive portal aparecer.

6.8 – Agora temos que configurar a regra de NAT, para funcionar com o WPAD, já que preferimos configurar como localhost.

18
6.9 – Configuramos na interface LAN, para este LAN Address, na porta 80, e configuramos para redirecionar para loopback.

6.10 – Podemos efetuar a validação do pacote, testando em outro computador, no nosso caso, estamos testando em uma
máquina VM com Linux. Caso na opção proxy.pac, ele já traga as configurações do WPAD o proxy já está funcionando.

19
6.11 – Lembrando que o proxy esta como transparent, então ele não altera na máquina.

7 – Testando a configuração inicial

7.1 – Com tudo configurado, verificamos que ao tentar acessar um site, ele já cai na tela do captive portal.

20
7.2 – Testamos o acesso então com o usuário e a senha (como não possuímos usuários gerados utilizamos o do pfSense®),
e o mesmo já é aprovado.

7.3 – Verificamos no log do e2guardian que o usuário admin efetuou o logon, mesmo ele não fazendo parte de nenhum grupo.

7.4 – Vamos adicionar ele a um grupo

21
7.5 – E forçamos um reload do UserAuth abrindo ele e salvando novamente.

7.6 – Vamos criar outra regra no firewall, descrevendo que o suporte tem acesso total a internet.

7.7 – Vamos colocar a regra do firewall por primeiro para podermos catalogar todo o trafego que a estação efetuar.

22
7.8 – Podemos verificar na guia Active Sessions que a conexão já está ativa.

7.9 – Agora com um pouco de acessos já podemos verificar que iniciam os registros de trafego na regra do firewall.

7.10 – Vamos criar um segundo usuário para avaliar e não vamos atribuir a nenhum grupo, pois esse usuário já está
adicionado no grupo restrito.

23
7.11 – Vamos testar em uma VM Windows agora, com outro browser para testar a diversidade.

7.12 – Podemos perceber que, por estar dentro do grupo restrito o site ao qual tentávamos acessar já foi bloqueado.

24
7.13 – Vamos criar uma exceção, para testar o acesso.

7.14 – Agora testando o site adicionado como exceção, percebemos que ele já está acessando normalmente.

8 - Configurando o UserAuth com AD e domínio.

8.1 – 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.

25
8.2 – Agora vamos para a aba de domínios no UserAuth e vamos atribuir um.

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

8.4 – E vamos na configuração do UserAuth e adicionamos a opção AD.

26
8.5 – 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.

8.6 – 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 generals/advanced options.

8.7 – E vamos remover os usuários dos grupos do E2guard, para não ter problema com o AD.

27
8.8 – Criamos grupos e usuários dentro do AD.

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

28
8.10 – 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.

8.11 – Então vamos forçar a desconexão das sessões.

8.12 - Agora vamos forçar o logon da conta do Marcelloc no domínio.

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

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

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

8.16 – Na tabela de real time do E2Guardian, também podemos verificar que a conta já está sendo utilizada.

30
8.17 – Agora vamos duplicar a regra de acesso para avaliar trafego, antes configuramos um alias de portas para auxiliar.

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

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

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

8.21 – 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).

8.22 – 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.

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

8.24 – 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).

33
8.25 – Agora vamos liberar o filtro SSL para o grupo.

8.26 – E vamos liberar o acesso aos sites no e2guardian.

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

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

35
8.29 – Liberado e baixado o mesmo, podemos importar para o browser.

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

36
8.31 – 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.

9 – Integração da autenticação AD com o Captive Portal local.

9.1 – Essa configuração efetua a comunicação do AD com o captive portal, efetuando com que, caso um equipamento não
esteja adicionado no AD, ele vai para a tela de autenticação do Active portal. Para iniciamos adicionando um Server de
autenticação.

9.2 – Efetuamos a configuração de um server com a autenticação LDAP, na descrição do nome podemos colocar qualquer
coisa, no nosso caso estaremos colocando AD.

37
9.3 – Configuramos o IP do servidor.

9.4 – Configuramos ele para a árvore inteira, com a nossa base local, que é o lab.local. Os containers colocamos como
Usuários, não colocamos autenticação anônima, e utilizamos a autenticação do administrador local.

9.5 – Por garantia o container libera a possibilidade de adicionar mais containers para autenticação, vamos adicionar eles
para ter certeza de que a base será importada.

38
9.6 – Configuramos os parâmetros UTF-8 e salvamos.

9.7 – Vamos para a tela de configuração, e dizemos que o servidor de autenticação é esse que nós configuramos. Clicamos
em salvar e testar.

9.8 – Caso tudo esteja certo, ele já carrega as informações. Caso a quantidade de grupos no AD seja extensa, a página de
teste se torna bem maior.

39
9.9 – Vamos efetuar o teste agora com a máquina virtual Linux, mas antes certificamos que as configurações estejam ok.
9.9.1 –Nas sessões ativas possuímos somente a do Windows, configurada antes pelo AD.

9.9.2 – A busca de informações por grupo no AD está ok.

9.9.3 – E na tela da autenticação do UserAuth, ele está configurado como Forward, sendo que ele funciona no local, e caso
ele não consiga acessar passa para o LDAP.

9.10 – 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.

40
9.11 – Utilizamos o usuário do AD para acessar.

9.12 – E o mesmo já efetua a autenticação e libera o acesso para a rede.

9.13 – Testamos o acesso em um site que não está permitido e o mesmo já retorna com a tela de bloqueio.

41
9.14 – E como não possuímos o certificado SSL instalado nessa máquina, caso tentamos acessar um site que efetue a
solicitação do certificado ele vai solicitar o mesmo.

9.15 – Para efetuar a instalação do certificado, sem a necessidade de acessar o firewall, ele é disponibilizado na tela de
autenticação.

42
9.16 – Efetuamos a importação do mesmo.

9.17 – Assim que instalado, ele passa a confiar na unidade certificadora e já retorna na tela de bloqueio.

9.18 – E se acessarmos os logs do E2guardian podemos verificar todos os logs de acesso bloqueado.

43
10 – Integração da autenticação com o captive portal do pfSense®.
10.1 – 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).

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

10.3 – Criamos então, um captive portal

10.4 – Configuramos ele na LAN

44
10.5 – Configuramos a autenticação por usuários locais ou voucher, e salvamos, efetuando uma configuração bem simples
nele.

10.6 – Agora sim, podemos configurar o UserAuth como pull and push, e selecionamos o Captive portal LAB, recém-criado.

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

10.8 – Efetuamos o acesso novamente da máquina virtual.

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

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

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

46
10.12 – 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®.

10.13 – 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.

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

47
10.15 – 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).

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

11 - Autenticação em banco de dados corporativos através de URL/webservice

11.1 - 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.

48
11.2 – 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.

11.3 – 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.

11.4 – 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.

49
11.5 O nosso teste autenticou.

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

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

11.8 – Testamos agora com o usuário joao.silva.

50
11.9 – O mesmo autenticou perfeitamente também.

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

11.11 – 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.

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

51
11.13 – 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.

11.14 – 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.

52
11.15 – Efetuamos o teste com o usuário salvo no nosso banco.

11.16 – Ele autenticou.

11.17 – 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.

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

11.19 – 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.

12 – Autenticação por MAC Address

12.1 – Nessa nova versão do UserAuth, foi incluída uma aba de usuários locais do UserAuth, podendo criar e gerenciar
usuários dentro da própria ferramenta.

54
12.2 – Dessa forma pode-se criar usuários e colocar um tempo de utilização desse usuário, por exemplo, colocando um
número de dias que ela ficará ativa, ou a data em que será expirada.

12.3 – Também, nas opções avançadas do usuário, é possível definir um MAC Adrress especifico para um usuário e senha,
removendo a necessidade de autenticação por um determinado equipamento.

12.4 – Na guia do captive portal, agora podemos também, adicionar somente usuários do UserAuth, vamos deixar somente
ela selecionada para efetuar os testes da ferramenta.

55
12.5 – Vamos tentar efetuar a conexão através do usuário que criamos no UserAuth.

12.6 – O mesmo autenticou normalmente.

12.7 – Nas conexões ativas, o mesmo já está aparecendo como ativo também, e conforme já havíamos definido que o usuário
joao.silva estaria no grupo operação, o mesmo já se conectou pelo grupo.

56
12.8 – Vamos efetuar a desconexão do usuário e definir um MAC Address para esse usuário.

12.9 – Dessa foram pegamos o MAC da minha máquina virtual.

12.10 – E inserimos na nossa ferramenta, dessa foram o nosso captive portal reconhecerá que, toda vez que esse MAC
conectar na rede, o usuário joao.silva estará efetuando a conexão.

12.11 – Podemos perceber que, agora, de forma totalmente transparente, o MAC foi reconhecido, pela ferramenta e habilitou
o acesso, sem a necessidade de inclusão de usuário e senha.

57
12.12 – Nas nossas conexões o usuário já está aparecendo como ativo.

12.13 – E nos nossos logs, podemos perceber que o mesmo reconhece que o usuário joao.silva efetuou a conexão com
sucesso através do mac/user do UserAuth.

12.14 – Como o nosso usuário está no grupo de operação, vamos criar uma regra de ping para avaliar o trafego sobre o
próprio grupo.

12.15 – Efetuando um ping na nossa máquina virtual, verificamos que o trafego no grupo operação pela nossa regra, já está
sendo realizado.

58
12.16 – Também dentro do pfSense®, podemos definir usuários com acessos exclusivos para adição e gerenciamento
desses usuários, para exemplo, criamos um usuário de sistema do pfSense®.

12.17 – E configuramos acesso somente ao UserAuth.

12.18 – Testamos agora nossa nova conexão, e verificamos que ela somente possui acesso à, local users, active sessions
e logs.

12.19 – Possibilitado, dessa forma, o usuário da empresa, criar usuários específicos, para, caso chegue alguém que necessite
utilizar a rede, o mesmo seja definido na hora.

59
12.20 – Dessa forma, a usuária está inclusa, e ao conectar-se à rede, ela já cairá no captive portal, onde deve colocar o
usuário e senha recém-criado.

13 – Autenticação pelas redes sociais (Facebook).

13.1 – Inicialmente na guia de configuração do UserAuth, devemos configurar o acesso através do Facebook.

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

13.3 – 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.

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

13.5 – 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 com o perfil do Facebook acima.

13.6 – Dessa forma, ele já disponibiliza o acesso através do perfil do Facebook.

61
13.7 – 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.

13.8 – 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.

13.9 – 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.

62
13.10 – 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.

13.11 – Então vamos testar. Tentando acessar de um site qualquer, já caímos na tela de login pelo Facebook.

13.12 – Ao efetuar a conexão pelo Facebook, ele já efetua a autenticação, e joga para uma tela de aguarde.

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

13.14 – 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.

13.15 – Dessa forma, ao atualizar a página, ela já nos disponibiliza a conexão novamente.

64
13.16 – Novamente o social é encaminhado ao moderador, vamos desta vez efetuar a liberação.

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

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

13.19 – 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.

65
13.20 – 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.

13.21 – Assim que banido, a tela do usuário já recebe essa informação.

66
13.22 – Vamos efetuar a remoção do MAC Address da regra de banimento, e agora bloquear o nosso usuário.

13.23 – 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.

67
14 - Login Social com o Google.
14.1 – Para a conexão através do login social do Google, deve ser flegada a opção Google da autenticação dos usuários.

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

14.3 – 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.

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

68
14.5 – 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.

14.6 – Outra implementação da versão atual do UserAuth, é a possibilidade de adição de somente redes sociais.

69
14.7 – Efetuando a conexão através do Google, ele já conecta, nesse caso, como estamos com a moderação ativa, ele
informa ao moderador.

14.8 – 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.

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”

70