Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Página dedicada para procedimentos com OpenLDAP com schema BrEduPerson, EduPerson e Schac.
Loading...
Loading...
Loading...
Requisitos de instalação do MFA na CAFe versão 4.2.1
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.
Antes de seguir com a instalação do MFA no seu IDP, efetue o backup de TODO SEU SERVIDOR. Em especial:
Garanta que efetuou o backup de toda a instalação do IDP (pasta padrão /opt/shibboleth-idp;
Garanta que efetuou o backup das configurações do servidor apache (pasta padrão /etc/apache2)
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 instalado na pasta padrão (/opt/shibboleth-idp)
Servidor Ubuntu 20.04.5 LTS
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.
Páginas destinadas a ajudar na etapa de configuração do MFA na CAFe versão 4.2.1
Objetivo
O escopo deste documento é detalhar os procedimentos associados à instalação do MFA nos IDPs.
Necessário ter o IDP 4.2.1 instalado (última versão homologada)
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.
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.
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.
O script de instalação foi concebido considerando uma instalação padrão do IDP Shibboleth 4.2.1.
NÃO PROSSIGA com a instalação caso tenha realizado customizações adicionais no seu IDP ou caso o mesmo não esteja instalado no local padrão.
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
Termos | Conceito |
---|---|
MFA (Multiplo Fator de Autenticação)
É quando é solicitado ao usuário mais de uma forma de autenticação, de forma a aprimorar a segurança, certificando-se que quem está fazendo o login é realmente o usuário e não uma pessoa se passando pela mesma. Por exemplo, após o usuário digitar o usuário e senha, é solicitada uma informação adicional que só o usuário tenha. Assim, mesmo que a senha do usuário seja roubada, o atacante não irá conseguir autenticar se fazendo passar pelo usuário;
Plugins MFA
Componentes adicionados à instalação do IDP para que o mesmo passe a suportar MFA;
Painel de Segurança MFA
Aplicação na qual o usuário gerencia seus fatores de autenticação adicionais. É através do Painel de Segurança, por exemplo, que o usuário indica que ele quer ativar novos fatores de autenticação na sua conta. É através do Painel também que a instituição irá administrar o serviço de MFA. Usuários podem receber permissões de administrador e operador no painel. Estes usuários poderão ter acesso a funcionalidades.
Durante essa etapa serão manipulados os seguintes arquivos:
/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
É fortemente recomendada a realização de backup do IDP antes de executar esse procedimento
No arquivo /opt/shibboleth-idp/conf/relying-party.xml
, sob o item <util:list id="shibboleth.RelyingPartyOverrides">
, adicione a configuração abaixo:
Já no arquivo /opt/shibboleth-idp/conf/saml-nameid.xml
, dentro do item <util:list id="shibboleth.SAML2NameIDGenerators">
, adicione a configuração abaixo:
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:
Ainda no arquivo /opt/shibboleth-idp/conf/attribute-resolver.xml
, adicione o atributo entryUUID
à lista de atributos retornaveis do dataconnector dcLDAP
. Exemplo:
O uso dos atributos entryUUID
e uid
é apropriado para ambientes OpenLDAP. Caso esteja utilizando outro diretório deve-se substituí-los pelos atributos correspondentes. Ex.: AD - entryUUID > objectGUID e uid > sAMAccountName.
Crie o arquivo /opt/shibboleth-idp/conf/attributes/custom/ImmutableID.properties
com o seguinte conteúdo:
Crie o arquivo /opt/shibboleth-idp/conf/attributes/custom/UserId.properties
com o seguinte conteúdo:
Para configurar o provedor de metadados, altere o arquivo /opt/shibboleth-idp/conf/metadata-providers.xml
e adicione a configuração abaixo:
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>
.
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.
Procedimento de instalação do MFA na CAFe versão 4.2.1
Quando a instalação é iniciada, uma série de informações é solicitada. Assim, ANTES de iniciar o processo de instalação, tenha em mãos as seguintes informações:
Digite o FQDN da maquina (exemplo: idp.instituicao.br): se trata do FQDN do seu servidor IDP. Exemplo: “idp.instituicao.br”
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.
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.
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 o caso da sua instituiçã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. 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.
Digite o endereço IP do servidor primário: deve ser o IP do servidor definido como servidor principal
Digite o endereço IP do servidor secundário: informação solicitada SOMENTE caso esteja instalando o servidor secundário. deve ser o IP do servidor secundário que está sendo instalado. ATENÇÃO, só instale o servidor secundário caso o servidor já tenha sido instalado.
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
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.
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 https://sp.rnp.br/ e se autenticar. Após a autenticação, será exibida a informação eduPerson-eduPersonPrincipalName. Pegue a informação que vem antes do @. Exemplo, se foi retornado “698dc19d489c4e4db73e28a713eab07b@instituicao.br”, o valor que deve ser copiado é somente “698dc19d489c4e4db73e28a713eab07b”
Somente após ter as informações indicadas em mãos, inicie os passos de instalação indicados na próxima seção.
Toda a instalação é realizada através de um script. Este script faz diversos procedimentos, sendo:
Download dos arquivos necessários para a instalação;
Cópias dos arquivos baixados para os locais de instalação;
Geração de chaves de criptografia adicionais necessários;
Instalação da base de dados;
Solicita as informações necessárias para a instalação (atenção à seção anterior);
Realiza a instalação.
ATENCÃO
Antes de iniciar a instalação certifique-se que o servidor está acessando adequadamente a Internet e que não terá nenhuma regra de firewall impedindo que o mesmo baixe o pacote de instalação associados. O script deve ser executado com um usuário com permissões de root.
Baixe o script de instalação na pasta /tmp;
Dê permissão de execução para o script: chmod +x mfa-install-v1.sh
Execute o script: /tmp/mfa-install-v1.sh
Após finalizar a instalação, alguns passos manuais são necessários serem executados.
Siga os passos indicados a seguir. Caso se trate de ambiente com redundância, veja os procedimentos descritos na seção “Ambiente com Redundância”.
Editar o arquivo “/opt/shibboleth-idp/conf/attribute-filter.xml”: é necessário editar o arquivo em questão para que o painel de segurança receba as credenciais do IDP. Para isso adicione a linha a seguir, substituindo [FQDN] pelo FQDN do servidor:
<Rule value="https://[FQDN]/sp/saml2/service-provider-metadata/dashboard" xsi:type="Requester" />
Supondo que o FQDN seja idp.instituicao.br, ficaria algo como a seguir:
Editar o arquivo “/opt/shibboleth-idp/conf/metadata-providers.xml”. É necessário adicionar neste arquivo uma entrada para que o IDP reconheça o Painel de Segurança como uma aplicação confiável.
Para isso adicione a linha a seguir, substituindo [FQDN] pelo FQDN do servidor. A linha em questão deve ser adicionada ao final do arquivo, antes de “</MetadataProvider>”.
Editar o arquivo “/etc/apache2/sites-available/01-idp.conf”: a alteração é necessária para que o apache redirecione adequadamente os acessos ao painel de segurança.
Adicionar as linhas a seguir antes de “</VirtualHost>":
ATENÇÃO, caso o arquivo já possua alguma entrada de Redirect para "/", remover a entrada em questão antes de adicionar as configurações acima.
Procedimento para auxilio em ambientes com redundância para o MFA da CAFe versão 4.2.1
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 base 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 apresenta 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.
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 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
Nos casos em que o servidor secundário se comunica com o primário, excepcionalmente o apontamento é realizado diretamente via IP.
Por conta deste requisito, é necessário que o certificado do servidor IDP contenha no alternative names uma entrada para 1.1.1.1 (no exemplo que estamos considerando como cenário).
O exemplo a seguir como deveria ser o arquivo de configuração do certificado a ser gerado com a informação do IP no alternative names para o cenário que estamos considerando como exemplo.
Gerenciando o serviço do painel de segurança
systemctl stop mfa.service: para o serviço
systemctl status mfa.service: verifica o status do serviço
systemctl start mfa.service: inicia o serviço
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)
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 encaminhe para o e-mail atendimento@rnp.br para análise do erro.
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.1. Inicialmente deve ser efetuada a instalação dos pacotes slapd
e ldap-utils
. Para tanto copie e cole o seguinte bloco de linhas:
ATENÇÃO: Lembre-se de substituir o valor das variáveis ${DOMINIO-INSTITUICAO}
(ex.: rnp.br) e ${INSTITUICAO}
(ex.: Rede Nacional de Ensino e Pesquisa).
Execute as linhas com os valores substituídos conforme a observação anterior:
O password do usuário admin por padrão é changeit, conforme descrito no códido acima. Caso queira alterar a senha, basta substituir a palavra changeit. Esta senha será usada mais tarde para o acesso feito no Apache DS.
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:
ATENÇÃO: Lembre-se de substituir o valor da variável ${HASH}
no conteúdo do arquivo pelo hash gerado anteriormente (2.2).
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.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
ATENÇÃO: Este tutorial assume a existência de um servidor previamente configurado com o padrão RNP/CAFe.
Essa página foi criada com a intenção de ajudar as instituições clientes da CAFe com a dúvida sobre como manter em seu ambiente mais de um instância do IdP em funcionamento.
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.
Os servidores de diretório, Local e em Nuvem devem se comunicar e sincronizar seus dados para que não ocorra problemas na autenticação. Isso é importante porque com o LB ativo a autenticação irá ser encaminhada para aquele IdP com maior disponiblidade, logo os dois diretórios precisam sempre estar com as bases idênticas.
Este tutorial apresenta os passos necessários para a configuração do campo sambaNTPassword no LDAP.
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"
O sambaSID é um identificador único para cada usuário, no exemplo abaixo, deixamos com o valor igual a 1, mas fica a critério da instituição qual valor deseja inserir.
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":
IMPORTANTE: A senha no campo do sambaNTPassword deverá ser a mesma senha no campo userPassword, ambos estarão criptografados de formas diferentes.
No exemplo utilizamos a senha "123456", então o userPassword deverá ser preenchido com "123456".
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).
Essa página tem como objetivo auxiliar na configuração do seu Provedor de Identidade Shibboleth IDP para acesso SSO junto ao Office 365. Roteiro válidado em ambiente com Ubuntu 22.04+Shibboleth V4.3.1
A configuração ocorrerá em duas etapas:
Configuração no Shibbboleth IDP
Configuração no Microsoft Entra
Testar a liberação de atributos
Exibir configurações da autenticação federada.
Retornar para autenticação gerenciada
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.
O Microsoft Entra (antigamente chamada de Azure AD) é a ferramenta destinada ao gerenciamento de usuários e controle de acesso no contexte de nuvem da Microsoft.
É necessário possuir um console PowerShell capaz de se conectar ao Microsoft Entra bem como as credenciais de administração.
A configuração demandará as seguintes informações:
Domino da Insituição. Ex.: instituicao.edu.br
Endereço do IDP. Ex.: https://idp.instituicao.edu.br
Certificado digital usado pelo Shibbboleth IDP disponível em
/opt/shibboleth-idp/credentials/idp.crt
. Apenas o conteúdo, sem o delimitadores de inicio e fim. Ex.: MIIDpzCCAo8CAgPo...
Conecte-se no Microsoft Entra.
Faça a definição das variáveis necessárias para a autenticação federada.
Fique atendo as substituições necessárias.
Execute a configuração da autenticação federada.
Configurações do MFA
Diversas informações ou algumas outras funcionalidades são configuráveis. Recomendamos que ajuste os arquivos de configuração para uma maior experiência de seu usuário.
Uma das configurações recomendadas de serem realizadas, são as informações associadas a envio de e-mail.
Para isso, edite o arquivo “/opt/dashboard/mfa.properties” configurando as propriedades indicadas a seguir:
Outra informação sugerida a ser configurada é “institution.site.Esta informação é exibida no e-mail enviado para os usuários.
Configure caso deseje que alguma URL institucional seja exibida junto ao e-mail.
Em ambientes com redundância, as configurações em questão só precisam ser acertadas no arquivo de propriedades do Painel de Segurança do servidor principal.
Não altere nenhuma outra informação do arquivo em questão, a menos que adequadamente instruído.
O CAPTCHA por padrão vem desabilitado. Para habilitá-lo, devem ser configuradas as suas chaves.
As configurações devem ser realizadas no arquivo “/opt/shibboleth-idp/conf/idp.properties”.
Devem ser configuradas as informações indicadas a seguir:
Deixe os valores vazio caso não deseje habilitar o CAPTCHA.
Para obter os valores a serem preenchidos, deve ser realizado o procedimento de cadastro da junto ao Google.
Os procedimentos de cadastro podem ser encontrados em: https://www.google.com/recaptcha/admin/create
No processo de cadastro, selecione a opção “reCAPTCHA v2”.
ATENÇÃO
Ao cadastrar o domínio, certifique-se que cadastrou o FDQN do servidor IDP de sua instituição. Lembre também de configurar os dados tanto no servidor principal como nos secundários (em caso de ambiente redundante).
Essa página tem por objetivo auxliar nossos clientes com a instalação manual da instância para o seu IDP v4.2.1
A proposta desse roteiro e mostrar como deve ser preparado o ambiente inicial do seu servidor IDP de forma manual, sem template. Esse roteiro não irá excluir o uso dos nossos scripts de inicialização. Fique atento aos pré requisitos !
Para iniciar esse processo você ira precisar:
Ubuntu 20.04.3 LTS server
Garantir que sua instância tenha conexão com a internet
Garantir as recomendações de hardware da sua instância, conforme a página anterior.
Esse documento apresenta o passo-a-passo para a instalação de um Provedor de Identidades Shibboleth.
Para aqueles clientes que desejam reailzar a instalação do seu IDP CAFe de forma manual, construindo a sua instância desde o início, nos temos um roteiro disponível para isso. Lembrando que a nossa recomendação é que sempre de preferência para o nosso processo automatizado.
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:
Configurar logrotate /etc/logrotate.conf
Incluir no final do arquivo as seguintes entradas:
● /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:
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 !
Essa página tem como objetivo auxiliar na configuração do seu IDP Shibboleth com a configuração de acesso SSO do Google Workspace.
Atenção !
Substituir a variável $DOMAIN presente no roteiro pelo domínio de sua instituição. Exemplo: $DOMAIN por "rnp.br"
Durante o processo de configuração em seu IDP com Shibboleth iremos editar e escrever em alguns arquivos, são eles:
relaying-party.xml
saml-nameid.xml
attribute-resolver.xml
metadata-providers.xml
attribute-filter.xml
Todos eles ficam no mesmo diretório /opt/shibboleth-idp/conf
Sugiro que seja feito um backup desses arquivos antes de edita-los, caso seja necessário basta voltar ao estado anterior deles para normalizar qualquer problema em seu IDP.
Seguir os procedimentos abaixo para a configuração da autenticação federada do Google em seu IdP:
Dentro da tag <util:list id="shibboleth.RelyingPartyOverrides">
<util:list
id="shibboleth.RelyingPartyOverrides">
...
</util:list>
Incluir o código abaixo
Dentro da tag <util:list id="shibboleth.SAML2NameIDGenerators">
Dentro da arquivo de configuração /conf/attribute-resolver.xml criar uma nova definição de atributo iniciando com o seguinte parâmetro <AttributeDefinition> para gerar o atrbituo "Gprincipal"
Dentro do diretório conf/attributes/custom/ criar o arquivo com o seguinte nome "Gprincipal.properties" e inserir o seguinte conteúdo:
Nessa etapa deve-se criar o arquivo de metadado dentro do diretório do Shibboleth. Para isso use um editor de sua preferência para criar o metadado com o segiunte nome:
google-md.xml
Dentro desse arquivo copiar e colar esse conteúdo:
ATENÇÃO! Essa etapa possui uma alteração no conteúdo abaixo, repare que nesse caso há uma variável "$DOMAIN", você deve substituir pelo domínio configurado na sua autenticação SSO do Google.
Acrescentar dentro do arquivo /conf/metadata-providers.xml o seguinte conteúdo:
Dentro da tag <AttributeFilterPolicyGroup>
Dentro do arquivo /conf/attribute-filter.xml inserir a seguinte liberação de regra:
Após terminar a criação e configuração do metadado do google será necessário reiniciar o serviço do shibboleth, para isso faça:
Sign-in page URL:
https://shibserver.university.edu/idp/profile/SAML2/Redirect/SSO
Sign-out page URL:
https://shibserver.university.edu/idp/profile/Logout
E certifique-se de que “Use a domain specific issuer” esteja marcado.
Além disso, esse "Verificiation certificate" é seu idp.crt
É isso. Depois de concluir o procedimento acima, você deverá ter uma instância do Google Apps for Education em funcionamento, autenticando-se em seu servidor Shibboleth.
Lembrando que é necessário que os usuários que irão acessar o google tenham configurado as suas permissões com acesso administrador ao espaço.