Red Hat Training
A Red Hat training course is available for RHEL 8
Instalando o Gerenciamento de Identidade
Começando a usar o Gerenciamento de Identidade
Resumo
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:
- 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.
- Use o cursor do mouse para destacar a parte do texto que você deseja comentar.
- Clique no pop-up Add Feedback que aparece abaixo do texto destacado.
- Siga as instruções apresentadas.
Para enviar comentários mais complexos, crie um bilhete Bugzilla:
- Ir para o site da Bugzilla.
- Como Componente, use Documentation.
- Preencha o campo Description com sua sugestão de melhoria. Inclua um link para a(s) parte(s) relevante(s) da documentação.
- 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.
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.
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.
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.
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.
- 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
- Para ativar o modo FIPS no sistema operacional RHEL, consulte Mudando o sistema para o modo FIPS no guia Security Hardening.
- Para mais detalhes sobre o FIPS 140-2, consulte os Requisitos de Segurança para Módulos Criptográficos no site do National Institute of Standards and Technology (NIST).
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
.
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ção | Comportamento |
---|---|
| Use-o para especificar um servidor NTP. Você pode usá-lo várias vezes para especificar vários servidores. |
| Use-o para especificar um pool de múltiplos servidores NTP resolvidos como um nome de host. |
|
Não configurar, iniciar ou ativar |
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
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.
-
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 porta123
. 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.
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 serlocalhost
oulocalhost6
.- Verificar a configuração do DNS para frente e para trás
Obter o endereço IP do servidor.
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 ...
Verifique a configuração do DNS forward usando o utilitário
dig
.Execute o comando
dig short server.example.com A
. O endereço IPv4 devolvido deve corresponder ao endereço IP devolvido porip addr show
:[root@server ~]# dig +short server.example.com A 192.0.2.1
Execute o comando
dig short server.example.com AAAA
. Se ele retornar um endereço, ele deve corresponder ao endereço IPv6 retornado porip addr show
:[root@server ~]# dig +short server.example.com AAAA 2001:DB8::1111
NotaSe
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.
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.
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
Se o comando
dig short -x server.example.com AAAA
na etapa anterior devolveu um endereço IPv6, usedig
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
NotaSe
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çãoSe 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çãoANSWER
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 [...]
-
status
- 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ço | Portos | Protocolo |
---|---|---|
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ço | Para maiores detalhes, veja: |
---|---|
|
|
|
|
|
|
Abertura dos portos necessários
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
Abra as portas necessárias usando o utilitário
firewall-cmd
. Escolha uma das seguintes opções: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}
Adicione os serviços
firewalld
ao firewall, usando o comandofirewall-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).
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 comandofirewall-cmd
, por exemplo:# Firewall-cmd - tempo de execução a permanente
-
Optional. Para verificar se as portas estão disponíveis agora, use o
nc
,telnet
, ounmap
utilitários para conectar a uma porta ou executar uma varredura de porta.
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
eAppStream
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
Habilite o fluxo
idm:DL1
:# yum module enable idm:DL1
Mude para as RPMs entregues através do fluxo
idm:DL1
:# yum distro-sync
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
edns
:# 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
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.
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.
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
Execute o utilitário ipa-server-install.
# ipa-server-install
O script solicita a configuração de um serviço DNS integrado. Digite
yes
.Você deseja configurar o DNS integrado (BIND)? [não]
yes
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çãoPlaneje cuidadosamente estes nomes. Você não poderá alterá-los após a conclusão da instalação.
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:
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).
-
Para as configurações padrão da política de encaminhamento, consulte a descrição
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.
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.
NotaO uso de IdM para gerenciar zonas invertidas é opcional. Você pode usar um serviço DNS externo para este fim.
Digite
yes
para confirmar a configuração do servidor.Continuar a configurar o sistema com estes valores? [não]
yes
- O roteiro de instalação agora configura o servidor. Aguarde que a operação seja concluída.
Após a conclusão do roteiro de instalação, atualize seus registros DNS da seguinte maneira:
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.com
Adicione um registro de servidor de nomes (NS) ao domínio paiexample.com
.ImportanteRepita esta etapa toda vez que um servidor DNS IdM for instalado.
-
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
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
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 paraadmin
, 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
-
Após a conclusão do roteiro de instalação, atualize seus registros DNS da seguinte maneira:
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.com
Adicione um registro de servidor de nomes (NS) ao domínio paiexample.com
.ImportanteRepita esta etapa toda vez que um servidor DNS IdM for instalado.
-
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 aipa-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
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).O script solicita a configuração de um serviço DNS integrado. Digite
yes
ouno
. Neste procedimento, estamos instalando um servidor com DNS integrado.Você deseja configurar o DNS integrado (BIND)? [não]
yes
NotaSe 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.
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çãoPlaneje cuidadosamente estes nomes. Você não poderá alterá-los após a conclusão da instalação.
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:
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).
-
Para as configurações padrão da política de encaminhamento, consulte a descrição
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.
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.
NotaO uso de IdM para gerenciar zonas invertidas é opcional. Você pode usar um serviço DNS externo para este fim.
Digite
yes
para confirmar a configuração do servidor.Continuar a configurar o sistema com estes valores? [não]
yes
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:
-
Submeter a RSE localizada em
/root/ipa.csr
à CA externa. O processo difere dependendo do serviço a ser usado como a CA externa. 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.
ImportanteCertifique-se de obter a cadeia completa de certificados para a CA, não apenas o certificado da CA.
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
-
Submeter a RSE localizada em
- O roteiro de instalação agora configura o servidor. Aguarde que a operação seja concluída.
Após a conclusão do roteiro de instalação, atualize seus registros DNS da seguinte maneira:
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.com
Adicione um registro de servidor de nomes (NS) ao domínio paiexample.com
.ImportanteRepita esta etapa toda vez que um servidor DNS IdM for instalado.
-
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.
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:
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
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
Remover a instalação do servidor de Gerenciamento de Identidade (IdM) que falhou:
# ipa-server-install --uninstall
-
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
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
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.
O script solicita a configuração de um serviço DNS integrado. Digite
yes
ouno
. Neste procedimento, estamos instalando um servidor com DNS integrado.Você deseja configurar o DNS integrado (BIND)? [não]
yes
NotaSe 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.
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çãoPlaneje cuidadosamente estes nomes. Você não poderá alterá-los após a conclusão da instalação.
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:
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).
-
Para as configurações padrão da política de encaminhamento, consulte a descrição
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.
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.
NotaO uso de IdM para gerenciar zonas invertidas é opcional. Você pode usar um serviço DNS externo para este fim.
Digite
yes
para confirmar a configuração do servidor.Continuar a configurar o sistema com estes valores? [não]
yes
- O roteiro de instalação agora configura o servidor. Aguarde que a operação seja concluída.
Após a conclusão do roteiro de instalação, atualize seus registros DNS da seguinte maneira:
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.com
Adicione um registro de servidor de nomes (NS) ao domínio paiexample.com
.ImportanteRepita esta etapa toda vez que um servidor DNS IdM for instalado.
-
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
Execute o utilitário
ipa-server-install
.# ipa-server-install
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]:
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çãoPlaneje cuidadosamente estes nomes. Você não poderá alterá-los após a conclusão da instalação.
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:
Digite
yes
para confirmar a configuração do servidor.Continuar a configurar o sistema com estes valores? [não]
yes
- O roteiro de instalação agora configura o servidor. Aguarde que a operação seja concluída.
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 ...
ImportanteA 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
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
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 paraadmin
, 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
-
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 ...
ImportanteA 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 aipa-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
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).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]:
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çãoPlaneje cuidadosamente estes nomes. Você não poderá alterá-los após a conclusão da instalação.
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:
Digite
yes
para confirmar a configuração do servidor.Continuar a configurar o sistema com estes valores? [não]
yes
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:
-
Submeter a RSE localizada em
/root/ipa.csr
à CA externa. O processo difere dependendo do serviço a ser usado como a CA externa. 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.
ImportanteCertifique-se de obter a cadeia completa de certificados para a CA, não apenas o certificado da CA.
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
-
Submeter a RSE localizada em
- O roteiro de instalação agora configura o servidor. Aguarde que a operação seja concluída.
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 ...
ImportanteA 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
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 aipa-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
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 paraadmin
, 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ínioPor 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).-
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:
-
Submeter a RSE localizada em
/root/ipa.csr
à CA externa. O processo difere dependendo do serviço a ser usado como a CA externa. 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.
ImportanteCertifique-se de obter a cadeia completa de certificados para a CA, não apenas o certificado da CA.
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
-
Submeter a RSE localizada em
- O roteiro de instalação agora configura o servidor. Aguarde que a operação seja concluída.
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 ...
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
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
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
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áriososreport
, 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ção | Descrição |
---|---|
|
Questões de alto nível e traços Python para o processo de instalação do |
|
Erros do serviço |
| Grandes pilhas de atividades JAVA no núcleo do produto Public Key Infrastructure (PKI) |
| Diário de auditoria do produto PKI |
| 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 |
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
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 emScriptError
. 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
- 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áriososreport
, 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
Desinstale o software do servidor IdM do host que você está tentando configurar como um servidor IdM.
[root@server ~]# ipa-server-install --uninstall
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
- Para detalhes adicionais sobre como desinstalar um servidor IdM, veja Desinstalar um servidor IdM.
-
Se as tentativas de instalação falharem após repetidas tentativas de desinstalação, e você 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
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áriososreport
, veja O que é um sosreport e como criar um no Red Hat Enterprise Linux?
7.4. Recursos adicionais
- Para solucionar problemas na instalação de uma réplica IdM, consulte Solução de problemas na instalação de réplicas IdM.
- Para solucionar problemas na instalação de um cliente IdM, consulte Solução de problemas na instalação do cliente IdM.
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.
A remoção do último servidor que serve como CA, KRA, ou servidor DNS perturba seriamente a funcionalidade de Gerenciamento de Identidade (IdM).
Procedimento
Em todos os servidores da topologia que têm um acordo de replicação com
server.idm.example.com
, use o comandoipa server-del
para excluir a réplica da topologia:[root@another_server ~]# ipa server-del server.idm.example.com
Em
server.idm.example.com
, use o comandoipa-server-install --uninstall
:[root@server ~]# ipa-server-install --uninstall ... Are you sure you want to continue with the uninstall procedure? [no]: yes
-
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
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.
ImportanteSe 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:
Pare a instância existente do servidor IdM.
[root@old_server ~]# ipactl stop
- 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
- Para detalhes sobre os requisitos DNS no IdM, veja Seção 1.4, “Nome do host e requisitos DNS para IdM”.
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
- Para informações sobre quais portos específicos são utilizados, ver Seção 1.5, “Exigências portuárias para IdM”.
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 manualsssd.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:
-
o fluxo
idm:client
. Para maiores detalhes, ver Seção 10.4.1, “Instalação de pacotes ipa-cliente a partir do idm:client stream”. -
o fluxo
idm:DL1
. Para maiores detalhes, ver Seção 10.4.2, “Instalação de pacotes ipa-cliente a partir do idm:DL1 stream”.
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.
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.
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
Para mudar para as RPMs entregues através do fluxo
idm:DL1
:# yum module enable idm:DL1 # yum distro-sync
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:
- Para instalar um cliente interativamente usando as credenciais de usuário privilegiado (a opção padrão), consulte Instalando um cliente usando as credenciais de usuário: Instalação interativa.
- Para instalar um cliente interativamente usando uma senha única, consulte Instalação de um cliente usando uma senha única: Instalação interativa.
- Para instalar um cliente de forma não interativa utilizando as credenciais de um usuário privilegiado, uma senha única ou uma tecla de uma inscrição anterior, consulte Instalando um cliente: Instalação não-interativa.
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
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
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 novamenteipa-client-install
e especifique os valores necessários adicionando opções de linha de comando aipa-client-install
, por exemplo:-
--hostname
-
--realm
-
--domain
-
--server
-
- Se o script não conseguir obter algumas configurações automaticamente, ele solicita os valores.
ImportanteO 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.
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 forhostadmin
@EXAMPLE.COM
: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 manualipa-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
Em um servidor no domínio, adicione o futuro sistema cliente como um host IdM. Use a opção
--random
com o comandoipa 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
NotaA 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
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
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 novamenteipa-client-install
e especifique os valores necessários adicionando opções de linha de comando aipa-client-install
, por exemplo:-
--hostname
-
--realm
-
--domain
-
--server
-
- Se o script não conseguir obter algumas configurações automaticamente, ele solicita os valores.
ImportanteO 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.
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 manualipa-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.ImportanteO 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)}:
-
Abrir
/etc/openldap/ldap.conf
e/etc/sssd/sssd.conf
. - Eliminar a configuração anterior.
- Descomentar a nova configuração da IdM.
-
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ção | Protocolo utilizado | Objetivo |
---|---|---|
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ção | Protocolo utilizado | Objetivo |
---|---|---|
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 |
Tabela 11.3. Operações de pós-instalação da Web UI
Operação | Protocolo utilizado | Objetivo |
---|---|---|
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ção | Protocolo utilizado | Objetivo |
---|---|---|
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ção | Protocolo utilizado | Objetivo |
---|---|---|
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ção | Protocolo utilizado | Objetivo |
---|---|---|
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
-
Não inicie o serviço
sshd
antes da inscrição no kickstart. Iniciarsshd
antes de inscrever o cliente gera as chaves SSH automaticamente, mas o arquivo Kickstart em Seção 12.2, “Arquivo Kickstart para instalação do cliente” usa um script para o mesmo propósito, que é a solução preferida.
Procedimento
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.
-
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
. - 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:- Todas as informações necessárias para acessar e configurar os serviços do domínio IdM
- A senha que você define ao pré-criar o host do cliente no servidor da IdM. em Seção 12.1, “Instalação de um cliente com Kickstart”.
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
aipa-client-install
. Para que o script de instalação do cliente solicite um certificado para a máquina:
-
Adicione a opção
--request-cert
aipa-client-install
. Defina o endereço do ônibus do sistema para
/dev/null
tanto para o utilitáriogetcert
como para oipa-client-install
no ambiente Kickstartchroot
. Para fazer isto, adicione estas linhas às instruções pós-instalação no arquivo Kickstart antes da instruçãoipa-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
-
Adicione a opção
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
Use o utilitário
grep
para recuperar quaisquer ocorrências da palavra-chaveScriptError
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.
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áriososreport
, 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
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
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
Use o utilitário
grep
para recuperar o conteúdo dos comandosnsupdate
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áriososreport
, 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
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
- 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áriososreport
, veja O que é um sosreport e como criar um no Red Hat Enterprise Linux?
13.4. Recursos adicionais
- Para solucionar problemas na instalação do primeiro servidor IdM, consulte Solução de problemas na instalação do servidor IdM.
- Para solucionar problemas na instalação de uma réplica IdM, consulte Solução de problemas na instalação de réplicas IdM.
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.
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.
- Re-criar a máquina do cliente com o mesmo nome de host.
Execute o comando
ipa-client-install --force-join
na máquina do cliente:# ipa-client-install --force-join
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 forhostadmin
@EXAMPLE.COM
:
Recursos adicionais
- Para um procedimento mais detalhado sobre a inscrição de clientes usando as credenciais de um usuário autorizado, veja Seção 11.2, “Instalação de um cliente usando as credenciais do usuário: Instalação interativa”.
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.
- Re-criar a máquina do cliente com o mesmo nome de host.
-
Copie o arquivo keytab do local de backup para o diretório
/etc/
na máquina do cliente recriada. 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
NotaA 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
Digite o comando
ipa-client-install --uninstall
:[root@client ~]# ipa-client-install --uninstall
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"
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
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
ImportanteA 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).
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:
- Preparando o anfitrião. Para detalhes, veja Seção 16.1, “Pré-requisitos”
- Desinstalando o cliente IdM do anfitrião. Para detalhes, veja Seção 16.2, “Desinstalando um cliente IdM”
- Renomeando o anfitrião. Para detalhes, veja Seção 16.3, “Renomeando o sistema hospedeiro”
- Instalando o cliente IdM no host com o novo nome. Para detalhes, veja Seção 16.4, “Re-instalação de um cliente IdM”
- 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.com
determinar a localização das fichas-chave correspondentes noold-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
Digite o comando
ipa-client-install --uninstall
:[root@client ~]# ipa-client-install --uninstall
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"
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
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
ImportanteA 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
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
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
- 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.- 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 pacoteipa-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.
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 emipaservers
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
) paraipa-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:Faça o login como administrador.
$ parentes admin
Adicione a nova máquina como um host IdM. Use a opção
--random
com o comandoipa 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.
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
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
NotaO 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).-
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 paiexample.com
.ImportanteRepita 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)
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
Execute
ipa-replica-install
com a opção--setup-ca
.# ipa-replica-install --setup-ca
Adicione os novos registros do serviço DNS da IdM ao seu servidor DNS:
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
-
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.
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
NotaNão adicione a opção
--ca-cert-file
. O utilitárioipa-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
Criar um usuário na nova réplica:
[admin@new_replica ~]$ ipa user-add test_user
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ção | Protocolo utilizado | Objetivo |
---|---|---|
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
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
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
(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 umsosreport
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áriososreport
, 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ção | Descrição |
---|---|
|
Questões de alto nível e traços Python para o processo de instalação do |
|
Erros do serviço |
| Grandes pilhas de atividades JAVA no núcleo do produto Public Key Infrastructure (PKI) |
| Diário de auditoria do produto PKI |
| 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
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
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 emScriptError
. 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
- 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 umsosreport
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áriososreport
, 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
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
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
- Tente instalar a réplica.
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 umsosreport
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áriososreport
, 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
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
.
- 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 umsosreport
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áriososreport
, veja O que é um sosreport e como criar um no Red Hat Enterprise Linux?
19.5. Recursos adicionais
- Para solucionar problemas na instalação do primeiro servidor IdM, consulte Solução de problemas na instalação do servidor IdM.
- Para solucionar problemas na instalação de um cliente IdM, consulte Solução de problemas na instalação do cliente IdM.
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.
A remoção do último servidor que serve como CA, KRA, ou servidor DNS perturba seriamente a funcionalidade de Gerenciamento de Identidade (IdM).
Procedimento
Em todos os servidores da topologia que têm um acordo de replicação com
server.idm.example.com
, use o comandoipa server-del
para excluir a réplica da topologia:[root@another_server ~]# ipa server-del server.idm.example.com
Em
server.idm.example.com
, use o comandoipa-server-install --uninstall
:[root@server ~]# ipa-server-install --uninstall ... Are you sure you want to continue with the uninstall procedure? [no]: yes
-
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.
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
NotaNos 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 teripa-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
- A ferramenta Healthcheck deve ser instalada. Veja Instalando o IdM Healthcheck.
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.
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.
Habilitar o repositório necessário:
# subscription-manager repos --enable ansible-2.8-for-rhel-8-x86_64-rpms
Instalar Possível:
# yum install ansible
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 deipaserver
,ipareplica
eipaclient
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órioplaybooks/
(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
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 oFQDN
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.
- Especifique o domínio e as informações do domínio IdM.
-
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
. Especifique as senhas para
admin
e para oDirectory 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 exemploinstall-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
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 oFQDN
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.
- Especifique o domínio e as informações do domínio IdM.
-
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
. Especifique as senhas para
admin
e para oDirectory 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 [...]
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
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
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
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 exemploinstall-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
-
Localize o arquivo
ipa.csr
de pedido de assinatura de certificado no controlador e submeta-o à CA externa. - 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.
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 exemploinstall-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.
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.
Habilitar o repositório necessário:
# subscription-manager repos --enable ansible-2.8-for-rhel-8-x86_64-rpms
Instalar Possível:
# yum install ansible
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 deipaserver
,ipareplica
eipaclient
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órioplaybooks/
(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
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. OFQDNs
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.
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á implantadoreplica1.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 playbookinstall-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
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: presentPara 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çãoipaadmin_password
na seção[ipareplicas:vars]
do arquivo do inventário. O arquivo do inventário e o arquivo do playbookinstall-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çãoipaadmin_password
para a senha. O arquivo do inventário e o arquivo do playbookinstall-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 peloipareplica
. 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 exemploinstall-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.
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:
- Instalando o pacote ansible-freeipa;
Configurando os parâmetros da implantação do cliente IdM para corresponder ao seu cenário de implantação:
- Configuração dos parâmetros do arquivo de inventário para o modo de instalação do cliente de autodescoberta;
- Definição dos parâmetros do arquivo de inventário para quando a auto-descoberta não é possível durante a instalação do cliente;
- Verificação dos parâmetros em install-client.yml;
- Implantação de um cliente IdM usando um livro de brincadeiras possível;
- Teste de um cliente de Gerenciamento de Identidade após a instalação.
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.
Habilitar o repositório necessário:
# subscription-manager repos --enable ansible-2.8-for-rhel-8-x86_64-rpms
Instalar Possível:
# yum install ansible
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 deipaserver
,ipareplica
eipaclient
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órioplaybooks/
(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
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 [...]
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: presentCom menos segurança, forneça as credenciais de
admin
usando a opçãoipaadmin_password
na seção[ipaclients:vars]
do arquivoinventory/hosts
. Alternativamente, para especificar um usuário autorizado diferente, use a opçãoipaadmin_principal
para o nome do usuário, e a opçãoipaadmin_password
para a senha. O arquivoinventory/hosts
do inventário e o arquivo do playbookinstall-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]
deinventory/hosts
.
-
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
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çãoipaclient_use_otp=yes
na seção[ipaclients:vars]
do arquivoinventory/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 arquivoinventory/hosts
. -
O admin keytab, por exemplo, fornecendo um valor para
ipaadmin_keytab
na seção[ipaclients:vars]
deinventory/hosts
.
-
O password of a user authorized to enroll clients, por exemplo, fornecendo um valor para
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
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.
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 IdMExemplo 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 [...]
-
a opção
-
o
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: presentCom menos segurança, forneça as credenciais de
admin
usando a opçãoipaadmin_password
na seção[ipaclients:vars]
do arquivoinventory/hosts
. Alternativamente, para especificar um usuário autorizado diferente, use a opçãoipaadmin_principal
para o nome do usuário, e a opçãoipaadmin_password
para a senha. O arquivo do playbookinstall-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]
deinventory/hosts
.
-
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
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 arquivoinventory/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 arquivoinventory/hosts
. -
O admin keytab, por exemplo, fornecendo um valor para
ipaadmin_keytab
na seção[ipaclients:vars]
deinventory/hosts
.
-
O password of a user authorized to enroll clients, por exemplo, fornecendo um valor para
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 oFQDNs
dos anfitriões no qual o scriptipa-client-install
deve ser executado. -
A entrada
become: true
especifica que as credenciais da raiz serão invocadas durante a execução do scriptipa-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
).
-
A entrada dos anfitriões especifica a seção do arquivo
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ção | Nota | Exemplo de arquivo de inventário | Exemplo 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 exemploinstall-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
NotaA 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.
- Para detalhes, consulte Instalando o Gerenciamento de Identidade.
- 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 é tipicamenteAD
. 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 nome NetBIOS de um domínio Active Directory ou IdM é geralmente a primeira parte do domínio DNS correspondente. Se o domínio DNS é
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.
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
- Para detalhes sobre Enterprise Admins, veja Enterprise Admins.
- Para obter detalhes sobre Admins de Domínios, consulte Admins de Domínios.
- Para detalhes sobre a AD trust, veja Como Funcionam os Trusts de Domínios e Florestas.
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:
Use o comando
update-crypto-policies
para ativar a subpolítica criptográficaAD-SUPPORT
, além da política criptográficaDEFAULT
.[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.
- Reinicie o anfitrião.
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çãopermitted_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
- Para mais informações sobre como trabalhar com políticas criptográficas RHEL, consulte Utilizando políticas criptográficas de todo o sistema no guia Security Hardening.
- Para mais informações sobre agentes de confiança da IdM e controladores de confiança, consulte Controladores de confiança e agentes de confiança no guia de Gerenciamento de Identidade de Planejamento.
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ço | Porto | Protocolo |
---|---|---|
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 |
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.
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.
O console web RHEL, que é uma IU com configurações de firewall baseadas em firewalld.
Para detalhes sobre a configuração do firewall através do console web, veja Habilitação de serviços no firewall usando o console web.
NotaO serviço
FreeIPA Trust Setup
atualmente inclui uma gama de portas RPC de1024-1300
, mas esta gama foi atualizada para49152-65535
no Windows Server 2008 e posteriormente. A definição do serviço de firewallFreeIPA Trust Setup
será atualizada, e esta edição é rastreada no Bug 1850418 - atualização da definição freeipa-trust.xml para incluir a faixa dinâmica correta do RPC.Até que esse bug tenha sido resolvido, abra manualmente a faixa de portas TCP
49152-65535
, além de habilitar o serviçoFreeIPA Trust Setup
no console web RHEL.
Tabela 25.2. Portos exigidos pelos servidores da IdM em um trust
Serviço | Porto | Protocolo |
---|---|---|
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ço | Porto | Protocolo |
---|---|---|
Kerberos | 88 | UDP e TCP |
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
- Para mais informações sobre a faixa de portas dinâmicas RPC no Windows Server 2008 e posteriores, consulte A faixa de portas dinâmicas padrão para TCP/IP mudou desde o Windows Vista e no Windows Server 2008.
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 eidm.example.com
para IdM -
example.com
para AD eidm.example.com
para IdM -
ad.example.com
para AD eexample.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 eidm.example.com
para a IdM, os nomes do reino Kerberos devem serAD.EXAMPLE.COM
eIDM.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
- Entrar na IDM Web UI com privilégios de administrador. Para detalhes, veja Acessando a IDM Web UI em um navegador da web.
- Clique na guia Network Services.
- Clique na guia DNS.
No menu suspenso, clique no item DNS Forward Zones.
- Clique no botão Add.
- Na caixa de diálogo Add DNS forward zone, adicione um nome de zona.
- No item Zone forwarders, clique no botão Add.
- No campo Zone forwarders, adicione o endereço IP do servidor para o qual você deseja criar a nova zona de encaminhamento.
Clique no botão Add.
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
A interface Web pode exibir um aviso sobre falha de validação DNSSEC após adicionar uma nova zona de avanço à configuração.
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
- Faça o login no Windows Server.
- Abrir Server Manager.
- Abrir DNS Manager.
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
- 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
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.
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:
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.
-
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.
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
- DNS configurado corretamente. Ambos os servidores IdM e AD devem ser capazes de resolver os nomes um do outro. Para detalhes, consulte Configurando o DNS e as configurações do reino para uma confiança.
- Tendo suportado versões de AD e IdM implantadas. Para detalhes, consulte Versões suportadas do Windows Server.
- Obtenção de um bilhete Kerberos. Para obter detalhes, consulte Utilizando parentes para fazer o login na IdM manualmente.
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
Instalar os pacotes necessários:
[root@ipaserver ~]#
yum install ipa-server ipa-server-trust-ad samba-client
Autenticar como usuário administrativo da IdM:
[root@ipaserver ~]#
kinit admin
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.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
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
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]:
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.
(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 para55000-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
Certifique-se de que o DNS esteja devidamente configurado, conforme descrito em Verificação da configuração do DNS para uma confiança.
ImportanteToda 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 executaripa-adtrust-install
, especialmente se o IdM ou AD não utilizarem servidores DNS integrados.Reinicie o serviço
ipa
:[root@ipaserver ~]#
ipactl restart
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
-
Para criar a confiança nos dois sentidos, adicione a seguinte opção ao comando
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
-
Para criar a confiança externa, adicione a seguinte opção ao comando
Nesta seção, os passos abaixo mostram como criar um acordo de confiança unidirecional.
Pré-requisitos
- Nome de usuário e senha de um administrador Windows.
- Você preparou o servidor IdM para a confiança.
Procedimento
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
- Entrar na IDM Web UI com privilégios de administrador. Para detalhes, veja Acessando a IDM Web UI em um navegador da web.
- Na interface web da IdM, clique na aba IPA Server.
- Na aba IPA Server, clique na aba Trusts.
No menu suspenso, selecione a opção Trusts.
- Clique no botão Add.
- Na caixa de diálogo Add Trust, digite o nome do domínio do Active Directory.
Nos campos Account e Password, adicione as credenciais do administrador do Active Directory.
- [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.
- [Opcional] Se seus domínios estão em florestas diferentes, selecione External trust.
- 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.
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
Solicite um ticket para um usuário do Active Directory (AD):
[root@ipaserver ~]# kinit user@AD.EXAMPLE.COM
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
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 seipa-adtrust-install
não tiver sido executado em nenhum servidor IdM, o que é normalmente antes de estabelecer a primeira relação de confiança.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
No servidor AD, configure o utilitário
nslookup.exe
para consultar os registros de serviço.C:\>nslookup.exe > set type=SRV
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
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"
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 sobreipa-adtrust-install
, veja Preparando o servidor IdM para a confiança. Note que a saída está vazia seipa-adtrust-install
não tiver sido executado em nenhum servidor IdM, o que é normalmente antes de estabelecer a primeira relação de confiança.Verificar se os serviços AD são resolvidos a partir do servidor AD.
C:\>nslookup.exe > set type=SRV
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
- Você obteve um bilhete Kerberos. Para obter detalhes, consulte Login no IdM na Web UI: Usando um bilhete Kerberos.
Procedimento
- Entrar na IDM Web UI com privilégios de administrador. Para detalhes, veja Acessando a IDM Web UI em um navegador da web.
- Na interface web da IdM, clique na aba IPA Server.
- Na aba IPA Server, clique na aba Trusts.
Selecione a confiança que você deseja remover.
- Clique no botão Delete.
Na caixa de diálogo Remove trusts, clique em Delete.
Se a confiança for excluída com sucesso, a interface de usuário da Web exibirá um pop-up verde com o texto:
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.
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:
- 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.
- 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.
- 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.
- 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.
- 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
.
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
:
- Atualize o sistema para a última versão RHEL 7.
Atualize o ipa-* pacotes para sua versão mais recente:
[root@rhel7 ~]# yum atualização ipa-*
AtençãoWhen 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
:
-
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. -
Garantir que o sistema
rhel8.example.com
utilize um servidor de tempo sincronizado comrhel7.example.com
. Isto é importante porque no RHEL 8, IdM não fornece seu próprio servidor de tempo: a instalação de IdM emrhel8.example.com
não resulta na instalação de um servidor NTP no host. -
Garantir que o sistema
rhel8.example.com
faça parte do domínio para o qualrhel7.example.com
é autoritário. 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 manualyum(8)
.
26.2. Instalando a réplica do RHEL 8
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 ...]
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 seurhel7.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 comandoipa-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 IdMNotaAlé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 comandoipa-replica-install
para configurar a capacidade de confiança do AD emrhel8.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.-
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
Verifique se
rhel7.example.com
erhel8.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: masterOpcionalmente, para exibir detalhes sobre o acordo de replicação entre
rhel7.example.com
erhel8.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
-
Opcionalmente, adicione um registro do serviço
_ntp._udp
(SRV) para o servidor de tempoNTP
ao DNS do servidor IdM recém-instalado,rhel8.example.com
. A presença do registro SRV para o servidor de temporhel8.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
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
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
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
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
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
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
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
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
Certifique-se de que todos os dados, incluindo as últimas mudanças, tenham sido migrados corretamente de
rhel7.example.com
pararhel8.example.com
. Por exemplo:Adicione um novo usuário em
rhel7.example.com
:[root@rhel7 ~]# ipa user-add random_user First name: random Last name: user
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
Pare todos os serviços da IdM em
rhel7.example.com
para forçar a descoberta de domínio para o novo servidorrhel8.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).- 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.
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.
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 manualyum(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
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 provedorfiles
possa acessar esses usuários e grupos.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
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
-
Abra o arquivo de configuração
/etc/sssd/sssd.conf
em um editor de texto. Substituir
id_provider=local
porid_provider=files
.[domain/example.com] id_provider = files ...
-
Salve o arquivo de configuração
/etc/sssd/sssd.conf
. 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
-
Abra o arquivo de configuração
/etc/sssd/sssd.conf
em um editor de texto. -
Remover quaisquer ocorrências das opções
ldap_groups_use_matching_rule_in_chain
ouldap_initgroups_use_matching_rule_in_chain
. -
Salve o arquivo de configuração
/etc/sssd/sssd.conf
. 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
.
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
-
Abra o arquivo de configuração
/etc/sssd/sssd.conf
em um editor de texto. No domínio
example.com
, definirldap_sudo_include_regexp=true
.[domain/example.com] ... ldap_sudo_include_regexp = true ...
-
Salve o arquivo de configuração
/etc/sssd/sssd.conf
. 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 comid_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ãofalse
-
Na RHEL 7, esta opção foi configurada para
true
por padrão. Se esta opção for definida paratrue
, o SSSD baixa cada regrasudo
que contém um wildcard no atributosudoHost
, 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
- Para mais detalhes sobre atualização para RHEL 8, consulte Atualização de RHEL 7 para RHEL 8.