CAFe
  • CAFe
  • Central de Ajuda - CAFe
  • Políticas do Serviço
    • Termo de privacidade do Provedor de Serviço (SP)
    • CAFe Service Provider (SP) Privacy Agreement
    • Política da Comunidade Acadêmica Federada (CAFe)
    • Politics of Federated Academic Community (CAFe)
  • Aviso - Vulnerabilidade Shibboleth SP
  • Verificação de Inicidentes
  • Lista de Clientes
  • Atributos da CAFe
  • Perguntas Frequentes
    • FAQ - CAFe
    • FAQ - Pentaho
  • Pentaho
    • Pentaho
    • Procedimentos de Instalação
      • Procedimento de importação do template de Máquina Virtual (PDI 9.0)
      • Instalação Cliente PDI - Versão 9
      • Configuração do EID-PDI
        • Apresentação da Arquitetura do EID-PDI
        • Vídeo de configuração do EID-PDI
        • Descrição do modelo de dados EID
        • Descrição dos Jobs e Transformações disponíveis no PDI/EID
        • Descrição dos parâmetros do EID/PDI 9.0
        • Logs EID PDI
      • Controle de versão Pentaho Data Integration
      • Pentaho Módulo Web
        • Relatórios Pentaho
        • Agendamento de Jobs
      • Instalação do Apache DS - Windows
      • Tutorial Básico Apache DS
      • Procedimentos de criação da VM EID PDI
  • OpenLDAP
    • Instalação do OpenLDAP com esquema brEduPerson no Ubuntu 22.04
    • Habilitando o campo do sambaNTPassword
  • IDP CAFe
    • Requisitos de Uso
    • Manual de Usuário
      • Problemas no acesso CAFe
      • Coleta/Verificação de Atributos
        • Chimarrão (Homologação)
        • CAFe (Produção)
    • Procedimentos Técnicos
      • Como alterar o atributo principal de autenticação em seu IDP
      • Gerar nova chave e certificado para o shibboleth
      • Gerar nova chave e certificado para o Apache (auto assinado)
      • Instalando um certificado web válido em um IdP
      • Critérios de consulta ao OpenLDAP para Shibboleth
      • Altera nível do log do IDP para DEBUG
      • Ajustando Atributos CPF e Data de Nascimento para ICPEdu
      • Alterando o hostname e dominio de um IdP em produção na CAFe
      • Desabilitando o serviço Fail2ban do IdP CAFe
      • Instalando certificado Let's Encrypt no IDP Shibboleth
      • Customização da mensagens de login no IDP
      • Integrando o Office 365 com Shibboleth IDP
        • Office 365 - Configuração no Shibbboleth IDP
        • Office 365 - Configuração no Microsoft Entra
      • Instalação Manual do MFA CAFe
        • Requisitos de instalação do MFA
        • Procedimento de instalação
        • Configurações importantes - CAPTCHA
        • Ambiente com Redundância
        • Operando MFA
      • Alta Disponibilidade do Serviço
  • RPilot (IDP)
    • Instalação IDP RPilot
      • Escolhendo o Produto
      • Execução da Receita
        • Solicitar Execução
        • Parâmetros de uma receita
        • Revisão das Variáveis
        • Solicitações de Execuções
      • Homologar a instalação do IDP
      • Homologar a instalação do MFA
      • Customização da logo Institucional
    • Sobre o MFA CAFe
      • Senhas descartáveis MFA
      • Códigos de Emergência MFA
  • Service Provider (SP)
    • Guia de Instalação Shibboleth SP (3.4)
Powered by GitBook
On this page
  • Informações Importantes
  • Executando
  • Configuração Servidor Primário
  • Configuração Servidor Secundário
  • Pontos de Atenção
  • Etapas Adicionais
  • Cópia de chaves de segurança
  • Acerto de /etc/hosts
  • Certificado SSL
  • Libertações de Firewall

Was this helpful?

Export as PDF
  1. IDP CAFe
  2. Procedimentos Técnicos
  3. Instalação Manual do MFA CAFe

Ambiente com Redundância

PreviousConfigurações importantes - CAPTCHANextOperando MFA

Last updated 11 months ago

Was this helpful?

Informações Importantes

Em instalações com redundância, existem alguns passos manuais adicionais que devem ser executados. Verifique atentamente cada um dos pontos apresentados.

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.

ATENÇÃO, o primário deve ter sido instalado ANTES de iniciar a instalação do 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.

Origem
Destino

Primário(1.1.1.1)

Secundário(2.2.2.2)

TCP 5432

Secundário(2.2.2.2)

Primário(1.1.1.1)

TCP 5432

Primário(1.1.1.1)

Servidor SNMP

Vai depender da Configuração do Servidor

Secundário(2.2.2.2)

Primário(1.1.1.1)

TCP 443