Red Hat Training

A Red Hat training course is available for RHEL 8

Instalando o Gerenciamento de Identidade

Red Hat Enterprise Linux 8

Começando a usar o Gerenciamento de Identidade

Resumo

Esta coleção de documentação fornece instruções sobre como instalar o Gerenciamento de Identidade no Red Hat Enterprise Linux 8 (RHEL) e como atualizar para ele a partir do RHEL 7.

Tornando o código aberto mais inclusivo

A Red Hat tem o compromisso de substituir a linguagem problemática em nosso código, documentação e propriedades da web. Estamos começando com estes quatro termos: master, slave, blacklist e whitelist. Por causa da enormidade deste esforço, estas mudanças serão implementadas gradualmente ao longo de vários lançamentos futuros. Para mais detalhes, veja a mensagem de nosso CTO Chris Wright.

Fornecendo feedback sobre a documentação da Red Hat

Agradecemos sua contribuição em nossa documentação. Por favor, diga-nos como podemos melhorá-la. Para fazer isso:

  • Para comentários simples sobre passagens específicas:

    1. Certifique-se de que você está visualizando a documentação no formato Multi-page HTML. Além disso, certifique-se de ver o botão Feedback no canto superior direito do documento.
    2. Use o cursor do mouse para destacar a parte do texto que você deseja comentar.
    3. Clique no pop-up Add Feedback que aparece abaixo do texto destacado.
    4. Siga as instruções apresentadas.
  • Para enviar comentários mais complexos, crie um bilhete Bugzilla:

    1. Ir para o site da Bugzilla.
    2. Como Componente, use Documentation.
    3. Preencha o campo Description com sua sugestão de melhoria. Inclua um link para a(s) parte(s) relevante(s) da documentação.
    4. Clique em Submit Bug.

Parte I. Instalando o Gerenciamento de Identidade

Capítulo 1. Preparando o sistema para a instalação do servidor IdM

As seções seguintes listam os requisitos para instalar um servidor de Gerenciamento de Identidade (IdM). Antes da instalação, certifique-se de que seu sistema atenda a estes requisitos.

1.1. Recomendações de Hardware

A RAM é a característica mais importante do hardware para dimensionar corretamente. Certifique-se de que seu sistema tenha RAM suficiente disponível. Os requisitos típicos de RAM são:

  • Para 10.000 usuários e 100 grupos: pelo menos 4 GB de RAM e 4 GB de espaço swap
  • Para 100.000 usuários e 50.000 grupos: pelo menos 16 GB de RAM e 4 GB de espaço swap

Para implantações maiores, é mais eficaz aumentar a RAM do que aumentar o espaço em disco, pois grande parte dos dados é armazenada em cache. Em geral, adicionar mais RAM leva a um melhor desempenho para implantações maiores, devido ao cache.

Nota

Uma entrada básica de usuário ou uma entrada simples de host com um certificado é de aproximadamente 5-10 kB de tamanho.

1.2. Requisitos de configuração personalizada para IdM

Instalar um servidor de Gerenciamento de Identidade (IdM) em um sistema limpo sem nenhuma configuração personalizada para serviços como DNS, Kerberos, Apache, ou Directory Server.

A instalação do servidor IdM sobregrava os arquivos do sistema para configurar o domínio IdM. IdM faz o backup dos arquivos originais do sistema para /var/lib/ipa/sysrestore/. Quando um servidor IdM é desinstalado no final do ciclo de vida, estes arquivos são restaurados.

1.2.1. Requisitos IPv6 no IdM

O sistema IdM deve ter o protocolo IPv6 habilitado no kernel. Se o IPv6 estiver desabilitado, então o plug-in CLDAP utilizado pelos serviços do IdM não se inicializa.

Nota

O IPv6 não precisa ser habilitado na rede.

1.2.2. Suporte para tipos de criptografia na IdM

O Red Hat Enterprise Linux (RHEL) usa a Versão 5 do protocolo Kerberos, que suporta tipos de criptografia como Padrão Avançado de Criptografia (AES), Camélia e Padrão de Criptografia de Dados (DES).

Lista de tipos de criptografia suportados

Enquanto as bibliotecas Kerberos nos servidores e clientes da IdM podem suportar mais tipos de criptografia, o Centro de Distribuição IdM Kerberos (KDC) suporta apenas os seguintes tipos de criptografia:

  • aes256-cts:normal
  • aes256-cts:special (padrão)
  • aes128-cts:normal
  • aes128-cts:special (padrão)
  • aes128-sha2:normal
  • aes128-sha2:special
  • aes256-sha2:normal
  • aes256-sha2:special
  • camellia128-cts-cmac:normal
  • camellia128-cts-cmac:special
  • camellia256-cts-cmac:normal
  • camellia256-cts-cmac:special

Os tipos de criptografia RC4 são desativados por padrão

Os seguintes tipos de criptografia RC4 foram depreciados e desativados por padrão no RHEL 8, pois são considerados menos seguros que os novos tipos de criptografia AES-128 e AES-256:

  • arcfour-hmac:normal
  • arcfour-hmac:special

Para mais informações sobre como habilitar manualmente o suporte RC4 para compatibilidade com ambientes herdados do Active Directory, consulte Garantia de suporte para tipos comuns de criptografia em AD e RHEL.

O suporte para criptografia DES e 3DES foi removido

Devido a razões de segurança, o suporte ao algoritmo DES foi depreciado no RHEL 7. A recente rebase dos pacotes Kerberos no RHEL 8.3.0 remove o suporte para os tipos de criptografia de um-DES (DES) e três-DES (3DES) do RHEL 8.

Nota

As instalações padrão da RHEL 8 IdM não utilizam os tipos de criptografia DES ou 3DES por padrão e não são afetadas pela atualização do Kerberos.

Se você configurou manualmente quaisquer serviços ou usuários para only usar criptografia DES ou 3DES (por exemplo, para clientes antigos), você poderá experimentar interrupções de serviço após a atualização para os últimos pacotes Kerberos, como por exemplo:

  • Erros de autenticação Kerberos
  • unknown enctype erros de criptografia
  • Os KDCs com chaves mestras criptografadas em DES (K/M) não conseguem iniciar

A Red Hat recomenda que você não use a criptografia DES ou 3DES em seu ambiente.

Nota

Você só precisa desativar os tipos de criptografia DES e 3DES se você configurou seu ambiente para usá-los.

1.2.3. Conformidade com o FIPS

Com o RHEL 8.3.0, você pode instalar um novo servidor IdM ou uma réplica em um sistema com o modo Federal Information Processing Standard (FIPS) habilitado.

O script de instalação do IdM detecta se o FIPS está habilitado e configura o IdM para usar somente tipos de criptografia que estejam em conformidade com o FIPS 140-2:

  • aes256-cts:normal
  • aes256-cts:special
  • aes128-cts:normal
  • aes128-cts:special
  • aes128-sha2:normal
  • aes128-sha2:special
  • aes256-sha2:normal
  • aes256-sha2:special

Você não pode ativar o modo FIPS em servidores onde o IdM estava previamente instalado com o modo FIPS desativado.

Para que um ambiente IdM seja compatível com FIPS, all Os servidores e réplicas IdM devem ter o modo FIPS habilitado.

Importante
  • Os trusts entre a IdM e o Active Directory (AD) não são compatíveis com o FIPS.
  • A autenticação RADIUS não está em conformidade com o FIPS.

Não instale IdM em um servidor com o modo FIPS habilitado se você precisar de fideicomissos entre florestas ou autenticação RADIUS.

Recursos adicionais

1.3. Requisitos de tempo de serviço para Idm

As seções seguintes discutem o uso de chronyd para manter seus anfitriões IdM em sincronia com uma fonte de tempo central:

1.3.1. Como IdM usa chronyd para sincronização

Kerberos, o mecanismo de autenticação subjacente na IdM, usa carimbos de tempo como parte de seu protocolo. A autenticação Kerberos falha se o tempo do sistema de um cliente IdM difere em mais de cinco minutos do tempo do sistema do Centro de Distribuição de Chaves (KDC).

Para garantir que servidores e clientes IdM fiquem em sincronia com uma fonte de tempo central, os scripts de instalação do IdM configuram automaticamente o software cliente chronyd Network Time Protocol (NTP).

Se você não passar nenhuma opção NTP para o comando de instalação do IdM, o instalador procura por registros _ntp._udp DNS service (SRV) que apontam para o servidor NTP em sua rede e configura chrony com esse endereço IP. Se você não tiver nenhum registro _ntp._udp SRV, chronyd usa a configuração enviada com o pacote chrony.

Nota

Como ntpd foi depreciado em favor de chronyd no RHEL 8, os servidores IdM não são mais configurados como servidores Network Time Protocol (NTP) e são configurados apenas como clientes NTP. O papel do servidor IdM da RHEL 7 NTP Server também foi depreciado na RHEL 8.

1.3.2. Lista de opções de configuração do NTP para comandos de instalação do IdM

Você pode especificar as seguintes opções com qualquer um dos comandos de instalação da IdM (ipa-server-install, ipa-replica-install, ipa-client-install) para configurar o software cliente chronyd durante a configuração.

Tabela 1.1. Lista de opções de configuração do NTP para comandos de instalação do IdM

OpçãoComportamento

--ntp-server

Use-o para especificar um servidor NTP. Você pode usá-lo várias vezes para especificar vários servidores.

--ntp-pool

Use-o para especificar um pool de múltiplos servidores NTP resolvidos como um nome de host.

-N, --no-ntp

Não configurar, iniciar ou ativar chronyd.

1.3.3. Assegurar que a IdM possa fazer referência ao seu servidor de tempo NTP

Este procedimento verifica se você tem as configurações necessárias para que a IdM possa se sincronizar com seu servidor de tempo Network Time Protocol (NTP).

Pré-requisitos

  • Você configurou um servidor de tempo NTP em seu ambiente. Neste exemplo, o hostname do servidor de tempo previamente configurado é ntpserver.example.com.

Procedimento

  1. Realizar uma busca de registro de serviço DNS (SRV) para servidores NTP em seu ambiente.

    [user@server ~]$ dig +short -t SRV _ntp._udp.example.com
    0 100 123 ntpserver.example.com.
  2. Se a pesquisa anterior dig não retornar seu servidor de tempo, adicione um registro _ntp._udp SRV que aponte para seu servidor de tempo na porta 123. Este processo depende de sua solução DNS.

Etapas de verificação

  • Verifique se o DNS retorna uma entrada para seu servidor de tempo na porta 123 quando você realizar uma pesquisa para _ntp._udp registros SRV.

    [user@server ~]$ dig +short -t SRV _ntp._udp.example.com
    0 100 123 ntpserver.example.com.

1.3.4. Recursos adicionais

1.4. Nome do host e requisitos DNS para IdM

Esta seção lista o nome do host e os requisitos DNS para servidores e réplicas de sistemas. Ela também mostra como verificar se os sistemas atendem aos requisitos.

Os requisitos desta seção se aplicam a todos os servidores de Gerenciamento de Identidade (IdM), aqueles com DNS integrado e aqueles sem DNS integrado.

Atenção

Os registros DNS são vitais para quase todas as funções do domínio IdM, incluindo a execução de serviços de diretório LDAP, Kerberos e integração com Active Directory. Seja extremamente cauteloso e assegure-se disso:

  • Você tem um serviço DNS testado e funcional disponível
  • O serviço está devidamente configurado

Esta exigência se aplica a servidores IdM com and sem DNS integrado.

Verificar o nome do host do servidor

O nome do host deve ser um nome de domínio totalmente qualificado, como por exemplo server.example.com.

O nome de domínio totalmente qualificado deve satisfazer as seguintes condições:

  • É um nome DNS válido, o que significa que somente números, caracteres alfabéticos e hífens (-) são permitidos. Outros caracteres, tais como sublinhados (_), no nome do host causam falhas no DNS.
  • É tudo em minúsculas. Não são permitidas letras maiúsculas.
  • Ele não resolve para o endereço de loopback. Ele deve resolver para o endereço IP público do sistema, não para 127.0.0.1.

Para verificar o nome do host, use o utilitário hostname no sistema onde você deseja instalar:

# hostname
server.idm.example.com

O resultado de hostname não deve ser localhost ou localhost6.

Verificar a configuração do DNS para frente e para trás
  1. Obter o endereço IP do servidor.

    1. O comando ip addr show exibe tanto os endereços IPv4 como IPv6. No exemplo a seguir, o endereço IPv6 relevante é 2001:DB8::1111 porque seu escopo é global:

      [root@server ~]# ip addr show
      ...
      2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
      	link/ether 00:1a:4a:10:4e:33 brd ff:ff:ff:ff:ff:ff
      	inet 192.0.2.1/24 brd 192.0.2.255 scope global dynamic eth0
      		valid_lft 106694sec preferred_lft 106694sec
      	inet6 2001:DB8::1111/32 scope global dynamic
       		valid_lft 2591521sec preferred_lft 604321sec
      	inet6 fe80::56ee:75ff:fe2b:def6/64 scope link
      	       valid_lft forever preferred_lft forever
      ...
  2. Verifique a configuração do DNS forward usando o utilitário dig.

    1. Execute o comando dig short server.example.com A. O endereço IPv4 devolvido deve corresponder ao endereço IP devolvido por ip addr show:

      [root@server ~]# dig +short server.example.com A
      192.0.2.1
    2. Execute o comando dig short server.example.com AAAA. Se ele retornar um endereço, ele deve corresponder ao endereço IPv6 retornado por ip addr show:

      [root@server ~]# dig +short server.example.com AAAA
      2001:DB8::1111
      Nota

      Se dig não retornar nenhuma saída para o registro AAAA, ele não indica configuração incorreta. Nenhuma saída significa apenas que nenhum endereço IPv6 está configurado no DNS para o sistema. Se você não pretende usar o protocolo IPv6 em sua rede, você pode prosseguir com a instalação nesta situação.

  3. Verificar a configuração DNS inversa (registros PTR). Use o utilitário dig e adicione o endereço IP.

    Se os comandos abaixo exibem um nome de host diferente ou nenhum nome de host, a configuração DNS inversa está incorreta.

    1. Execute o comando dig short -x IPv4_address. A saída deve exibir o nome do host do servidor. Por exemplo:

      [root@server ~]# dig +short -x 192.0.2.1
      server.example.com
    2. Se o comando dig short -x server.example.com AAAA na etapa anterior devolveu um endereço IPv6, use dig para consultar também o endereço IPv6. A saída deve mostrar o nome do host do servidor. Por exemplo:

      [root@server ~]# dig +short -x 2001:DB8::1111
      server.example.com
      Nota

      Se dig short server.example.com AAAA na etapa anterior não exibia nenhum endereço IPv6, consultando o registro AAAA não produziu nada. Neste caso, este é um comportamento normal e não indica configuração incorreta.

      Atenção

      Se uma busca DNS reversa (registro PTR) retorna vários nomes de host, httpd e outros softwares associados à IdM podem mostrar um comportamento imprevisível. A Red Hat recomenda fortemente a configuração de apenas um registro PTR por IP.

Verificar a conformidade com as normas dos encaminhadores DNS (exigido apenas para o DNS integrado)

Certifique-se de que todos os encaminhadores DNS que você deseja utilizar com o servidor DNS da IdM estejam em conformidade com os mecanismos de extensão para os padrões DNS (EDNS0) e Extensões de Segurança DNS (DNSSEC). Para fazer isso, inspecione a saída do seguinte comando para cada encaminhador separadamente:

$ dig dnssec @IP_address_of_the_DNS_forwarder . SOA

A saída esperada exibida pelo comando contém as seguintes informações:

  • status NOERROR
  • bandeiras ra
  • Bandeiras EDNS do
  • O registro RRSIG deve estar presente na seção ANSWER

Se algum desses itens estiver faltando na saída, inspecione a documentação para seu encaminhador DNS e verifique se EDNS0 e DNSSEC são suportados e habilitados. Nas versões mais recentes do servidor BIND, a opção dnssec-enable yes; deve ser definida no arquivo /etc/named.conf.

Exemplo da produção esperada produzida por dig:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48655
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096

;; ANSWER SECTION:
. 31679 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2015100701 1800 900 604800 86400
. 31679 IN RRSIG SOA 8 0 86400 20151017170000 20151007160000 62530 . GNVz7SQs [...]
Verifique o arquivo /etc/hosts

Verifique se o arquivo /etc/hosts preenche uma das seguintes condições:

  • O arquivo não contém uma entrada para o anfitrião. Ele apenas lista as entradas IPv4 e IPv6 do localhost para o host.
  • O arquivo contém uma entrada para o anfitrião e o arquivo preenche todas as condições a seguir:

    • As duas primeiras entradas são as entradas IPv4 e IPv6 localhost.
    • A próxima entrada especifica o endereço IPv4 do servidor IdM e o nome do host.
    • O FQDN do servidor da IdM vem antes do nome curto do servidor da IdM.
    • O nome do anfitrião do servidor IdM não faz parte da entrada do anfitrião local.

    A seguir, um exemplo de um arquivo /etc/hosts corretamente configurado:

127.0.0.1	localhost.localdomain	localhost
::1		localhost6.localdomain6	localhost6
192.0.2.1	server.example.com	server
2001:DB8::1111	server.example.com	server

1.5. Exigências portuárias para IdM

A Gestão de Identidade (IdM) utiliza uma série de portos para se comunicar com seus serviços. Estas portas devem estar abertas e disponíveis para conexões de entrada ao servidor IdM para que o IdM funcione. Elas não devem ser usadas atualmente por outro serviço ou bloqueadas por um firewall.

Tabela 1.2. Portos IdM

ServiçoPortosProtocolo

HTTP/HTTPS

80, 443

TCP

LDAP/LDAPS

389, 636

TCP

Kerberos

88, 464

TCP e UDP

DNS

53

TCP e UDP (opcional)

NTP

123

UDP (opcional)

Além disso, os portos 8080, 8443, e 749 devem ser livres, pois são utilizados internamente. Não abra estas portas e, em vez disso, deixe-as bloqueadas por um firewall.

Tabela 1.3. firewalld serviços

Nome do serviçoPara maiores detalhes, veja:

freeipa-ldap

/usr/lib/firewalld/services/freeipa-ldap.xml

freeipa-ldaps

/usr/lib/firewalld/services/freeipa-ldaps.xml

dns

/usr/lib/firewalld/services/dns.xml

Abertura dos portos necessários

  1. Certifique-se de que o serviço firewalld esteja funcionando.

    • Para saber se o site firewalld está funcionando atualmente:

      # systemctl status firewalld.service
    • Para iniciar firewalld e configurá-lo para iniciar automaticamente quando o sistema inicia:

      # systemctl start firewalld.service
      # systemctl enable firewalld.service
  2. Abra as portas necessárias usando o utilitário firewall-cmd. Escolha uma das seguintes opções:

    1. Adicione as portas individuais ao firewall, usando o comando firewall-cmd --add-port. Por exemplo, para abrir as portas na zona padrão:

      # firewall-cmd --permanent --add-port={80/tcp,443/tcp,389/tcp,636/tcp,88/tcp,88/udp,464/tcp,464/udp,53/tcp,53/udp,123/udp}
    2. Adicione os serviços firewalld ao firewall, usando o comando firewall-cmd --add-service. Por exemplo, para abrir as portas na zona padrão:

      # firewall-cmd --permanent --add-service={freeipa-ldap,freeipa-ldaps,dns}

      Para detalhes sobre como usar firewall-cmd para abrir portas em um sistema, consulte a página de manual firewall-cmd(1).

  3. Recarregar a configuração firewall-cmd para garantir que a mudança ocorra imediatamente:

    # firewall-cmd --reload

    Note que a recarga do firewalld em um sistema em produção pode causar interrupções no tempo de conexão DNS. Se necessário, para evitar o risco de interrupções e para que as mudanças persistam no sistema em execução, use a opção --runtime-to-permanent do comando firewall-cmd, por exemplo:

    # Firewall-cmd - tempo de execução a permanente
  4. Optional. Para verificar se as portas estão disponíveis agora, use o nc, telnet, ou nmap utilitários para conectar a uma porta ou executar uma varredura de porta.
Nota

Observe que você também tem que abrir firewalls baseados na rede para o tráfego de entrada e saída.

1.6. Instalação dos pacotes necessários para um servidor IdM

No RHEL8, os pacotes necessários para instalar um servidor de Gerenciamento de Identidade (IdM) são enviados como um módulo. O fluxo do módulo do servidor IdM é chamado de fluxo DL1, e você precisa habilitar este fluxo antes de baixar os pacotes deste fluxo. O procedimento a seguir mostra como baixar os pacotes necessários para a configuração do ambiente IdM de sua escolha.

Pré-requisitos

  • Você tem um sistema RHEL recentemente instalado.
  • Você disponibilizou os repositórios necessários:

    • Se seu sistema RHEL não estiver rodando na nuvem, você registrou seu sistema com o Gerente de Assinaturas da Red Hat (RHSM). Para detalhes, consulte Registro, anexando e removendo assinaturas na linha de comando do Gerenciador de Assinaturas. Você também habilitou os repositórios BaseOS e AppStream que a IdM utiliza:

      # subscription-manager repos --enable=rhel-8-for-x86_64-baseos-rpms
      # subscription-manager repos --enable=rhel-8-for-x86_64-appstream-rpms

    Para detalhes sobre como habilitar e desabilitar repositórios específicos usando o RHSM, consulte Configurando opções no Red Hat Subscription Manager.

    • Se seu sistema RHEL estiver funcionando na nuvem, pule o registro. Os repositórios necessários já estão disponíveis através da Infraestrutura de Atualização da Red Hat (RHUI).
  • Você não ativou anteriormente um fluxo de módulos IdM.

Procedimento

  1. Habilite o fluxo idm:DL1:

    # yum module enable idm:DL1
  2. Mude para as RPMs entregues através do fluxo idm:DL1:

    # yum distro-sync
  3. Escolha uma das seguintes opções, dependendo de suas exigências de IdM:

    • Para baixar os pacotes necessários para a instalação de um servidor IdM sem um DNS integrado:

      # yum module install idm:DL1/server
    • Para baixar os pacotes necessários para a instalação de um servidor IdM com um DNS integrado:

      # yum module install idm:DL1/dns
    • Para baixar os pacotes necessários para a instalação de um servidor IdM que tenha um acordo de confiança com o Active Directory:

      # yum module install idm:DL1/adtrust
    • Para baixar os pacotes de vários perfis, por exemplo, os perfis adtrust e dns:

      # yum module install idm:DL1/{dns,adtrust}
    • Para baixar os pacotes necessários para a instalação de um cliente IdM:

      # yum module install idm:DL1/client
Importante

Ao mudar para um novo fluxo de módulos uma vez que você já tenha habilitado um fluxo diferente e baixado pacotes dele, você precisa primeiro remover explicitamente todo o conteúdo instalado relevante e desabilitar o fluxo de módulos atual antes de habilitar o novo fluxo de módulos. Tentar ativar um novo fluxo sem desativar o fluxo atual resulta em um erro. Para obter detalhes sobre como proceder, consulte Mudando para um fluxo posterior.

Atenção

Embora seja possível instalar pacotes de módulos individualmente, esteja ciente de que se você instalar qualquer pacote de um módulo que não esteja listado como "API" para aquele módulo, ele só será suportado pela Red Hat no contexto daquele módulo. Por exemplo, se você instalar bind-dyndb-ldap diretamente do repositório para usar com sua configuração personalizada do 389 Directory Server, quaisquer problemas que você tenha serão ignorados, a menos que ocorram para o IdM, também.

Capítulo 2. Instalação de um servidor IdM: Com DNS integrado, com uma CA integrada como a CA raiz

A instalação de um novo servidor de Gerenciamento de Identidade (IdM) com DNS integrado tem as seguintes vantagens:

  • Você pode automatizar grande parte da manutenção e do gerenciamento de registros DNS usando ferramentas nativas da IdM. Por exemplo, os registros DNS SRV são criados automaticamente durante a configuração, e posteriormente são atualizados automaticamente.
  • Você pode ter uma conexão estável com o resto da Internet, instalando forwarders globais durante a instalação do servidor IdM. Os redirecionadores globais também são úteis para os fideicomissos com o Active Directory.
  • Você pode configurar uma zona reversa DNS para impedir que e-mails do seu domínio sejam considerados spam por servidores de e-mail fora do domínio IdM.

A instalação de IdM com DNS integrado tem certas limitações:

  • O IdM DNS não deve ser usado como um servidor DNS para fins gerais. Algumas das funções avançadas do DNS não são suportadas.

Este capítulo descreve como você pode instalar um novo servidor IdM com uma autoridade de certificado integrada (CA) como a CA raiz.

Nota

A configuração padrão para o comando ipa-server-install é uma CA integrada como a CA raiz. Se nenhuma opção CA, por exemplo --external-ca ou --ca-less for especificada, o servidor IdM é instalado com uma CA integrada.

2.1. Instalação interativa

Durante a instalação interativa utilizando o ipa-server-install é solicitado que você forneça a configuração básica do sistema, por exemplo, o domínio, a senha do administrador e a senha do Gerente de Diretório.

O script de instalação ipa-server-install cria um arquivo de log em /var/log/ipaserver-install.log. Se a instalação falhar, o log pode ajudá-lo a identificar o problema.

Procedimento

  1. Execute o utilitário ipa-server-install.

    # ipa-server-install
  2. O script solicita a configuração de um serviço DNS integrado. Digite yes.

    Você deseja configurar o DNS integrado (BIND)? [não] yes
  3. O script solicita várias configurações necessárias e oferece os valores padrão recomendados entre parênteses.

    • Para aceitar um valor padrão, pressione Enter.
    • Para fornecer um valor personalizado, digite o valor requerido.

      Server host name [server.example.com]:
      Please confirm the domain name [example.com]:
      Please provide a realm name [EXAMPLE.COM]:
      Atenção

      Planeje cuidadosamente estes nomes. Você não poderá alterá-los após a conclusão da instalação.

  4. Digite as senhas para o superusuário Directory Server (cn=Directory Manager) e para a conta de usuário do sistema de administração do Gerenciamento de Identidade (IdM) (admin).

    Directory Manager password:
    IPA admin password:
  5. O roteiro solicita encaminhadores DNS.

    Você quer configurar os encaminhadores DNS? [sim]:
    • Para configurar os encaminhadores DNS, digite yes, e depois siga as instruções na linha de comando. O processo de instalação adicionará os endereços IP do encaminhador ao arquivo /etc/named.conf no servidor IdM instalado.

      • Para as configurações padrão da política de encaminhamento, consulte a descrição --forward-policy na página de manual ipa-dns-install(1).
    • Se você não quiser usar o encaminhamento DNS, digite no.

      Sem encaminhadores DNS, seu ambiente será isolado e os nomes de outros domínios DNS em sua infra-estrutura não serão resolvidos.

  6. O script pede para verificar se algum registro DNS reverso (PTR) para os endereços IP associados com o servidor precisa ser configurado.

    Você quer procurar por zonas invertidas ausentes? [sim]:

    Se você executar a busca e forem descobertas zonas reversa ausentes, o script pergunta se você deve criar as zonas reversa junto com os registros PTR.

    Do you want to create reverse zone for IP 192.0.2.1 [yes]:
    Please specify the reverse zone name [2.0.192.in-addr.arpa.]:
    Using reverse zone(s) 2.0.192.in-addr.arpa.
    Nota

    O uso de IdM para gerenciar zonas invertidas é opcional. Você pode usar um serviço DNS externo para este fim.

  7. Digite yes para confirmar a configuração do servidor.

    Continuar a configurar o sistema com estes valores? [não] yes
  8. O roteiro de instalação agora configura o servidor. Aguarde que a operação seja concluída.
  9. Após a conclusão do roteiro de instalação, atualize seus registros DNS da seguinte maneira:

    1. Adicionar a delegação DNS do domínio pai ao domínio DNS IdM. Por exemplo, se o domínio DNS do IdM for ipa.example.comAdicione um registro de servidor de nomes (NS) ao domínio pai example.com.

      Importante

      Repita esta etapa toda vez que um servidor DNS IdM for instalado.

    2. Adicione um registro do serviço _ntp._udp (SRV) para seu servidor de tempo ao seu DNS IdM. A presença do registro SRV para o servidor de tempo do servidor IdM recém-instalado no DNS da IdM garante que futuras réplicas e instalações do cliente sejam automaticamente configuradas para sincronizar com o servidor de tempo usado por este servidor IdM primário.

2.2. Instalação não-interativa

Nota

O script de instalação ipa-server-install cria um arquivo de log em /var/log/ipaserver-install.log. Se a instalação falhar, o log pode ajudá-lo a identificar o problema.

Procedimento

  1. Execute o utilitário ipa-server-install com as opções para fornecer todas as informações necessárias. As opções mínimas exigidas para instalação não-interativa são:

    • --realm para fornecer o nome do reino de Kerberos
    • --ds-password para fornecer a senha para o Gerente de Diretório (DM), o super usuário do Servidor de Diretório
    • --admin-password para fornecer a senha para admin, o administrador da Gestão de Identidade (IdM)
    • --unattended para deixar o processo de instalação selecionar opções padrão para o nome do host e nome de domínio

    Para instalar um servidor com DNS integrado, acrescente também estas opções:

    • --setup-dns para configurar o DNS integrado
    • --forwarder ou --no-forwarders, dependendo se você deseja ou não configurar os encaminhadores DNS
    • --auto-reverse ou --no-reverse, dependendo se você deseja configurar a detecção automática das zonas DNS invertidas que devem ser criadas no DNS do IdM ou nenhuma autodetecção da zona reversa

    Por exemplo:

    # ipa-server-install --realm EXAMPLE.COM --ds-password DM_password --admin-password admin_password --unattended --setup-dns --forwarder 192.0.2.1 --no-reverse
  2. Após a conclusão do roteiro de instalação, atualize seus registros DNS da seguinte maneira:

    1. Adicionar a delegação DNS do domínio pai ao domínio DNS IdM. Por exemplo, se o domínio DNS do IdM for ipa.example.comAdicione um registro de servidor de nomes (NS) ao domínio pai example.com.

      Importante

      Repita esta etapa toda vez que um servidor DNS IdM for instalado.

    2. Adicione um registro do serviço _ntp._udp (SRV) para seu servidor de tempo ao seu DNS IdM. A presença do registro SRV para o servidor de tempo do servidor IdM recém-instalado no DNS da IdM garante que futuras réplicas e instalações do cliente sejam automaticamente configuradas para sincronizar com o servidor de tempo usado por este servidor IdM primário.

Recursos adicionais

  • Para uma lista completa de opções aceitas por ipa-server-install, execute o comando ipa-server-install --help.

Capítulo 3. Instalação de um servidor IdM: Com DNS integrado, com uma CA externa como a CA raiz

A instalação de um novo servidor de Gerenciamento de Identidade (IdM) com DNS integrado tem as seguintes vantagens:

  • Você pode automatizar grande parte da manutenção e do gerenciamento de registros DNS usando ferramentas nativas da IdM. Por exemplo, os registros DNS SRV são criados automaticamente durante a configuração, e posteriormente são atualizados automaticamente.
  • Você pode ter uma conexão estável com o resto da Internet, instalando forwarders globais durante a instalação do servidor IdM. Os redirecionadores globais também são úteis para os fideicomissos com o Active Directory.
  • Você pode configurar uma zona reversa DNS para impedir que e-mails do seu domínio sejam considerados spam por servidores de e-mail fora do domínio IdM.

A instalação de IdM com DNS integrado tem certas limitações:

  • O IdM DNS não deve ser usado como um servidor DNS para fins gerais. Algumas das funções avançadas do DNS não são suportadas.

Este capítulo descreve como você pode instalar um novo servidor IdM com uma autoridade de certificação externa (CA) como a CA raiz.

3.1. Instalação interativa

Durante a instalação interativa utilizando o ipa-server-install é solicitado que você forneça a configuração básica do sistema, por exemplo, o domínio, a senha do administrador e a senha do Gerente de Diretório.

O script de instalação ipa-server-install cria um arquivo de log em /var/log/ipaserver-install.log. Se a instalação falhar, o log pode ajudá-lo a identificar o problema.

Este procedimento descreve como instalar um servidor:

  • com DNS integrado
  • com uma autoridade de certificação externa (CA) como a CA de raiz

Pré-requisitos

  • Decida sobre o tipo de CA externa que você utiliza (a opção --external-ca-type ). Veja a ipa-server-install(1) página de homem para detalhes.
  • Alternativamente, decidir sobre a opção --external-ca-profile que permite especificar um modelo alternativo do Active Directory Certificate Services (AD CS). Por exemplo, para especificar um identificador de objeto específico da instalação do AD CS:

    [root@server ~]# ipa-server-install --external-ca --external-ca-type=ms-cs --external-ca-profile=1.3.6.1.4.1.311.21.8.8950086.10656446.2706058.12775672.480128.147.7130143.4405632:1

Procedimento

  1. Execute o utilitário ipa-server-install com a opção --external-ca.

    # ipa-server-install --external-ca

    Se você estiver usando o Microsoft Certificate Services CA, use também a opção --external-ca-type. Para detalhes, consulte a página de manual ipa-server-install(1).

  2. O script solicita a configuração de um serviço DNS integrado. Digite yes ou no. Neste procedimento, estamos instalando um servidor com DNS integrado.

    Você deseja configurar o DNS integrado (BIND)? [não] yes
    Nota

    Se você deseja instalar um servidor sem DNS integrado, o script de instalação não solicitará a configuração do DNS como descrito nos passos abaixo. Consulte Capítulo 5, Instalação de um servidor IdM: Sem DNS integrado, com uma CA integrada como a CA raiz para obter detalhes sobre os passos para a instalação de um servidor sem DNS.

  3. O script solicita várias configurações necessárias e oferece os valores padrão recomendados entre parênteses.

    • Para aceitar um valor padrão, pressione Enter.
    • Para fornecer um valor personalizado, digite o valor requerido.

      Server host name [server.example.com]:
      Please confirm the domain name [example.com]:
      Please provide a realm name [EXAMPLE.COM]:
      Atenção

      Planeje cuidadosamente estes nomes. Você não poderá alterá-los após a conclusão da instalação.

  4. Digite as senhas para o superusuário Directory Server (cn=Directory Manager) e para a conta de usuário do sistema de administração do Gerenciamento de Identidade (IdM) (admin).

    Directory Manager password:
    IPA admin password:
  5. O roteiro solicita encaminhadores DNS.

    Você quer configurar os encaminhadores DNS? [sim]:
    • Para configurar os encaminhadores DNS, digite yes, e depois siga as instruções na linha de comando. O processo de instalação adicionará os endereços IP do encaminhador ao arquivo /etc/named.conf no servidor IdM instalado.

      • Para as configurações padrão da política de encaminhamento, consulte a descrição --forward-policy na página de manual ipa-dns-install(1).
    • Se você não quiser usar o encaminhamento DNS, digite no.

      Sem encaminhadores DNS, seu ambiente será isolado e os nomes de outros domínios DNS em sua infra-estrutura não serão resolvidos.

  6. O script pede para verificar se algum registro DNS reverso (PTR) para os endereços IP associados com o servidor precisa ser configurado.

    Você quer procurar por zonas invertidas ausentes? [sim]:

    Se você executar a busca e forem descobertas zonas reversa ausentes, o script pergunta se você deve criar as zonas reversa junto com os registros PTR.

    Do you want to create reverse zone for IP 192.0.2.1 [yes]:
    Please specify the reverse zone name [2.0.192.in-addr.arpa.]:
    Using reverse zone(s) 2.0.192.in-addr.arpa.
    Nota

    O uso de IdM para gerenciar zonas invertidas é opcional. Você pode usar um serviço DNS externo para este fim.

  7. Digite yes para confirmar a configuração do servidor.

    Continuar a configurar o sistema com estes valores? [não] yes
  8. Durante a configuração da instância do Sistema de Certificado, o utilitário imprime o local do pedido de assinatura do certificado (CSR): /root/ipa.csr:

    ...
    
    Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds
      [1/8]: creating certificate server user
      [2/8]: configuring certificate server instance
    The next step is to get /root/ipa.csr signed by your CA and re-run /sbin/ipa-server-install as:
    /sbin/ipa-server-install --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate

    Quando isto acontece:

    1. Submeter a RSE localizada em /root/ipa.csr à CA externa. O processo difere dependendo do serviço a ser usado como a CA externa.
    2. Recuperar o certificado emitido e a cadeia de certificados da CA para a CA emissora em um blob básico 64 codificado (um arquivo PEM ou um certificado Base_64 de uma CA Windows). Novamente, o processo difere para cada serviço de certificado. Normalmente, um link para download em uma página da web ou no e-mail de notificação permite ao administrador baixar todos os certificados exigidos.

      Importante

      Certifique-se de obter a cadeia completa de certificados para a CA, não apenas o certificado da CA.

    3. Execute ipa-server-install novamente, desta vez especificando os locais e nomes do certificado recém-emitido da CA e os arquivos da cadeia da CA. Por exemplo, o arquivo de corrente da CA:

      # ipa-server-install --external-cert-file=/tmp/servercert20170601.pem --external-cert-file=/tmp/cacert.pem
  9. O roteiro de instalação agora configura o servidor. Aguarde que a operação seja concluída.
  10. Após a conclusão do roteiro de instalação, atualize seus registros DNS da seguinte maneira:

    1. Adicionar a delegação DNS do domínio pai ao domínio DNS IdM. Por exemplo, se o domínio DNS do IdM for ipa.example.comAdicione um registro de servidor de nomes (NS) ao domínio pai example.com.

      Importante

      Repita esta etapa toda vez que um servidor DNS IdM for instalado.

    2. Adicione um registro do serviço _ntp._udp (SRV) para seu servidor de tempo ao seu DNS IdM. A presença do registro SRV para o servidor de tempo do servidor IdM recém-instalado no DNS da IdM garante que futuras réplicas e instalações do cliente sejam automaticamente configuradas para sincronizar com o servidor de tempo usado por este servidor IdM primário.
Nota

O comando ipa-server-install --external-ca às vezes pode falhar com o seguinte erro:

ipa         : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/configuration_file' returned non-zero exit status 1
Configuration of CA failed

Esta falha ocorre quando as variáveis ambientais do *_proxy são definidas. Para uma solução do problema, ver Seção 3.2, “Solução de problemas: Falha na instalação externa da CA”.

3.2. Solução de problemas: Falha na instalação externa da CA

O comando ipa-server-install --external-ca falha com o seguinte erro:

ipa         : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/configuration_file' returned non-zero exit status 1
Configuration of CA failed

O comando env|grep proxy exibe variáveis tais como as seguintes:

# env|grep proxy
http_proxy=http://example.com:8080
ftp_proxy=http://example.com:8080
https_proxy=http://example.com:8080

O que isto significa:

As variáveis ambientais *_proxy estão impedindo que o servidor seja instalado.

Para consertar o problema:

  1. Use o seguinte roteiro em shell para desajustar as variáveis ambientais do *_proxy:

    # for i in ftp http https; do unset ${i}_proxy; done
  2. Execute o utilitário pkidestroy para remover a instalação mal sucedida do subsistema da autoridade certificadora (CA):

    # pkidestroy -s CA -i pki-tomcat; rm -rf /var/log/pki/pki-tomcat /etc/sysconfig/pki-tomcat /etc/sysconfig/pki/tomcat/pki-tomcat /var/lib/pki/pki-tomcat /etc/pki/pki-tomcat /root/ipa.csr
  3. Remover a instalação do servidor de Gerenciamento de Identidade (IdM) que falhou:

    # ipa-server-install --uninstall
  4. Tente novamente ipa-server-install --external-ca.

Capítulo 4. Instalação de um servidor IdM: Com DNS integrado, sem uma CA

A instalação de um novo servidor de Gerenciamento de Identidade (IdM) com DNS integrado tem as seguintes vantagens:

  • Você pode automatizar grande parte da manutenção e do gerenciamento de registros DNS usando ferramentas nativas da IdM. Por exemplo, os registros DNS SRV são criados automaticamente durante a configuração, e posteriormente são atualizados automaticamente.
  • Você pode ter uma conexão estável com o resto da Internet, instalando forwarders globais durante a instalação do servidor IdM. Os redirecionadores globais também são úteis para os fideicomissos com o Active Directory.
  • Você pode configurar uma zona reversa DNS para impedir que e-mails do seu domínio sejam considerados spam por servidores de e-mail fora do domínio IdM.

A instalação de IdM com DNS integrado tem certas limitações:

  • O IdM DNS não deve ser usado como um servidor DNS para fins gerais. Algumas das funções avançadas do DNS não são suportadas.

Este capítulo descreve como você pode instalar um novo servidor IdM sem uma autoridade de certificado (CA).

4.1. Certificados necessários para instalar um servidor IdM sem uma CA

Esta seção lista:

  • os certificados necessários para instalar um servidor de Gerenciamento de Identidade (IdM) sem uma autoridade de certificado (CA)
  • as opções de linha de comando utilizadas para fornecer esses certificados à concessionária ipa-server-install
Importante

Você não pode instalar um servidor ou réplica usando certificados de servidor de terceiros autoassinados porque os arquivos de certificados importados devem conter toda a cadeia de certificados da CA que emitiu os certificados de servidor LDAP e Apache.

O certificado do servidor LDAP e a chave privada
  • --dirsrv-cert-file para o certificado e arquivos chave privados para o certificado do servidor LDAP
  • --dirsrv-pin para obter a senha de acesso à chave privada nos arquivos especificados em --dirsrv-cert-file
O certificado de servidor Apache e chave privada
  • --http-cert-file para o certificado e arquivos chave privados para o certificado do servidor Apache
  • --http-pin para obter a senha de acesso à chave privada nos arquivos especificados em --http-cert-file
A cadeia completa de certificados CA da CA que emitiu os certificados de servidor LDAP e Apache
  • --dirsrv-cert-file e --http-cert-file para os arquivos de certificados com a cadeia completa de certificados CA ou uma parte dela

Você pode fornecer os arquivos especificados nas opções --dirsrv-cert-file e --http-cert-file nos seguintes formatos:

  • Certificado codificado de privacidade (PEM) codificado (RFC 7468). Observe que o instalador do Gerenciamento de Identidade aceita objetos concatenados codificados com PEM.
  • Regras de Codificação Distinta (DER)
  • PKCS #7 objetos de cadeia de certificados
  • PKCS #8 objetos chave privados
  • Arquivos PKCS #12

Você pode especificar as opções --dirsrv-cert-file e --http-cert-file várias vezes para especificar vários arquivos.

Os arquivos de certificados para completar a cadeia completa de certificados CA (não necessários em alguns ambientes)
  • --ca-cert-file para o arquivo ou arquivos contendo o certificado da CA que emitiu os certificados LDAP, Apache Server, e Kerberos KDC. Use esta opção se o certificado da CA não estiver presente nos arquivos de certificados fornecidos pelas outras opções.

Os arquivos fornecidos usando --dirsrv-cert-file e --http-cert-file combinados com o arquivo fornecido usando --ca-cert-file devem conter a cadeia completa de certificados da CA que emitiu os certificados de servidor LDAP e Apache.

O centro de distribuição de chaves Kerberos (KDC) certificado PKINIT e chave privada (opcional)
  • --pkinit-cert-file para o certificado Kerberos KDC SSL e chave privada
  • --pkinit-pin para obter a senha de acesso à chave privada do Kerberos KDC nos arquivos especificados em --pkinit-cert-file
  • --no-pkinit para desativar as etapas de configuração do pkinit

Se você não fornecer o certificado PKINIT, ipa-server-install configura o servidor IdM com um KDC local com um certificado autoassinado.

Recursos adicionais

  • Para obter detalhes sobre o formato do arquivo de certificado que estas opções aceitam, consulte o ipa-server-install(1) página de homem.

4.2. Instalação interativa

Durante a instalação interativa utilizando o ipa-server-install é solicitado que você forneça a configuração básica do sistema, por exemplo, o domínio, a senha do administrador e a senha do Gerente de Diretório.

O script de instalação ipa-server-install cria um arquivo de log em /var/log/ipaserver-install.log. Se a instalação falhar, o log pode ajudá-lo a identificar o problema.

Procedimento

  1. Execute o ipa-server-install e fornecer todos os certificados exigidos. Por exemplo:

    [root@server ~]# ipa-server-install \
        --http-cert-file /tmp/server.crt \
        --http-cert-file /tmp/server.key \
        --http-pin secret \
        --dirsrv-cert-file /tmp/server.crt \
        --dirsrv-cert-file /tmp/server.key \
        --dirsrv-pin secret \
        --ca-cert-file ca.crt

    Consulte Seção 4.1, “Certificados necessários para instalar um servidor IdM sem uma CA” para obter detalhes sobre os certificados fornecidos.

  2. O script solicita a configuração de um serviço DNS integrado. Digite yes ou no. Neste procedimento, estamos instalando um servidor com DNS integrado.

    Você deseja configurar o DNS integrado (BIND)? [não] yes
    Nota

    Se você deseja instalar um servidor sem DNS integrado, o script de instalação não solicitará a configuração do DNS como descrito nos passos abaixo. Consulte Capítulo 5, Instalação de um servidor IdM: Sem DNS integrado, com uma CA integrada como a CA raiz para obter detalhes sobre os passos para a instalação de um servidor sem DNS.

  3. O script solicita várias configurações necessárias e oferece os valores padrão recomendados entre parênteses.

    • Para aceitar um valor padrão, pressione Enter.
    • Para fornecer um valor personalizado, digite o valor requerido.

      Server host name [server.example.com]:
      Please confirm the domain name [example.com]:
      Please provide a realm name [EXAMPLE.COM]:
      Atenção

      Planeje cuidadosamente estes nomes. Você não poderá alterá-los após a conclusão da instalação.

  4. Digite as senhas para o superusuário Directory Server (cn=Directory Manager) e para a conta de usuário do sistema de administração do Gerenciamento de Identidade (IdM) (admin).

    Directory Manager password:
    IPA admin password:
  5. O roteiro solicita encaminhadores DNS.

    Você quer configurar os encaminhadores DNS? [sim]:
    • Para configurar os encaminhadores DNS, digite yes, e depois siga as instruções na linha de comando. O processo de instalação adicionará os endereços IP do encaminhador ao arquivo /etc/named.conf no servidor IdM instalado.

      • Para as configurações padrão da política de encaminhamento, consulte a descrição --forward-policy na página de manual ipa-dns-install(1).
    • Se você não quiser usar o encaminhamento DNS, digite no.

      Sem encaminhadores DNS, seu ambiente será isolado e os nomes de outros domínios DNS em sua infra-estrutura não serão resolvidos.

  6. O script pede para verificar se algum registro DNS reverso (PTR) para os endereços IP associados com o servidor precisa ser configurado.

    Você quer procurar por zonas invertidas ausentes? [sim]:

    Se você executar a busca e forem descobertas zonas reversa ausentes, o script pergunta se você deve criar as zonas reversa junto com os registros PTR.

    Do you want to create reverse zone for IP 192.0.2.1 [yes]:
    Please specify the reverse zone name [2.0.192.in-addr.arpa.]:
    Using reverse zone(s) 2.0.192.in-addr.arpa.
    Nota

    O uso de IdM para gerenciar zonas invertidas é opcional. Você pode usar um serviço DNS externo para este fim.

  7. Digite yes para confirmar a configuração do servidor.

    Continuar a configurar o sistema com estes valores? [não] yes
  8. O roteiro de instalação agora configura o servidor. Aguarde que a operação seja concluída.
  9. Após a conclusão do roteiro de instalação, atualize seus registros DNS da seguinte maneira:

    1. Adicionar a delegação DNS do domínio pai ao domínio DNS IdM. Por exemplo, se o domínio DNS do IdM for ipa.example.comAdicione um registro de servidor de nomes (NS) ao domínio pai example.com.

      Importante

      Repita esta etapa toda vez que um servidor DNS IdM for instalado.

    2. Adicione um registro do serviço _ntp._udp (SRV) para seu servidor de tempo ao seu DNS IdM. A presença do registro SRV para o servidor de tempo do servidor IdM recém-instalado no DNS da IdM garante que futuras réplicas e instalações do cliente sejam automaticamente configuradas para sincronizar com o servidor de tempo usado por este servidor IdM primário.

Capítulo 5. Instalação de um servidor IdM: Sem DNS integrado, com uma CA integrada como a CA raiz

Este capítulo descreve como você pode instalar um novo servidor de Gerenciamento de Identidade (IdM) sem DNS integrado.

5.1. Instalação interativa

Durante a instalação interativa utilizando o ipa-server-install é solicitado que você forneça a configuração básica do sistema, por exemplo, o domínio, a senha do administrador e a senha do Gerente de Diretório.

O script de instalação ipa-server-install cria um arquivo de log em /var/log/ipaserver-install.log. Se a instalação falhar, o log pode ajudá-lo a identificar o problema.

Este procedimento instala um servidor:

  • Sem DNS integrado
  • Com o Gerenciamento de Identidade Integrado (IdM) autoridade certificadora (CA) como a CA raiz, que é a configuração padrão da CA

Procedimento

  1. Execute o utilitário ipa-server-install.

    # ipa-server-install
  2. O script solicita a configuração de um serviço DNS integrado. Pressione Enter para selecionar a opção padrão no.

    Você deseja configurar o DNS integrado (BIND)? [não]:
  3. O script solicita várias configurações necessárias e oferece os valores padrão recomendados entre parênteses.

    • Para aceitar um valor padrão, pressione Enter.
    • Para fornecer um valor personalizado, digite o valor requerido.

      Server host name [server.example.com]:
      Please confirm the domain name [example.com]:
      Please provide a realm name [EXAMPLE.COM]:
      Atenção

      Planeje cuidadosamente estes nomes. Você não poderá alterá-los após a conclusão da instalação.

  4. Digite as senhas para o superusuário Directory Server (cn=Directory Manager) e para a conta de usuário do sistema de administração IdM (admin).

    Directory Manager password:
    IPA admin password:
  5. Digite yes para confirmar a configuração do servidor.

    Continuar a configurar o sistema com estes valores? [não] yes
  6. O roteiro de instalação agora configura o servidor. Aguarde que a operação seja concluída.
  7. O script de instalação produz um arquivo com registros de recursos DNS: the /tmp/ipa.system.records.UFRPto.db arquivo no exemplo de saída abaixo. Acrescente estes registros aos servidores DNS externos existentes. O processo de atualização dos registros DNS varia de acordo com a solução DNS específica.

    ...
    Restarting the KDC
    Please add records in this file to your DNS system: /tmp/ipa.system.records.UFRBto.db
    Restarting the web server
    ...
    Importante

    A instalação do servidor não está completa até que você adicione os registros DNS aos servidores DNS existentes.

5.2. Instalação não-interativa

Este procedimento instala um servidor:

  • Sem DNS integrado
  • Com o Gerenciamento de Identidade Integrado (IdM) autoridade certificadora (CA) como a CA raiz, que é a configuração padrão da CA
Nota

O script de instalação ipa-server-install cria um arquivo de log em /var/log/ipaserver-install.log. Se a instalação falhar, o log pode ajudá-lo a identificar o problema.

Procedimento

  1. Execute o ipa-server-install com as opções para fornecer todas as informações necessárias. As opções mínimas exigidas para instalação não-interativa são:

    • --realm para fornecer o nome do reino de Kerberos
    • --ds-password para fornecer a senha para o Gerente de Diretório (DM), o super usuário do Servidor de Diretório
    • --admin-password para fornecer a senha para admin, o administrador da IdM
    • --unattended para deixar o processo de instalação selecionar opções padrão para o nome do host e nome de domínio

    Por exemplo:

    # ipa-server-install --realm EXAMPLE.COM --ds-password DM_password --admin-password admin_password --unattended
  2. O script de instalação produz um arquivo com registros de recursos DNS: the /tmp/ipa.system.records.UFRPto.db arquivo no exemplo de saída abaixo. Acrescente estes registros aos servidores DNS externos existentes. O processo de atualização dos registros DNS varia de acordo com a solução DNS específica.

    ...
    Restarting the KDC
    Please add records in this file to your DNS system: /tmp/ipa.system.records.UFRBto.db
    Restarting the web server
    ...
    Importante

    A instalação do servidor não está completa até que você adicione os registros DNS aos servidores DNS existentes.

Recursos adicionais

  • Para uma lista completa de opções aceitas por ipa-server-install, execute o comando ipa-server-install --help.

Capítulo 6. Instalação de um servidor IdM: Sem DNS integrado, com uma CA externa como a CA raiz

Este capítulo descreve como você pode instalar um novo servidor de Gerenciamento de Identidade (IdM), sem DNS integrado, que usa uma autoridade de certificado externa (CA) como a CA raiz.

6.1. Instalação interativa

Durante a instalação interativa utilizando o ipa-server-install é solicitado que você forneça a configuração básica do sistema, por exemplo, o domínio, a senha do administrador e a senha do Gerente de Diretório.

O script de instalação ipa-server-install cria um arquivo de log em /var/log/ipaserver-install.log. Se a instalação falhar, o log pode ajudá-lo a identificar o problema.

Este procedimento descreve como instalar um servidor:

  • Sem DNS integrado
  • Com uma autoridade de certificação externa (CA) como a CA raiz

Pré-requisitos

  • Decida sobre o tipo de CA externa que você utiliza (a opção --external-ca-type ). Veja a ipa-server-install(1) página de homem para detalhes.
  • Alternativamente, decidir sobre a opção --external-ca-profile que permite especificar um modelo alternativo do Active Directory Certificate Services (AD CS). Por exemplo, para especificar um identificador de objeto específico da instalação do AD CS:

    [root@server ~]# ipa-server-install --external-ca --external-ca-type=ms-cs --external-ca-profile=1.3.6.1.4.1.311.21.8.8950086.10656446.2706058.12775672.480128.147.7130143.4405632:1

Procedimento

  1. Execute o utilitário ipa-server-install com a opção --external-ca.

    # ipa-server-install --external-ca

    Se você estiver usando o Microsoft Certificate Services CA, use também a opção --external-ca-type. Para detalhes, consulte a página de manual ipa-server-install(1).

  2. O script solicita a configuração de um serviço DNS integrado. Pressione Enter para selecionar a opção padrão no.

    Você deseja configurar o DNS integrado (BIND)? [não]:
  3. O script solicita várias configurações necessárias e oferece os valores padrão recomendados entre parênteses.

    • Para aceitar um valor padrão, pressione Enter.
    • Para fornecer um valor personalizado, digite o valor requerido.

      Server host name [server.example.com]:
      Please confirm the domain name [example.com]:
      Please provide a realm name [EXAMPLE.COM]:
      Atenção

      Planeje cuidadosamente estes nomes. Você não poderá alterá-los após a conclusão da instalação.

  4. Digite as senhas para o superusuário Directory Server (cn=Directory Manager) e para a conta de usuário do sistema de administração IdM (admin).

    Directory Manager password:
    IPA admin password:
  5. Digite yes para confirmar a configuração do servidor.

    Continuar a configurar o sistema com estes valores? [não] yes
  6. Durante a configuração da instância do Sistema de Certificado, o utilitário imprime o local do pedido de assinatura do certificado (CSR): /root/ipa.csr:

    ...
    
    Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds
      [1/8]: creating certificate server user
      [2/8]: configuring certificate server instance
    The next step is to get /root/ipa.csr signed by your CA and re-run /sbin/ipa-server-install as:
    /sbin/ipa-server-install --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate

    Quando isto acontece:

    1. Submeter a RSE localizada em /root/ipa.csr à CA externa. O processo difere dependendo do serviço a ser usado como a CA externa.
    2. Recuperar o certificado emitido e a cadeia de certificados da CA para a CA emissora em um blob básico 64 codificado (um arquivo PEM ou um certificado Base_64 de uma CA Windows). Novamente, o processo difere para cada serviço de certificado. Normalmente, um link para download em uma página da web ou no e-mail de notificação permite ao administrador baixar todos os certificados exigidos.

      Importante

      Certifique-se de obter a cadeia completa de certificados para a CA, não apenas o certificado da CA.

    3. Execute ipa-server-install novamente, desta vez especificando os locais e nomes do certificado recém-emitido da CA e os arquivos da cadeia da CA. Por exemplo, o arquivo de corrente da CA:

      # ipa-server-install --external-cert-file=/tmp/servercert20170601.pem --external-cert-file=/tmp/cacert.pem
  7. O roteiro de instalação agora configura o servidor. Aguarde que a operação seja concluída.
  8. O script de instalação produz um arquivo com registros de recursos DNS: the /tmp/ipa.system.records.UFRPto.db arquivo no exemplo de saída abaixo. Acrescente estes registros aos servidores DNS externos existentes. O processo de atualização dos registros DNS varia de acordo com a solução DNS específica.

    ...
    Restarting the KDC
    Please add records in this file to your DNS system: /tmp/ipa.system.records.UFRBto.db
    Restarting the web server
    ...
    Importante

    A instalação do servidor não está completa até que você adicione os registros DNS aos servidores DNS existentes.

Recursos adicionais

  • O comando ipa-server-install --external-ca às vezes pode falhar com o seguinte erro:

    ipa         : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/pass:quotes[configuration_file]' returned non-zero exit status 1
    Configuration of CA failed

    Esta falha ocorre quando as variáveis ambientais do *_proxy são definidas. Para uma solução do problema, ver Seção 3.2, “Solução de problemas: Falha na instalação externa da CA”.

6.2. Instalação não-interativa

Este procedimento instala um servidor:

  • Sem DNS integrado
  • com uma autoridade de certificação externa (CA) como a CA de raiz
Nota

O script de instalação ipa-server-install cria um arquivo de log em /var/log/ipaserver-install.log. Se a instalação falhar, o log pode ajudá-lo a identificar o problema.

Pré-requisitos

  • Decida sobre o tipo de CA externa que você utiliza (a opção --external-ca-type ). Veja a ipa-server-install(1) página de homem para detalhes.
  • Alternativamente, decidir sobre a opção --external-ca-profile que permite especificar um modelo alternativo do Active Directory Certificate Services (AD CS). Por exemplo, para especificar um identificador de objeto específico da instalação do AD CS:

    [root@server ~]# ipa-server-install --external-ca --external-ca-type=ms-cs --external-ca-profile=1.3.6.1.4.1.311.21.8.8950086.10656446.2706058.12775672.480128.147.7130143.4405632:1

Procedimento

  1. Execute o ipa-server-install com as opções para fornecer todas as informações necessárias. As opções mínimas necessárias para a instalação não interativa de um servidor IdM com uma CA externa como a CA raiz são:

    • --external-ca para especificar uma CA externa é a CA de raiz
    • --realm para fornecer o nome do reino de Kerberos
    • --ds-password para fornecer a senha para o Gerente de Diretório (DM), o super usuário do Servidor de Diretório
    • --admin-password para fornecer a senha para admin, o administrador da IdM
    • --unattended para deixar o processo de instalação selecionar opções padrão para o nome do host e nome de domínio

      Por exemplo:

      # ipa-server-install --external-ca --realm EXAMPLE.COM --ds-password DM_password --admin-password admin_password --unattended

    Se você estiver usando o Microsoft Certificate Services CA, use também a opção --external-ca-type. Para detalhes, consulte a página de manual ipa-server-install(1).

  2. Durante a configuração da instância do Sistema de Certificado, o utilitário imprime o local do pedido de assinatura do certificado (CSR): /root/ipa.csr:

    ...
    
    Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
      [1/11]: configuring certificate server instance
    The next step is to get /root/ipa.csr signed by your CA and re-run /usr/sbin/ipa-server-install as:
    /usr/sbin/ipa-server-install --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate
    The ipa-server-install command was successful

    Quando isto acontece:

    1. Submeter a RSE localizada em /root/ipa.csr à CA externa. O processo difere dependendo do serviço a ser usado como a CA externa.
    2. Recuperar o certificado emitido e a cadeia de certificados da CA para a CA emissora em um blob básico 64 codificado (um arquivo PEM ou um certificado Base_64 de uma CA Windows). Novamente, o processo difere para cada serviço de certificado. Normalmente, um link para download em uma página da web ou no e-mail de notificação permite ao administrador baixar todos os certificados exigidos.

      Importante

      Certifique-se de obter a cadeia completa de certificados para a CA, não apenas o certificado da CA.

    3. Execute ipa-server-install novamente, desta vez especificando os locais e nomes do certificado recém-emitido da CA e os arquivos da cadeia da CA. Por exemplo, o arquivo de corrente da CA:

      # ipa-server-install --external-cert-file=/tmp/servercert20170601.pem --external-cert-file=/tmp/cacert.pem --realm EXAMPLE.COM --ds-password DM_password --admin-password admin_password --unattended
  3. O roteiro de instalação agora configura o servidor. Aguarde que a operação seja concluída.
  4. O script de instalação produz um arquivo com registros de recursos DNS: o arquivo /tmp/ipa.system.records.UFRPto.db no exemplo de saída abaixo. Acrescente estes registros aos servidores DNS externos existentes. O processo de atualização dos registros DNS varia de acordo com a solução DNS específica.

    ...
    Restarting the KDC
    Please add records in this file to your DNS system: /tmp/ipa.system.records.UFRBto.db
    Restarting the web server
    ...
Importante

A instalação do servidor não está completa até que você adicione os registros DNS aos servidores DNS existentes.

Capítulo 7. Solução de problemas de instalação do servidor IdM

As seções seguintes descrevem como reunir informações sobre a instalação de um servidor IdM falho, e como resolver problemas comuns de instalação.

7.1. Revisão dos logs de erros de instalação do servidor IdM

Quando você instala um servidor de Gerenciamento de Identidade (IdM), as informações de depuração são anexadas aos seguintes arquivos de registro:

  • /var/log/ipaserver-install.log
  • /var/log/httpd/error_log
  • /var/log/dirsrv/slapd-INSTANCE-NAME/access
  • /var/log/dirsrv/slapd-INSTANCE-NAME/errors

As últimas linhas dos arquivos de registro relatam sucesso ou fracasso, e as entradas em ERROR e DEBUG fornecem um contexto adicional.

Para solucionar problemas de instalação de um servidor IdM falho, revise os erros no final dos arquivos de registro e use essas informações para resolver quaisquer problemas correspondentes.

Pré-requisitos

  • Você deve ter privilégios root para exibir o conteúdo dos arquivos de log do IdM.

Procedimento

  1. Use o comando tail para exibir as últimas linhas de um arquivo de log. O exemplo a seguir mostra as últimas 10 linhas de /var/log/ipaserver-install.log.

    [user@server ~]$ sudo tail -n 10 /var/log/ipaserver-install.log
    [sudo] password for user:
    value = gen.send(prev_value)
    File "/usr/lib/python3.6/site-packages/ipapython/install/common.py", line 65, in _install
    for unused in self._installer(self.parent):
    File "/usr/lib/python3.6/site-packages/ipaserver/install/server/init.py", line 564, in main
    master_install(self)
    File "/usr/lib/python3.6/site-packages/ipaserver/install/server/install.py", line 291, in decorated
    raise ScriptError()
    
    2020-05-27T22:59:41Z DEBUG The ipa-server-install command failed, exception: ScriptError:
    2020-05-27T22:59:41Z ERROR The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information
  2. Para revisar um arquivo de log interativamente, abra o final do arquivo de log usando o utilitário less e use as teclas de seta e para navegar. O exemplo a seguir abre o arquivo /var/log/ipaserver-install.log interativamente.

    [usuário@servidor ~]$ sudo less -N G /var/log/ipaserver-install.log
  3. Reúna informações adicionais de solução de problemas repetindo este processo de revisão com os arquivos de registro restantes.

    [user@server ~]$ sudo less -N +G /var/log/httpd/error_log
    
    [user@server ~]$ sudo less -N +G /var/log/dirsrv/slapd-INSTANCE-NAME/access
    
    [user@server ~]$ sudo less -N +G /var/log/dirsrv/slapd-INSTANCE-NAME/errors

Recursos adicionais

  • Se você não conseguir resolver uma falha na instalação do servidor IdM e tiver uma assinatura do Suporte Técnico da Red Hat, abra um caso de Suporte Técnico no Portal do Cliente da Red Hat e forneça um endereço sosreport do servidor.
  • O utilitário sosreport coleta detalhes de configuração, registros e informações do sistema a partir de um sistema RHEL. Para mais informações sobre o utilitário sosreport, veja O que é um sosreport e como criar um no Red Hat Enterprise Linux?

7.2. Revisão dos erros de instalação da IdM CA

Ao instalar o serviço de Autoridade Certificadora (CA) em um servidor de Gerenciamento de Identidade (IdM), as informações de depuração são anexadas aos seguintes locais (em ordem de prioridade recomendada):

LocalizaçãoDescrição

/var/log/pki/pki-ca-spawn.$TIME_OF_INSTALLATION.log

Questões de alto nível e traços Python para o processo de instalação do pkispawn

journalctl -u pki-tomcatd@pki-tomcat output

Erros do serviço pki-tomcatd@pki-tomcat

/var/log/pki/pki-tomcat/ca/debug.$DATE.log

Grandes pilhas de atividades JAVA no núcleo do produto Public Key Infrastructure (PKI)

/var/log/pki/pki-tomcat/ca/signedAudit/ca_audit arquivo de log

Diário de auditoria do produto PKI

  • /var/log/pki/pki-tomcat/ca/system
  • /var/log/pki/pki-tomcat/ca/transactions
  • /var/log/pki/pki-tomcat/catalina.$DATE.log

Dados de depuração de baixo nível de operações de certificados para diretores de serviço, hospedeiros e outras entidades que utilizam certificados

Nota

Se uma instalação completa do servidor IdM falhar durante a instalação do componente opcional da CA, nenhum detalhe sobre a CA é registrado; uma mensagem é registrada no arquivo /var/log/ipaserver-install.log indicando que o processo geral de instalação falhou. A Red Hat recomenda a revisão dos arquivos de registro listados acima para obter detalhes específicos da falha de instalação da CA.

A única exceção a este comportamento é quando você está instalando o serviço CA e a CA de raiz é uma CA externa. Se houver um problema com o certificado da CA externa, os erros são registrados em /var/log/ipaserver-install.log.

Para solucionar problemas em uma instalação de IdM CA em falha, revise os erros no final destes arquivos de registro e use estas informações para resolver quaisquer problemas correspondentes.

Pré-requisitos

  • Você deve ter privilégios root para exibir o conteúdo dos arquivos de log do IdM.

Procedimento

  1. Para revisar um arquivo de log interativamente, abra o final do arquivo de log usando o utilitário less e use as teclas de seta e para navegar, enquanto procura por entradas em ScriptError. O seguinte exemplo abre /var/log/pki/pki-ca-spawn.$TIME_OF_INSTALLATION.log.

    [usuário@servidor ~]$ sudo less -N G /var/log/pki/pki-ca-spawn.20200527185902.log
  2. Reúna informações adicionais de solução de problemas repetindo este processo de revisão com todos os arquivos de registro listados acima.

Recursos adicionais

  • Se você não conseguir resolver uma falha na instalação do servidor IdM e tiver uma assinatura do Suporte Técnico da Red Hat, abra um caso de Suporte Técnico no Portal do Cliente da Red Hat e forneça um endereço sosreport do servidor.
  • O utilitário sosreport coleta detalhes de configuração, registros e informações do sistema a partir de um sistema RHEL. Para mais informações sobre o utilitário sosreport, veja O que é um sosreport e como criar um no Red Hat Enterprise Linux?

7.3. Remoção de uma instalação parcial do servidor IdM

Se a instalação de um servidor IdM falhar, alguns arquivos de configuração podem ser deixados para trás. Outras tentativas de instalação do servidor IdM falham e o script de instalação informa que o IPA já está configurado.

[root@server ~]# ipa-server-install

The log file for this installation can be found in /var/log/ipaserver-install.log
IPA server is already configured on this system.
If you want to reinstall the IPA server, please uninstall it first using 'ipa-server-install --uninstall'.
The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information

Para resolver este problema, desinstale a configuração parcial do servidor IdM e tente novamente o processo de instalação.

Pré-requisitos

  • Você deve ter privilégios no site root.

Procedimento

  1. Desinstale o software do servidor IdM do host que você está tentando configurar como um servidor IdM.

    [root@server ~]# ipa-server-install --uninstall
  2. Se você continuar tendo dificuldades para instalar um servidor IdM por causa de repetidas instalações com falhas, reinstale o sistema operacional.

    Um dos requisitos para a instalação de um servidor IdM é um sistema limpo sem nenhuma personalização. Instalações fracassadas podem ter comprometido a integridade do host ao modificar inesperadamente os arquivos do sistema.

Recursos adicionais

7.4. Recursos adicionais

Capítulo 8. Desinstalando um servidor IdM

Como administrador, você pode remover um servidor de Gerenciamento de Identidade (IdM) da topologia.

Este procedimento descreve como você pode desinstalar um servidor de exemplo chamado server.idm.example.com.

Pré-requisitos

  • Antes de desinstalar um servidor que serve como autoridade de certificado (CA), autoridade de recuperação de chaves (KRA), ou servidor DNS, certifique-se de que estes serviços estão sendo executados em outro servidor no domínio.
Atenção

A remoção do último servidor que serve como CA, KRA, ou servidor DNS perturba seriamente a funcionalidade de Gerenciamento de Identidade (IdM).

Procedimento

  1. Em todos os servidores da topologia que têm um acordo de replicação com server.idm.example.com, use o comando ipa server-del para excluir a réplica da topologia:

    [root@another_server ~]# ipa server-del server.idm.example.com
  2. Em server.idm.example.com, use o comando ipa-server-install --uninstall:

    [root@server ~]# ipa-server-install --uninstall
    ...
    Are you sure you want to continue with the uninstall procedure? [no]: yes
  3. Certifique-se de que todos os registros DNS do servidor de nomes (NS) que apontam para server.idm.example.com sejam excluídos de suas zonas DNS. Isto se aplica independentemente de você usar DNS integrado gerenciado pela IdM ou DNS externo.

Capítulo 9. Renomeando um servidor IdM

Você não pode mudar o nome do host de um servidor de Gerenciamento de Identidade (IdM) existente. Entretanto, você pode substituir o servidor por uma réplica de um nome diferente.

Procedimento

  1. Instale uma nova réplica que substituirá o servidor existente, garantindo que a réplica tenha o nome do host e o endereço IP necessários. Para maiores detalhes, veja Capítulo 18, Instalação de uma réplica da IdM.

    Importante

    Se o servidor que você está desinstalando é o servidor editor da lista de revogação de certificados (CRL), faça de outro servidor o servidor editor da CRL antes de prosseguir. Para detalhes de como isto é feito no contexto de um procedimento de migração, veja as seções seguintes:

  2. Pare a instância existente do servidor IdM.

    [root@old_server ~]# ipactl stop
  3. Desinstale o servidor existente, conforme descrito em Capítulo 8, Desinstalando um servidor IdM.

Capítulo 10. Preparando o sistema para a instalação do cliente IdM

Este capítulo descreve as condições que seu sistema deve cumprir para instalar um cliente de Gerenciamento de Identidade (IdM).

10.1. Requisitos DNS para clientes da IdM

O instalador do cliente por padrão tenta procurar por _ldap._tcp.DOMAIN registros DNS SRV para todos os domínios que são pais de seu hostname. Por exemplo, se uma máquina cliente tem um hostname client1.idm.example.com, o instalador tentará recuperar um hostname do servidor IdM em _ldap._tcp.idm.example.com, _ldap._tcp.example.com e _ldap._tcp.com registros DNS SRV, respectivamente. O domínio descoberto é então utilizado para configurar componentes clientes (por exemplo, configuração SSSD e Kerberos 5) na máquina.

Entretanto, os nomes das host dos clientes da IdM não são obrigados a fazer parte do domínio DNS primário. Se o hostname da máquina cliente não estiver em um subdomínio de um servidor IdM, passe o domínio IdM como opção --domain do comando ipa-client-install. Nesse caso, após a instalação do cliente, ambos os componentes SSSD e Kerberos terão o domínio configurado em seus arquivos de configuração e o utilizarão para auto-descobrir servidores IdM.

Recursos adicionais

10.2. Requisitos portuários para clientes da IdM

Os clientes de Gerenciamento de Identidade (IdM) se conectam a uma série de portas em servidores IdM para se comunicar com seus serviços.

No cliente IdM, estes portos devem estar abertos in the outgoing direction. Se você estiver usando um firewall que não filtra pacotes de saída, como firewalld, as portas já estão disponíveis na direção de saída.

Recursos adicionais

10.3. Requisitos IPv6 para clientes IdM

O Gerenciamento de Identidade (IdM) não requer que o protocolo IPv6 esteja habilitado no kernel do hospedeiro que você deseja inscrever-se no IdM. Por exemplo, se sua rede interna usa apenas o protocolo IPv4, você pode configurar o Daemon System Security Services (SSSD) para usar apenas IPv4 para se comunicar com o servidor IdM. Você pode fazer isto inserindo a seguinte linha no [domain/NAME] seção do arquivo /etc/sssd/sssd.conf:

lookup_family_order = ipv4_only

Recursos adicionais

  • Para mais informações sobre a opção lookup_family_order, consulte a página de manual sssd.conf(5).

10.4. Pacotes necessários para instalar um cliente IdM

Na RHEL8, os pacotes necessários para a instalação de um cliente de Gerenciamento de Identidade (IdM) são enviados como um módulo. Dois fluxos IdM fornecem pacotes de clientes IdM:

10.4.1. Instalação de pacotes ipa-cliente a partir do idm:client stream

O fluxo idm:client é o fluxo padrão do módulo idm. Use este fluxo para baixar os pacotes de clientes IdM se você não precisar instalar componentes de servidor em sua máquina. O uso do fluxo idm:client é especialmente recomendado se você precisar usar consistentemente o software cliente IdM que é suportado a longo prazo, desde que você não precise de componentes de servidor também.

Importante

Ao mudar para o fluxo idm:client depois de ter ativado anteriormente o fluxo idm:DL1 e baixado pacotes dele, você precisa primeiro remover explicitamente todo o conteúdo instalado relevante e desativar o fluxo idm:DL1 antes de ativar o fluxo idm:client. Tentar ativar um novo fluxo sem desativar o fluxo atual resulta em um erro. Para obter detalhes sobre como proceder, consulte Mudando para um fluxo posterior.

Procedimento

  • Para baixar os pacotes necessários para a instalação de um cliente IdM:

    # yum module install idm

10.4.2. Instalação de pacotes ipa-cliente a partir do idm:DL1 stream

O fluxo idm:DL1 precisa ser ativado antes que você possa baixar pacotes a partir dele. Use este fluxo para baixar os pacotes clientes IdM se você precisar instalar os componentes do servidor IdM em sua máquina.

Importante

Ao mudar para o fluxo idm:DL1 depois de ter ativado anteriormente o fluxo idm:client e baixado pacotes dele, você precisa primeiro remover explicitamente todo o conteúdo instalado relevante e desativar o fluxo idm:client antes de ativar o fluxo idm:DL1. Tentar ativar um novo fluxo sem desativar o fluxo atual resulta em um erro. Para obter detalhes sobre como proceder, consulte Mudando para um fluxo posterior.

Procedimento

  1. Para mudar para as RPMs entregues através do fluxo idm:DL1:

    # yum module enable idm:DL1
    # yum distro-sync
  2. Para baixar os pacotes necessários para a instalação de um cliente IdM:

    # yum module install idm:DL1/client

Capítulo 11. Instalação de um cliente IdM: Cenário básico

As seções seguintes descrevem como configurar um sistema como um cliente de Gerenciamento de Identidade (IdM) usando o utilitário ipa-client-install. A configuração de um sistema como cliente IdM o cadastra em um domínio IdM e permite que o sistema utilize serviços IdM em servidores IdM no domínio.

Para instalar um cliente de Gerenciamento de Identidade (IdM) com sucesso, é necessário fornecer credenciais que possam ser utilizadas para a inscrição do cliente. Os seguintes métodos de autenticação estão disponíveis:

11.1. Pré-requisitos

Antes de começar a instalação do cliente IdM, certifique-se de que você tenha cumprido todos os pré-requisitos. Ver Capítulo 10, Preparando o sistema para a instalação do cliente IdM.

11.2. Instalação de um cliente usando as credenciais do usuário: Instalação interativa

Este procedimento descreve a instalação interativa de um cliente de Gerenciamento de Identidade (IdM), usando as credenciais de um usuário autorizado para registrar o sistema no domínio.

Pré-requisitos

  • Certifique-se de ter as credenciais de um usuário autorizado a cadastrar clientes no domínio IdM. Este poderia ser, por exemplo, um usuário hostadmin com a função de Administrador de Inscrição.

Procedimento

  1. Execute o utilitário ipa-client-install no sistema que você deseja configurar como um cliente IdM.

    # ipa-client-install

    Adicione a opção --enable-dns-updates para atualizar os registros DNS com o endereço IP do sistema do cliente se uma das seguintes condições se aplicar:

    • O servidor IdM com o qual o cliente será cadastrado foi instalado com DNS integrado
    • O servidor DNS na rede aceita atualizações de entrada DNS com o protocolo GSS-TSIG
    # ipa-client-install --enable-dns-updates

    A ativação de atualizações DNS é útil se seu cliente:

    • tem um endereço IP dinâmico emitido usando o Protocolo de Configuração Dinâmica do Host
    • tem um endereço IP estático, mas acabou de ser alocado e o servidor IdM não sabe sobre ele
  2. O script de instalação tenta obter automaticamente todas as configurações necessárias, tais como registros DNS.

    • Se os registros SRV forem definidos corretamente na zona DNS do IdM, o script descobre automaticamente todos os outros valores necessários e os exibe. Digite yes para confirmar.

      Client hostname: client.example.com
      Realm: EXAMPLE.COM
      DNS Domain: example.com
      IPA Server: server.example.com
      BaseDN: dc=example,dc=com
      
      Continue to configure the system with these values? [no]: yes
    • Para instalar o sistema com valores diferentes, digite no. Em seguida, execute novamente ipa-client-install e especifique os valores necessários adicionando opções de linha de comando a ipa-client-install, por exemplo:

      • --hostname
      • --realm
      • --domain
      • --server
    • Se o script não conseguir obter algumas configurações automaticamente, ele solicita os valores.
    Importante

    O nome de domínio totalmente qualificado deve ser um nome DNS válido:

    • Somente números, caracteres alfabéticos e hífens (-) são permitidos. Por exemplo, os sublinhados não são permitidos e podem causar falhas no DNS.
    • O nome do anfitrião deve ser todo em letra minúscula. Não são permitidas letras maiúsculas.
  3. O roteiro solicita um usuário cuja identidade será usada para inscrever o cliente. Este poderia ser, por exemplo, um usuário hostadmin com a função de Administrador de Inscrição:

    User authorized to enroll computers: hostadmin
    Password for hostadmin@EXAMPLE.COM:
  4. O roteiro de instalação agora configura o cliente. Aguarde que a operação seja concluída.

    Configuração completa do cliente.

Recursos adicionais

  • Para detalhes sobre como o script de instalação do cliente busca os registros DNS, consulte a seção DNS Autodiscovery na página de manual ipa-client-install(1).

11.3. Instalação de um cliente usando uma senha única: Instalação interativa

Este procedimento descreve a instalação interativa de um cliente de Gerenciamento de Identidade (IdM), usando uma senha única para registrar o sistema no domínio.

Pré-requisitos

  1. Em um servidor no domínio, adicione o futuro sistema cliente como um host IdM. Use a opção --random com o comando ipa host-add para gerar uma senha aleatória única para a inscrição.

    $ ipa host-add client.example.com --random
     --------------------------------------------------
     Added host "client.example.com"
     --------------------------------------------------
      Host name: client.example.com
      Random password: W5YpARl=7M.n
      Password: True
      Keytab: False
      Managed by: server.example.com
    Nota

    A senha gerada se tornará inválida após sua utilização para registrar a máquina no domínio IdM. Ela será substituída por uma guia de chave de host apropriada após o término da matrícula.

Procedimento

  1. Execute o utilitário ipa-client-install no sistema que você deseja configurar como um cliente IdM. Use a opção --password para fornecer a senha aleatória única. Como a senha muitas vezes contém caracteres especiais, coloque-a entre aspas simples (').

    # ipa-client-install

    Adicione a opção --enable-dns-updates para atualizar os registros DNS com o endereço IP do sistema do cliente se uma das seguintes condições se aplicar:

    • O servidor IdM com o qual o cliente será cadastrado foi instalado com DNS integrado
    • O servidor DNS na rede aceita atualizações de entrada DNS com o protocolo GSS-TSIG
    # ipa-client-install --password 'W5YpARl=7M.n' --enable-dns-updates

    A ativação de atualizações DNS é útil se seu cliente:

    • tem um endereço IP dinâmico emitido usando o Protocolo de Configuração Dinâmica do Host
    • tem um endereço IP estático, mas acabou de ser alocado e o servidor IdM não sabe sobre ele
  2. O script de instalação tenta obter automaticamente todas as configurações necessárias, tais como registros DNS.

    • Se os registros SRV forem definidos corretamente na zona DNS do IdM, o script descobre automaticamente todos os outros valores necessários e os exibe. Digite yes para confirmar.

      Client hostname: client.example.com
      Realm: EXAMPLE.COM
      DNS Domain: example.com
      IPA Server: server.example.com
      BaseDN: dc=example,dc=com
      
      Continue to configure the system with these values? [no]: yes
    • Para instalar o sistema com valores diferentes, digite no. Em seguida, execute novamente ipa-client-install e especifique os valores necessários adicionando opções de linha de comando a ipa-client-install, por exemplo:

      • --hostname
      • --realm
      • --domain
      • --server
    • Se o script não conseguir obter algumas configurações automaticamente, ele solicita os valores.
    Importante

    O nome de domínio totalmente qualificado deve ser um nome DNS válido:

    • Somente números, caracteres alfabéticos e hífens (-) são permitidos. Por exemplo, os sublinhados não são permitidos e podem causar falhas no DNS.
    • O nome do anfitrião deve ser todo em letra minúscula. Não são permitidas letras maiúsculas.
  3. O roteiro de instalação agora configura o cliente. Aguarde que a operação seja concluída.

    Configuração completa do cliente.

Recursos adicionais

  • Para detalhes sobre como o script de instalação do cliente busca os registros DNS, consulte a seção DNS Autodiscovery na página de manual ipa-client-install(1).

11.4. Instalação de um cliente: Instalação não-interativa

Para uma instalação não-interativa, você deve fornecer todas as informações necessárias ao utilitário ipa-client-install usando as opções de linha de comando. As seções seguintes descrevem as opções mínimas necessárias para uma instalação não-interativa.

Opções para o método de autenticação pretendido para a inscrição do cliente

As opções disponíveis são:

  • --principal e --password para especificar as credenciais de um usuário autorizado a matricular clientes
  • --random para especificar uma senha aleatória gerada uma única vez para o cliente
  • --keytab para especificar a tabela de chaves de um cadastro anterior
A opção de instalação desacompanhada

A opção --unattended permite que a instalação seja executada sem a necessidade de confirmação do usuário.

Se os registros SRV forem definidos corretamente na zona DNS do IdM, o script descobre automaticamente todos os outros valores necessários. Se o script não puder descobrir os valores automaticamente, forneça-os usando opções de linha de comando, como por exemplo:

  • --hostname para especificar um nome de domínio estático totalmente qualificado (FQDN) para a máquina do cliente.

    Importante

    O FQDN deve ser um nome DNS válido:

    • Somente números, caracteres alfabéticos e hífens (-) são permitidos. Por exemplo, os sublinhados não são permitidos e podem causar falhas no DNS.
    • O nome do anfitrião deve ser todo em letra minúscula. Não são permitidas letras maiúsculas.
  • --domain para especificar o domínio DNS primário de uma implantação IdM existente, por exemplo, exemplo.com. O nome é uma versão em letras minúsculas do nome do reino IdM Kerberos.
  • --server para especificar a FQDN do servidor IdM a ser conectado. Quando esta opção é utilizada, a auto-descoberta DNS para Kerberos é desativada e uma lista fixa de servidores KDC e Admin é configurada. Em circunstâncias normais, esta opção não é necessária, pois a lista de servidores é recuperada a partir do domínio DNS primário do IdM.
  • --realm para especificar o reino Kerberos de uma implantação de IdM existente. Normalmente é uma versão em maiúsculas do domínio DNS primário usado pela instalação do IdM. Em circunstâncias normais, esta opção não é necessária, pois o nome do domínio é recuperado do servidor do IdM.

Um exemplo de um comando básico ipa-client-install para instalação não-interativa:

# ipa-client-install --password 'W5YpARl=7M.n' --unattended


Um exemplo de um comando ipa-client-install para instalação não interativa com mais opções especificadas:

# ipa-client-install --password 'W5YpARl=7M.n' --domain example.com --server server.idm.example.com --realm EXAMPLE.COM --unattended

Recursos adicionais

  • Para uma lista completa das opções aceitas por ipa-client-install, consulte a página de manual ipa-client-install(1).

11.5. Remoção da configuração pré-IdM após a instalação de um cliente

O script ipa-client-install não remove nenhuma configuração anterior do LDAP e do Daemon dos Serviços de Segurança do Sistema (SSSD) dos arquivos /etc/openldap/ldap.conf e /etc/sssd/sssd.conf. Se você modificou a configuração nestes arquivos antes de instalar o cliente, o script adiciona os novos valores do cliente, mas os comenta. Por exemplo:

BASE   dc=example,dc=com
URI    ldap://ldap.example.com

#URI ldaps://server.example.com # modified by IPA
#BASE dc=ipa,dc=example,dc=com # modified by IPA

Para aplicar os novos valores de configuração do Gerenciamento de Identidade (IdM)}:

  1. Abrir /etc/openldap/ldap.conf e /etc/sssd/sssd.conf.
  2. Eliminar a configuração anterior.
  3. Descomentar a nova configuração da IdM.
  4. Os processos do servidor que dependem da configuração do LDAP em todo o sistema podem exigir um reinício para aplicar as mudanças. As aplicações que utilizam bibliotecas openldap normalmente importam a configuração quando iniciadas.

11.6. Testando um cliente IdM

A Interface da Linha de Comando informa que a ipa-client-install foi bem sucedida, mas você também pode fazer seu próprio teste.

Para testar se o cliente de Gerenciamento de Identidade (IdM) pode obter informações sobre os usuários definidos no servidor, verifique se você é capaz de resolver um usuário definido no servidor. Por exemplo, para verificar o usuário padrão admin:

[user@client ~]$ id admin
uid=1254400000(admin) gid=1254400000(admins) groups=1254400000(admins)

Para testar se a autenticação funciona corretamente, su para um usuário root de um usuário não-root:

[user@client ~]$ su -
Last login: Thu Oct 18 18:39:11 CEST 2018 from 192.168.122.1 on pts/0
[root@client ~]#

11.7. Conexões realizadas durante a instalação de um cliente IdM

Tabela 11.1, “Pedidos realizados durante a instalação de um cliente IdM” lista as operações realizadas por ipa-client-install, a ferramenta de instalação do cliente Identity Management (IdM).

Tabela 11.1. Pedidos realizados durante a instalação de um cliente IdM

OperaçãoProtocolo utilizadoObjetivo

Resolução DNS contra os resolvedores DNS configurados no sistema do cliente

DNS

Descobrir os endereços IP dos mestres da IdM; (opcionalmente) adicionar registros A/AAAA e SSHFP

Pedidos às portas 88 (TCP/TCP6 e UDP/UDP6) em uma réplica do IdM

Kerberos

Para obter um bilhete Kerberos

Chamadas do JSON-RPC para o serviço web baseado no IdM Apache sobre mestres IdM descobertos ou configurados

HTTPS

Inscrição de cliente IdM; recuperação da cadeia de certificados CA se o método LDAP falhar; solicitação de emissão de certificado, se necessário

Solicitações sobre TCP/TCP6 para portas 389 em servidores IdM, usando autenticação SASL GSSAPI, LDAP simples, ou ambos

LDAP

Inscrição de clientes IdM; recuperação de identidade por processos SSSD; recuperação da chave Kerberos para o principal anfitrião

Descoberta e resolução do protocolo de tempo de rede (NTP) (opcionalmente)

NTP

Para sincronizar o tempo entre o sistema cliente e um servidor NTP

11.8. Comunicações do cliente IdM com o servidor durante a implantação pós-instalação

O lado cliente da estrutura de Gerenciamento de Identidade (IdM) é implementado com duas aplicações diferentes:

  • a interface de linha de comando (CLI) ipa
  • a interface Web baseada no navegador

A interface Web baseada no navegador é opcional.

Asoperações de pós-instalação da CLI mostram as operações realizadas pela CLI durante uma implantação pós-instalação de um cliente da IdM. As operações de pós-instalação da Web UI mostram as operações realizadas pela Web UI durante a implantação de um cliente IdM pós-instalação.

Dois daemons rodam no cliente IdM, o System Security Services Daemon (SSSD) e certmonger. Os padrões de comunicação SSSD e Certmonger descrevem como estes daemons se comunicam com os serviços disponíveis nos servidores da IdM e Active Directory.

Tabela 11.2. Operações CLI pós-instalação

OperaçãoProtocolo utilizadoObjetivo

Resolução DNS contra os resolvedores DNS configurados no sistema do cliente

DNS

Para descobrir os endereços IP dos mestres da IdM

Pedidos às portas 88 (TCP/TCP6 e UDP/UDP6) e 464 (TCP/TCP6 e UDP/UDP6) em uma réplica do IdM

Kerberos

Para obter um bilhete Kerberos; mudar uma senha Kerberos; autenticar na IDM Web UI

Chamadas do JSON-RPC para o serviço web baseado no IdM Apache sobre mestres IdM descobertos ou configurados

HTTPS

qualquer ipa uso utilitário

Tabela 11.3. Operações de pós-instalação da Web UI

OperaçãoProtocolo utilizadoObjetivo

Chamadas do JSON-RPC para o serviço web baseado no IdM Apache sobre mestres IdM descobertos ou configurados

HTTPS

Para recuperar as páginas da IdM Web UI

11.8.1. Padrões de comunicação SSSD

O System Security Services Daemon (SSSD) é um serviço de sistema para acessar diretórios remotos e mecanismos de autenticação. Se configurado em um cliente IdM de Gerenciamento de Identidade, ele se conecta ao servidor IdM, que fornece autenticação, autorização e outras informações de identidade e política. Se o servidor IdM estiver em um relacionamento de confiança com o Active Directory (AD), o SSSD também se conecta ao AD para realizar autenticação para usuários AD usando o protocolo Kerberos. Por padrão, o SSSD usa o Kerberos para autenticar qualquer usuário não-local. Em situações especiais, o SSSD pode ser configurado para usar o protocolo LDAP em seu lugar.

O SSSD pode ser configurado para se comunicar com vários servidores. Os padrões de comunicação do SSSD em clientes IdM ao conversar com servidores IdM e os padrões de comunicação do SSSD em servidores IdM agindo como agentes de confiança ao conversar com Controladores de Domínio Active Directory mostram padrões de comunicação comuns para SSSD no IdM.

Tabela 11.4. Padrões de comunicação de SSSD em clientes da IdM ao falar com servidores da IdM

OperaçãoProtocolo utilizadoObjetivo

Resolução DNS contra os resolvedores DNS configurados no sistema do cliente

DNS

Para descobrir os endereços IP dos mestres da IdM

Pedidos às portas 88 (TCP/TCP6 e UDP/UDP6), 464 (TCP/TCP6 e UDP/UDP6), e 749 (TCP/TCP6) sobre uma réplica de Gerenciamento de Identidade e controladores de domínio Active Directory

Kerberos

Para obter um bilhete Kerberos; para mudar uma senha Kerberos

Solicitações sobre TCP/TCP6 para portas 389 em servidores IdM, usando autenticação SASL GSSAPI, LDAP simples, ou ambos

LDAP

Para obter informações sobre usuários e hosts IdM, baixe as regras HBAC e sudo, mapas automáticos, o contexto do usuário SELinux, chaves SSH públicas e outras informações armazenadas no IdM LDAP

(opcionalmente) Em caso de autenticação de cartão inteligente, os pedidos ao OCSP (Online Certificate Status Protocol) respondem, se estiver configurado. Isto freqüentemente é feito via porta 80, mas depende do valor real da URL do respondedor OCSP em um certificado de cliente.

HTTP

Para obter informações sobre o status do certificado instalado no Cartão Smart Card

Tabela 11.5. Padrões de comunicação de SSSD em servidores IdM agindo como agentes de confiança ao falar com Controladores de Domínio Active Directory

OperaçãoProtocolo utilizadoObjetivo

Resolução DNS contra os resolvedores DNS configurados no sistema do cliente

DNS

Para descobrir os endereços IP dos mestres da IdM

Pedidos às portas 88 (TCP/TCP6 e UDP/UDP6), 464 (TCP/TCP6 e UDP/UDP6), e 749 (TCP/TCP6) sobre uma réplica de Gerenciamento de Identidade e controladores de domínio Active Directory

Kerberos

Para obter um bilhete Kerberos; mudar uma senha Kerberos; administrar Kerberos remotamente

Solicitações às portas 389 (TCP/TCP6 e UDP/UDP6) e 3268 (TCP/TCP6)

LDAP

Para consultar informações de usuários e grupos do Active Directory; para descobrir os controladores de domínio do Active Directory

(opcionalmente) Em caso de autenticação de cartão inteligente, os pedidos ao OCSP (Online Certificate Status Protocol) respondem, se estiver configurado. Isto freqüentemente é feito via porta 80, mas depende do valor real da URL do respondedor OCSP em um certificado de cliente.

HTTP

Para obter informações sobre o status do certificado instalado no Cartão Smart Card

11.8.2. Padrões de comunicação da Certmonger

Certmonger é um daemon rodando no Gerenciamento de Identidade (IdM) masters e clientes de IdM para permitir uma renovação oportuna dos certificados SSL associados aos serviços no host. O Tabela 11.6, “Padrões de comunicação da Certmonger” mostra as operações realizadas pelo utilitário certmonger do cliente IdM nos mestres IdM.

Tabela 11.6. Padrões de comunicação da Certmonger

OperaçãoProtocolo utilizadoObjetivo

Resolução DNS contra os resolvedores DNS configurados no sistema do cliente

DNS

Para descobrir os endereços IP dos mestres da IdM

Pedidos às portas 88 (TCP/TCP6 e UDP/UDP6) e 464 (TCP/TCP6 e UDP/UDP6) em uma réplica do IdM

Kerberos

Para obter um bilhete Kerberos

Chamadas do JSON-RPC para o serviço web baseado no IdM Apache sobre mestres IdM descobertos ou configurados

HTTPS

Para solicitar novos certificados

Acesso através da porta 8080 (TCP/TCP6) no mestre da IdM

HTTP

Para obter um OCSP (Online Certificate Status Protocol) de resposta e status do certificado

(no primeiro servidor instalado ou no servidor onde o rastreamento de certificados foi transferido) Acesso pela porta 8443 (TCP/TCP6) no mestre do IdM

HTTPS

Para administrar a Autoridade Certificadora no mestre IdM (somente durante a instalação do mestre IdM e réplica)

Capítulo 12. Instalando um cliente IdM com Kickstart

Uma inscrição Kickstart adiciona automaticamente um novo sistema ao domínio Gerenciamento de Identidade (IdM) no momento em que o Red Hat Enterprise Linux é instalado.

12.1. Instalação de um cliente com Kickstart

Este procedimento descreve como usar um arquivo Kickstart para instalar um cliente de Gerenciamento de Identidade (IdM).

Pré-requisitos

Procedimento

  1. Pré-criar a entrada do host no servidor IdM e definir uma senha temporária para a entrada:

    $ ipa host-add client.example.com --password=secret

    A senha é usada pelo Kickstart para autenticar durante a instalação do cliente e expira após a primeira tentativa de autenticação. Depois que o cliente é instalado com sucesso, ele se autentica usando sua chaveta.

  2. Crie um arquivo Kickstart com o conteúdo descrito em Seção 12.2, “Arquivo Kickstart para instalação do cliente”. Certifique-se de que a rede esteja configurada corretamente no arquivo Kickstart usando o comando network.
  3. Use o arquivo Kickstart para instalar o cliente IdM.

12.2. Arquivo Kickstart para instalação do cliente

Esta seção descreve o conteúdo de um arquivo kickstart que você pode usar para instalar um cliente de Gerenciamento de Identidade (IdM).

O pacote ipa-client na lista de pacotes a instalar

Adicione o pacote ipa-client à seção %packages do arquivo kickstart. Por exemplo:

%packages
...
ipa-client
...
Instruções pós-instalação para o cliente IdM

As instruções pós-instalação devem incluir:

  • Uma instrução para garantir que as chaves SSH sejam geradas antes da matrícula
  • Uma instrução para executar o utilitário ipa-client-install, especificando ao mesmo tempo:

Por exemplo, as instruções pós-instalação para uma instalação de pontapé inicial que usa uma senha única e recupera as opções necessárias da linha de comando em vez de via DNS podem se parecer com isto:

%post --log=/root/ks-post.log

# Generate SSH keys; ipa-client-install uploads them to the IdM server by default
/usr/libexec/openssh/sshd-keygen rsa

# Run the client install script
/usr/sbin/ipa-client-install --hostname=client.example.com --domain=EXAMPLE.COM --enable-dns-updates --mkhomedir -w secret --realm=EXAMPLE.COM --server=server.example.com

Opcionalmente, você também pode incluir outras opções no arquivo Kickstart, como por exemplo:

  • Para uma instalação não interativa, adicione a opção --unattended a ipa-client-install.
  • Para que o script de instalação do cliente solicite um certificado para a máquina:

    • Adicione a opção --request-cert a ipa-client-install.
    • Defina o endereço do ônibus do sistema para /dev/null tanto para o utilitário getcert como para o ipa-client-install no ambiente Kickstart chroot. Para fazer isto, adicione estas linhas às instruções pós-instalação no arquivo Kickstart antes da instrução ipa-client-install:

      # env DBUS_SYSTEM_BUS_ADDRESS=unix:path=/dev/null getcert list
      # env DBUS_SYSTEM_BUS_ADDRESS=unix:path=/dev/null ipa-client-install

12.3. Testando um cliente IdM

A Interface da Linha de Comando informa que a ipa-client-install foi bem sucedida, mas você também pode fazer seu próprio teste.

Para testar se o cliente de Gerenciamento de Identidade (IdM) pode obter informações sobre os usuários definidos no servidor, verifique se você é capaz de resolver um usuário definido no servidor. Por exemplo, para verificar o usuário padrão admin:

[user@client ~]$ id admin
uid=1254400000(admin) gid=1254400000(admins) groups=1254400000(admins)

Para testar se a autenticação funciona corretamente, su para um usuário root de um usuário não-root:

[user@client ~]$ su -
Last login: Thu Oct 18 18:39:11 CEST 2018 from 192.168.122.1 on pts/0
[root@client ~]#

Capítulo 13. Solução de problemas de instalação do cliente IdM

As seções seguintes descrevem como reunir informações sobre uma instalação cliente IdM falhada, e como resolver problemas comuns de instalação.

13.1. Revisão dos erros de instalação do cliente IdM

Quando você instala um cliente de Gerenciamento de Identidade (IdM), as informações de depuração são anexadas a /var/log/ipaclient-install.log. Se a instalação de um cliente falhar, o instalador registra a falha e faz um roll back das mudanças para desfazer quaisquer modificações no host. O motivo da falha na instalação pode não estar no final do arquivo de registro, pois o instalador também registra o procedimento de roll back.

Para solucionar um problema de instalação de um cliente IdM falho, revise as linhas etiquetadas ScriptError no arquivo /var/log/ipaclient-install.log e use estas informações para resolver quaisquer problemas correspondentes.

Pré-requisitos

  • Você deve ter privilégios root para exibir o conteúdo dos arquivos de log do IdM.

Procedimento

  1. Use o utilitário grep para recuperar quaisquer ocorrências da palavra-chave ScriptError do arquivo /var/log/ipaserver-install.log.

    [user@server ~]$ sudo grep ScriptError /var/log/ipaclient-install.log
    [sudo] password for user:
    2020-05-28T18:24:50Z DEBUG The ipa-client-install command failed, exception: ScriptError: One of password / principal / keytab is required.
  2. Para revisar um arquivo de log interativamente, abra o final do arquivo de log usando o utilitário less e use as teclas de seta e para navegar.

    [usuário@servidor ~]$ sudo less -N G /var/log/ipaclient-install.log

Recursos adicionais

  • Se você não conseguir resolver uma instalação falhada do cliente IdM e tiver uma assinatura do Suporte Técnico da Red Hat, abra um caso de Suporte Técnico no Portal do Cliente da Red Hat e forneça um e-mail sosreport do cliente.
  • O utilitário sosreport coleta detalhes de configuração, registros e informações do sistema a partir de um sistema RHEL. Para mais informações sobre o utilitário sosreport, veja O que é um sosreport e como criar um no Red Hat Enterprise Linux?

13.2. Resolução de problemas caso a instalação do cliente não atualize os registros DNS

O instalador do cliente IdM emite comandos nsupdate para criar PTR, SSHFP, e registros DNS adicionais. Entretanto, o processo de instalação falha se o cliente não conseguir atualizar os registros DNS após a instalação e configuração do software do cliente.

Para corrigir este problema, verifique a configuração e reveja os erros de DNS em /var/log/client-install.log.

Pré-requisitos

  • Você está usando IdM DNS como a solução DNS para seu ambiente IdM

Procedimento

  1. Garantir que atualizações dinâmicas para a zona DNS em que o cliente se encontra estejam habilitadas:

    [usuário@servidor ~]$ ipa dnszone-mod idm.example.com. --dynamic-update=TRUE
  2. Garantir que o servidor IdM que executa o serviço DNS tenha a porta 53 aberta para ambos os protocolos TCP e UDP.

    [user@server ~]$ sudo firewall-cmd --permanent --add-port=53/tcp --add-port=53/udp
    [sudo] password for user:
    success
    [user@server ~]$ firewall-cmd --runtime-to-permanent
    success
  3. Use o utilitário grep para recuperar o conteúdo dos comandos nsupdate de /var/log/client-install.log para ver quais atualizações de registros DNS estão falhando.

    [usuário@servidor ~]$ sudo grep nsupdate /var/log/ipaclient-install.log

Recursos adicionais

  • Se você não conseguir resolver uma instalação em falha, e tiver uma assinatura de Suporte Técnico da Red Hat, abra um caso de Suporte Técnico no Portal do Cliente da Red Hat e forneça um e-mail sosreport do cliente.
  • O utilitário sosreport coleta detalhes de configuração, registros e informações do sistema a partir de um sistema RHEL. Para mais informações sobre o utilitário sosreport, veja O que é um sosreport e como criar um no Red Hat Enterprise Linux?

13.3. Resolução de problemas se a instalação do cliente não aderir ao reino da IdM Kerberos

O processo de instalação do cliente IdM falha se o cliente não puder se juntar ao reino da IdM Kerberos.

Joining realm failed: Failed to add key to the keytab
child exited with 11

Installation failed. Rolling back changes.

Esta falha pode ser causada por um keytab Kerberos vazio.

Pré-requisitos

  • A remoção de arquivos do sistema requer privilégios do root.

Procedimento

  1. Remover /etc/krb5.keytab.

    [user@client ~]$ sudo rm /etc/krb5.keytab
    [sudo] password for user:
    [user@client ~]$ ls /etc/krb5.keytab
    ls: cannot access '/etc/krb5.keytab': No such file or directory
  2. Tente novamente a instalação do cliente IdM.

Recursos adicionais

  • Se você não conseguir resolver uma instalação em falha, e tiver uma assinatura de Suporte Técnico da Red Hat, abra um caso de Suporte Técnico no Portal do Cliente da Red Hat e forneça um e-mail sosreport do cliente.
  • O utilitário sosreport coleta detalhes de configuração, registros e informações do sistema a partir de um sistema RHEL. Para mais informações sobre o utilitário sosreport, veja O que é um sosreport e como criar um no Red Hat Enterprise Linux?

13.4. Recursos adicionais

Capítulo 14. Recrutamento de um cliente IdM

14.1. Recrutamento de clientes na IdM

Esta seção descreve como re-inscrever um cliente de Gerenciamento de Identidade (IdM).

Se uma máquina cliente foi destruída e perdeu a conexão com os servidores da IdM, por exemplo, devido a falha de hardware do cliente, e ainda tem sua chave de acesso, você pode re-inscrever o cliente. Neste cenário, você quer colocar o cliente de volta no ambiente IdM com o mesmo hostname.

Durante a reinscrição, o cliente gera uma nova chave Kerberos e chaves SSH, mas a identidade do cliente no banco de dados LDAP permanece inalterada. Após a reinscrição, o host tem suas chaves e outras informações no mesmo objeto LDAP com o mesmo FQDN como anteriormente, antes da perda da conexão da máquina com os servidores IdM.

Importante

Você só pode re-inscrever clientes cuja entrada de domínio ainda esteja ativa. Se você desinstalou um cliente (usando ipa-client-install --uninstall) ou desabilitou sua entrada no host (usando ipa host-disable), você não pode re-inscrevê-lo.

Não é possível matricular novamente um cliente depois de renomeá-lo. Isto porque no IdM, o atributo chave da entrada do cliente no LDAP é o nome de anfitrião do cliente, seu FQDN. Ao contrário de reinscrever um cliente, durante o qual o objeto LDAP do cliente permanece inalterado, o resultado da renomeação de um cliente é que o cliente tem suas chaves e outras informações em um objeto LDAP diferente com um novo FQDN. Assim, a única maneira de renomear um cliente é desinstalar o host da IdM, mudar o nome do host e instalá-lo como um cliente IdM com um novo nome. Para detalhes sobre como renomear um cliente, veja Capítulo 16, Renomeando sistemas clientes IdM.

14.1.1. O que acontece durante a re-inscrição do cliente

Durante a re-inscrição, IdM:

  • Revoga o certificado original do anfitrião
  • Cria novas chaves SSH
  • Gera um novo keytab

14.2. Recrutamento de um cliente através de credenciais de usuário: Re-inscrição interativa

Este procedimento descreve a reinscrição interativa de um cliente de Gerenciamento de Identidade (IdM), usando as credenciais de um usuário autorizado.

  1. Re-criar a máquina do cliente com o mesmo nome de host.
  2. Execute o comando ipa-client-install --force-join na máquina do cliente:

    # ipa-client-install --force-join
  3. O roteiro solicita um usuário cuja identidade será usada para re-inscrever o cliente. Este poderia ser, por exemplo, um usuário hostadmin com a função de Administrador de Inscrição:

    User authorized to enroll computers: hostadmin
    Password for hostadmin@EXAMPLE.COM:

Recursos adicionais

14.3. Recrutamento de um cliente usando a tecla client keytab: Recrutamento não-interativo

Pré-requisitos

  • Faça backup do arquivo keytab original do cliente, por exemplo, no diretório /tmp ou /root.

Procedimento

Este procedimento descreve a reinscrição de um cliente de Gerenciamento de Identidade (IdM) não-interativamente usando o keytab do sistema do cliente. Por exemplo, a reinscrição usando o keytab do cliente é apropriada para uma instalação automatizada.

  1. Re-criar a máquina do cliente com o mesmo nome de host.
  2. Copie o arquivo keytab do local de backup para o diretório /etc/ na máquina do cliente recriada.
  3. Use o utilitário ipa-client-install para reinscrever o cliente, e especifique a localização da tabela de chaves com a opção --keytab:

    # ipa-client-install --keytab /etc/krb5.keytab
    Nota

    A tabela de chaves especificada na opção --keytab é usada somente quando se autentica para iniciar a inscrição. Durante o recadastramento, a IdM gera uma nova tabela de chaves para o cliente.

14.4. Testando um cliente IdM

A Interface da Linha de Comando informa que a ipa-client-install foi bem sucedida, mas você também pode fazer seu próprio teste.

Para testar se o cliente de Gerenciamento de Identidade (IdM) pode obter informações sobre os usuários definidos no servidor, verifique se você é capaz de resolver um usuário definido no servidor. Por exemplo, para verificar o usuário padrão admin:

[user@client ~]$ id admin
uid=1254400000(admin) gid=1254400000(admins) groups=1254400000(admins)

Para testar se a autenticação funciona corretamente, su para um usuário root de um usuário não-root:

[user@client ~]$ su -
Last login: Thu Oct 18 18:39:11 CEST 2018 from 192.168.122.1 on pts/0
[root@client ~]#

Capítulo 15. Desinstalando um cliente IdM

Como administrador, você pode remover um cliente de Gerenciamento de Identidade (IdM) do ambiente.

15.1. Desinstalando um cliente IdM

A desinstalação de um cliente remove o cliente do domínio de Gerenciamento de Identidade (IdM), juntamente com toda a configuração específica do IdM dos serviços do sistema, tais como System Security Services Daemon (SSSD). Isto restaura a configuração anterior do sistema do cliente.

Procedimento

  1. Digite o comando ipa-client-install --uninstall:

    [root@client ~]# ipa-client-install --uninstall
  2. Remover manualmente do servidor as entradas DNS para o host cliente:

    [root@server ~]# ipa dnsrecord-del
    Record name: old-client-name
    Zone name: idm.example.com
    No option to delete specific record provided.
    Delete all? Yes/No (default No): yes
    ------------------------
    Deleted record "old-client-name"
  3. Para cada chaveta identificada que não seja /etc/krb5.keytab, remova os antigos diretores:

    [root@client ~]# ipa-rmkeytab -k /path/to/keytab -r EXAMPLE.COM
  4. Em um servidor IdM, remova a entrada do host cliente do servidor LDAP da IdM. Isto remove todos os serviços e revoga todos os certificados emitidos para aquele host:

    [root@server ~]# ipa host-del client.idm.example.com
    Importante

    A remoção da entrada de host do cliente do servidor LDAP da IdM é crucial se você acha que pode re-inscrever o cliente no futuro, com um endereço IP diferente ou um hostname diferente.

Capítulo 16. Renomeando sistemas clientes IdM

As seções seguintes descrevem como mudar o nome do host de um sistema cliente de Gerenciamento de Identidade (IdM).

Atenção

A renomeação de um cliente é um procedimento manual. Não o realize a menos que seja absolutamente necessária a mudança do nome do anfitrião.

A renomeação de um cliente da IdM envolve:

  1. Preparando o anfitrião. Para detalhes, veja Seção 16.1, “Pré-requisitos”
  2. Desinstalando o cliente IdM do anfitrião. Para detalhes, veja Seção 16.2, “Desinstalando um cliente IdM”
  3. Renomeando o anfitrião. Para detalhes, veja Seção 16.3, “Renomeando o sistema hospedeiro”
  4. Instalando o cliente IdM no host com o novo nome. Para detalhes, veja Seção 16.4, “Re-instalação de um cliente IdM”
  5. Configuração do host após a instalação do cliente IdM. Para detalhes, veja Seção 16.5, “Serviços de readmissão, re-geração de certificados, e readmissão de grupos anfitriões”

16.1. Pré-requisitos

Antes de desinstalar o cliente atual, tome nota de certas configurações para o cliente. Esta configuração será aplicada após a reinscrição da máquina com um novo nome de host.

  • Identificar quais serviços estão funcionando na máquina:

    • Use o comando ipa service-find, e identifique os serviços com certificados na saída:

      $ ipa service-find old-client-name.example.com
    • Além disso, cada host tem um padrão host service que não aparece na saída do ipa service-find. O principal serviço para o serviço de hospedagem, também chamado host principal, é host/old-client-name.example.com.
  • Para todos os principais serviços exibidos por ipa service-find old-client-name.example.comdeterminar a localização das fichas-chave correspondentes no old-client-name.example.com sistema:

    # find / -name "*.keytab"

    Cada serviço no sistema do cliente tem um Kerberos principal no formulário service_name/host_name@REALM, como por exemplo ldap/old-client-name.example.com@EXAMPLE.COM.

  • Identificar todos os grupos anfitriões aos quais a máquina pertence.

    # ipa hostgroup-find old-client-name.example.com

16.2. Desinstalando um cliente IdM

A desinstalação de um cliente remove o cliente do domínio de Gerenciamento de Identidade (IdM), juntamente com toda a configuração específica do IdM dos serviços do sistema, tais como System Security Services Daemon (SSSD). Isto restaura a configuração anterior do sistema do cliente.

Procedimento

  1. Digite o comando ipa-client-install --uninstall:

    [root@client ~]# ipa-client-install --uninstall
  2. Remover manualmente do servidor as entradas DNS para o host cliente:

    [root@server ~]# ipa dnsrecord-del
    Record name: old-client-name
    Zone name: idm.example.com
    No option to delete specific record provided.
    Delete all? Yes/No (default No): yes
    ------------------------
    Deleted record "old-client-name"
  3. Para cada chaveta identificada que não seja /etc/krb5.keytab, remova os antigos diretores:

    [root@client ~]# ipa-rmkeytab -k /path/to/keytab -r EXAMPLE.COM
  4. Em um servidor IdM, remova a entrada do host cliente do servidor LDAP da IdM. Isto remove todos os serviços e revoga todos os certificados emitidos para aquele host:

    [root@server ~]# ipa host-del client.idm.example.com
    Importante

    A remoção da entrada de host do cliente do servidor LDAP da IdM é crucial se você acha que pode re-inscrever o cliente no futuro, com um endereço IP diferente ou um hostname diferente.

16.3. Renomeando o sistema hospedeiro

Renomear a máquina conforme necessário. Por exemplo:

# hostnamectl set-hostname new-client-name.example.com

Agora você pode reinstalar o cliente de Gerenciamento de Identidade (IdM) no domínio IdM com o novo nome do host.

16.4. Re-instalação de um cliente IdM

Instale um cliente em seu host renomeado seguindo o procedimento descrito em Capítulo 11, Instalação de um cliente IdM: Cenário básico.

16.5. Serviços de readmissão, re-geração de certificados, e readmissão de grupos anfitriões

  1. No servidor de Gerenciamento de Identidade (IdM), adicionar um novo keytab para cada serviço identificado em Seção 16.1, “Pré-requisitos”.

    [root@server ~]# ipa service-add service_name/new-client-name
  2. Gerar certificados para serviços que tiveram um certificado atribuído em Seção 16.1, “Pré-requisitos”. Você pode fazer isso:

    • Usando as ferramentas de administração da IdM
    • Usando a utilidade certmonger
  3. Rele Relembrar o cliente aos grupos anfitriões identificados em Seção 16.1, “Pré-requisitos”.

Capítulo 17. Preparando o sistema para instalação de réplicas IdM

As seções seguintes listam os requisitos para instalar uma réplica do Gerenciamento de Identidade (IdM). Antes da instalação, certifique-se de que seu sistema atenda a estes requisitos.

Um sistema onde se deseja instalar uma réplica deve atender aos requisitos gerais dos servidores Capítulo 1, Preparando o sistema para a instalação do servidor IdM

Para requisitos adicionais específicos para réplicas, veja Seção 17.1, “Requisitos da versão de réplica”

17.1. Requisitos da versão de réplica

O Red Hat Enterprise Linux (RHEL) 8 réplicas só funcionam com masters de Gerenciamento de Identidade (IdM) rodando no RHEL 7.4 e posteriores. Antes de introduzir as réplicas IdM rodando no RHEL 8 em uma implementação existente, atualize todos os servidores IdM para o RHEL 7.4 ou posterior, e mude o nível de domínio para 1.

Além disso, a réplica deve estar rodando a mesma versão ou versão posterior da IdM. Por exemplo, a réplica deve estar rodando a mesma versão ou uma versão posterior da IdM:

  • O servidor mestre é instalado no Red Hat Enterprise Linux 8 e usa os pacotes IdM 4.x.
  • Você deve instalar a réplica também no Red Hat Enterprise Linux 8 ou posterior e usar o IdM versão 4.x ou posterior.

Isto garante que a configuração possa ser copiada corretamente do servidor para a réplica.

Para detalhes sobre como exibir a versão do software IdM, veja Seção 17.2, “Métodos de exibição da versão do software IdM”.

17.2. Métodos de exibição da versão do software IdM

Você pode exibir o número da versão IdM com:

  • a IdM WebUI
  • ipa comandos
  • rpm comandos

Versão de exibição através da WebUI

Na IdM WebUI, a versão do software pode ser exibida escolhendo About no menu de nome de usuário no canto superior direito.

Checking IdM Software Version
Versão de exibição com comandos ipa

A partir da linha de comando, use o comando ipa --version.

[root@server ~]# ipa --version
VERSION: 4.8.0, API_VERSION: 2.233
Versão de exibição com comandos rpm

Se os serviços da IdM não estiverem funcionando corretamente, você pode usar o utilitário rpm para determinar o número da versão do pacote ipa-server que está atualmente instalado.

[root@server ~]# rpm -q ipa-server
ipa-server-4.8.0-11.module+el8.1.0+4247+9f3fd721.x86_64

Capítulo 18. Instalação de uma réplica da IdM

As seções seguintes descrevem como instalar uma réplica de Gerenciamento de Identidade (IdM) com base em um servidor existente. O processo de instalação da réplica copia a configuração do servidor existente, e instala a réplica com base nessa configuração.

Nota

Instale uma réplica da IdM de cada vez. A instalação de múltiplas réplicas ao mesmo tempo não é suportada.

Antes de instalar uma réplica, o sistema alvo deve ser autorizado para a inscrição no domínio IdM. Veja:

Para os procedimentos de instalação das réplicas, veja:

Para solucionar os problemas do procedimento de instalação da réplica, veja:

Após a instalação, veja:

18.1. Pré-requisitos para a instalação de uma réplica em um cliente IdM

Ao instalar uma réplica em um cliente existente, escolha um dos seguintes métodos de autorização.

As credenciais de um usuário privilegiado

Escolha este método para autorizar a instalação da réplica, fornecendo as credenciais de um usuário privilegiado:

  • Faça login como usuário privilegiado antes de executar o utilitário ipa-replica-install. O usuário privilegiado padrão é admin:

    $ kinit admin
  • Deixe o Gerenciamento de Identidade (IdM) solicitar as credenciais de forma interativa. Este é o comportamento padrão.
O grupo anfitrião ipaservers

Escolha este método para autorizar a instalação da réplica, adicionando o cliente ao grupo anfitrião ipaservers. A associação em ipaservers concede à máquina privilégios elevados, análogos às credenciais do administrador.

Para adicionar o cliente como membro do ipaservers:

$ kinit admin
$ ipa hostgroup-add-member ipaservers --hosts replica.example.com
  Host-group: ipaservers
  Description: IPA server hosts
  Member hosts: server.idm.example.com, client.example.com
-------------------------
Number of members added 1
-------------------------

18.2. Pré-requisitos para a instalação de uma réplica em um sistema fora do domínio IdM

Quando você executa o utilitário ipa-replica-install em um sistema que ainda não foi registrado no domínio de Gerenciamento de Identidade (IdM), ipa-replica-install primeiro registra o sistema como um cliente e depois instala os componentes da réplica.

Ao instalar uma réplica em um sistema fora do domínio do IdM, escolha um dos seguintes métodos de autorização.

As credenciais de um usuário privilegiado

Usando este método, a instalação da réplica é autorizada, fornecendo as credenciais de um usuário privilegiado. O usuário privilegiado padrão é admin.

Para usar este método, adicione as opções principais de nome e senha (--principal admin --admin-password password) para ipa-replica-install diretamente durante a instalação.

Uma senha aleatória gerada em um servidor IdM

Usando este método, a instalação da réplica é autorizada, fornecendo uma senha aleatória para inscrição única.

Para gerar a senha aleatória para a futura réplica e adicionar o futuro sistema de réplicas ao grupo host ipaservers, use estes comandos em qualquer servidor do domínio:

  1. Faça o login como administrador.

    $ parentes admin
  2. Adicione a nova máquina como um host IdM. Use a opção --random com o comando ipa host-add para gerar uma senha aleatória única a ser usada para a instalação da réplica.

    $ ipa host-add replica.example2.com --random
    --------------------------------------------------
    Added host "replica.example2.com"
    --------------------------------------------------
      Host name: replica.example2.com
      Random password: W5YpARl=7M.n
      Password: True
      Keytab: False
      Managed by: server.example.com

    A senha gerada se tornará inválida após sua utilização para registrar a máquina no domínio IdM. Ela será substituída por uma guia de chave de host apropriada após o término da matrícula.

  3. Adicione a máquina ao grupo anfitrião ipaservers.

    $ ipa hostgroup-add-member ipaservers --hosts replica.example2.com
      Host-group: ipaservers
      Description: IPA server hosts
      Member hosts: server.example.com, replica.example2.com
    -------------------------
    Number of members added 1
    -------------------------

    A associação em ipaservers concede à máquina os privilégios elevados necessários para a instalação dos serviços de servidor necessários.

18.3. Instalação de uma réplica do IdM com DNS integrado

Este procedimento descreve a instalação de uma réplica:

  • Com DNS integrado
  • Sem uma autoridade certificadora (AC) em um ambiente de Gerenciamento de Identidade (IdM) no qual uma AC já está instalada. A réplica encaminhará todas as operações de certificado para o servidor de IdM com uma CA instalada.

Procedimento

  1. Execute ipa-replica-install com estas opções:

    • --setup-dns para configurar a réplica como o servidor DNS
    • --forwarder para especificar um despachante, ou --no-forwarder se você não quiser usar nenhum despachante. Para especificar vários encaminhadores por motivos de falha, use --forwarder várias vezes.

    Por exemplo, para criar uma réplica com um servidor DNS integrado que encaminha todas as solicitações DNS não gerenciadas pelos servidores IdM para o servidor DNS rodando no IP 192.0.2.1:

    # ipa-replica-install --setup-dns --forwarder 192.0.2.1
    Nota

    O utilitário ipa-replica-install aceita uma série de outras opções relacionadas às configurações do DNS, tais como --no-reverse ou --no-host-dns. Para mais informações sobre elas, consulte a página de manual ipa-replica-install(1).

  2. Após a conclusão da instalação, adicione uma delegação DNS do domínio pai ao domínio DNS IdM. Por exemplo, se o domínio DNS IdM for ipa.example.com, adicione um registro de servidor de nomes (NS) ao domínio pai example.com.

    Importante

    Repita este passo a cada vez depois de ter instalado um servidor DNS IdM.

18.4. Instalação de uma réplica do IdM com um CA

Este procedimento descreve a instalação de uma réplica:

  • Sem DNS integrado
  • Com uma autoridade certificadora (CA)
Importante

Ao configurar uma réplica com um CA, a configuração do CA da réplica deve refletir a configuração do CA do servidor mestre.

Por exemplo, se o servidor inclui uma CA integrada de Gerenciamento de Identidade (IdM) como a CA raiz, a réplica também deve ser instalada com uma CA integrada como a CA raiz. Nenhuma outra configuração de CA está disponível neste caso.

A inclusão da opção --setup-ca no comando ipa-replica-install cuida da cópia da configuração CA do servidor inicial.

Procedimento

  1. Execute ipa-replica-install com a opção --setup-ca.

    # ipa-replica-install --setup-ca
  2. Adicione os novos registros do serviço DNS da IdM ao seu servidor DNS:

    1. Exportar os registros do serviço DNS da IdM para um arquivo no formato nsupdate:

      $ ipa dns-update-system-records --dry-run --out dns_records_file.nsupdate
    2. Envie uma solicitação de atualização do DNS para seu servidor DNS usando o utilitário nsupdate e o arquivo dns_records_file.nsupdate. Para mais informações, consulte Atualização de Registros DNS Externos Utilizando nsupdate na documentação RHEL 7. Alternativamente, consulte a documentação de seu servidor DNS para adicionar registros DNS.

18.5. Instalação de uma réplica do IdM sem uma CA

Este procedimento descreve a instalação de uma réplica:

  • Sem DNS integrado
  • Sem uma autoridade certificadora (CA), fornecendo os certificados exigidos manualmente. A suposição aqui é que o servidor mestre também foi instalado sem uma AC.
Importante

Você não pode instalar um servidor ou réplica usando certificados de servidor de terceiros autoassinados porque os arquivos de certificados importados devem conter toda a cadeia de certificados da CA que emitiu os certificados de servidor LDAP e Apache.

Procedimento

  • Execute ipa-replica-install, e forneça os arquivos de certificados necessários, adicionando estas opções:

    • --dirsrv-cert-file
    • --dirsrv-pin
    • --http-cert-file
    • --http-pin

    Para detalhes sobre os arquivos que são fornecidos utilizando estas opções, veja Seção 4.1, “Certificados necessários para instalar um servidor IdM sem uma CA”.

    Por exemplo:

    # ipa-replica-install \
        --dirsrv-cert-file /tmp/server.crt \
        --dirsrv-cert-file /tmp/server.key \
        --dirsrv-pin secret \
        --http-cert-file /tmp/server.crt \
        --http-cert-file /tmp/server.key \
        --http-pin secret
    Nota

    Não adicione a opção --ca-cert-file. O utilitário ipa-replica-install retira esta parte das informações do certificado automaticamente do servidor mestre.

18.6. Instalando uma réplica oculta da IdM

Uma réplica oculta (não divulgada) é um servidor IdM que tem todos os serviços funcionando e disponíveis. Entretanto, não possui registros SRV no DNS, e as funções do servidor LDAP não estão habilitadas. Portanto, os clientes não podem usar a descoberta de serviços para detectar essas réplicas ocultas.

Para mais detalhes sobre réplicas ocultas, veja O modo de réplica oculta.

Procedimento

  • Para instalar uma réplica oculta, use o seguinte comando:

    ipa-replica-instalar --replicação oculta

Note que o comando instala uma réplica sem registros DNS SRV e com funções de servidor LDAP desabilitadas.

Você também pode mudar o modo de réplica existente para oculta. Para detalhes, consulte Demotion e promoção de réplicas ocultas.

18.7. Teste de uma réplica da IdM

Após criar uma réplica, verifique se a réplica reproduz os dados como esperado. Você pode usar o seguinte procedimento.

Procedimento

  1. Criar um usuário na nova réplica:

    [admin@new_replica ~]$ ipa user-add test_user
  2. Certifique-se de que o usuário esteja visível em outra réplica:

    [admin@another_replica_replica ~]$ ipa user-show test_user

18.8. Conexões realizadas durante a instalação de uma réplica IdM

Tabela 18.1, “Pedidos realizados durante a instalação de uma réplica da IdM” lista as operações realizadas por ipa-replica-install, a ferramenta de instalação de réplicas de Gerenciamento de Identidade (IdM).

Tabela 18.1. Pedidos realizados durante a instalação de uma réplica da IdM

OperaçãoProtocolo utilizadoObjetivo

Resolução DNS contra os resolvedores DNS configurados no sistema do cliente

DNS

Para descobrir os endereços IP dos mestres da IdM

Pedidos aos portos 88 (TCP/TCP6 e UDP/UDP6) sobre os mestres de IdM descobertos

Kerberos

Para obter um bilhete Kerberos

Chamadas JSON-RPC para o serviço web baseado no IdM Apache sobre os mestres IdM descobertos ou configurados

HTTPS

Inscrição de clientes IdM; recuperação de réplicas de chaves e emissão de certificados, se necessário

Solicitações sobre TCP/TCP6 para a porta 389 no servidor IdM, usando autenticação SASL GSSAPI, LDAP simples, ou ambos

LDAP

Inscrição de cliente IdM; recuperação de cadeia de certificados CA; replicação de dados LDAP

Solicitações sobre TCP/TCP6 para porta 22 no servidor IdM

SSH

Para verificar se a conexão está funcionando

(opcionalmente) Acesso sobre a porta 8443 (TCP/TCP6) no mestre da IdM

HTTPS

Para administrar a Autoridade Certificadora no mestre IdM (somente durante a instalação do mestre IdM e réplica)

Capítulo 19. Solução de problemas de instalação de réplicas IdM

As seções seguintes descrevem o processo de coleta de informações sobre uma instalação de réplica IdM falhada, e como resolver alguns problemas comuns de instalação.

19.1. Revisão de erros de instalação de réplicas de IdM

Ao instalar uma réplica de Gerenciamento de Identidade (IdM), as informações de depuração são anexadas aos seguintes arquivos de log na réplica:

  • /var/log/ipareplica-install.log
  • /var/log/ipareplica-conncheck.log
  • /var/log/ipaclient-install.log
  • /var/log/httpd/error_log
  • /var/log/dirsrv/slapd-INSTANCE-NAME/access
  • /var/log/dirsrv/slapd-INSTANCE-NAME/errors
  • /var/log/ipaserver-install.log

O processo de instalação da réplica também acrescenta informações de depuração aos seguintes arquivos de log no IdM server que a réplica está entrando em contato:

  • /var/log/httpd/error_log
  • /var/log/dirsrv/slapd-INSTANCE-NAME/access
  • /var/log/dirsrv/slapd-INSTANCE-NAME/errors

A última linha de cada arquivo de log relata sucesso ou fracasso, e ERROR e DEBUG as entradas fornecem contexto adicional.

Para solucionar problemas de instalação de uma réplica IdM falhada, reveja os erros no final destes arquivos de registro em ambos os hosts (réplica e servidor) e use estas informações para resolver quaisquer problemas correspondentes.

Pré-requisitos

  • Você deve ter privilégios root para exibir o conteúdo dos arquivos de log do IdM.

Procedimento

  1. Use o comando tail para exibir os últimos erros do arquivo primário de registro /var/log/ipareplica-install.log. O exemplo a seguir mostra as últimas 10 linhas.

    [user@replica ~]$ sudo tail -n 10 /var/log/ipareplica-install.log
    [sudo] password for user:
      func(installer)
    File "/usr/lib/python3.6/site-packages/ipaserver/install/server/replicainstall.py", line 424, in decorated
      func(installer)
    File "/usr/lib/python3.6/site-packages/ipaserver/install/server/replicainstall.py", line 785, in promote_check
      ensure_enrolled(installer)
    File "/usr/lib/python3.6/site-packages/ipaserver/install/server/replicainstall.py", line 740, in ensure_enrolled
      raise ScriptError("Configuration of client side components failed!")
    
    2020-05-28T18:24:51Z DEBUG The ipa-replica-install command failed, exception: ScriptError: Configuration of client side components failed!
    2020-05-28T18:24:51Z ERROR Configuration of client side components failed!
    2020-05-28T18:24:51Z ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information
  2. Para rever o arquivo de log interativamente, abra o final do arquivo de log usando o utilitário less e use as teclas de seta e para navegar.

    [user@replica ~]$ sudo less -N G /var/log/ipareplica-install.log
  3. (Opcional) Enquanto /var/log/ipareplica-install.log é o arquivo de registro principal para uma réplica de instalação, você pode reunir informações adicionais de solução de problemas repetindo este processo de revisão com arquivos adicionais na réplica e no servidor.

    Sobre a réplica:

    [user@replica ~]$ sudo less -N +G /var/log/ipareplica-conncheck.log
    [user@replica ~]$ sudo less -N +G /var/log/ipaclient-install.log
    [user@replica ~]$ sudo less -N +G /var/log/httpd/error_log
    [user@replica ~]$ sudo less -N +G /var/log/dirsrv/slapd-INSTANCE-NAME/access
    [user@replica ~]$ sudo less -N +G /var/log/dirsrv/slapd-INSTANCE-NAME/errors
    [user@replica ~]$ sudo less -N +G /var/log/ipaserver-install.log

    No servidor:

    [user@server ~]$ sudo less -N +G /var/log/httpd/error_log
    [user@server ~]$ sudo less -N +G /var/log/dirsrv/slapd-INSTANCE-NAME/access
    [user@server ~]$ sudo less -N +G /var/log/dirsrv/slapd-INSTANCE-NAME/errors

Recursos adicionais

  • Se você não conseguir resolver uma instalação de réplica falhada e tiver uma assinatura do Suporte Técnico da Red Hat, abra um caso de Suporte Técnico no Portal do Cliente da Red Hat e forneça um sosreport da réplica e um sosreport do servidor.
  • O utilitário sosreport coleta detalhes de configuração, registros e informações do sistema a partir de um sistema RHEL. Para mais informações sobre o utilitário sosreport, veja O que é um sosreport e como criar um no Red Hat Enterprise Linux?

19.2. Revisão dos erros de instalação da IdM CA

A instalação do serviço de Autoridade Certificadora (CA) em uma réplica de Gerenciamento de Identidade (IdM) acrescenta informações de depuração a vários locais na réplica e o servidor IdM com o qual a réplica se comunica.

Tabela 19.1. Sobre a réplica (em ordem de prioridade recomendada):

LocalizaçãoDescrição

/var/log/pki/pki-ca-spawn.$TIME_OF_INSTALLATION.log

Questões de alto nível e traços Python para o processo de instalação do pkispawn

journalctl -u pki-tomcatd@pki-tomcat output

Erros do serviço pki-tomcatd@pki-tomcat

/var/log/pki/pki-tomcat/ca/debug.$DATE.log

Grandes pilhas de atividades JAVA no núcleo do produto Public Key Infrastructure (PKI)

/var/log/pki/pki-tomcat/ca/signedAudit/ca_audit

Diário de auditoria do produto PKI

  • /var/log/pki/pki-tomcat/ca/system
  • /var/log/pki/pki-tomcat/ca/transactions
  • /var/log/pki/pki-tomcat/catalina.$DATE.log

Dados de depuração de baixo nível de operações de certificados para diretores de serviço, hospedeiros e outras entidades que utilizam certificados

No servidor contatado pela réplica:

  • /var/log/httpd/error_log arquivo de log

A instalação do serviço CA em uma réplica do IdM existente também escreve informações de depuração no seguinte arquivo de registro:

  • /var/log/ipareplica-ca-install.log arquivo de log
Nota

Se uma réplica completa do IdM falhar durante a instalação do componente opcional da CA, nenhum detalhe sobre a CA é registrado; uma mensagem é registrada no arquivo /var/log/ipareplica-install.log indicando que o processo geral de instalação falhou. A Red Hat recomenda a revisão dos arquivos de registro listados acima para detalhes específicos sobre a falha de instalação da CA.

A única exceção a este comportamento é quando você está instalando o serviço CA e a CA de raiz é uma CA externa. Se houver um problema com o certificado da CA externa, os erros são registrados em /var/log/ipareplica-install.log.

Para solucionar problemas em uma instalação de IdM CA em falha, revise os erros no final destes arquivos de registro e use estas informações para resolver quaisquer problemas correspondentes.

Pré-requisitos

  • Você deve ter privilégios root para exibir o conteúdo dos arquivos de log do IdM.

Procedimento

  1. Para revisar um arquivo de log interativamente, abra o final do arquivo de log usando o utilitário less e use as teclas de seta e para navegar, enquanto procura por entradas em ScriptError. O seguinte exemplo abre /var/log/pki/pki-ca-spawn.$TIME_OF_INSTALLATION.log.

    [usuário@servidor ~]$ sudo less -N G /var/log/pki/pki-ca-spawn.20200527185902.log
  2. Reúna informações adicionais de solução de problemas repetindo este processo de revisão com todos os arquivos de registro listados acima.

Recursos adicionais

  • Se você não conseguir resolver uma instalação em falha e tiver uma assinatura do Suporte Técnico da Red Hat, abra um caso de Suporte Técnico no Portal do Cliente da Red Hat e forneça um sosreport da réplica e um sosreport do servidor.
  • O utilitário sosreport coleta detalhes de configuração, registros e informações do sistema a partir de um sistema RHEL. Para mais informações sobre o utilitário sosreport, veja O que é um sosreport e como criar um no Red Hat Enterprise Linux?

19.3. Remoção de uma instalação de réplica parcial da IdM

Se uma réplica da IdM falhar, alguns arquivos de configuração podem ser deixados para trás. Outras tentativas de instalar a réplica do IdM podem falhar e o script de instalação informa que o IPA já está configurado.

[root@server ~]# ipa-replica-install
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

IPA server is already configured on this system.
If you want to reinstall the IPA server, please uninstall it first using 'ipa-server-install --uninstall'.
The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information

Para resolver este problema, desinstale o software IdM da réplica, remova a réplica da topologia IdM, e tente novamente o processo de instalação.

Pré-requisitos

  • Você deve ter privilégios no site root.

Procedimento

  1. Desinstale o software do servidor IdM no host que você está tentando configurar como uma réplica do IdM.

    [root@replica ~]# ipa-server-install --uninstall
  2. Em todos os outros servidores da topologia, use o comando ipa server-del para excluir qualquer referência à réplica que não tenha sido instalada corretamente.

    [root@other-replica ~]# ipa server-del replica.idm.example.com
  3. Tente instalar a réplica.
  4. Se você continuar tendo dificuldades para instalar uma réplica da IdM devido a repetidas instalações com falhas, reinstale o sistema operacional.

    Um dos requisitos para instalar uma réplica do IdM é um sistema limpo sem qualquer customização. Instalações fracassadas podem ter comprometido a integridade do host ao modificar inesperadamente os arquivos do sistema.

Recursos adicionais

  • Para detalhes adicionais sobre como desinstalar uma réplica da IdM, veja Desinstalar uma réplica da IdM.
  • Se as tentativas de instalação falharem após repetidas tentativas de desinstalação, e você tiver uma assinatura do Suporte Técnico da Red Hat, abra um caso de Suporte Técnico no Portal do Cliente da Red Hat e forneça um sosreport da réplica e um sosreport do servidor.
  • O utilitário sosreport coleta detalhes de configuração, registros e informações do sistema a partir de um sistema RHEL. Para mais informações sobre o utilitário sosreport, veja O que é um sosreport e como criar um no Red Hat Enterprise Linux?

19.4. Resolução de erros de credenciais inválidos

Se uma réplica da IdM falhar com um erro Invalid credentials, os relógios do sistema nos hosts podem estar fora de sincronia entre si:

[27/40]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 15 seconds elapsed
[ldap://master.example.com:389] reports: Update failed! Status: [49 - LDAP error: Invalid credentials]

[error] RuntimeError: Failed to start replication
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall): ERROR    Failed to start replication
ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall): ERROR    The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information

Se você usar as opções --no-ntp ou -N para tentar a instalação da réplica enquanto os relógios estão fora de sincronia, a instalação falha porque os serviços não conseguem se autenticar com Kerberos.

Para resolver esta questão, sincronize os relógios em ambos os anfitriões e tente novamente o processo de instalação.

Pré-requisitos

  • Você deve ter root privilégios para mudar o tempo do sistema.

Procedimento

  1. Sincronizar os relógios do sistema manualmente ou com chronyd (ntp não é mais suportado no RHEL 8).

    • Synchronizing manually:

      Mostrar o tempo do sistema no mestre e definir o tempo da réplica para corresponder.

      [user@master ~]$ date
      Thu May 28 21:03:57 EDT 2020
      
      [user@replica ~]$ sudo timedatectl set-time '2020-05-28 21:04:00'
    • Synchronizing with chronyd:

      Consulte a seção Utilização do conjunto Chrony para configurar o NTP para configurar e definir o tempo do sistema com as ferramentas chrony.

  2. Tente novamente a instalação da réplica do IdM.

Recursos adicionais

  • Se você não conseguir resolver uma instalação de réplica falhada e tiver uma assinatura do Suporte Técnico da Red Hat, abra um caso de Suporte Técnico no Portal do Cliente da Red Hat e forneça um sosreport da réplica e um sosreport do servidor.
  • O utilitário sosreport coleta detalhes de configuração, registros e informações do sistema a partir de um sistema RHEL. Para mais informações sobre o utilitário sosreport, veja O que é um sosreport e como criar um no Red Hat Enterprise Linux?

19.5. Recursos adicionais

Capítulo 20. Desinstalando uma réplica da IdM

Como administrador, você pode remover um servidor de Gerenciamento de Identidade (IdM) da topologia.

Este procedimento descreve como você pode desinstalar um servidor de exemplo chamado server.idm.example.com.

Pré-requisitos

  • Antes de desinstalar um servidor que serve como autoridade de certificado (CA), autoridade de recuperação de chaves (KRA), ou servidor DNS, certifique-se de que estes serviços estão sendo executados em outro servidor no domínio.
Atenção

A remoção do último servidor que serve como CA, KRA, ou servidor DNS perturba seriamente a funcionalidade de Gerenciamento de Identidade (IdM).

Procedimento

  1. Em todos os servidores da topologia que têm um acordo de replicação com server.idm.example.com, use o comando ipa server-del para excluir a réplica da topologia:

    [root@another_server ~]# ipa server-del server.idm.example.com
  2. Em server.idm.example.com, use o comando ipa-server-install --uninstall:

    [root@server ~]# ipa-server-install --uninstall
    ...
    Are you sure you want to continue with the uninstall procedure? [no]: yes
  3. Certifique-se de que todos os registros DNS do servidor de nomes (NS) que apontam para server.idm.example.com sejam excluídos de suas zonas DNS. Isto se aplica independentemente de você usar DNS integrado gerenciado pela IdM ou DNS externo.

Capítulo 21. Instalando e rodando a ferramenta IdM Healthcheck

Este capítulo descreve a ferramenta IdM Healthcheck e como instalá-la e executá-la.

Pré-requisitos

  • A ferramenta Healthcheck só está disponível no RHEL 8.1 ou posterior.

21.1. Healthcheck na IdM

A ferramenta Healthcheck em Gerenciamento de Identidade (IdM) ajuda a encontrar problemas que podem impactar a saúde de seu ambiente IdM.

Nota

A ferramenta Healthcheck é uma ferramenta de linha de comando que pode ser usada sem autenticação Kerberos.

21.1.1. Os módulos são independentes

O Healthcheck consiste em módulos independentes que são testados para:

  • Questões de replicação
  • Validade do certificado
  • Questões de infra-estrutura da Autoridade Certificadora
  • IdM e questões de confiança do Active Directory
  • Corrigir permissões de arquivo e configurações de propriedade

21.1.2. Dois formatos de saída

O Healthcheck gera os seguintes resultados, que você pode definir usando a opção output-type:

  • json: Saída legível por máquina no formato JSON (padrão)
  • human: Saída legível pelo homem

Você pode especificar um destino de arquivo diferente com a opção --output-file.

21.1.3. Resultados

Cada módulo do Healthcheck retorna um dos seguintes resultados:

SUCESSO
configurado como esperado
ADVERTÊNCIA
não é um erro, mas vale a pena ficar de olho ou avaliar
ERROR
não configurado como esperado
CRÍTICO
não configurado como esperado, com uma alta possibilidade de impacto

21.2. Instalando o IdM Healthcheck

Esta seção descreve como instalar a ferramenta IdM Healthcheck.

Procedimento

  • Instale o pacote ipa-healthcheck:

    [root@master ~]# dnf install ipa-healthcheck
    Nota

    Nos sistemas RHEL 8.1 e 8.2, use o comando dnf install /usr/bin/ipa-healthcheck.

Etapas de verificação

  • Use a opção --failures-only para ter ipa-healthcheck apenas para reportar erros. Uma instalação IdM totalmente funcional retorna um resultado vazio de [].

    [root@master ~]# ipa-healthcheck --failures-only
    []

Recursos adicionais

  • Use ipa-healthcheck --help para ver todos os argumentos apoiados.

21.3. Executando o IdM Healthcheck

O Healthcheck pode ser executado manualmente ou automaticamente usando a rotação de logs.

Pré-requisitos

Procedimento

  • Para executar o healthcheck manualmente, digite o comando ipa-healthcheck.

    [root@master ~]# ipa-healthcheck

Recursos adicionais

Para todas as opções, consulte a página de homem: man ipa-healthcheck .

21.4. Recursos adicionais

Veja as seguintes seções de Configuração e gerenciamento de Gerenciamento de Identidade para exemplos de uso do IdM Healthcheck.

Capítulo 22. Instalação de um servidor de Gerenciamento de Identidade usando um Livro de Jogadas Anível

22.1. Possível e suas vantagens para a instalação do IdM

Ansible é uma ferramenta de automação usada para configurar sistemas, implantar software e realizar atualizações rolantes. Ansible inclui suporte para Gerenciamento de Identidade (IdM), e você pode usar módulos Ansible para automatizar tarefas de instalação como a configuração de um servidor IdM, réplica, cliente, ou uma topologia IdM inteira.

Vantagens de usar o Ansible to install IdM

A lista a seguir apresenta as vantagens de instalar o Gerenciamento de Identidade usando o Ansible, em contraste com a instalação manual.

  • Você não precisa entrar no nó administrado.
  • Você não precisa configurar as configurações em cada host para ser implantado individualmente. Ao invés disso, você pode ter um arquivo de inventário para implantar um cluster completo.
  • Você pode reutilizar um arquivo de inventário mais tarde para tarefas de gerenciamento, por exemplo, para adicionar usuários e anfitriões. Você pode reutilizar um arquivo de inventário mesmo para tarefas que não estejam relacionadas à IdM.

22.2. Instalação de um servidor IdM usando um livro de jogos possível

As seções seguintes descrevem como configurar um sistema como um servidor IdM usando o Ansible. A configuração de um sistema como um servidor IdM estabelece um domínio IdM e permite ao sistema oferecer serviços IdM aos clientes IdM. A implantação é gerenciada pelo ipaserver Ansible role.

Nota

Antes de instalar um servidor IdM usando o Ansible, certifique-se de que você entendeu os conceitos de Ansible e IdM. Certifique-se de que você compreenda os seguintes termos que são usados neste capítulo:

  • Papéis possíveis
  • Nós possíveis
  • Inventário possível
  • Tarefas possíveis
  • Módulos possíveis
  • Peças e livros didáticos possíveis

Visão geral

A instalação consiste das seguintes partes:

22.3. Instalando o pacote ansible-freeipa

Pré-requisitos

No site managed node:

  • Assegurar que o nó gerenciado seja um sistema Red Hat Enterprise Linux 8 com um endereço IP estático e um gerenciador de pacotes funcional.

No site controller:

  • Garantir que o controlador seja um sistema Red Hat Enterprise Linux com uma assinatura válida. Se este não for o caso, consulte a documentação oficial Ansible Manual de instalação para instruções alternativas de instalação.
  • Certifique-se de que você possa alcançar o nó gerenciado através do protocolo SSH a partir do controlador. Verifique se o nó gerenciado está listado no arquivo /root/.ssh/known_hosts do controlador.

Procedimento

Execute o seguinte procedimento no Controlador Possível.

  1. Habilitar o repositório necessário:

    # subscription-manager repos --enable ansible-2.8-for-rhel-8-x86_64-rpms
  2. Instalar Possível:

    # yum install ansible
  3. Instalar o IdM Funções possíveis:

    # yum install ansible-freeipa

    As funções são instaladas no diretório /usr/share/ansible/roles/.

22.4. Localização possível das funções no sistema de arquivo

Por padrão, as funções do ansible-freeipa estão instaladas no diretório /usr/share/ansible/roles/. A estrutura do pacote ansible-freeipa é a seguinte:

  • O diretório /usr/share/ansible/roles/ armazena os papéis de ipaserver, ipareplica e ipaclient no controlador Ansible. Cada diretório de funções armazena exemplos, uma visão geral básica, a licença e documentação sobre a função em um arquivo README.md Markdown.

    [root@server]# ls -1 /usr/share/ansible/roles/
    ipaclient
    ipareplica
    ipaserver
  • O diretório /usr/share/doc/ansible-freeipa/ armazena a documentação sobre funções individuais e a topologia nos arquivos README.md Markdown. Ele também armazena o subdiretório playbooks/ (veja abaixo).

    [root@server]# ls -1 /usr/share/doc/ansible-freeipa/
    playbooks
    README-client.md
    README.md
    README-replica.md
    README-server.md
    README-topology.md
  • O diretório /usr/share/doc/ansible-freeipa/playbooks/ armazena os exemplos de livros didáticos:

    [root@server]# ls -1 /usr/share/doc/ansible-freeipa/playbooks/
    install-client.yml
    install-cluster.yml
    install-replica.yml
    install-server.yml
    uninstall-client.yml
    uninstall-cluster.yml
    uninstall-replica.yml
    uninstall-server.yml

22.5. Implantando um servidor IdM com uma CA integrada como CA de raiz usando um livro de exercícios possível

22.5.1. Definição dos parâmetros para um desdobramento com uma CA integrada como a CA raiz

Complete este procedimento para configurar o arquivo de inventário para instalar um servidor IdM com uma CA integrada como a CA raiz.

Procedimento

  1. Abra o arquivo do inventário para edição. Especifique os nomes de domínio totalmente qualificados (FQDN) do host que você deseja usar como um servidor IdM. Certifique-se de que o FQDN atenda aos seguintes critérios:

    • Somente caracteres alfanuméricos e hífens (-) são permitidos. Por exemplo, os sublinhados não são permitidos e podem causar falhas no DNS.
    • O nome do anfitrião deve ser todo em letra minúscula.
  2. Especifique o domínio e as informações do domínio IdM.
  3. Especifique se você deseja que o servidor IdM tenha um DNS integrado e se você deseja que ele utilize encaminhadores do arquivo /etc/resolv.conf.
  4. Especifique as senhas para admin e para o Directory Manager. Use o Ansible Vault para armazenar a senha, e consulte o arquivo Vault do arquivo do playbook. Alternativamente e com menos segurança, especifique as senhas diretamente no arquivo do inventário.

    Exemplo de um arquivo de inventário com as informações necessárias do servidor (excluindo as senhas)

    [ipaserver]
    server.idm.example.com
    
    [ipaserver:vars]
    ipaserver_domain=idm.example.com
    ipaserver_realm=IDM.EXAMPLE.COM
    ipaserver_setup_dns=yes
    ipaserver_auto_forwarders=yes
    [...]

    Exemplo de um arquivo de inventário com as informações necessárias do servidor (incluindo as senhas)

    [ipaserver]
    server.idm.example.com
    
    [ipaserver:vars]
    ipaserver_domain=idm.example.com
    ipaserver_realm=IDM.EXAMPLE.COM
    ipaserver_setup_dns=yes
    ipaserver_auto_forwarders=yes
    ipaadmin_password=MySecretPassword123
    ipadm_password=MySecretPassword234
    
    [...]

    Exemplo de playbook para configurar um servidor IdM usando senhas de administrador e Gerenciador de Diretório armazenadas em um arquivo Ansible Vault

    ---
    - name: Playbook to configure IPA server
      hosts: ipaserver
      become: true
      vars_files:
      - playbook_sensitive_data.yml
    
      roles:
      - role: ipaserver
        state: present

    Exemplo de playbook para configurar um servidor IdM usando senhas de administrador e Gerenciador de Diretório a partir de um arquivo de inventário

    ---
    - name: Playbook to configure IPA server
      hosts: ipaserver
      become: true
    
      roles:
      - role: ipaserver
        state: present

Para obter detalhes sobre a instalação do servidor IdM e as opções disponíveis, consulte Parte I, “Instalando o Gerenciamento de Identidade”.

22.5.2. Implantando um servidor IdM com uma CA integrada como CA de raiz usando um livro de exercícios possível

Complete este procedimento para implantar um servidor IdM com uma autoridade de certificado integrada (CA) como a CA raiz, usando um livro de exercícios.

Procedimento

  • Execute o comando ansible-playbook com o nome do arquivo do playbook, por exemplo install-server.yml. Especifique o arquivo do inventário com a opção -i:

    $ ansible-playbook -v -i <path_to_inventory_directory>/hosts <path_to_playbooks_directory>/install-server.yml

    Especifique o nível de verbosidade usando a opção -v, -vv, ou -vvv.

    Você pode ver a saída do script do livro de reprodução possível na interface de linha de comando (CLI). A saída seguinte mostra que o script foi executado com sucesso, já que 0 tarefas falharam:

    PLAY RECAP
    server.idm.example.com : ok=18   changed=10   unreachable=0    failed=0    skipped=21   rescued=0    ignored=0

Você instalou um servidor IdM em seu anfitrião usando um livro de jogo Ansible playbook.

22.6. Implantando um servidor IdM com uma CA externa como CA de raiz usando um livro de exercícios possível

22.6.1. Definição dos parâmetros para uma implantação com uma CA externa como a CA de raiz

Complete este procedimento para configurar o arquivo de inventário para instalar um servidor IdM com uma CA externa como a CA raiz.

Procedimento

  1. Abra o arquivo do inventário para edição. Especifique os nomes de domínio totalmente qualificados (FQDN) do host que você deseja usar como um servidor IdM. Certifique-se de que o FQDN atenda aos seguintes critérios:

    • Somente caracteres alfanuméricos e hífens (-) são permitidos. Por exemplo, os sublinhados não são permitidos e podem causar falhas no DNS.
    • O nome do anfitrião deve ser todo em letra minúscula.
  2. Especifique o domínio e as informações do domínio IdM.
  3. Especifique se você deseja que o servidor IdM tenha um DNS integrado e se você deseja que ele utilize encaminhadores do arquivo /etc/resolv.conf.
  4. Especifique as senhas para admin e para o Directory Manager. Use o Ansible Vault para armazenar a senha, e consulte o arquivo Vault do arquivo do playbook. Alternativamente e com menos segurança, especifique as senhas diretamente no arquivo do inventário.

    Exemplo de um arquivo de inventário com as informações necessárias do servidor (excluindo as senhas)

    [ipaserver]
    server.idm.example.com
    
    [ipaserver:vars]
    ipaserver_domain=idm.example.com
    ipaserver_realm=IDM.EXAMPLE.COM
    ipaserver_setup_dns=yes
    ipaserver_auto_forwarders=yes
    [...]

    Exemplo de um arquivo de inventário com as informações necessárias do servidor (incluindo as senhas)

    [ipaserver]
    server.idm.example.com
    
    [ipaserver:vars]
    ipaserver_domain=idm.example.com
    ipaserver_realm=IDM.EXAMPLE.COM
    ipaserver_setup_dns=yes
    ipaserver_auto_forwarders=yes
    ipaadmin_password=MySecretPassword123
    ipadm_password=MySecretPassword234
    
    [...]

  5. Criar um playbook para a primeira etapa da instalação. Insira instruções para gerar o pedido de assinatura do certificado (CSR) e copiá-lo do controlador para o nó gerenciado.

    Figura 22.1. Exemplo de playbook para configurar um servidor IdM com uma CA assinada externamente usando senhas administrativas e Gerenciador de Diretório armazenadas em um arquivo Ansible Vault: Primeiro passo

    external CA server ansible install step 1
  6. Criar outro playbook para a etapa final da instalação.

    Figura 22.2. Exemplo de playbook para configurar um servidor IdM com uma CA assinada externamente usando senhas administrativas e Gerenciador de Diretório armazenadas em um arquivo Ansible Vault: Etapa final

    external CA server ansible install step 2

Para detalhes sobre as opções disponíveis para você ao instalar um servidor IdM com uma CA externa assinada, veja Capítulo 3, Instalação de um servidor IdM: Com DNS integrado, com uma CA externa como a CA raiz.

22.6.2. Implantando um servidor IdM com uma CA externa como CA de raiz usando um livro de exercícios possível

Completar este procedimento para implantar um servidor IdM com uma autoridade de certificação externa (CA) como CA de raiz usando um livro de exercícios.

Procedimento

  1. Execute o comando ansible-playbook com o nome do arquivo do playbook que contém instruções para a primeira etapa da instalação, por exemplo install-server-step1.yml. Especifique o arquivo do inventário com a opção -i:

    $ ansible-playbook -v -i <path_to_inventory_directory>/host.server <path_to_playbooks_directory>/install-server-step1.yml

    Especifique o nível de verbosidade usando a opção -v, -vv ou -vvv.

    Você pode ver a saída do script do livro de reprodução possível na interface de linha de comando (CLI). A saída seguinte mostra que o script foi executado com sucesso, já que 0 tarefas falharam:

    PLAY RECAP
    server.idm.example.com : ok=18   changed=10   unreachable=0    failed=0    skipped=21   rescued=0    ignored=0
  2. Localize o arquivo ipa.csr de pedido de assinatura de certificado no controlador e submeta-o à CA externa.
  3. Coloque o certificado IdM CA assinado pela CA externa no sistema de arquivo do controlador para que a cartilha no próximo passo possa encontrá-lo.
  4. Execute o comando ansible-playbook com o nome do arquivo do playbook que contém instruções para a etapa final da instalação, por exemplo install-server-step2.yml. Especifique o arquivo do inventário com a opção -i:

    $ ansible-playbook -v -i <path_to_inventory_directory>/host.server <path_to_playbooks_directory>/install-server-step2.yml

Você instalou um servidor IdM com uma CA assinada externamente em seu host, usando um livro de jogo possível.

Capítulo 23. Instalação de uma réplica de Gerenciamento de Identidade usando um Livro de Jogadas Anível

23.1. Possível e suas vantagens para a instalação do IdM

Ansible é uma ferramenta de automação usada para configurar sistemas, implantar software e realizar atualizações rolantes. Ansible inclui suporte para Gerenciamento de Identidade (IdM), e você pode usar módulos Ansible para automatizar tarefas de instalação como a configuração de um servidor IdM, réplica, cliente, ou uma topologia IdM inteira.

Vantagens de usar o Ansible to install IdM

A lista a seguir apresenta as vantagens de instalar o Gerenciamento de Identidade usando o Ansible, em contraste com a instalação manual.

  • Você não precisa entrar no nó administrado.
  • Você não precisa configurar as configurações em cada host para ser implantado individualmente. Ao invés disso, você pode ter um arquivo de inventário para implantar um cluster completo.
  • Você pode reutilizar um arquivo de inventário mais tarde para tarefas de gerenciamento, por exemplo, para adicionar usuários e anfitriões. Você pode reutilizar um arquivo de inventário mesmo para tarefas que não estejam relacionadas à IdM.

23.2. Instalação de réplicas do IdM usando um livro de reprodução possível

As seções seguintes descrevem como configurar um sistema como uma réplica do IdM usando o Ansible. A configuração de um sistema como uma réplica IdM o inscreve em um domínio IdM e permite que o sistema use serviços IdM em servidores IdM no domínio.

A implantação é gerenciada pelo ipareplica Papel possível. A função pode usar o modo de auto-descoberta para identificar os servidores IdM, domínio e outras configurações. No entanto, se você implantar múltiplas réplicas em um modelo semelhante ao de camada, com diferentes grupos de réplicas sendo implantadas em momentos diferentes, você deve definir servidores ou réplicas específicas para cada grupo.

Nota

Antes de instalar uma réplica do IdM usando o Ansible, certifique-se de compreender os conceitos de Ansible e IdM. Certifique-se de que você compreenda os seguintes termos que são usados neste capítulo:

  • Papéis possíveis
  • Nós possíveis
  • Inventário possível
  • Tarefas possíveis
  • Módulos possíveis
  • Peças e livros didáticos possíveis

Visão geral

A instalação consiste das seguintes partes:

23.3. Instalando o pacote ansible-freeipa

Pré-requisitos

No site managed node:

  • Assegurar que o nó gerenciado seja um sistema Red Hat Enterprise Linux 8 com um endereço IP estático e um gerenciador de pacotes funcional.

No site controller:

  • Garantir que o controlador seja um sistema Red Hat Enterprise Linux com uma assinatura válida. Se este não for o caso, consulte a documentação oficial Ansible Manual de instalação para instruções alternativas de instalação.
  • Certifique-se de que você possa alcançar o nó gerenciado através do protocolo SSH a partir do controlador. Verifique se o nó gerenciado está listado no arquivo /root/.ssh/known_hosts do controlador.

Procedimento

Execute o seguinte procedimento no Controlador Possível.

  1. Habilitar o repositório necessário:

    # subscription-manager repos --enable ansible-2.8-for-rhel-8-x86_64-rpms
  2. Instalar Possível:

    # yum install ansible
  3. Instalar o IdM Funções possíveis:

    # yum install ansible-freeipa

    As funções são instaladas no diretório /usr/share/ansible/roles/.

23.4. Localização possível das funções no sistema de arquivo

Por padrão, as funções do ansible-freeipa estão instaladas no diretório /usr/share/ansible/roles/. A estrutura do pacote ansible-freeipa é a seguinte:

  • O diretório /usr/share/ansible/roles/ armazena os papéis de ipaserver, ipareplica e ipaclient no controlador Ansible. Cada diretório de funções armazena exemplos, uma visão geral básica, a licença e documentação sobre a função em um arquivo README.md Markdown.

    [root@server]# ls -1 /usr/share/ansible/roles/
    ipaclient
    ipareplica
    ipaserver
  • O diretório /usr/share/doc/ansible-freeipa/ armazena a documentação sobre funções individuais e a topologia nos arquivos README.md Markdown. Ele também armazena o subdiretório playbooks/ (veja abaixo).

    [root@server]# ls -1 /usr/share/doc/ansible-freeipa/
    playbooks
    README-client.md
    README.md
    README-replica.md
    README-server.md
    README-topology.md
  • O diretório /usr/share/doc/ansible-freeipa/playbooks/ armazena os exemplos de livros didáticos:

    [root@server]# ls -1 /usr/share/doc/ansible-freeipa/playbooks/
    install-client.yml
    install-cluster.yml
    install-replica.yml
    install-server.yml
    uninstall-client.yml
    uninstall-cluster.yml
    uninstall-replica.yml
    uninstall-server.yml

23.5. Definição dos parâmetros da implantação da réplica do IdM

Antes de implantar um host alvo como uma réplica do IdM, configure as seguintes configurações:

23.5.1. Especificando a base, servidor e variáveis do cliente para instalação da réplica do IdM

Complete este procedimento para configurar o arquivo de inventário para a instalação de uma réplica do IdM.

Procedimento

  1. Abra o arquivo do inventário para edição. Especifique os nomes de domínio totalmente qualificados (FQDN) dos hosts para se tornarem réplicas IdM. O FQDNs deve ser nomes DNS válidos:

    • Somente números, caracteres alfabéticos e hífens (-) são permitidos. Por exemplo, os sublinhados não são permitidos e podem causar falhas no DNS.
    • O nome do anfitrião deve ser todo em letra minúscula.

      Exemplo de um simples arquivo de inventário com apenas o FQDN das réplicas definido

      [ipareplicas]
      replica1.idm.example.com
      replica2.idm.example.com
      replica3.idm.example.com
      [...]

      Se o servidor mestre IdM já estiver implantado e os registros SRV estiverem definidos corretamente na zona DNS da IdM, o script descobre automaticamente todos os outros valores necessários.

  2. Opcionalmente, forneça informações adicionais no arquivo de inventário com base em qual dos seguintes cenários é o mais próximo ao seu:

    • Scenario 1

      Se você quiser evitar a auto-descoberta e tiver todas as réplicas listadas na seção [ipareplicas] use um servidor IdM específico, configure o servidor na seção [ipaservers] do arquivo do inventário.

      Exemplo de arquivo de inventário com o FQDN do servidor IdM e réplicas definidas

      [ipaservers]
      server.idm.example.com
      
      [ipareplicas]
      replica1.idm.example.com
      replica2.idm.example.com
      replica3.idm.example.com
      [...]

    • Scenario 2

      Alternativamente, se você quiser evitar a auto-descoberta mas quiser implantar réplicas específicas com servidores específicos, configure os servidores para réplicas específicas individualmente na seção [ipareplicas] no arquivo de inventário.

      Exemplo de arquivo de inventário com um servidor IdM específico definido para uma réplica específica

      [ipaservers]
      server.idm.example.com
      replica1.idm.example.com
      
      [ipareplicas]
      replica2.idm.example.com
      replica3.idm.example.com ipareplica_servers=replica1.idm.example.com

      No exemplo acima, replica3.idm.example.com utiliza o já implantado replica1.idm.example.com como seu servidor mestre.

    • Scenario 3

      Se você estiver implantando várias réplicas em um lote e o tempo for uma preocupação para você, a implantação de réplicas em vários níveis pode ser útil para você. Defina grupos específicos de réplicas no arquivo de inventário, por exemplo [ipareplicas_tier1] e [ipareplicas_tier2], e projete peças separadas para cada grupo no playbook install-replica.yml.

      Exemplo de arquivo de inventário com réplicas de níveis definidos

      [ipaservers]
      server.idm.example.com
      
      [ipareplicas_tier1]
      replica1.idm.example.com
      
      [ipareplicas_tier2]
      replica2.idm.example.com \ ipareplica_servers=replica1.idm.example.com,server.idm.example.com

      A primeira entrada em ipareplica_servers será usada como o mestre. A segunda entrada será usada como uma opção de recurso. Ao utilizar várias camadas para implantar réplicas IdM, você deve ter tarefas separadas no playbook para primeiro implantar réplicas da camada 1 e depois réplicas da camada 2:

      Exemplo de um arquivo de playbook com diferentes peças para diferentes grupos de réplicas

      ---
      - name: Playbook to configure IPA replicas (tier1)
        hosts: ipareplicas_tier1
        become: true
      
        roles:
        - role: ipareplica
          state: present
      
      - name: Playbook to configure IPA replicas (tier2)
        hosts: ipareplicas_tier2
        become: true
      
        roles:
        - role: ipareplica
          state: present

23.5.2. Especificação das credenciais para a instalação da réplica do IdM usando um livro de reprodução possível

Complete este procedimento para configurar a autorização de instalação da réplica do IdM.

Procedimento

  1. Especifique o password of a user authorized to deploy replicas, por exemplo o IdM admin.

    • A Red Hat recomenda o uso do Ansible Vault para armazenar a senha e referenciar o arquivo Vault do arquivo do playbook, por exemplo install-replica.yml:

      Exemplo de arquivo de playbook usando o principal de um arquivo de inventário e senha de um arquivo do Ansible Vault

      - name: Playbook to configure IPA replicas
        hosts: ipareplicas
        become: true
        vars_files:
        - playbook_sensitive_data.yml
      
        roles:
        - role: ipareplica
          state: present

      Para detalhes sobre como usar o Ansible Vault, consulte a documentação oficial do Ansible Vault.

    • Com menos segurança, forneça as credenciais de admin diretamente no arquivo do inventário. Use a opção ipaadmin_password na seção [ipareplicas:vars] do arquivo do inventário. O arquivo do inventário e o arquivo do playbook install-replica.yml podem então ser vistos da seguinte forma:

      Exemplo de inventário hospeda.replica arquivo

      [...]
      [ipareplicas:vars]
      ipaadmin_password=Secret123

      Exemplo de playbook usando o principal e senha do arquivo de inventário

      - name: Playbook to configure IPA replicas
        hosts: ipareplicas
        become: true
      
        roles:
        - role: ipareplica
          state: present

    • Como alternativa, mas também menos segura, forneça as credenciais de outro usuário autorizado a implantar uma réplica diretamente no arquivo do inventário. Para especificar um usuário autorizado diferente, use a opção ipaadmin_principal para o nome do usuário, e a opção ipaadmin_password para a senha. O arquivo do inventário e o arquivo do playbook install-replica.yml podem então ter a seguinte aparência:

      Exemplo de inventário hospeda.replica arquivo

      [...]
      [ipareplicas:vars]
      ipaadmin_principal=my_admin
      ipaadmin_password=my_admin_secret123

      Exemplo de playbook usando o principal e senha do arquivo de inventário

      - name: Playbook to configure IPA replicas
        hosts: ipareplicas
        become: true
      
        roles:
        - role: ipareplica
          state: present

Recursos adicionais

  • /usr/share/ansible/roles/ipareplica/README.md Para obter detalhes sobre as opções aceitas pelo ipareplica. Para obter detalhes sobre as opções aceitas pelo .

23.6. Implantação de uma réplica do IdM usando um livro de jogo possível

Completar este procedimento para usar um livro de reprodução possível para implantar uma réplica da IdM.

Procedimento

  • Para instalar uma réplica do IdM usando um livro de reprodução possível, use o comando ansible-playbook com o nome do arquivo do livro de reprodução, por exemplo install-replica.yml. Especifique o arquivo do inventário com a opção -i:

    $ ansible-playbook -v -i <path_to_inventory_directory>/hosts.replica <path_to_playbooks_directory>/install-replica.yml

    Especifique o nível de verbosidade usando a opção -v, -vv ou -vvv.

    Ansible o informa sobre a execução do roteiro do Ansible playbook. A saída seguinte mostra que o script foi executado com sucesso, já que 0 tarefas falharam:

    PLAY RECAP
    replica.idm.example.com : ok=18   changed=10   unreachable=0    failed=0    skipped=21   rescued=0    ignored=0

Agora você instalou uma réplica da IdM.

Capítulo 24. Instalação de um cliente de Gerenciamento de Identidade usando um Livro de Jogadas Anível

24.1. Possível e suas vantagens para a instalação do IdM

Ansible é uma ferramenta de automação usada para configurar sistemas, implantar software e realizar atualizações rolantes. Ansible inclui suporte para Gerenciamento de Identidade (IdM), e você pode usar módulos Ansible para automatizar tarefas de instalação como a configuração de um servidor IdM, réplica, cliente, ou uma topologia IdM inteira.

Vantagens de usar o Ansible to install IdM

A lista a seguir apresenta as vantagens de instalar o Gerenciamento de Identidade usando o Ansible, em contraste com a instalação manual.

  • Você não precisa entrar no nó administrado.
  • Você não precisa configurar as configurações em cada host para ser implantado individualmente. Ao invés disso, você pode ter um arquivo de inventário para implantar um cluster completo.
  • Você pode reutilizar um arquivo de inventário mais tarde para tarefas de gerenciamento, por exemplo, para adicionar usuários e anfitriões. Você pode reutilizar um arquivo de inventário mesmo para tarefas que não estejam relacionadas à IdM.

24.2. Instalação do cliente IdM usando um livro de jogos possível

As seções seguintes descrevem como configurar um sistema como um cliente de Gerenciamento de Identidade (IdM) usando o Ansible. A configuração de um sistema como cliente IdM o cadastra em um domínio IdM e permite que o sistema utilize serviços IdM em servidores IdM no domínio.

A implantação é gerenciada pelo ipaclient Papel possível. Por padrão, a função usa o modo de auto-descoberta para identificar os servidores IdM, domínio e outras configurações. A função pode ser modificada para que o livro de jogo Ansible use as configurações especificadas, por exemplo, no arquivo de inventário.

Nota

Antes de instalar um cliente IdM usando o Ansible, certifique-se de compreender os conceitos de Ansible e IdM. Certifique-se de que você compreenda os seguintes termos que são usados neste capítulo:

  • Papéis possíveis
  • Nós possíveis
  • Inventário possível
  • Tarefas possíveis
  • Módulos possíveis
  • Peças e livros didáticos possíveis

Visão geral

A instalação consiste das seguintes partes:

24.3. Instalando o pacote ansible-freeipa

Pré-requisitos

No site managed node:

  • Assegurar que o nó gerenciado seja um sistema Red Hat Enterprise Linux 8 com um endereço IP estático e um gerenciador de pacotes funcional.

No site controller:

  • Garantir que o controlador seja um sistema Red Hat Enterprise Linux com uma assinatura válida. Se este não for o caso, consulte a documentação oficial Ansible Manual de instalação para instruções alternativas de instalação.
  • Certifique-se de que você possa alcançar o nó gerenciado através do protocolo SSH a partir do controlador. Verifique se o nó gerenciado está listado no arquivo /root/.ssh/known_hosts do controlador.

Procedimento

Execute o seguinte procedimento no Controlador Possível.

  1. Habilitar o repositório necessário:

    # subscription-manager repos --enable ansible-2.8-for-rhel-8-x86_64-rpms
  2. Instalar Possível:

    # yum install ansible
  3. Instalar o IdM Funções possíveis:

    # yum install ansible-freeipa

    As funções são instaladas no diretório /usr/share/ansible/roles/.

24.4. Localização possível das funções no sistema de arquivo

Por padrão, as funções do ansible-freeipa estão instaladas no diretório /usr/share/ansible/roles/. A estrutura do pacote ansible-freeipa é a seguinte:

  • O diretório /usr/share/ansible/roles/ armazena os papéis de ipaserver, ipareplica e ipaclient no controlador Ansible. Cada diretório de funções armazena exemplos, uma visão geral básica, a licença e documentação sobre a função em um arquivo README.md Markdown.

    [root@server]# ls -1 /usr/share/ansible/roles/
    ipaclient
    ipareplica
    ipaserver
  • O diretório /usr/share/doc/ansible-freeipa/ armazena a documentação sobre funções individuais e a topologia nos arquivos README.md Markdown. Ele também armazena o subdiretório playbooks/ (veja abaixo).

    [root@server]# ls -1 /usr/share/doc/ansible-freeipa/
    playbooks
    README-client.md
    README.md
    README-replica.md
    README-server.md
    README-topology.md
  • O diretório /usr/share/doc/ansible-freeipa/playbooks/ armazena os exemplos de livros didáticos:

    [root@server]# ls -1 /usr/share/doc/ansible-freeipa/playbooks/
    install-client.yml
    install-cluster.yml
    install-replica.yml
    install-server.yml
    uninstall-client.yml
    uninstall-cluster.yml
    uninstall-replica.yml
    uninstall-server.yml

24.5. Definição dos parâmetros da implantação do cliente IdM

Antes de implantar um host alvo como cliente IdM, configure as instruções de implantação no nó de controle. Além disso, configure os parâmetros do host alvo, dependendo de qual das seguintes opções você está planejando:

24.5.1. Definição dos parâmetros do arquivo de inventário para o modo de instalação do cliente de auto-descoberta

Para instalar um cliente de Gerenciamento de Identidade usando um livro de exercícios possível, forneça as seguintes informações em um arquivo de inventário, por exemplo inventory/hosts:

  • as informações sobre o anfitrião
  • a autorização para a tarefa

O arquivo de inventário pode estar em um dos muitos formatos, dependendo dos plugins de inventário que você tiver. O formato INI-like é um dos padrões do Ansible e é usado nos exemplos abaixo.

Procedimento

  1. Especifique o hostname totalmente qualificado (FQDN) do anfitrião para se tornar um cliente IdM. O nome de domínio totalmente qualificado deve ser um nome DNS válido:

    • Somente números, caracteres alfabéticos e hífens (-) são permitidos. Por exemplo, os sublinhados não são permitidos e podem causar falhas no DNS.
    • O nome do anfitrião deve ser todo em letra minúscula. Não são permitidas letras maiúsculas.

      Se os registros SRV forem definidos corretamente na zona DNS do IdM, o script descobre automaticamente todos os outros valores necessários.

    Exemplo de um simples arquivo de inventário com apenas o cliente FQDN definido

    [ipaclients]
    client.idm.example.com
    [...]

  2. Especificar as credenciais para a inscrição do cliente. Os seguintes métodos de autenticação estão disponíveis:

    • O password of a user authorized to enroll clients. Esta é a opção padrão.

      • A Red Hat recomenda o uso do Ansible Vault para armazenar a senha, e referenciar o arquivo Vault do arquivo do playbook, por exemplo install-client.yml, diretamente:

        Exemplo de arquivo de playbook usando o principal de um arquivo de inventário e senha de um arquivo do Ansible Vault

        - name: Playbook to configure IPA clients with username/password
          hosts: ipaclients
          become: true
          vars_files:
          - playbook_sensitive_data.yml
        
          roles:
          - role: ipaclient
            state: present

      • Com menos segurança, forneça as credenciais de admin usando a opção ipaadmin_password na seção [ipaclients:vars] do arquivo inventory/hosts. Alternativamente, para especificar um usuário autorizado diferente, use a opção ipaadmin_principal para o nome do usuário, e a opção ipaadmin_password para a senha. O arquivo inventory/hosts do inventário e o arquivo do playbook install-client.yml podem então ser vistos da seguinte forma:

        Exemplo de inventário hospeda arquivo

        [...]
        [ipaclients:vars]
        ipaadmin_principal=my_admin
        ipaadmin_password=Secret123

        Exemplo de Playbook usando o principal e senha do arquivo de inventário

        - name: Playbook to unconfigure IPA clients
          hosts: ipaclients
          become: true
        
          roles:
          - role: ipaclient
            state: true

    • O client keytab do cadastro anterior, caso ainda esteja disponível:

      • Esta opção está disponível se o sistema estivesse previamente inscrito como cliente de Gerenciamento de Identidade. Para utilizar este método de autenticação, descomente a opção #ipaclient_keytab, especificando o caminho para o arquivo que armazena a tabela de chaves, por exemplo, na seção [ipaclient:vars] de inventory/hosts.
    • A random, one-time password (OTP) a ser gerado durante a matrícula. Para usar este método de autenticação, use a opção ipaclient_use_otp=yes em seu arquivo de inventário. Por exemplo, você pode descomentar a opção ipaclient_use_otp=yes na seção [ipaclients:vars] do arquivo inventory/hosts. Observe que com OTP você também deve especificar uma das seguintes opções:

      • O password of a user authorized to enroll clients, por exemplo, fornecendo um valor para ipaadmin_password na seção [ipaclients:vars] do arquivo inventory/hosts.
      • O admin keytab, por exemplo, fornecendo um valor para ipaadmin_keytab na seção [ipaclients:vars] de inventory/hosts.

Recursos adicionais

  • Para maiores detalhes sobre as opções aceitas pelo ipaclient. Para informações detalhadas sobre as opções aceitas pelo , consulte o arquivo /usr/share/ansible/roles/ipaclient/README.md README.

24.5.2. Definição dos parâmetros do arquivo de inventário quando a auto-descoberta não é possível durante a instalação do cliente

Para instalar um cliente de Gerenciamento de Identidade usando um livro de exercícios possível, forneça as seguintes informações em um arquivo de inventário, por exemplo inventory/hosts:

  • as informações sobre o host, o servidor IdM e o domínio IdM ou o domínio IdM
  • a autorização para a tarefa

O arquivo de inventário pode estar em um dos muitos formatos, dependendo dos plugins de inventário que você tiver. O formato INI-like é um dos padrões do Ansible e é usado nos exemplos abaixo.

Procedimento

  1. Especifique o hostname totalmente qualificado (FQDN) do anfitrião para se tornar um cliente IdM. O nome de domínio totalmente qualificado deve ser um nome DNS válido:

    • Somente números, caracteres alfabéticos e hífens (-) são permitidos. Por exemplo, os sublinhados não são permitidos e podem causar falhas no DNS.
    • O nome do anfitrião deve ser todo em letra minúscula. Não são permitidas letras maiúsculas.
  2. Especifique outras opções nas seções relevantes do arquivo inventory/hosts:

    • o FQDN dos servidores na seção [ipaservers] para indicar com qual servidor IdM o cliente será inscrito
    • uma das duas opções a seguir:

      • a opção ipaclient_domain na seção [ipaclients:vars] para indicar o nome de domínio DNS do servidor IdM com o qual o cliente será cadastrado
      • a opção ipaclient_realm na seção [ipaclients:vars] para indicar o nome do reino de Kerberos controlado pelo servidor IdM

        Exemplo de um arquivo de hosts de inventário com o cliente FQDN, o servidor FQDN e o domínio definido

        [ipaclients]
        client.idm.example.com
        
        [ipaservers]
        server.idm.example.com
        
        [ipaclients:vars]
        ipaclient_domain=idm.example.com
        [...]

  3. Especificar as credenciais para a inscrição do cliente. Os seguintes métodos de autenticação estão disponíveis:

    • O password of a user authorized to enroll clients. Esta é a opção padrão.

      • A Red Hat recomenda o uso do Ansible Vault para armazenar a senha, e referenciar o arquivo Vault do arquivo do playbook, por exemplo install-client.yml, diretamente:

        Exemplo de arquivo de playbook usando o principal de um arquivo de inventário e senha de um arquivo do Ansible Vault

        - name: Playbook to configure IPA clients with username/password
          hosts: ipaclients
          become: true
          vars_files:
          - playbook_sensitive_data.yml
        
          roles:
          - role: ipaclient
            state: present

      • Com menos segurança, forneça as credenciais de admin usando a opção ipaadmin_password na seção [ipaclients:vars] do arquivo inventory/hosts. Alternativamente, para especificar um usuário autorizado diferente, use a opção ipaadmin_principal para o nome do usuário, e a opção ipaadmin_password para a senha. O arquivo do playbook install-client.yml pode então ter a seguinte aparência:

        Exemplo de inventário hospeda arquivo

        [...]
        [ipaclients:vars]
        ipaadmin_principal=my_admin
        ipaadmin_password=Secret123

        Exemplo de Playbook usando o principal e senha do arquivo de inventário

        - name: Playbook to unconfigure IPA clients
          hosts: ipaclients
          become: true
        
          roles:
          - role: ipaclient
            state: true

    • O client keytab do cadastro anterior, caso ainda esteja disponível:

      • Esta opção está disponível se o sistema estivesse previamente inscrito como cliente de Gerenciamento de Identidade. Para utilizar este método de autenticação, descomente a opção ipaclient_keytab, especificando o caminho para o arquivo que armazena a tabela de chaves, por exemplo, na seção [ipaclient:vars] de inventory/hosts.
    • A random, one-time password (OTP) a ser gerado durante a matrícula. Para usar este método de autenticação, use a opção ipaclient_use_otp=yes em seu arquivo de inventário. Por exemplo, você pode descomentar a opção #ipaclient_use_otp=yes na seção [ipaclients:vars] do arquivo inventory/hosts. Observe que com OTP você também deve especificar uma das seguintes opções:

      • O password of a user authorized to enroll clients, por exemplo, fornecendo um valor para ipaadmin_password na seção [ipaclients:vars] do arquivo inventory/hosts.
      • O admin keytab, por exemplo, fornecendo um valor para ipaadmin_keytab na seção [ipaclients:vars] de inventory/hosts.

Recursos adicionais

  • Para maiores detalhes sobre as opções aceitas pelo ipaclient. Para informações detalhadas sobre as opções aceitas pelo , consulte o arquivo /usr/share/ansible/roles/ipaclient/README.md README.

24.5.3. Verificação dos parâmetros no arquivo install-client.yml

O arquivo do playbook install-client.yml contém instruções para a implantação do cliente IdM.

  • Abra o arquivo e verifique se as instruções no manual de instruções correspondem ao que você está planejando para sua implantação. O conteúdo normalmente é parecido com este:

    ---
    - name: Playbook to configure IPA clients with username/password
      hosts: ipaclients
      become: true
    
      roles:
      - role: ipaclient
        state: present

    Isto é o que significam as entradas individuais:

    • A entrada dos anfitriões especifica a seção do arquivo inventory/hosts onde o script anível busca o FQDNs dos anfitriões no qual o script ipa-client-install deve ser executado.
    • A entrada become: true especifica que as credenciais da raiz serão invocadas durante a execução do script ipa-client-install.
    • A entrada role: ipaclient especifica o papel que será instalado no host: neste caso, é o papel do cliente ipa.
    • A entrada state: present especifica que o cliente deve ser instalado em vez de desinstalado (absent).

24.5.4. Opções de autorização para a inscrição de clientes IdM usando um livro de jogo possível

Esta seção referencial apresenta opções de autorização individual para inscrição de clientes IdM com exemplos de arquivos de inventário e playbook.

Tabela 24.1. Opções de autorização para inscrição de clientes IdM usando Ansible

Opção de autorizaçãoNotaExemplo de arquivo de inventárioExemplo install-client.yml playbook file

Senha de um usuário autorizado a matricular um cliente: Opção 1

Senha armazenada no Cofre Possível

[ipaclients:vars]
[...]
- name: Playbook to configure IPA clients with username/password
  hosts: ipaclients
  become: true
  vars_files:
  - playbook_sensitive_data.yml

  roles:
  - role: ipaclient
    state: present

Senha de um usuário autorizado a matricular um cliente: Opção 2

Senha armazenada no arquivo de inventário

[ipaclients:vars]
ipaadmin_password=Secret123
- name: Playbook to configure IPA clients
  hosts: ipaclients
  become: true

  roles:
  - role: ipaclient
    state: true

Uma senha aleatória, de uso único (OTP): Opção 1

Senha do administrador OTP

[ipaclients:vars]
ipaadmin_password=Secret123
ipaclient_use_otp=yes
- name: Playbook to configure IPA clients
  hosts: ipaclients
  become: true

  roles:
  - role: ipaclient
    state: true

Uma senha aleatória, de uso único (OTP): Opção 2

OTP uma tabela de chaves administrativas

[ipaclients:vars]
ipaadmin_keytab=/tmp/admin.keytab
ipaclient_use_otp=yes
- name: Playbook to configure IPA clients
  hosts: ipaclients
  become: true

  roles:
  - role: ipaclient
    state: true

A ficha-chave do cliente do cadastro anterior

 
[ipaclients:vars]
ipaclient_keytab=/tmp/krb5.keytab
- name: Playbook to configure IPA clients
  hosts: ipaclients
  become: true

  roles:
  - role: ipaclient
    state: true

24.6. Implantação de um cliente IdM usando um livro de brincadeiras possível

Complete este procedimento para usar um caderno de exercícios possível para implantar um cliente IdM em seu ambiente IdM.

Procedimento

  • Para instalar um cliente IdM usando um livro de reprodução possível, use o comando ansible-playbook com o nome do arquivo do livro de reprodução, por exemplo install-client.yml. Especifique o arquivo do inventário com a opção -i:

    $ ansible-playbook -v -i inventory/hosts install-client.yml

    Especifique o nível de verbosidade usando a opção -v, -vv ou -vvv.

    Ansible o informa sobre a execução do roteiro do Ansible playbook. A saída seguinte mostra que o roteiro foi executado com sucesso, pois nenhuma tarefa falhou:

    PLAY RECAP
    client1.idm.example.com : ok=18 changed=10 unreachable=0 failed=0 skipped=21 rescued=0 ignored=0
    Nota

    A Ansible usa cores diferentes para fornecer diferentes tipos de informações sobre o processo em execução. Você pode modificar as cores padrão na seção [colors] do arquivo /etc/ansible/ansible.cfg:

    [colors]
    [...]
    #error = red
    #debug = dark gray
    #deprecate = purple
    #skip = cyan
    #unreachable = red
    #ok = green
    #changed = yellow
    [...]

Agora você instalou um cliente IdM em seu anfitrião usando um livro de jogo Ansible playbook.

24.7. Teste de um cliente de Gerenciamento de Identidade após Instalação Possível

A interface de linha de comando (CLI) informa que o comando ansible-playbook foi bem sucedido, mas você também pode fazer seu próprio teste.

Para testar se o cliente de Gerenciamento de Identidade pode obter informações sobre os usuários definidos no servidor, verifique se você é capaz de resolver um usuário definido no servidor. Por exemplo, para verificar o usuário padrão admin:

[user@client1 ~]$ id admin
uid=1254400000(admin) gid=1254400000(admins) groups=1254400000(admins)

Para testar se a autenticação funciona corretamente, su - como outro usuário IdM já existente:

[user@client1 ~]$ su - idm_user
Last login: Thu Oct 18 18:39:11 CEST 2018 from 192.168.122.1 on pts/0
[idm_user@client1 ~]$

Parte II. Integrando IdM e AD

Capítulo 25. Instalando a confiança entre IdM e AD

Este capítulo visa ajudá-lo a criar uma confiança entre o servidor IdM de Gerenciamento de Identidade e o Active Directory (AD), onde ambos os servidores estão localizados na mesma floresta.

Pré-requisitos

  • Primeiro, leia o documento Planning a cross-forest trust between Identity Management and Active Directory.
  • AD é instalado com um controlador de domínio sobre ele.
  • O servidor IdM está instalado e funcionando.

  • Tanto o servidor AD quanto o servidor IdM devem ter seus relógios sincronizados porque Kerberos requer um atraso máximo de 5 minutos na comunicação.
  • Nomes NetBIOS exclusivos para cada um dos servidores colocados na confiança porque os nomes NetBIOS são críticos para identificar o domínio do Active Directory.

    • O nome NetBIOS de um domínio Active Directory ou IdM é geralmente a primeira parte do domínio DNS correspondente. Se o domínio DNS é ad.example.com, o nome NetBIOS é tipicamente AD. Entretanto, ele não é necessário. Importante é que o nome NetBIOS é apenas uma palavra sem pontos. O comprimento máximo de um nome NetBIOS é de 15 caracteres.
  • O sistema IdM deve ter o protocolo IPv6 habilitado no kernel.

    • Se IPv6 estiver desabilitado, então o plug-in CLDAP utilizado pelos serviços da IdM não se inicializa.

25.1. Versões suportadas do Windows Server

Você pode estabelecer uma relação de confiança com as florestas do Active Directory (AD) que utilizam os seguintes níveis funcionais de floresta e domínio:

  • Faixa de nível funcional da floresta: Servidor Windows 2008 - Windows Servidor 2016
  • Gama de níveis funcionais de domínio: Servidor Windows 2008 - Windows Servidor 2016

O Gerenciamento de Identidade (IdM) suporta os seguintes sistemas operacionais:

  • Windows Server 2008
  • Windows Server 2008 R2
  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows Server 2016
  • Windows Server 2019

25.2. Como funciona a confiança

A confiança entre a Identity Management IdM e o Active Directory (AD) é estabelecida no Cross-realm Kerberos trust. Esta solução utiliza a capacidade da Kerberos de estabelecer trusts entre diferentes fontes de identidade. Portanto, todos os usuários do AD podem:

  • Faça o login para acessar os sistemas e recursos Linux.
  • Use single sign-on (SSO).

Todos os objetos da IdM são administrados na IdM no trust.

Todos os objetos do AD são administrados no AD no trust.

Em ambientes complexos, uma única floresta IdM pode ser conectada a várias florestas AD. Esta configuração permite uma melhor separação de tarefas para diferentes funções na organização. Os administradores de AD podem se concentrar nos usuários e políticas relacionadas aos usuários, enquanto os administradores do Linux têm controle total sobre a infra-estrutura do Linux. Neste caso, o domínio Linux controlado pelo IdM é análogo a um domínio ou domínio de recursos AD, mas com sistemas Linux dentro dele.

Da perspectiva do AD, a Gestão da Identidade representa uma floresta AD separada com um único domínio AD. Quando a confiança cruzada entre um domínio AD florestal raiz e um domínio IdM é estabelecida, os usuários dos domínios AD florestais podem interagir com máquinas e serviços Linux do domínio IdM.

Nota

Em ambientes de confiança, IdM permite que você use visões de identificação para configurar atributos POSIX para usuários AD no servidor do IdM.

25.3. Direitos de administração de AD

Quando você quiser construir uma confiança entre AD (Active Directory) e IdM (Identity Management), você precisará usar uma conta de administrador de AD com privilégios apropriados de AD.

Tal administrador AD deve ser membro de um dos seguintes grupos:

  • Grupo de administração de empresas na floresta AD
  • Grupo de administradores de domínio no domínio raiz da floresta para sua floresta AD

Informações relacionadas

25.4. Garantia de suporte para tipos comuns de criptografia em AD e RHEL

Por padrão, a Gestão de Identidade estabelece uma confiança cruzada com suporte aos tipos de criptografia RC4, AES-128 e AES-256 Kerberos.

A criptografia RC4 foi depreciada e desativada por padrão no RHEL 8, pois é considerada menos segura que os novos tipos de criptografia AES-128 e AES-256. Em contraste, as credenciais de usuário do Active Directory (AD) e os trusts entre domínios AD suportam a criptografia RC4 e podem não suportar os tipos de criptografia AES.

Sem nenhum tipo de encriptação comum, a comunicação entre os domínios de crianças IdM e AD pode não funcionar, ou algumas contas AD podem não ser capazes de autenticar. Para remediar esta situação, modifique uma das seguintes configurações:

  • Enable AES encryption support in Active Directory (recommended option): Para garantir a confiança entre os domínios AD em uma floresta AD suporta fortes tipos de criptografia AES, veja o seguinte artigo da Microsoft: AD DS: Segurança: Kerberos Erro de tipo "Unsupported etype" ao acessar um recurso em um domínio confiável
  • Enable RC4 support in RHEL: Em cada controlador de confiança da IdM, agente de confiança e cliente onde ocorre a autenticação contra controladores de domínio AD:

    1. Use o comando update-crypto-policies para ativar a subpolítica criptográfica AD-SUPPORT, além da política criptográfica DEFAULT.

      [root@host ~]# update-crypto-policies --set DEFAULT:AD-SUPPORT
      Setting system policy to DEFAULT:AD-SUPPORT
      Note: System-wide crypto policies are applied on application start-up.
      It is recommended to restart the system for the change of policies
      to fully take place.
    2. Reinicie o anfitrião.
Importante

A sub-política criptográfica AD-SUPPORT só está disponível no RHEL 8.3 e mais recente.

  • Para permitir o suporte ao RC4 no RHEL 8.2, crie e habilite uma política de módulos criptográficos personalizados com cipher = RC4-128 . Para obter mais detalhes, consulte Personalização de políticas criptográficas em todo o sistema com modificadores de políticas.
  • Para habilitar o suporte para RC4 no RHEL 8.0 e RHEL 8.1, adicione rc4 à opção permitted_enctypes no arquivo /etc/crypto-policies/back-ends/krb5.config:

    [libdefaults]
    permitted_enctypes = aes256-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 camellia256-cts-cmac aes128-cts-hmac-sha1-96 aes128-cts-hmac-sha256-128 camellia128-cts-cmac +rc4

Recursos adicionais

25.5. Portos necessários para a comunicação entre IdM e AD

Para permitir a comunicação entre os controladores de domínio Active Directory (AD) e os servidores de Gerenciamento de Identidade (IdM), você deve abrir portas em suas firewalls.

Tabela 25.1. Portos necessários para um fundo AD

ServiçoPortoProtocolo

Portmapper de resolução de ponto final

135

TCP

NetBIOS-DGM

138

TCP e UDP

NetBIOS-SSN

139

TCP e UDP

Microsoft-DS

445

TCP e UDP

RPC dinâmico

49152-65535

TCP

Catálogo global AD

3268

TCP

LDAP

389

TCP e UDP

Nota

A porta TCP 389 não precisa estar aberta nos servidores IdM para confiança, mas é necessária para os clientes que se comunicam com o servidor IdM.

Para abrir os portos, você pode usar os seguintes métodos:

  • Firewalld service - you pode habilitar os portos específicos ou habilitar os seguintes serviços que incluem os portos:

    • Configuração de confiança FreeIPA
    • FreeIPA com LDAP
    • Kerberos
    • DNS

    Para obter detalhes, consulte Controlar portos usando CLI.

Nota

O serviço freeipa-trust Firewalld inclui atualmente uma gama de portas RPC de 1024-1300, mas esta gama foi atualizada para 49152-65535 no Windows Server 2008 e posteriormente. O serviço freeipa-trust Firewalld será atualizado para refletir esta nova faixa, e esta edição é rastreada no Bug 1850418 - update freeipa-trust.xml definition para incluir a faixa correta de RPCs dinâmicos.

Até que esse bug tenha sido resolvido, abra manualmente a faixa de portas TCP 49152-65535 além de habilitar o serviço freeipa-trust Firewalld.

Tabela 25.2. Portos exigidos pelos servidores da IdM em um trust

ServiçoPortoProtocolo

Kerberos

88, 464

TCP e UDP

LDAP

389

TCP

DNS

53

TCP e UDP

Tabela 25.3. Portos exigidos pelos clientes da IdM em um fundo AD

ServiçoPortoProtocolo

Kerberos

88

UDP e TCP

Nota

A biblioteca libkrb5 utiliza o UDP e volta ao protocolo TCP se os dados enviados pelo Centro de Distribuição de Chaves (KDC) forem muito grandes. O Active Directory anexa um Certificado de Atribuição de Privilégio (PAC) ao bilhete Kerberos, o que aumenta o tamanho e requer o uso do protocolo TCP. Para evitar a queda e reenviar a solicitação, por default, o SSSD no Red Hat Enterprise Linux 7.4 e mais tarde usa o TCP para autenticação do usuário. Se você quiser configurar o tamanho antes da libkrb5 usar TCP, defina o udp_preference_limit no arquivo /etc/krb.5.conf. Para detalhes, veja a página de manual krb5.conf(5).

Recursos adicionais

25.6. Configurando configurações de DNS e domínio para uma confiança

Antes de conectar o Gerenciamento de Identidade (IdM) e o Active Directory (AD) em uma confiança, você precisa garantir que os servidores se vejam e resolvam corretamente os nomes de domínio. Este cenário descreve a configuração do DNS para permitir o uso de nomes de domínio entre eles:

  • Um servidor IdM primário usando servidor DNS integrado e Autoridade de Certificação.
  • Um Controlador de Domínio AD.

As configurações do DNS exigem:

  • Configuração de zonas DNS no servidor IdM
  • Configuração do encaminhamento DNS condicional no AD
  • Verificação da exatidão da configuração do DNS

25.6.1. Domínios DNS primários exclusivos

No Windows, cada domínio é um reino Kerberos e um domínio DNS ao mesmo tempo. Cada domínio gerenciado pelo controlador de domínio precisa ter sua própria zona DNS dedicada. O mesmo se aplica quando o Gerenciamento de Identidade (IdM) é confiável pelo Active Directory (AD) como uma floresta. O AD espera que o IdM tenha seu próprio domínio DNS. Para que a configuração de confiança funcione, o domínio DNS precisa ser dedicado ao ambiente Linux.

Cada sistema deve ter seu próprio domínio DNS primário exclusivo configurado. Por exemplo, cada um deles deve ter seu próprio domínio DNS primário configurado:

  • ad.example.com para AD e idm.example.com para IdM
  • example.com para AD e idm.example.com para IdM
  • ad.example.com para AD e example.com para IdM

A solução de gerenciamento mais conveniente é um ambiente onde cada domínio DNS é gerenciado por servidores DNS integrados, mas também é possível utilizar qualquer outro servidor DNS compatível com o padrão.

Nomes do reino Kerberos como versões em caixa alta dos nomes de domínio DNS primários
Os nomes do reino Kerberos devem ser os mesmos que os nomes de domínio DNS primários, com todas as letras em maiúsculas. Por exemplo, se os nomes de domínio forem ad.example.com para AD e idm.example.com para a IdM, os nomes do reino Kerberos devem ser AD.EXAMPLE.COM e IDM.EXAMPLE.COM.
Registros DNS resolvíveis a partir de todos os domínios DNS do trust
Todas as máquinas devem ser capazes de resolver os registros DNS de todos os domínios DNS envolvidos na relação de confiança.
Sem sobreposição entre os domínios DNS IdM e AD
As máquinas unidas à IdM podem ser distribuídas em vários domínios DNS. Os domínios DNS contendo clientes IdM não devem se sobrepor aos domínios DNS contendo máquinas unidas à AD. O domínio DNS principal da IdM deve ter registros SRV adequados para suportar os trusts AD.

Você pode adquirir uma lista dos registros SRV necessários específicos para a configuração de seu sistema, executando o seguinte comando:

$ ipa dns-update-system-records --dry-run

A lista gerada pode se parecer, por exemplo, com esta:

IPA DNS records:
  _kerberos-master._tcp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com.
  _kerberos-master._udp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com.
  _kerberos._tcp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com.
  _kerberos._tcp.idm.example.com. 86400 IN SRV 0 100 88 server.idm.example.com.
  _kerberos.idm.example.com. 86400 IN TXT "IDM.EXAMPLE.COM"
  _kpasswd._tcp.idm.example.com. 86400 IN SRV 0 100 464 server.idm.example.com.
  _kpasswd._udp.idm.example.com. 86400 IN SRV 0 100 464 server.idm.example.com.
  _ldap._tcp.idm.example.com. 86400 IN SRV 0 100 389 server.idm.example.com.
  _ipa-ca.idm.example.com. 86400 IN A 192.168.122.2

Para outros domínios DNS que fazem parte do mesmo domínio do IdM, não é necessário que os registros SRV sejam configurados quando a confiança para AD é configurada. A razão é que os controladores de domínio AD não usam os registros SRV para descobrir os KDCs, mas baseiam a descoberta do KDC nas informações de roteamento do sufixo do nome para o trust.

25.6.2. Configuração de zonas DNS na interface web do IdM

Esta seção descreve como adicionar uma nova zona de encaminhamento DNS ao servidor de Gerenciamento de Identidade (IdM).

As zonas de encaminhamento DNS permitem o encaminhamento de consultas DNS para uma zona específica para um servidor DNS diferente.

Por exemplo, em seu servidor IdM, você deseja encaminhar as consultas para o domínio Active Directory (AD).

Pré-requisitos

  • Acesso à IDM Web UI com uma conta de usuário que tem direitos de administrador.
  • Servidor DNS configurado corretamente.

Procedimento

  1. Entrar na IDM Web UI com privilégios de administrador. Para detalhes, veja Acessando a IDM Web UI em um navegador da web.
  2. Clique na guia Network Services.
  3. Clique na guia DNS.
  4. No menu suspenso, clique no item DNS Forward Zones.

    guia web ui dns

  5. Clique no botão Add.
  6. Na caixa de diálogo Add DNS forward zone, adicione um nome de zona.
  7. No item Zone forwarders, clique no botão Add.
  8. No campo Zone forwarders, adicione o endereço IP do servidor para o qual você deseja criar a nova zona de encaminhamento.
  9. Clique no botão Add.

    web ui forward zone acrescentar

A zona encaminhada foi adicionada às configurações do DNS e você pode verificá-la nas configurações das Zonas de Encaminhamento DNS. A interface Web o informa sobre o sucesso com a seguinte mensagem pop-up DNS Forward Zone successfully added.

Você pode realizar o mesmo procedimento na linha de comando com o seguinte comando:

# ipa dnsforwardzone-add $AD_DOMAIN --forwarder=$AD_IP_ADDR --forward-policy=only
Nota

A interface Web pode exibir um aviso sobre falha de validação DNSSEC após adicionar uma nova zona de avanço à configuração.

web ui forward zone dnssec válido

O DNSSEC (Domain Name System Security Extensions) protege os dados DNS com uma assinatura digital para proteger o DNS contra ataques. O serviço DNSSEC é habilitado por padrão no servidor IdM. O aviso apareceu porque o servidor DNS remoto não usava também o DNSSEC. Agora, você pode:

  • Habilitar o DNSSEC no servidor DNS remoto.
  • Desativar a validação do DNSSEC no arquivo /etc/named.conf salvo no servidor do IdM:
dnssec-validação nº;

Após salvar a mudança de configuração, não se esqueça de reiniciar o serviço ipactl:

# reinício do ipactl

O aviso não voltará a aparecer.

Para verificar se a zona dns foi criada com sucesso, use o comando nslookup com o nome do servidor DNS remoto:

$ nslookup ad.example.com
Server:        192.168.122.2
Address:       192.168.122.2#53

No-authoritative answer:
Name:          ad.example.com
Address:       192.168.122.3

Se o encaminhamento de domínio estiver configurado corretamente, nslookup mostrará um endereço IP do servidor DNS remoto.

25.6.3. Configurando o encaminhamento DNS no AD

Esta seção descreve como configurar um encaminhamento DNS no Active Directory (AD) para o servidor de Gerenciamento de Identidade (IdM).

Pré-requisitos

  • Servidor Windows com AD instalado.
  • Porta DNS aberta em ambos os servidores.

Procedimento

  1. Faça o login no Windows Server.
  2. Abrir Server Manager.
  3. Abrir DNS Manager.
  4. Em Conditional Forwarders, acrescente um novo forwarder condicional com:

    • O endereço IP do servidor IdM
    • Um nome de domínio totalmente qualificado, por exemplo, server.idm.example.com
  5. Salvar as configurações.

25.6.4. Verificando a configuração do DNS

Antes de configurar a confiança, verifique se os servidores de Gerenciamento de Identidade (IdM) e Active Directory (AD) podem resolver a si mesmos e uns aos outros.

Pré-requisitos

  • Você precisa estar logado com as permissões sudo.

Procedimento

  1. Execute uma consulta DNS para os Kerberos sobre os registros do serviço UDP e LDAP sobre os registros do serviço TCP.

    [admin@server ~]# dig +short -t SRV _kerberos._udp.idm.example.com.
    0 100 88 server.ipa.example.com.
    
    [admin@server ~]# dig +short -t SRV _ldap._tcp.idm.example.com.
    0 100 389 server.idm.example.com.

    Os comandos devem listar todos os servidores IdM.

  2. Execute uma consulta DNS para o registro TXT com o nome IdM Kerberos do reino. Espera-se que o valor obtido corresponda ao reino Kerberos que você especificou ao instalar o IdM.

    [admin@server ~]# dig +short -t TXT _kerberos.idm.example.com.
    "IDM.EXAMPLE.COM"

    Se os passos anteriores não retornaram todos os registros esperados, atualize a configuração do DNS com os registros que faltam:

    • Se seu ambiente IdM usa um servidor DNS integrado, insira o comando ipa dns-update-system-records sem nenhuma opção para atualizar seus registros do sistema:

      [admin@server ~]$ ipa dns-update-system-records
    • Se seu ambiente IdM não utiliza um servidor DNS integrado:

      1. No servidor da IdM, exportar os registros DNS da IdM para um arquivo:

        [admin@server ~]$ ipa dns-update-system-records --dry-run --out dns_records_file.nsupdate

        O comando cria um arquivo chamado dns_records_file.nsupdate com os registros DNS relevantes da IdM.

      2. Envie uma solicitação de atualização do DNS para seu servidor DNS usando o utilitário nsupdate e o arquivo dns_records_file.nsupdate. Para mais informações, consulte Atualização de Registros DNS Externos Utilizando nsupdate na documentação RHEL 7. Alternativamente, consulte a documentação de seu servidor DNS para adicionar registros DNS.
  3. Verificar se o IdM é capaz de resolver registros de serviço para AD com um comando que executa uma consulta DNS para Kerberos e LDAP sobre registros de serviço TCP:

    [admin@server ~]# dig +short -t SRV _kerberos._tcp.dc._msdcs.ad.example.com.
    0 100 88 addc1.ad.example.com.
    
    [admin@server ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.ad.example.com.
    0 100 389 addc1.ad.example.com.

25.7. Criando um fundo

Esta seção descreve como configurar a confiança do Gerenciamento de Identidade (IdM)/Diretório Ativo (AD) no lado do IdM usando a linha de comando.

Pré-requisitos

25.7.1. Preparando o servidor IdM para a confiança

Antes de estabelecer uma confiança com AD e se você quiser configurar o Samba em um cliente IdM, você deve preparar o domínio IdM usando o utilitário ipa-adtrust-install em um servidor IdM. Entretanto, mesmo que ambas as situações se apliquem, você deve rodar ipa-adtrust-install apenas uma vez em um master IdM.

Pré-requisitos

  • O IdM está instalado.

Procedimento

  1. Instalar os pacotes necessários:

    [root@ipaserver ~]# yum install ipa-server ipa-server-trust-ad samba-client
  2. Autenticar como usuário administrativo da IdM:

    [root@ipaserver ~]# kinit admin
  3. Execute o utilitário ipa-adtrust-install:

    [root@ipaserver ~]# ipa-adtrust-install

    Os registros do serviço DNS são criados automaticamente se a IdM foi instalada com um servidor DNS integrado.

    Se o IdM foi instalado sem um servidor DNS integrado, ipa-adtrust-install imprime uma lista de registros de serviços que devem ser adicionados manualmente ao DNS antes que você possa continuar.

  4. O roteiro lhe pede que o /etc/samba/smb.conf já existe e será reescrito:

    WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing Samba configuration.
    
    Do you wish to continue? [no]: yes
  5. O script solicita que você configure o plug-in slapi-nis, um plug-in de compatibilidade que permite que clientes Linux mais antigos trabalhem com usuários confiáveis:

    Do you want to enable support for trusted domains in Schema Compatibility plugin?
    This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users.
    
    Enable trusted domains support in slapi-nis? [no]: yes
  6. Quando solicitado, digite o nome NetBIOS para o domínio IdM ou pressione Enter para aceitar o nome sugerido:

    Trust is configured but no NetBIOS domain name found, setting it now.
    Enter the NetBIOS name for the IPA domain.
    Only up to 15 uppercase ASCII letters, digits and dashes are allowed.
    Example: EXAMPLE.
    
    NetBIOS domain name [IDM]:
  7. Você é solicitado a executar a tarefa da geração SID para criar um SID para qualquer usuário existente:

    Você quer executar a tarefa ipa-sidgen? [não] yes

    Quando o diretório é instalado pela primeira vez, pelo menos um usuário (o administrador do IdM) existe e como esta é uma tarefa de recursos intensivos, se você tiver um alto número de usuários, você pode executá-la em outro momento.

  8. (Optional) Por padrão, a faixa de portas Dynamic RPC é definida como 49152-65535 para Windows Server 2008 e posteriores. Se você precisar definir uma faixa de portas Dynamic RPC diferente para seu ambiente, configure o Samba para usar diferentes portas e abra essas portas em suas configurações de firewall. O exemplo a seguir define o intervalo de portas para 55000-65000.

    [root@ipaserver ~]# net conf setparm global 'rpc server dynamic port range' 55000-65000
    [root@ipaserver ~]# firewall-cmd --add-port=55000-65000/tcp
    [root@ipaserver ~]# firewall-cmd --runtime-to-permanent
  9. Certifique-se de que o DNS esteja devidamente configurado, conforme descrito em Verificação da configuração do DNS para uma confiança.

    Importante

    Toda vez que você executar ipa-adtrust-install, a Red Hat recomenda fortemente que você verifique a configuração do DNS conforme descrito em Verificação da configuração do DNS para uma confiança toda vez após executar ipa-adtrust-install, especialmente se o IdM ou AD não utilizarem servidores DNS integrados.

  10. Reinicie o serviço ipa:

    [root@ipaserver ~]# ipactl restart
  11. Use o utilitário smbclient para verificar se o Samba responde à autenticação Kerberos do lado do IdM:

    [root@ipaserver ~]# smbclient -L server.idm.example.com -k
    lp_load_ex: changing to config backend registry
        Sharename       Type      Comment
        ---------       ----      -------
        IPC$            IPC       IPC Service (Samba 4.12.3)
    ...

25.7.2. Estabelecimento de um acordo de confiança usando a linha de comando

Esta seção descreve como estabelecer o acordo de confiança usando a linha de comando. O servidor de Gerenciamento de Identidade (IdM) permite que você configure três tipos de acordos de confiança:

  • Opção  default- default de mão única. A confiança unidirecional permite que usuários e grupos do Active Directory (AD) acessem recursos no IdM, mas não o contrário. O domínio IdM confia na floresta AD, mas a floresta AD não confia no domínio IdM.
  • A confiança bidirecional trust - Two permite que usuários e grupos AD acessem recursos na IdM. Entretanto, a confiança bidirecional em IdM não dá aos usuários nenhum direito adicional em comparação com a solução de confiança unidirecional em AD. Ambas as soluções são consideradas igualmente seguras devido às configurações padrão de filtragem SID de confiança cruzada.

    • Para criar a confiança nos dois sentidos, adicione a seguinte opção ao comando --two-way=true
  • Confiança externa para uma relação de confiança entre domínios que se encontram em florestas diferentes.

    • Para criar a confiança externa, adicione a seguinte opção ao comando --external=true

Nesta seção, os passos abaixo mostram como criar um acordo de confiança unidirecional.

Pré-requisitos

Procedimento

  1. Criar um acordo de confiança para o domínio AD e o domínio IdM, usando o comando ipa trust-add:

    [root@server ~]# ipa trust-add --type=ad ad_domain_name --admin ad_admin_username --password

O comando ipa trust-add configura o servidor IdM como um controlador de confiança por padrão.

25.7.3. Estabelecendo um acordo de confiança na IDM Web UI

Esta seção descreve como configurar o acordo de confiança do Gerenciamento de Identidade (IdM)/Diretório Ativo (AD) no lado do IdM usando a interface web do IdM.

Pré-requisitos

  • O DNS está configurado corretamente. Ambos os servidores IdM e AD devem ser capazes de resolver os nomes um do outro.
  • As versões suportadas de AD e IdM são implantadas.
  • Você obteve um bilhete Kerberos.
  • Antes de criar uma confiança na Web UI, prepare o servidor IdM para a confiança, conforme descrito em: Preparando o servidor IdM para a confiança.
  • Você precisa estar logado como administrador da IdM.

Procedimento

  1. Entrar na IDM Web UI com privilégios de administrador. Para detalhes, veja Acessando a IDM Web UI em um navegador da web.
  2. Na interface web da IdM, clique na aba IPA Server.
  3. Na aba IPA Server, clique na aba Trusts.
  4. No menu suspenso, selecione a opção Trusts.

    ipa trust confia

  5. Clique no botão Add.
  6. Na caixa de diálogo Add Trust, digite o nome do domínio do Active Directory.
  7. Nos campos Account e Password, adicione as credenciais do administrador do Active Directory.

    ipa trust acrescenta

  8. [Opcional] Selecione Two-way trust, se você quiser habilitar usuários e grupos AD para acessar recursos no IdM. Entretanto, a confiança bidirecional em IdM não dá aos usuários nenhum direito adicional em comparação com a solução de confiança unidirecional em AD. Ambas as soluções são consideradas igualmente seguras devido às configurações padrão de filtragem SID de confiança cruzada.
  9. [Opcional] Se seus domínios estão em florestas diferentes, selecione External trust.
  10. Clique em Add.

Se a confiança foi adicionada com sucesso ao servidor IdM, você pode ver a janela pop-up verde na interface web da IdM. Isso significa que a:

  • O nome de domínio existe
  • O nome de usuário e a senha do Windows Server foram adicionados corretamente.

idm trust acrescentado

Agora você pode continuar a testar a conexão de confiança e a autenticação Kerberos.

25.7.4. Verificando a configuração do Kerberos

Para verificar a configuração do Kerberos, testar se é possível obter um bilhete para um usuário de Gerenciamento de Identidade (IdM) e se o usuário do IdM pode solicitar bilhetes de serviço.

Procedimento

  1. Solicite um ticket para um usuário do Active Directory (AD):

    [root@ipaserver ~]# kinit user@AD.EXAMPLE.COM
  2. Solicitar tickets de serviço para um serviço dentro do domínio IdM:

    [root@server ~]# kvno -S host server.idm.example.com

    Se o ingresso de serviço AD for concedido com sucesso, há um ingresso de concessão cruzada (TGT) listado com todos os outros ingressos solicitados. O nome do TGT é krbtgt/IPA.DOMAIN@AD.DOMAIN.

[root@server ]# klist
Ticket cache: KEYRING:persistent:0:krb_ccache_hRtox00
Default principal: user@AD.EXAMPLE.COM

Valid starting       Expires              Service principal
03.05.2016 18:31:06  04.05.2016 04:31:01  host/server.idm.example.com@IDM.EXAMPLE.COM
	renew until 04.05.2016 18:31:00
03.05.2016 18:31:06 04.05.2016 04:31:01 krbtgt/IDM.EXAMPLE.COM@AD.EXAMPLE.COM
	renew until 04.05.2016 18:31:00
03.05.2016 18:31:01  04.05.2016 04:31:01  krbtgt/AD.EXAMPLE.COM@AD.EXAMPLE.COM
	renew until 04.05.2016 18:31:00

O plug-in localauth mapeia os principais nomes de usuários locais do Kerberos System Security Services Daemon (SSSD). Isto permite aos usuários AD usar a autenticação Kerberos e acessar serviços Linux, que suportam a autenticação GSSAPI diretamente.

25.7.5. Verificando a configuração de confiança na IdM

Antes de configurar a confiança, verifique se os servidores de Gerenciamento de Identidade (IdM) e Active Directory (AD) podem resolver a si mesmos e uns aos outros.

Pré-requisitos

  • Você precisa estar logado com privilégios de administrador.

Procedimento

  1. Execute uma consulta DNS para os Kerberos MS DC sobre os registros de serviço UDP e LDAP sobre os registros de serviço TCP.

    [root@server ~]# dig +short -t SRV _kerberos._udp.dc._msdcs.idm.example.com.
    0 100 88 server.idm.example.com.
    
    [root@server ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.idm.example.com.
    0 100 389 server.idm.example.com.

    Estes comandos listam todos os servidores IdM nos quais ipa-adtrust-install foi executado. A saída está vazia se ipa-adtrust-install não tiver sido executado em nenhum servidor IdM, o que é normalmente antes de estabelecer a primeira relação de confiança.

  2. Execute uma consulta DNS para o Kerberos e LDAP sobre os registros de serviço TCP para verificar se a IdM é capaz de resolver registros de serviço para AD:

    [root@server ~]# dig +short -t SRV _kerberos._tcp.dc._msdcs.ad.example.com.
    0 100 88 addc1.ad.example.com.
    
    [root@ipaserver ~]# dig +short -t SRV _ldap._tcp.dc._msdcs.ad.example.com.
    0 100 389 addc1.ad.example.com.

.

25.7.6. Verificando a configuração de confiança no AD

Após configurar a confiança, verifique isso:

  • Os serviços de Gerenciamento de Identidade (IdM) são resolvidos a partir do servidor do Active Directory (AD).
  • Os serviços AD são resolvidos a partir do servidor AD.

Pré-requisitos

  • Você precisa estar logado com privilégios de administrador.

Procedimento

  1. No servidor AD, configure o utilitário nslookup.exe para consultar os registros de serviço.

    C:\>nslookup.exe
    > set type=SRV
  2. Digite o nome de domínio para os Kerberos sobre UDP e LDAP sobre os registros de serviço TCP.

    > _kerberos._udp.idm.example.com.
    _kerberos._udp.idm.example.com.       SRV service location:
        priority                = 0
        weight                  = 100
        port                    = 88
        svr hostname   = server.idm.example.com
    > _ldap._tcp.idm.example.com
    _ldap._tcp.idm.example.com       SRV service location:
        priority                = 0
        weight                  = 100
        port                    = 389
        svr hostname   = server.idm.example.com
  3. Mude o tipo de serviço para TXT e execute uma consulta DNS para o registro TXT com o nome do domínio IdM Kerberos.

    C:\>nslookup.exe
    > set type=TXT
    > _kerberos.idm.example.com.
    _kerberos.idm.example.com.        text =
    
        "IDM.EXAMPLE.COM"
  4. Execute uma consulta DNS para os Kerberos MS DC sobre os registros de serviço UDP e LDAP sobre os registros de serviço TCP.

    C:\>nslookup.exe
    > set type=SRV
    > _kerberos._udp.dc._msdcs.idm.example.com.
    _kerberos._udp.dc._msdcs.idm.example.com.        SRV service location:
        priority = 0
        weight = 100
        port = 88
        svr hostname = server.idm.example.com
    > _ldap._tcp.dc._msdcs.idm.example.com.
    _ldap._tcp.dc._msdcs.idm.example.com.        SRV service location:
        priority = 0
        weight = 100
        port = 389
        svr hostname = server.idm.example.com

    Espera-se que o comando liste todos os servidores IdM nos quais o utilitário ipa-adtrust-install foi executado. Para detalhes sobre ipa-adtrust-install, veja Preparando o servidor IdM para a confiança. Note que a saída está vazia se ipa-adtrust-install não tiver sido executado em nenhum servidor IdM, o que é normalmente antes de estabelecer a primeira relação de confiança.

  5. Verificar se os serviços AD são resolvidos a partir do servidor AD.

    C:\>nslookup.exe
    > set type=SRV
  6. Digite o nome de domínio para os Kerberos sobre UDP e LDAP sobre os registros de serviço TCP.

    > _kerberos._udp.dc._msdcs.ad.example.com.
    _kerberos._udp.dc._msdcs.ad.example.com. 	SRV service location:
        priority = 0
        weight = 100
        port = 88
        svr hostname = addc1.ad.example.com
    > _ldap._tcp.dc._msdcs.ad.example.com.
    _ldap._tcp.dc._msdcs.ad.example.com. 	SRV service location:
        priority = 0
        weight = 100
        port = 389
        svr hostname = addc1.ad.example.com

25.8. Removendo a confiança usando a IDM Web UI

Esta seção descreve como remover a confiança do Gerenciamento de Identidade (IdM)/Diretório Ativo (AD) no lado do IdM usando a interface web do IdM.

Pré-requisitos

Procedimento

  1. Entrar na IDM Web UI com privilégios de administrador. Para detalhes, veja Acessando a IDM Web UI em um navegador da web.
  2. Na interface web da IdM, clique na aba IPA Server.
  3. Na aba IPA Server, clique na aba Trusts.
  4. Selecione a confiança que você deseja remover.

    idm trust remover

  5. Clique no botão Delete.
  6. Na caixa de diálogo Remove trusts, clique em Delete.

    idm trust apagar

Se a confiança for excluída com sucesso, a interface de usuário da Web exibirá um pop-up verde com o texto:

idm trust eliminado

Parte III. Migrando o IdM de RHEL 7 para RHEL 8 e mantendo-o atualizado

Capítulo 26. Migrando seu ambiente IdM dos servidores RHEL 7 para os servidores RHEL 8

Para atualizar um ambiente RHEL 7 IdM para RHEL 8, você deve primeiro adicionar novas réplicas RHEL 8 IdM ao seu ambiente RHEL 7 IdM, e depois aposentar os servidores RHEL 7.

Atenção

A realização de uma atualização no local dos servidores da RHEL 7 IdM para a RHEL 8 não é suportada.

Esta seção descreve como migrate todos os dados e configurações de Gerenciamento de Identidade (IPA) de um servidor Red Hat Enterprise Linux (RHEL) 7 para um servidor RHEL 8.

O procedimento de migração inclui:

  1. Configurando um servidor RHEL 8 IdM e adicionando-o como uma réplica ao seu ambiente atual RHEL 7 IdM. Para detalhes, consulte Instalando a réplica do RHEL 8.
  2. Tornar o servidor RHEL 8 o servidor de renovação da autoridade de certificado (CA). Para detalhes, consulte Atribuição da função de servidor de renovação da CA ao servidor da RHEL 8 IdM.
  3. Parar a geração da lista de revogação de certificados (CRL) no servidor RHEL 7 e redirecionar as solicitações da CRL para a RHEL 8. Para detalhes, consulte Parando a geração da CRL em um servidor RHEL 7 IdM CA.
  4. Início da geração da CRL no servidor RHEL 8. Para detalhes, consulte Iniciando a geração do CRL no novo servidor RHEL 8 IdM CA.
  5. Parada e desativação do servidor de renovação original RHEL 7 CA. Para detalhes, consulte Parando e desativando o servidor RHEL 7.

Nos seguintes procedimentos:

  • rhel8.example.com é o sistema RHEL 8 que se tornará o novo servidor de renovação da CA.
  • rhel7.example.com é o servidor de renovação original da RHEL 7 CA. Para identificar qual servidor Red Hat Enterprise Linux 7 é o servidor de renovação CA, execute o seguinte comando em qualquer servidor IdM:

    [root@rhel7 ~]# ipa config-show | grep "CA renewal"
    IPA CA renewal master: rhel7.example.com

    Se sua implantação do IdM for sem CA, qualquer servidor IdM rodando no RHEL 7 pode ser rhel7.example.com.

Nota

Complete as etapas nas seções seguintes only se sua implantação de IdM utiliza uma autoridade de certificado (CA) incorporada:

26.1. Pré-requisitos para migrar o IdM da RHEL 7 para 8

Em rhel7.example.com:

  1. Atualize o sistema para a última versão RHEL 7.
  2. Atualize o ipa-* pacotes para sua versão mais recente:

    [root@rhel7 ~]# yum atualização ipa-*
    Atenção

    When upgrading multiple Identity Management (IdM) servers, wait at least 10 minutes between each upgrade.

    Quando dois ou mais servidores são atualizados simultaneamente ou com apenas pequenos intervalos entre as atualizações, não há tempo suficiente para replicar as mudanças de dados pós atualização em toda a topologia, o que pode resultar em eventos de replicação conflitantes.

Em rhel8.example.com:

  1. Garantir que o sistema rhel8.example.com atenda aos requisitos listados em Capítulo 1, Preparando o sistema para a instalação do servidor IdM.
  2. Garantir que o sistema rhel8.example.com utilize um servidor de tempo sincronizado com rhel7.example.com. Isto é importante porque no RHEL 8, IdM não fornece seu próprio servidor de tempo: a instalação de IdM em rhel8.example.com não resulta na instalação de um servidor NTP no host.
  3. Garantir que o sistema rhel8.example.com faça parte do domínio para o qual rhel7.example.com é autoritário.
  4. Atualize o ipa-* pacotes para sua versão mais recente:

    [root@rhel8 ~]# yum atualização ipa-*

Informações relacionadas

  • Para detalhes sobre o uso do utilitário yum, consulte as páginas do manual yum(8).

26.2. Instalando a réplica do RHEL 8

  1. Liste quais funções de servidor estão presentes em seu ambiente RHEL 7:

    [root@rhel7 ~]# ipa server-role-find --status enabled
    ----------------------
    4 server roles matched
    ----------------------
      Server name: rhel7.example.com
      Role name: CA server
      Role status: enabled
    
      Server name: replica7.example.com
      Role name: DNS server
      Role status: enabled
    
      Server name: rhel7.example.com
      Role name: DNS server
      Role status: enabled
    
      Server name: rhel7.example.com
      Role name: NTP server
      Role status: enabled
    [... output truncated ...]
  2. Instale o servidor IdM de Gerenciamento de Identidade em rhel8.example.com como uma réplica do servidor IdM RHEL 7, incluindo todas as funções do servidor presentes em seu rhel7.example.com, exceto a função de servidor NTP. Para instalar as funções a partir do exemplo acima, use estas opções com o comando ipa-replica-install:

    • --setup-ca to set up the Certificate System component
    • --setup-dns e --forwarder para configurar um servidor DNS integrado e definir um encaminhador para cuidar de consultas DNS que vão para fora do domínio IdM

      Nota

      Além disso, se sua implantação de IdM estiver em uma relação de confiança com o Active Directory (AD), adicione a opção --setup-adtrust ao comando ipa-replica-install para configurar a capacidade de confiança do AD em rhel8.example.com.

      Para configurar um servidor IdM com o endereço ip 192.0.2.1 que utiliza um encaminhador com o endereço ip 192.0.2.20:

      [root@rhel8 ~]# ipa-replica-install --setup-ca --ip-address 192.0.2.1 --setup-dns --forwarder 192.0.2.20

    Você não precisa especificar o servidor RHEL 7 IdM porque se o DNS estiver funcionando corretamente, rhel8.example.com o encontrará usando o DNS autodiscovery.

  3. Após a conclusão da instalação, verifique se os serviços da IdM estão funcionando em rhel8.example.com:

    [root@rhel8 ~]# ipactl status
    Directory Service: RUNNING
    [... output truncated ...]
    ipa: INFO: The ipactl command was successful
  4. Verifique se rhel7.example.com e rhel8.example.com estão ambos configurados como servidores da autoridade certificadora (CA):

    [root@rhel8 ~]$ kinit admin
    [root@rhel8 ~]$ ipa-csreplica-manage list
    rhel7.example.com: master
    rhel8.example.com: master
  5. Opcionalmente, para exibir detalhes sobre o acordo de replicação entre rhel7.example.com e rhel8.example.com:

    [root@rhel8 ~]# ipa-csreplica-manage list --verbose rhel8.example.com
    Directory Manager password:
    
    rhel7.example.com
    last init status: None
    last init ended: 1970-01-01 00:00:00+00:00
    last update status: Error (0) Replica acquired successfully: Incremental update succeeded
    last update ended: 2019-02-13 13:55:13+00:00
  6. Opcionalmente, adicione um registro do serviço _ntp._udp (SRV) para o servidor de tempo NTP ao DNS do servidor IdM recém-instalado, rhel8.example.com. A presença do registro SRV para o servidor de tempo rhel8.example.com no DNS da IdM garante que futuras réplicas e instalações do cliente sejam automaticamente configuradas para sincronizar com o servidor de tempo utilizado pelo novo servidor da IdM CA que combina as funções do servidor de renovação CA e do servidor de geração CRL, rhel8.example.com.

26.3. Atribuição do papel de servidor de renovação da CA ao servidor RHEL 8 IdM

Nota

Complete as etapas desta seção somente se sua implantação de IdM usar uma autoridade de certificado (CA) incorporada.

Em rhel8.example.com, configure rhel8.example.com como o novo servidor de renovação da CA:

  • Configurar rhel8.example.com para tratar da renovação do certificado do subsistema CA:

    [root@rhel8 ~]# ipa config-mod --ca-renewal-master-server rhel8.example.com
      ...
      IPA masters: rhel7.example.com, rhel8.example.com
      IPA CA servers: rhel7.example.com, rhel8.example.com
      IPA NTP servers: rhel7.example.com, rhel8.example.com
      IPA CA renewal master: rhel8.example.com

    A saída confirma que a atualização foi bem sucedida.

26.4. Parando a geração de CRL em um servidor RHEL 7 IdM CA

Nota

Complete as etapas desta seção somente se sua implantação de IdM usar uma autoridade de certificado (CA) incorporada.

Esta seção descreve como parar de gerar a Lista de Revogação de Certificados (CRL) no servidor rhel7.example.com CA usando o comando ipa-crlgen-manage.

Pré-requisitos

  • Você deve estar logado como raiz.

Procedimento

  1. Opcionalmente, verifique se rhel7.example.com está gerando a CRL:

    [root@rhel7 ~]# ipa-crlgen-manage status
    CRL generation: enabled
    Last CRL update: 2019-10-31 12:00:00
    Last CRL Number: 6
    The ipa-crlgen-manage command was successful
  2. Pare de gerar a CRL no servidor rhel7.example.com:

    [root@rhel7 ~]# ipa-crlgen-manage disable
    Stopping pki-tomcatd
    Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
    Starting pki-tomcatd
    Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
    Restarting httpd
    CRL generation disabled on the local host. Please make sure to configure CRL generation on another master with ipa-crlgen-manage enable.
    The ipa-crlgen-manage command was successful
  3. Opcionalmente, verifique se o servidor rhel7.example.com parou de gerar a CRL:

    [root@rhel7 ~]# ipa-crlgen-manage status

O servidor rhel7.example.com parou de gerar a CRL. O próximo passo é permitir a geração da CRL em rhel8.example.com.

26.5. Início da geração de CRL no novo servidor RHEL 8 IdM CA

Nota

Complete as etapas desta seção somente se sua implantação de IdM usar uma autoridade de certificado (CA) incorporada.

Pré-requisitos

  • Você deve estar logado como root na máquina rhel8.example.com.

Procedimento

  1. Para começar a gerar CRL em rhel8.example.com, use o comando ipa-crlgen-manage enable:

    [root@rhel8 ~]# ipa-crlgen-manage enable
    Stopping pki-tomcatd
    Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
    Starting pki-tomcatd
    Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
    Restarting httpd
    Forcing CRL update
    CRL generation enabled on the local host. Please make sure to have only a single CRL generation master.
    The ipa-crlgen-manage command was successful
  2. Para verificar se a geração de CRL está habilitada, use o comando ipa-crlgen-manage status:

    [root@rhel8 ~]# ipa-crlgen-manage status
    CRL generation: enabled
    Last CRL update: 2019-10-31 12:10:00
    Last CRL Number: 7
    The ipa-crlgen-manage command was successful

26.6. Parando e desativando o servidor RHEL 7

  1. Certifique-se de que todos os dados, incluindo as últimas mudanças, tenham sido migrados corretamente de rhel7.example.com para rhel8.example.com. Por exemplo:

    1. Adicione um novo usuário em rhel7.example.com:

      [root@rhel7 ~]# ipa user-add random_user
      First name: random
      Last name: user
    2. Verifique se o usuário foi replicado para rhel8.example.com:

      [root@rhel8 ~]# ipa user-find random_user
      --------------
      1 user matched
      --------------
        User login: random_user
        First name: random
        Last name: user
  2. Pare todos os serviços da IdM em rhel7.example.com para forçar a descoberta de domínio para o novo servidor rhel8.example.com.

    [root@rhel7 ~]# ipactl stop
    Stopping CA Service
    Stopping pki-ca:                                           [  OK  ]
    Stopping HTTP Service
    Stopping httpd:                                            [  OK  ]
    Stopping MEMCACHE Service
    Stopping ipa_memcached:                                    [  OK  ]
    Stopping DNS Service
    Stopping named: .                                          [  OK  ]
    Stopping KPASSWD Service
    Stopping Kerberos 5 Admin Server:                          [  OK  ]
    Stopping KDC Service
    Stopping Kerberos 5 KDC:                                   [  OK  ]
    Stopping Directory Service
    Shutting down dirsrv:
        EXAMPLE-COM...                                         [  OK  ]
        PKI-IPA...                                             [  OK  ]

    Depois disso, o utilitário ipa entrará em contato com o novo servidor através de uma chamada de procedimento remoto (RPC).

  3. Remover o servidor RHEL 7 da topologia executando os comandos de remoção no servidor RHEL 8. Para detalhes, consulte Capítulo 8, Desinstalando um servidor IdM.

Capítulo 27. Atualização e desclassificação do IdM

Você pode usar o utilitário yum para atualizar os pacotes de Gerenciamento de Identidade (IdM) no sistema.

  • Para atualizar todos os pacotes IdM que sejam relevantes para seu perfil e que tenham atualizações disponíveis:

    # yum upgrade ipa-* *
  • Alternativamente, para instalar ou atualizar pacotes para corresponder à última versão disponível para seu perfil a partir de qualquer repositório habilitado:

    # yum distro-sync ipa-* *

Após atualizar os pacotes IdM em pelo menos um servidor, todos os outros servidores da topologia recebem o esquema atualizado, mesmo que você não atualize seus pacotes. Isto assegura que qualquer nova entrada que utilize o novo esquema possa ser replicada entre os outros servidores.

Atenção

Ao atualizar vários servidores IdM, aguarde pelo menos 10 minutos depois de atualizar um servidor antes de atualizar outro servidor. Entretanto, o tempo real necessário para o sucesso da atualização de um servidor depende da topologia implantada, da latência das conexões e do número de mudanças geradas pela atualização.

Quando dois ou mais servidores são atualizados simultaneamente ou com apenas pequenos intervalos entre as atualizações, não há tempo suficiente para replicar as mudanças de dados pós atualização em toda a topologia, o que pode resultar em eventos de replicação conflitantes.

O rebaixamento manual dos pacotes IdM não é suportado. Use yum distro-sync para atualizar e fazer downgrade de pacotes em módulos.

Importante

Não execute o comando yum downgrade em nenhum dos ipa-* embalagens.

Informações relacionadas

  • Para detalhes sobre o uso do utilitário yum, consulte as páginas do manual yum(8).

Capítulo 28. Atualização de um cliente IdM de RHEL 7 para RHEL 8

Ao contrário dos servidores IdM, a realização de uma atualização no local de um cliente IdM de RHEL 7 para RHEL 8 é suportada.

No RHEL 8, algumas opções incomuns e funcionalidades não utilizadas foram removidas do System Security Services Daemon (SSSD), o serviço responsável pela autenticação em um ambiente IdM. Veja nas seções seguintes as etapas para remover essas opções.

28.1. Atualização da configuração do SSSD após a atualização para o RHEL 8

Após atualizar um cliente de Gerenciamento de Identidade (IdM) do Red Hat Enterprise Linux (RHEL) 7 para o RHEL 8, o aplicativo de atualização leapp pode exibir um aviso de que algumas opções de configuração SSSD não são mais suportadas.

Os procedimentos a seguir descrevem como atualizar sua configuração de SSSD para resolver estes problemas.

Pré-requisitos

  • Você atualizou um cliente da IdM de RHEL 7 para RHEL 8.
  • Você tem root permissões para editar /etc/sssd/sssd.conf.

28.1.1. Mudando do provedor de ID local para o provedor de ID files

Se você vir o seguinte erro, substitua o provedor de ID local pelo provedor de ID files:

SSSD Domain "example.com": local provider is no longer supported and the domain will be ignored.
Local provider is no longer supported.

Procedimento

  1. Certifique-se de que todos os usuários e grupos que você recuperou com o provedor de ID local também estão nos arquivos /etc/passwd e /etc/group. Isto assegura que o provedor files possa acessar esses usuários e grupos.

    1. Se você precisar criar usuários, use o comando useradd. Se você precisar especificar a UID, adicione a opção -u:

      [root@client ~]# useradd -u 3001 username
    2. Se você precisar criar grupos, use o comando groupadd. Se você precisar especificar o GID, adicione a opção -g:

      [root@client ~]# groupadd -g 5001 groupname
  2. Abra o arquivo de configuração /etc/sssd/sssd.conf em um editor de texto.
  3. Substituir id_provider=local por id_provider=files.

    [domain/example.com]
    id_provider = files
    ...
  4. Salve o arquivo de configuração /etc/sssd/sssd.conf.
  5. Reinicie o SSSD para carregar as mudanças de configuração.

    [root@client ~]# systemctl restart sssd

28.1.2. Remoção das opções depreciadas

Se você vir algum dos seguintes erros em relação às opções depreciadas, a Red Hat recomenda a remoção dessas opções do arquivo de configuração /etc/sssd/sssd.conf:

SSSD Domain "example.com": option ldap_groups_use_matching_rule_in_chain has no longer any effect
Option ldap_groups_use_matching_rule_in_chain was removed and it will be ignored.
SSSD Domain "example.com": option ldap_initgroups_use_matching_rule_in_chain has no longer any effect
Option ldap_initgroups_use_matching_rule_in_chain was removed and it will be ignored.

Procedimento

  1. Abra o arquivo de configuração /etc/sssd/sssd.conf em um editor de texto.
  2. Remover quaisquer ocorrências das opções ldap_groups_use_matching_rule_in_chain ou ldap_initgroups_use_matching_rule_in_chain.
  3. Salve o arquivo de configuração /etc/sssd/sssd.conf.
  4. Reinicie o SSSD para carregar as mudanças de configuração.

    [root@client ~]# systemctl restart sssd

28.1.3. Permitindo a correspondência de wildcard para as regras do sudo

O seguinte aviso indica que as regras sudo com wildcards não funcionarão por padrão no RHEL 8, pois a opção ldap_sudo_include_regexp está agora definida por padrão para false.

SSSD Domain "example.com": sudo rules containing wildcards will stop working.
Default value of ldap_sudo_include_regexp changed from true to false for performance reason.

Se você utiliza as regras sudo com curingas e deseja habilitar a correspondência de curingas, defina manualmente a opção ldap_sudo_include_regexp para true.

Nota

A Red Hat recomenda contra o uso de wildcards para corresponder às regras do sudo

Se a opção ldap_sudo_include_regexp estiver definida para true, o SSSD baixa cada regra sudo que contém um wildcard no atributo sudoHost, o que impacta negativamente o desempenho da busca LDAP.

Procedimento

  1. Abra o arquivo de configuração /etc/sssd/sssd.conf em um editor de texto.
  2. No domínio example.com, definir ldap_sudo_include_regexp=true.

    [domain/example.com]
    ...
    ldap_sudo_include_regexp = true
    ...
  3. Salve o arquivo de configuração /etc/sssd/sssd.conf.
  4. Reinicie o SSSD para carregar as mudanças de configuração.

    [root@client ~]# systemctl restart sssd

28.2. Lista da funcionalidade SSSD removida no RHEL 8

A seguinte funcionalidade SSSD foi removida no RHEL 8.

O provedor de ID local foi removido
O provedor de ID local, usado para servir informações do usuário a partir do cache SSSD local, foi depreciado no RHEL 7 e não é mais suportado no RHEL 8. Se você tem um domínio com id_provider=local em sua configuração /etc/sssd/sssd.conf, o SSSD ignora este domínio e inicia normalmente.
As ferramentas de linha de comando para gerenciar usuários e grupos nos domínios local foram removidas

Os seguintes comandos, que afetavam apenas os domínios local, foram removidos:

  • sss_useradd
  • sss_userdel
  • sss_groupadd
  • sss_groupdel
O suporte para a opção ldap_groups_use_matching_rule_in_chain foi removido
Esta opção específica do Active Directory não oferece um benefício significativo de desempenho e é ignorada em qualquer configuração do RHEL 8 sssd.conf.
O suporte para a opção ldap_initgroups_use_matching_rule_in_chain foi removido
Esta opção específica do Active Directory não oferece um benefício significativo de desempenho e é ignorada em qualquer configuração do RHEL 8 sssd.conf.
A opção ldap_sudo_include_regexp agora tem como padrão false
Na RHEL 7, esta opção foi configurada para true por padrão. Se esta opção for definida para true, o SSSD baixa cada regra sudo que contém um wildcard no atributo sudoHost, o que impacta negativamente o desempenho da busca LDAP.
O respondedor do site sssd-secrets foi removido
Como o Kerberos Cache Manager (KCM) não depende mais do respondedor sssd-secrets, e nenhum outro processo de IdM o utiliza, ele foi removido.

28.3. Recursos adicionais