Requisitos

Antes de seguir com esta seção é importante a leitura integral das seções anteriores e da documentação de apoio gerada. Consulte as documentações de apoio indicadas ao final deste documento.

1. Garanta que efetuou o backup de toda a instalação do IDP (pasta padrão /opt/shibboleth-idp;

2. Garanta que efetuou o backup das configurações do servidor apache (pasta padrão /etc/apache2)

3. Garanta que efetuou backup dos certificados configurados no servidor apache (são os arquivos de certificado - geralmente .crt e .key referenciados dentro dos arquivos de configuração do apache em /etc/apache2/sites-enabled/)

Certifique-se que seu servidor tem os recursos necessários. Recomendamos ao menos:

• 4GB de RAM;

• 20GB de espaço em disco livre disponível.

• Conforme o nível de uso do seu IDP, pode ser necessário mais recursos. Recomendamos monitorar o nível de uso dos recursos computacionais para verificar se o mesmo está operando em níveis aceitáveis.

Outros requisitos considerados são:

• IDP Shibboleth 4.2.1 ou superior instalado na pasta padrão (/opt/shibboleth-idp)

• Servidor Ubuntu 20.04.5 LTS ou Ubuntu 22.04.5 LTS (SO que foram homologadas)

• Seu IDP faz uso de certificados VÁLIDOS no APACHE (em caso de certificados auto assinados - como ambiente de testes - é necessário procedimentos adicionais manuais para a instalação do MFA).

• Seu SP MFA fará uso obrigatório do recurso SMTP. Para isso será necessário que a instituição tenha disponível uma conta SMTP(host SMTP, usuário e senha) para envios de mensagens geradas pelo MFA.

Gerenciando o serviço do painel de segurança

systemctl stop mfa.service
systemctl status mfa.service
systemctl start mfa.service

Verificando os logs

Painel de segurança: /opt/dashboard/logs

Shibboleth: /opt/shibboleth-idp/logs/mfa-plugins.log (onde são logados dados específicos associados ao MFA)

Dúvidas Frequentes?

Ocorreu um erro durante a execução do script, o que devo fazer?

Copie o texto de erro (copiar tudo que apareceu na tela) e passe para a equipe da CAFe de forma que possamos investigar.

Material de Apoio

https://ajuda.rnp.br/cafe/manual-do-usuario/painel-de-seguranca-mfa-cafe : site de ajuda do MFA

Premissas e Informações importantes

• Necessário ter o IDP 4.2.1 ou superior

Recomendamos também a leitura da documentação geral do MFA, para um melhor entendimento deste documento. Ou seja, NÃO é escopo deste documento descrever o processo de instalação do IDP, mas sim, somente a instalação dos componentes adicionais associados a suporte de MFA.

Conceitos e Terminologias

Componentes

A instalação do MFA no seu IDP envolve a instalação dos seguintes componentes:

• Banco de Dados: é instalado um banco de dados no seu IDP. O banco de dados é utilizado para armazenar os dados associados aos MFA dos usuários. O banco de dados é acessado tanto pelo IDP como pelo painel de Segurança. Caso o mesmo fique indisponível irá acarretar também na indisponibilização dos mesmos;

• Plugins MFA: envolve uma série de componentes adicionados à instalação do seu IDP. Compreende bibliotecas Java, novas páginas, novos arquivos de configuração, etc. Na instalação dos plugins também é necessário alterar alguns arquivos de configuração existentes no seu IDP;

• Painel de Segurança: painel de segurança MFA ou Dashboard MFA. Estes dois termos podem ser utilizados para referenciar esta aplicação. Se trata de uma aplicação java que é instalada também no seu servidor IDP.

A figura a seguir ilustra os componentes citados.

Atente que as requisições sempre chegam no Apache, que por sua vez, encaminha para o IDP ou para o Painel de Segurança, conforme ação realizada pelo usuário.

Fatores de autenticação

Os seguintes fatores de autenticação são suportados atualmente:

• Senha Descartável: Senha Descartável ou OTP (One Time Password). Valor que altera ao longo do tempo. Mesmo que o valor seja roubado, ele não poderá ser reutilizado posteriormente, garantindo assim maior segurança no processo de autenticação;

• Código de Emergência: Código de Emergência ou Backup Code. Consiste de um conjunto de senhas que podem ser utilizadas uma única vez. Como não podem ser reutilizadas, também possibilitam maior segurança no acesso.

Outros mecanismos de proteção e facilidades suportadas:

• CAPTCHA: além de suporte a fatores de autenticação adicionais para aprimorar a segurança do acesso, os plugins instalados no seu IDP permitem a ativação do CAPTCHA. O CAPTCHA é um mecanismo que tenta proteger contra ataques de força bruta, que é quando robôs são criados para tentar descobrir a senha do usuário tentando realizar o acesso múltiplas vezes, cada vez, tentando uma combinação diferente até descobrir a senha do usuário. O CAPTCHA que foi integrado é o do Google. A ativação do CAPTCHA é opcional e envolve etapa adicional manual detalhada posteriormente em outra seção deste documento.

• Dispositivos Confiáveis: a solicitação de outros fatores de autenticação podem gerar um incômodo nos usuários, uma vez que eles terão que realizar passos adicionais para se autenticar. Para minimizar este problema, o usuário pode através do painel de segurança configurar um dispositivo como confiável. Assim, caso o usuário marque seu computador pessoal como confiável, o IDP somente irá verificar o usuário e senha. Logicamente o usuário NÃO deve marcar um dispositivo de uso público/compartilhado como confiável. Um aspecto importante que precisa ficar claro, é que apesar do nome “Dispositivo Confiável”, na prática, armazenamos a informação do browser do usuário. Assim, se o usuário navega na Internet pois mais de um Browser, ele terá que adicionar cada um dos Browsers como confiável. Por questões de segurança o tempo que um browser é marcado como confiável expira após um tempo e precisa ser configurado novamente pelo usuário como confiável. O processo de guardar a informação dos dispositivos confiáveis envolve também guardar um cookie no browser marcado como confiável. Assim, a limpeza de cookies pode também fazer com que o mesmo deixe de ser considerado confiável. A qualquer momento, através do painel de segurança o usuário pode marcar os dispositivos como não sendo mais confiáveis.

Para maiores informações sobre o Painel de Segurança do MFA, favor acessar o procedimento de ajuda neste link.

Caso ainda ocorram duvidas, favor entrar em contato com a RNP através do e-mail: atendimento@rnp.br

As configurações devem ser realizadas no arquivo “/opt/shibboleth-idp/conf/idp.propeties”. Devem ser configuradas as informações indicadas a seguir:

rnp.authn.CaptchaToken.key
rnp.authn.CaptchaToken.secret

Para obter os valores a serem preenchidos, deve ser realizado o procedimento de cadastro da junto ao Google. Procedimentos em: https://www.google.com/recaptcha/admin/create

A figura a seguir detalha o processo de cadastro. No processo de cadastro, selecione a opção “reCAPTCHA v2”. e depois “Selo de reCaptcha invisível”. EM etiqueta digite qualquer palavra que te ajude a lembrar do que se trata o cadastro. Importante é cadastrar adequadamente o domínio em “Domínios” (digitar o domínio ao lado do botão “+”).

Ao final, clique em “Enviar”. Será exibida uma tela como a seguir.

Basta copiar os dados e configurar no arquivo de propriedade.

● rnp.authn.CaptchaToken.key=[colocar aqui o valor de “Chave de site”]

● rnp.authn.CaptchaToken.secret=[colocar aqui o valor de “Chave secreta”]

A configuração ocorrerá em duas etapas:

Configuração no Shibbboleth IDP

Configuração no Microsoft Entra

Dicas

1. Testar a liberação de atributos

1. Exibir configurações da autenticação federada.

1. Retornar para autenticação gerenciada

1. Criar usuário

O valor a ser utilizado como ImmutableId é obtido a partir do NameID. Para obter esse valor execute o comando descrito em Dicas 1.

1. Introdução

Este tutorial apresenta os passos necessários para efetuar a instalação do diretório OpenLDAP com o esquema brEduPerson no Ubuntu Server 22.04 LTS. Será utilizada a abordagem OLC (cn=config) que permite a alteração de configurações em tempo real.

2. Roteiro

2.1. Inicialmente, copie e cole o seguinte bloco de linhas:

Execute as linhas com os valores substituídos conforme a observação anterior:

Em seguida execute o comando:

Por fim, instale o slapd e ldap-utils:

2.2. Para iniciar a configuração do usuário admin do cn=config faça a geração do hash da senha. Para tanto, execute o comando a seguir:

Após a execução do comando, será solicitado a criação de uma senha. Desta senha, será criada um Hash, guarde esta informação.

2.3. A seguir, crie o arquivo /root/admin-cn-config.ldif com o seguinte conteúdo:

2.4. Aplique a configuração da senha do usuário admin do cn=config:

2.5. Faça download e importação dos schemas:

Em seguida, execute a importação dos schemas individualmente:

2.6. Caso a máquina possua Firewall local, para liberar o acesso as portas utilizadas para acesso remoto ao LDAP, adicione as linhas a seguir no final do arquivo de regras do firewall (/etc/default/firewall).:

Em seguida, reinicie o firewall.

2.7. Por fim, para fazer a carga inicial de dados e ajuste de ACLs, execute as linhas abaixo:

Edite o arquivo popula.sh e altere as seguintes informações de RAIZ_BASE_LDAP e DOMINIO_INST no início do arquivo, de acordo com o seu domínio, conforme o exemplo:

Altere o script para ser executado:

Execute o script popula.sh

3. Acesso ao OpenLDAP

3.1. Para acessar a DIT principal deve-se utilizar os seguintes parâmetros:

• Hostname: IP do Servidor

• Porta: 389

• Bind DN: Concatenação de "cn=admin" com a Base DN. Ex.: cn=admin,dc=rnp,dc=br

• Bind Password: Senha definida no item 2.1. Padrão "changeit" caso não tenha sido alterada.

• Base DN: Conversão da varíavel ${DOMINIO-INSTITUICAO} do item 2.1 para o formato LDAP. Ex.: "rnp.br" >> "dc=rnp,dc=br"

3.2. Para acessar a DIT de configuração deve-se utilizar os seguintes parâmetros:

• Hostname: IP do Servidor

• Porta: 389

• Bind DN: cn=admin,cn=config

• Bind Password: Senha definida no item 2.3.

• Base DN: cn=config

1. Digite o FQDN da máquina: se trata do FQDN do seu servidor IDP. Exemplo: “idp.instituicao.br”

2. Digite o texto a ser exibido para o usuário de forma que ele saiba o que deve preencher para se autenticar (ex.: Seu email @rnp.br): cada instituição utiliza uma informação diferente para se autenticar, seja o número de matrícula, um email, etc. Neste campo você personaliza o texto que deve ser exibido ao usuário na tela de usuário e senha.

3. Link de recuperação de senha (ex.: https://urlpaginarecuperacaodesenha.instituicao.br): informação opcional. Recomendamos fortemente que preencha esta informação caso tenha uma url que os usuários possam acessar para recuperar a senha.

4. Você está utilizando um ambiente de alta disponibilidade: esta informação se aplica para as instituições que possuem mais de um servidor IDP e que estes servidores operem de forma concomitante, ou seja, em que os servidores estejam ativos ao mesmo tempo. Caso este seja esta a sua situação, recomendamos que entre em contato com a equipe da CAFe para realizar uma instalação monitorada, uma vez que a instalação envolve alguns passos adicionais e pontos de atenção adicionais. Caso seja um ambiente de alta disponibilidade, será perguntado as seguintes informações adicionais:

Se o servidor que está sendo instalado é o primário/principal ou se é o servidor secundário: se sua instituição tiver uma instalação com redundância, um dos servidores servidores precisará ser definido como servidor principal (primário). Todos os demais servidores serão considerados como secundários. Assim um ambiente com redundância terá um servidor principal e um ou mais servidores secundários. Recomendamos a leitura da seção que detalha pontos importantes associados a ambientes com redundância.

1. Digite o endereço IP do servidor primário: deve ser o IP do servidor definido como servidor principal

2. Digite o endereço IP do servidor secundário: deve ser o IP do servidor secundário. ATENÇÃO, só instale o servidor secundário caso o servidor primário já tenha sido instalado.

3. Digite o FQDN alternativo do servidor primário: este FQDN é utilizado para o servidor secundário se comunicar com o servidor primário.

4. Digite a senha para sincronização da base: pergunta realizada somente na instalação do servidor secundário. Necessário para o servidor secundário se conectar na base de dados do servidor primário. No detalhamento da instalação de ambiente redundante é explicado onde a informação da senha é obtida.

5. Digite o nome do usuário administrador (ex.: Joao da Silva): Será criada uma conta inicial de administrador para o usuário em questão: quando o painel de segurança é instalado, é cadastrado automaticamente um usuário inicial que receberá permissão de administrador. Será este usuário que irá atribuir permissões de administrador e operador a outros usuários. Certifique que todos os dados do usuário administrador inicial foi cadastrado corretamente

6. Digite o e-mail do usuário administrador (deve ser o mesmo cadastrado no IDP): associado ao cadastro do administrador. Deve ser o MESMO e-mail que o usuário tem cadastrado no IDP da instituição.

7. Digite o EPPN do usuario administrador (somente o valor antes do @): Exemplo, se valor de eppn for abc@instituicao.br, deve ser cadastrado somente abc: associado também ao cadastro do administrador. O EPPN na maior parte das instituições é o MD5 do username. Em caso de dúvidas do valor, peça para o usuário administrador acessar a url e se autenticar. Após a autenticação, será exibida a informação eduPerson-eduPersonPrincipalName. Pegue a informação que vem antes do @. A figura a seguir mostra um exemplo onde é retornado “73637a38dea854e281cda9f6f00af507@instituicao.br”.

• O valor que deve ser copiado é somente “73637a38dea854e281cda9f6f00af507”.

1. Digite o endereço do servidor SMTP: se trata dos dados de acesso necessários para que o painel de segurança possa enviar e-mails. Preencha aqui o endereço do servidor SMTP. Exemplo: smtp.instituicao.br.

2. Digite a porta do servidor SMTP: porta do servidor SMTP. Exemplo: 587.

3. Digite o username do usuario SMTP: conta a ser utilizada para se autenticar no servidor SMTP.

4. Digite a senha do usuario SMTP: senha para autenticação na conta SMTP.

5. Digite o Nome amigavel a ser exibido para identificar quem envia os e-mails: na ser exibido para identificar quem envia os e-mails (exemplo: Nome da Instituição).

6. Digite o E-mail do originador: E-mail do originador. Se trata do e-mail que será exibido para o usuário como originador do e-mail (exemplo: no-reply@instituticao.br)

Instalação

Toda a instalação é realizada através de um script. Este script faz diversos procedimentos, sendo:

1. Download dos arquivos necessários para a instalação;

2. Cópias dos arquivos baixados para os locais de instalação;

3. Geração de chaves de criptografia adicionais necessários;

4. Instalação da base de dados;

5. Solicita as informações necessárias para a instalação (atenção à seção anterior);

6. Realiza a instalação.

Execução do procedimento

• Baixe o script de instalação na pasta /tmp

• Dê permissão de execução para o script

• Execute o script como ROOT

Executando o Script de instalação

A seguir são detalhadas as perguntas apresentadas pelo script. Para que possa digitar as respostas é necessário saber as informações indicadas na seção 7.

Etapas do Script

Pergunta 1.

Inicialmente é solicitado o FQDN do servidor. Deve ser o FQDN configurado no DNS associado ao servidor. Em negrito é apresentada a pergunta apresentada pelo script. Em itálico é apresentado um exemplo hipotético de resposta considerando que o FDQN do servidor é “serveridp.instituicao.br”.

Digite o FQDN da maquina (exemplo: idp.instituicao.br): serveridp.instituicao.br

O valor de hostname realmente é "serveridp.intituicao.br"? (s/n) s

Pergunta 2.

Na sequência será solicitada a informação que deve ser exibida na tela de login do IDP para que o usuário se identifique. A figura a seguir mostra um exemplo de qual texto se refere. Por exemplo, se o login do usuário é o número de matrícula, digite “Seu número de matricula”

Digite o texto a ser exibido para o usuário de forma que ele saiba o que deve preencher para se autenticar (ex.: Seu email @rnp.br): Seu número de matrícula

O valor de hostname realmente é "Seu número de matrícula"? (s/n) s

Pergunta 3.

A próxima pergunta solicitada pelo script será a url que o usuário será redirecionado caso clique no link “Recuperar senha” na figura apresentada anteriormente. Caso não tenha o link, basta digitar 2. O exemplo a seguir ilustra um caso hipotético onde a url é “https://recuperasenha.instituicao”.

Link de recuperação de senha (ex.: https://urlpaginarecuperacaodesenha.instituicao.br):

1 - SIM

2 - NAO

A instituicao possui uma pagina para recuperacao de senha? 1

O valor de SIM/NAO realmente é "1"? (s/n) s

Digite a url para a pagina de recuperacao de senha (ex.: https://urlpaginarecuperacaodesenha.instituicao.br): https://recuperasenha.instituicao.br

O valor de URL página recuperacao de senha realmente é "https://recuperasenha.instituicao.br"? (s/n) s

Pergunta 4.

A pergunta apresentada na sequência é para saber se seu ambiente é redundante ou não. A resposta apresentada no exemplo a seguir considera que NÃO é um ambiente redundante.

Você está utilizando um ambiente de alta disponibilidade:

1 - Sim

2 - Não

Escolha uma das opções: 2

O valor de uso de ambiente de alta disponibilidade (caso haverá mais de um servidor) realmente é "2"? (s/n) s

Pergunta 5.

A pergunta 5 se refere ao nome do usuário a ser cadastrado como administrador do painel de segurança da instituição. O exemplo a seguir considera que o nome do administrador é “José da Silva”

Digite o nome do usuário administrador (ex.: Joao da Silva). Será criada uma conta inicial de admin para o usuário em questão: José da Silva

O valor de nome do contato tecnico realmente é "José da Silva"? (s/n) s

Pergunta 6.

Nesta pergunta você deve preencher o e-mail da pessoa cadastrada na pergunta 5 (e-mail do usuário que será o adminsitrador). Atenção que deve ser o mesmo e-mail que o usuário tem cadastrado no IDP.

Digite o e-mail do usuario administrador (deve ser o mesmo cadastrado no IDP): jose@instituicao.br

O valor de e-mail realmente é "jose@instituicao.br"? (s/n) s

Pergunta 7.

Nesta pergunta você deve digitar o EPPN do usuário a ser cadastrado como administrador. Em caso de dúvida, consulte as instruções apresentadas na seção 7.

Digite o EPPN do USUÁRIO administrador (somente o valor antes do @). Exemplo, se valor de eppn for abc@instituicao.br, deve ser cadastrado somente abc: 73637a38dea854e281cda9f6f00af507

O valor de eppn realmente é "73637a38dea854e281cda9f6f00af507"? (s/n) s

Pergunta 8.

Esta pergunta e as próximas referem-se ao servidor SMTP da instituição para envio de e-mails. Em caso de dúvida, consulte as instruções apresentadas na seção 7.

Digite o endereço do servidor smtp (exemplo: smtp.instituicao.br): smtp.instituicao.br

O valor do servidor SMTP realmente é "smtp.instituicao.br"? (s/n) s

Pergunta 9.

Nesta pergunta você deve digitar a porta do servidor SMTP da instituição para envio de e-mails.

Digite a porta do servidor SMTP (exemplo: 587): 587

O valor da porta do servidor SMTP realmente é "587"? (s/n) s

Pergunta 10.

Nesta pergunta você deve digitar o username do usuário do servidor SMTP da instituição. Em caso de dúvida, consulte as instruções apresentadas na seção 7.

Digite o username do usuario SMTP (exemplo: usernamesmtp): usernamesmtp

O valor do username do usuario do servidor SMTP realmente é "usernamesmtp"? (s/n) s

Pergunta 11.

Nesta pergunta você deve digitar a senha do usuário do servidor SMTP da instituição.

Digite a senha do usuario SMTP (exemplo: passwordsmtp): passwordsmtp

O valor da senha do usuario do servidor SMTP realmente é "passwordsmtp"? (s/n) s

Pergunta 12.

Nesta pergunta você deve digitar um nome amigavel para identificar quem envia o e-mail. Em caso de dúvida, consulte as instruções apresentadas na seção 7.

Digite o Nome amigavel a ser exibido para identificar quem envia os e-mails (exemplo: Nome da Instituicao): Nome da Insituicao

O valor do nome amigavel a ser exibido para identificar quem envia o e-mail realmente é "Nome da Instituicao"? (s/n) s

Pergunta 13.

Nesta pergunta você deve digitar o e-mail do originador que será indicado como remetente no envio do e-mail.

Digite o E-mail do originador (exemplo: no-reply@instituticao.br): no-reply@instituicao.br

O valor do E-mail do originador realmente é "no-reply@instituicao.br"? (s/n) s

Pergunta 14.

Nesta pergunta você deve digitar um nome a ser inserido no rodapé do e-mail enviado.

Digite o nome a ser colocado no rodape do e-mail. Recomenda-se colocar o nome da instituicao (exemplo: Nome Instituicao): Nome Instituicao

O valor do nome a ser colocado no rodape do e-mail realmente é "Nome Instituicao"? (s/n) s

Informações Importantes

Uma questão importante em relação a ambientes redundantes, é que a instalação é realizada de forma diferente nos servidores secundários. Ou seja, NÃO se deve clonar a instalação do servidor principal e achar que automaticamente o servidor clonado irá operar adequadamente como secundário.

Isso acontece porque os dados precisam estar sincronizados entre as bases de dados. Para garantir a sincronização de forma segura, evitando qualquer inconsistência nos dados, somente a base de dados do servidor principal opera em modo escrita.

A Figura apresentada ilustra o cenário. A base de dados no servidor secundário opera em modo somente leitura. Toda vez que o usuário está no servidor secundário e realiza alguma operação que envolve escrita na base de dados, o servidor secundário se comunica com o primário e pede para o primário realizar a escrita. Tudo que é escrito/alterado no banco de dados do servidor principal é então replicado para o banco de dados secundário.

Executando

O processo inicial de instalação do ambiente redundante é idêntico a uma instalação simples (ver seção 8.3). A diferença começa a partir da pergunta 4. Nela deve ser indicado que se trata de ambiente redundante e as perguntas seguintes irão ser distintas conforme o servidor sendo instalado (se é o servidor primário ou secundário)

Pergunta 4.

A pergunta apresentada na sequência é para saber se seu ambiente é redundante ou não. A resposta apresentada no exemplo a seguir considera que SIM, é um ambiente redundante.

Você está utilizando um ambiente de alta disponibilidade:

1 - Sim

2 - Não

Escolha uma das opções: 2

O valor de uso de ambiente de alta disponibilidade (caso haverá mais de um servidor) realmente é "1"? (s/n) s

Após a pergunta 4, as perguntas serão distintas conforme o servidor.

Conforme ilustração, dados adicionais a respeito dos servidores são solicitados no caso de ambientes redundantes. E para o servidor secundário, é necessário preencher dados específicos necessários para a replicação da base. mais detalhes a seguir.

Configuração Servidor Primário

Siga os passos a seguir se for a instalação do servidor primário.

Pergunta associada a servidores. Deve ser indicado qual servidor se trata e na sequência os dados dos servidores primário e secundário.

No que se refere à configuração do seu ambiente, esse é o servidor:

1 - Primário/Principal

2 - Secundário

Escolha uma das opções: 1

O valor de Servidor que está sendo configurado realmente é "1"? (s/n) s

Digite o endereco IP do servidor primário: 11.11.11.11

O valor de IP realmente é "11.11.11.11"? (s/n) s

Digite o FQDN alternativo para o servidor primário (exemplo: idpprimario.instituicao.br): primario.instituicao.br

O valor de hostname realmente é "primario.instituicao.br"? (s/n) s

Digite o endereco IP do servidor secundário: 22.22.22.22

O valor de IP realmente é "22.22.22.22"? (s/n) s

Na sequência, conforme a figura apresentada, devem ser respondidas as perguntas 5 a 7 já apresentadas anteriormente

Configuração Servidor Secundário

Siga os passos a seguir se for a instalação do servidor secundário.

Pergunta associada a servidores. Deve ser indicado qual servidor se trata e na sequência os dados dos servidores primário e secundário.

No que se refere à configuração do seu ambiente, esse é o servidor:

1 - Primário/Principal

2 - Secundário

Escolha uma das opções: 2

O valor de Servidor que está sendo configurado realmente é "2"? (s/n) s

Digite o endereco IP do servidor primário: 11.11.11.11

O valor de IP realmente é "11.11.11.11"? (s/n) s

Digite o FQDN alternativo para o servidor primário (exemplo: idpprimario.instituicao.br): primario.instituicao.br

O valor de hostname realmente é "primario.instituicao.br"? (s/n) s

Digite o endereco IP do servidor secundário: 22.22.22.22

O valor de IP realmente é "22.22.22.22"? (s/n) s

Pergunta de dados de replicação da base. Deve ser indicado a senha de replicação da base.

O local onde a informação deve ser verificada é indicado pelo script (arquivo /opt/dashboard/database.properties do servidor primário, no atributo database.repl.password.

Copiar o valor contido e preencher aqui. O valor da senha é um valor aleatório gerado no momento da instalação do primário. O valor abaixo é um mero exemplo. Verifique o valor no servidor primário conforme instruções.

Digite a senha para sincronizacao da base (veja no servidor primario em /opt/dashboard/database.properties o valor configurado em database.repl.password: kuj65RGe

O valor de Senha realmente é "kuj65RGe"? (s/n) s

Na sequência a instalação do secundário já é iniciada.

Pontos de Atenção

Depois de responder as perguntas (seja no primário ou no secundário), deve ser executado os procedimentos adicionais indicados nas seções Configurações Importantes - CAPTCHA (para os dois servidores). A configuração da seção SMTP associada ao servidor de e-mail é necessária somente no servidor primário. Após a execução dos procedimentos em questão, seguir com os procedimentos apresentados a seguir.

Etapas Adicionais

Seguem etapas adicionais a serem realizadas após a execução dos procedimentos já descritos anteriormente.

Cópia de chaves de segurança

No servidor principal, em /opt/shibboleth-idp/credentials, copie os arquivos a seguir para a mesma pasta no servidor secundário (sobrescrevendo no secundário os arquivos existentes):

● cafesealer.kver

● cafesealer.jks

Acerto de /etc/hosts

Em ambientes redundantes, precisamos garantir que os componentes em cada servidor se comuniquem entre si de forma adequada. Como as configurações são realizadas através da definição do FQDN, caso o DNS resolva um IP diferente a cada vez, isso pode ser um problema.

Assim é necessário editar o arquivo /etc/hosts de cada servidor para forçar que o servidor sempre resolva para o próprio IP.

Exemplo: Suponha IDP redundante de FQDN idp.instituicao.br que tem o servidor principal com IP 1.1.1.1 e o IP do servidor secundário seja 2.2.2.2. Para este caso hipotético, teremos:

Servidor principal - /etc/hosts terá uma entrada como:

1.1.1.1 idp.instituicao.br

Servidor secundário - /etc/hosts terá uma entrada como:

2.2.2.2 idp.instituicao.br

Certificado SSL

Nos casos em que o servidor secundário se comunica com o primário, é necessário um FQDN alternativo para o servidor primário. Este FQDN alternativo é utilizado para que o secundário possa se comunicar com o primário.

Ou o certificado do servidor primário precisa ter também este FQDN alternativo ou ele precisa ser um wildcard que comporte tanto o FDQN principal e secundário.

Exemplo, suponha que o FQDN do IDP seja “idp.istituicao.br” e o FQDN alternativo para o servidor primário seja “idpprimario.instituicao.br”. Assim o certificado deve responder tanto por “idp.inistuicao.br” como por “idpprimario.instiutuicao.br” (através de definiçao de alternative names no certificado) ou o certificado deve ser um wildcard como “*.instituicao.br”

É importante lembrar, que nestes casos, o Apache do primário deve ser configurado para responder aos dois domínios. Assim, é necessário adicionar na configuração do apache algo como:

ServerName idp.istituicao.br

ServerAlias idpprimario.instituicao.br

Libertações de Firewall

Decorrente das interações necessárias para que os servidores operem de forma conjunta, é necessário que sejam realizadas algumas liberações de firewall.

Conecte-se no Microsoft Entra.

Faça a definição das variáveis necessárias para a autenticação federada.

Execute a configuração da autenticação federada.

Introdução

Esse documento apresenta o passo-a-passo para a instalação de um Provedor de Identidades Shibboleth.

Roteiro de Instalação

Primeiro iremos acertar o hostname do seu IDP, lembre-se esse hostname será o seu DNS que ficará visível na URL do seu IDP na federação CAFe, escolha de forma definitiva pois a sua alteração e trabalhosa após a configuração do Shibboleth.

Usar o seguinte comando:

Agora vamos aplicar um update na base de repositório do ubuntu e instalar os novos pacotes, para isso faça o seguinte:

Próximo passo e removar os pacotes que não são necessários:

Agora vamos instalar os pacotes necessários:

Configuração de logs, firewall, ntp, java e jetty

Configurar logrotate /etc/logrotate.conf

Incluir no final do arquivo as seguintes entradas:

Configurando o Firewall

● /etc/default/firewall - arquivo com as regras de firewall

● /etc/systemd/system/firewall.service - arquivo de configuração para o systemd

● /opt/rnp/firewall/firewall.sh - script de manipulação do firewall

Ajustar permissões no firewall e habilitar serviço:

Ajustar NTP. Desabilitar o timedatectl e usar o ntp.

Adicionar repositório Amazon Corretto 11.

Configurar variável JAVA_HOME ao arquivo /etc/environment.

Instalar Java Amazon Corretto 11.

Instalar Jetty.

Baixar pacote Shib IDP e descompactar.

Baixar o firstboot.sh e ajustar permissões.

Pronto, sua instalação do servidor IDP está pronta para ser iniciada, agora você precisa configurar seu Shibboleth, Jetty e Apache mas não se preocupe porque você pode fazer isso usando o nosso script de inicialização do IDP CAFe. Basta seguir para a próxima página e o nosso roteiro estará disponível.

Em nosso roteiro usamos o usuário "cafe" com nossa senha padrão, porém na sua criação você pode ter usado um usuário e senha de sua preferência, sem problemas, apenas ignore em nosso roteiro essa informações e use as suas credencias para acessar o host via SSH.

Obrigado !

• /opt/shibboleth-idp/conf/relying-party.xml

• /opt/shibboleth-idp/conf/saml-nameid.xml

• /opt/shibboleth-idp/conf/attribute-resolver.xml

• /opt/shibboleth-idp/conf/attributes/custom/ImmutableID.properties

• /opt/shibboleth-idp/conf/attributes/custom/UserId.properties

• /opt/shibboleth-idp/conf/metadata-providers.xml

• /opt/shibboleth-idp/metadata/office365-md.xml

• /opt/shibboleth-idp/conf/attribute-filter.xml

No arquivo /opt/shibboleth-idp/conf/relying-party.xml, sob o item <util:list id="shibboleth.RelyingPartyOverrides">, adicione a configuração abaixo:

<bean id="Office365" parent="RelyingPartyByName" c:relyingPartyIds="urn:federation:MicrosoftOnline">
   <property name="profileConfigurations">
      <list>
         <bean parent="SAML2.SSO" p:encryptAssertions="false" p:signAssertions="true" p:signResponses="false" />
         <bean parent="SAML2.ECP" p:encryptAssertions="false" p:signAssertions="true" p:signResponses="false" p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" />
      </list>
   </property>
</bean>

Já no arquivo /opt/shibboleth-idp/conf/saml-nameid.xml, dentro do item <util:list id="shibboleth.SAML2NameIDGenerators">, adicione a configuração abaixo:

<!-- CAFe- Persistent NameID -->
<bean parent="shibboleth.SAML2PersistentGenerator">
   <property name="activationCondition">
      <bean parent="shibboleth.Conditions.NOT">
         <constructor-arg>
            <bean parent="shibboleth.Conditions.RelyingPartyId" c:candidate="urn:federation:MicrosoftOnline" />
         </constructor-arg>
      </bean>
   </property>
</bean>

<!-- CAFe - Persistent NameID exclusivo para Microsoft -->
<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
      p:omitQualifiers="true"
      p:format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
      p:attributeSourceIds="#{ {'ImmutableID'} }">
   <property name="activationCondition">
      <bean parent="shibboleth.Conditions.RelyingPartyId" c:candidate="urn:federation:MicrosoftOnline" />
   </property>
</bean>

Para criar os atribututos que serão usados (ImmutableID e UserId), altere o arquivo /opt/shibboleth-idp/conf/attribute-resolver.xml adicionando as linhas a seguir:

<!-- CAFe - ImmutableID para Microsoft -->
<AttributeDefinition xsi:type="Simple" id="ImmutableID">
   <InputDataConnector ref="dcLDAP" attributeNames="entryUUID"/>
</AttributeDefinition>

<!-- CAFe - UserId para Microsoft -->
<AttributeDefinition scope="%{idp.scope}" xsi:type="Scoped" id="UserId">
   <InputDataConnector ref="dcLDAP" attributeNames="uid"/>
 </AttributeDefinition>

Ainda no arquivo /opt/shibboleth-idp/conf/attribute-resolver.xml, adicione o atributo entryUUID à lista de atributos retornaveis do dataconnector dcLDAP. Exemplo:

<ReturnAttributes>%{idp.authn.LDAP.returnAttributes} mail cn givenName sn brPersonCPF schacDateOfBirth entryUUID</ReturnAttributes>

Crie o arquivo /opt/shibboleth-idp/conf/attributes/custom/ImmutableID.properties com o seguinte conteúdo:

# Microsoft Entra ImmutableID

id=ImmutableID
transcoder=SAML2StringTranscoder
displayName.en=Microsoft Entra ImmutableID
displayName.pt-br=Microsoft Entra ImmutableID
description.en=Microsoft Entra ImmutableID
description.pt-br=Microsoft Entra ImmutableID
saml2.name=urn:oid:1.2.840.113556.1.4.2
saml1.encodeType=false

Crie o arquivo /opt/shibboleth-idp/conf/attributes/custom/UserId.properties com o seguinte conteúdo:

# Microsoft Entra User ID

id=UserId
transcoder=SAML2ScopedStringTranscoder
displayName.en=Microsoft Entra User ID
displayName.pt-br=Microsoft Entra User ID
description.en=Microsoft Entra User ID
description.pt-br=Microsoft Entra User ID
saml2.name=urn:oid:0.9.2342.19200300.100.1.1
saml1.encodeType=false

Para configurar o provedor de metadados, altere o arquivo /opt/shibboleth-idp/conf/metadata-providers.xml e adicione a configuração abaixo:

<MetadataProvider id="Office365" xsi:type="FilesystemMetadataProvider" metadataFile="%{idp.home}/metadata/microsoft-md.xml"/>

A seguir baixe o arquivo de metadados da Microsoft e armazene-o no local apropriado e remova a linha <NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</NameIDFormat>.

wget https://nexus.microsoftonline-p.com/federationmetadata/saml20/federationmetadata.xml -O /opt/shibboleth-idp/metadata/microsoft-md.xml

Por fim, altere o arquivo /opt/shibboleth-idp/conf/attribute-filter.xml incluindo a política de liberação de atributos para o Microsoft Entra.

<AttributeFilterPolicy id="PolicyForMicrosoftEntra">
   <PolicyRequirementRule xsi:type="Requester" value="urn:federation:MicrosoftOnline" />
   
   <AttributeRule attributeID="UserId">
      <PermitValueRule xsi:type="ANY"/>
   </AttributeRule>
   
   <AttributeRule attributeID="ImmutableID">
      <PermitValueRule xsi:type="ANY"/>
   </AttributeRule>

</AttributeFilterPolicy>

Começando...

Primeiro passo:

Como pré requisito básico, a instituição precisa já ser aderente a CAFe e possuir um IdP configurado.

Segundo passo:

Duplicar o seu atual IDP. A atual VM IDP possui todos os arquivos necessários do Shibboleth para o funcionamento correta da instância. Duplicar o contéudo atual, que está em produção, para dentro da sua nova instância alvo, reconfigurando a rede com novo IP, NETMASK, GATEWAY.

Terceiro passo:

Criar um Load Balancer com regras de distribuição de tráfego para os dois IDPs. O LB deve responder pela URL original do IDP cadastrado na CAFe, ou seja, o Load Balancer deverá responder diretamente as requisições feitas quando acionado o IDP da instituição na CAFe. Esse Load Balancer poderá ser por exemplo, um proxy Apache ou Nginx ou outro serviço de LB.

Quarto passo:

Configurar os IP do Load Balancer no DNS para que ele assuma as respostas das requisições vindas do IdP institucional.

Considerações Finais:

Essas orientações visam exemplificar o procedimento recomendado pela equipe de operação e suporte da CAFe RNP aos clientes. Existem diversas formas e ferramentas que podem ser usadas para auxiliar, como respositorios, Load Balancers, etc...

Desta forma a operação orienta os passos necessários para ativação de uma alta disponiblidade no serviço do IdP, porém cada cliente possui seus recursos específicos que deverão ser adaptados para essa demanda.

Exemplo de um projeto em LB para o IDP da CAFe

1 IDP Local configurado em um domínio institucional com 1 LDAP local dentro do mesmo domínio local institucional. Ambos se comunicam dentro do mesmo domínio + 1 IDP Cloud configurado na nuvem em um domínio cloud com 1 LDAP Cloud dentro do mesmo domínio em nuvem.

Nessa topologia não foi apresentado a sincronização entre as bases LDAP, em domínios diferentes, mas é muito recomendado que seja feita essa sincroinzação entre as bases, pois isso pode gerar problemas na autenticação de seus usuários.

1. Introdução

Este tutorial apresenta os passos necessários para a configuração do campo sambaNTPassword no LDAP.

2. Roteiro

2.1 Após a instalação do OpenLDAP, selecione um usuário da base, como o exemplo abaixo:

2.2 Na tela à direita, selecione qualquer objectClass e clique com o botão direito. Vá em "New Value":

2.3 Na tela abaixo, procure na coluna da esquerda por "sambaSamAccount" conforme ilustrado a seguir. Selecione, e clique em "Add" depois vá em "Next":

2.4 Na tela seguinte, perceba que o objectClass do "sambaSamAccount" aparece inserido, e temos um novo campo do "sambaSID"

Após inserir o valor, clique em "Finish".

2.5 Clique na área em branco, e vá na opção "New Attribute..."

2.6 Na tela abaixo, procure por "sambaNTPassword", e em seguida clique em "Finish"

2.7 Após adicionar o atributo, ele aparecerá sem valor. Neste campo, é necessário colocar uma senha com o Hash NTLM.

Para isto, crie uma senha e converta no site abaixo para o Hash mencionado.

No exemplo abaixo, utilizamos a senha "123456", em seguida, clicamos em "Calculate NTLM Hash":

Agora temos o Hash NTLM sendo baseado na senha inserida:

Basta copia-lo para o campo do "sambaNTPassword":

2.8 Clique duas vezes na opção userPassword, que está em branco, e crie a nova senha para este campo. Feito isto, dê "OK":

2.9 Abaixo, é um exemplo de como os campos ficarão preenchidos:

Agora o LDAP estará configurado para os protocolos PAP (default) e MSCHAPv2 (sambaNTPassword).