Red Hat Training

A Red Hat training course is available for RHEL 8

Configuração e gerenciamento da Gestão de Identidade

Red Hat Enterprise Linux 8

Configuração, gerenciamento e manutenção do Gerenciamento de Identidade no Red Hat Enterprise Linux 8

Resumo

Esta coleção de documentação fornece instruções sobre como efetivamente configurar, gerenciar e manter o Gerenciamento de Identidade no Red Hat Enterprise Linux 8.

Tornando o código aberto mais inclusivo

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

Fornecendo feedback sobre a documentação da Red Hat

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

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

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

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

Capítulo 1. Login para Gerenciamento de Identidade a partir da linha de comando

A Gestão de Identidade (IdM) usa o protocolo Kerberos para suportar o sign-on único. Single sign-on significa que o usuário digita o nome de usuário e senha corretos apenas uma vez, e então acessa os serviços da IdM sem que o sistema solicite novamente as credenciais.

Importante

Na IdM, o System Security Services Daemon (SSSD) obtém automaticamente um ticket-granting ticket (TGT) para um usuário depois que o usuário faz o login com sucesso no ambiente de trabalho em uma máquina cliente IdM com o nome principal correspondente Kerberos. Isto significa que após o login, o usuário não é obrigado a usar o utilitário kinit para acessar os recursos da IdM.

Se você tiver liberado seu cache de credenciais Kerberos ou se seu Kerberos TGT tiver expirado, você precisa solicitar um bilhete Kerberos manualmente para acessar os recursos da IdM. As seções seguintes apresentam operações básicas do usuário ao usar o Kerberos no IdM.

1.1. Usando kinit para fazer o log in manualmente no IdM

Este procedimento descreve o uso do utilitário kinit para autenticar manualmente para um ambiente de Gerenciamento de Identidade (IdM). O utilitário kinit obtém e armazena um bilhete de passagem Kerberos (TGT) em nome de um usuário IdM.

Nota

Use este procedimento somente se você tiver destruído seu Kerberos TGT inicial ou se ele tiver expirado. Como um usuário IdM, ao entrar em sua máquina local, você também estará automaticamente entrando na IdM. Isto significa que, após o login, você não é obrigado a usar o utilitário kinit para acessar os recursos da IdM.

Procedimento

  1. Para fazer login na IdM

    • sob o nome do usuário que está atualmente logado no sistema local, use kinit sem especificar um nome de usuário. Por exemplo, se você estiver logado como example_user no sistema local:

      [example_user@server ~]$ kinit
      Password for example_user@EXAMPLE.COM:
      [example_user@server ~]$

      Se o nome do usuário local não corresponder a nenhuma entrada de usuário no IdM, a tentativa de autenticação falha:

      [example_user@server ~]$ kinit
      kinit: Client 'example_user@EXAMPLE.COM' not found in Kerberos database while getting initial credentials
    • usando um Kerberos principal que não corresponde ao seu nome de usuário local, passe o nome de usuário requerido para o utilitário kinit. Por exemplo, para fazer o login como usuário admin:

      [example_user@server ~]$ kinit admin
      Password for admin@EXAMPLE.COM:
      [example_user@server ~]$
  2. Opcionalmente, para verificar se o login foi bem sucedido, use o utilitário klist para exibir o TGT em cache. No exemplo a seguir, o cache contém um ticket para o principal example_user, o que significa que neste host em particular, apenas example_user está atualmente autorizado a acessar os serviços da IdM:

    $ klist
    Ticket cache: KEYRING:persistent:0:0
    Default principal: example_user@EXAMPLE.COM
    
    Valid starting     	Expires            	Service principal
    11/10/2019 08:35:45  	11/10/2019 18:35:45  	krbtgt/EXAMPLE.COM@EXAMPLE.COM

1.2. Destruir o bilhete Kerberos ativo de um usuário

Esta seção descreve como limpar o cache de credenciais que contém o bilhete Kerberos ativo do usuário.

Procedimento

  1. Para destruir seu bilhete Kerberos:

    [exemplo_utilizador@servidor ~]$ kdestroy
  2. Opcionalmente, para verificar se o bilhete do Kerberos foi destruído:

    [example_user@server ~]$ klist
    klist: Credentials cache keyring 'persistent:0:0' not found

1.3. Configuração de um sistema externo para autenticação Kerberos

Esta seção descreve como configurar um sistema externo para que os usuários do Gerenciamento de Identidade (IdM) possam fazer login no IdM a partir do sistema externo usando suas credenciais Kerberos.

Habilitar a autenticação Kerberos em sistemas externos é especialmente útil quando sua infra-estrutura inclui múltiplos reinos ou domínios sobrepostos. Também é útil se o sistema não tiver sido registrado em nenhum domínio IdM através de ipa-client-install.

Para permitir a autenticação Kerberos ao IdM a partir de um sistema que não seja membro do domínio IdM, defina um arquivo de configuração Kerberos específico do IdM no sistema externo.

Pré-requisitos

  • O pacote krb5-workstation está instalado no sistema externo.

    Para descobrir se o pacote está instalado, use o seguinte comando CLI:

    # yum list installed krb5-workstation
    Installed Packages
    krb5-workstation.x86_64    1.16.1-19.el8     @BaseOS

Procedimento

  1. Copie o arquivo /etc/krb5.conf do servidor da IdM para o sistema externo. Por exemplo:

    # scp /etc/krb5.conf root@externalsystem.example.com:/etc/krb5_ipa.conf
    Atenção

    Não sobrescreva o arquivo krb5.conf existente no sistema externo.

  2. No sistema externo, configure a sessão terminal para usar o arquivo de configuração copiado da IdM Kerberos:

    $ export KRB5_CONFIG=/etc/krb5_ipa.conf

    A variável KRB5_CONFIG existe apenas temporariamente até que você termine a sessão. Para evitar esta perda, exporte a variável com um nome de arquivo diferente.

  3. Copie os trechos de configuração Kerberos do diretório /etc/krb5.conf.d/ para o sistema externo.

Os usuários do sistema externo podem agora usar o utilitário kinit para se autenticar contra o servidor IdM.

Recursos adicionais

  • Para obter detalhes sobre Kerberos, consulte as páginas man krb5.conf(5), kinit(1), klist(1), e kdestroy(1).

Capítulo 2. Visualização, início e parada dos serviços de Gerenciamento de Identidade

Os servidores de Gerenciamento de Identidade (IdM) são sistemas Red Hat Enterprise Linux que funcionam como controladores de domínio (DCs). Vários serviços diferentes estão rodando nos servidores IdM, mais notadamente o Directory Server, Certificate Authority (CA), DNS e Kerberos.

2.1. Os serviços da IdM

2.1.1. Lista de serviços hospedados por servidores da IdM

A maioria dos serviços a seguir não é estritamente necessária para ser instalada no servidor da IdM. Por exemplo, você pode instalar serviços como uma autoridade de certificado (CA) ou servidor DNS em um servidor externo fora do domínio da IdM.

Kerberos
os serviços krb5kdc e kadmin

A IdM usa o protocolo Kerberos para apoiar o single sign-on. Com Kerberos, os usuários só precisam apresentar o nome de usuário e senha corretos uma única vez e podem acessar os serviços da IdM sem que o sistema solicite novamente as credenciais.

Kerberos está dividido em duas partes:

  • O serviço krb5kdc é o serviço Kerberos Authentication e o daemon do Centro de Distribuição de Chaves (KDC).
  • O serviço kadmin é o programa de administração do banco de dados Kerberos.

Para informações sobre como autenticar usando Kerberos no IdM, veja Login para Gerenciamento de Identidade a partir da linha de comando e Login para IdM na interface Web: Usando um bilhete Kerberos.

Servidor de diretório LDAP
o serviço dirsrv

A instância IdM LDAP directory server armazena todas as informações IdM, tais como informações relacionadas a Kerberos, contas de usuários, entradas de host, serviços, políticas, DNS e outros. A instância do servidor de diretório LDAP é baseada na mesma tecnologia do Red Hat Directory Server. Entretanto, ela está sintonizada com tarefas específicas do IdM.

Autoridade Certificadora
o serviço pki-tomcatd

O certificate authority (CA) integrado é baseado na mesma tecnologia do Sistema de Certificado da Red Hat. pki é a Interface da Linha de Comando para acesso aos serviços do Sistema de Certificado.

Você também pode instalar o servidor sem a CA integrada se você criar e fornecer todos os certificados exigidos independentemente.

Para mais informações, consulte Planejando seus serviços de CA.

Sistema de nomes de domínio (DNS)
o serviço named

IdM usa DNS para a descoberta dinâmica de serviços. O utilitário de instalação do cliente IdM pode usar informações do DNS para configurar automaticamente a máquina cliente. Após o cliente estar registrado no domínio IdM, ele usa o DNS para localizar servidores e serviços IdM dentro do domínio. A implementação BIND (Berkeley Internet Name Domain) dos protocolos DNS (Domain Name System) no Red Hat Enterprise Linux inclui o servidor DNS named. named-pkcs11 é uma versão do servidor DNS BIND construída com suporte nativo para o padrão criptográfico PKCS#11.

Para informações, consulte Planejamento de seus serviços DNS e nomes de host.

Servidor HTTP Apache
o serviço httpd

O Apache HTTP web server fornece a interface Web da IdM, e também gerencia a comunicação entre a Autoridade Certificadora e outros serviços da IdM.

Samba / Winbind
smb e winbind serviços

Samba implementa o protocolo Server Message Block (SMB), também conhecido como o protocolo Common Internet File System (CIFS), no Red Hat Enterprise Linux. Através do serviço smb, o protocolo SMB permite o acesso a recursos em um servidor, como compartilhamento de arquivos e impressoras compartilhadas. Se você configurou um Trust com um ambiente Active Directory (AD), o serviço`Winbind` gerencia a comunicação entre os servidores IdM e os servidores AD.

Autenticação por senha única (OTP)
os serviços ipa-otpd

Senhas únicas (OTP) são senhas que são geradas por um token de autenticação para apenas uma sessão, como parte da autenticação de dois fatores. A autenticação OTP é implementada no Red Hat Enterprise Linux através do serviço ipa-otpd.

Para mais informações, consulte Login na Interface Web de Gerenciamento de Identidade usando senhas de uso único.

OpenDNSSEC
o serviço ipa-dnskeysyncd

OpenDNSSEC é um gerenciador de DNS que automatiza o processo de acompanhamento das extensões de segurança DNS (DNSSEC) e a assinatura de zonas. O serviço ipa-dnskeysyncd gerencia a sincronização entre o Servidor de Diretório IdM e o OpenDNSSEC.

The Identity Management Server: Unifying Services

2.1.2. Lista de serviços hospedados por clientes da IdM

  • System Security Services Daemon: o serviço sssd

O System Security Services Daemon (SSSD) é o aplicativo do lado do cliente que gerencia as credenciais de autenticação e cache de usuários. O cache permite que o sistema local continue as operações normais de autenticação se o servidor IdM ficar indisponível ou se o cliente ficar offline.

Para mais informações, consulte Entendendo o SSSD e seus benefícios.

  • Certmonger: o serviço certmonger

O serviço certmonger monitora e renova os certificados do cliente. Ele pode solicitar novos certificados para os serviços no sistema.

Para mais informações, consulte Obtenção de um certificado IdM para um serviço utilizando o certmonger.

Interactions Between IdM Services

2.2. Visualizando o status dos serviços da IdM

Para visualizar o status dos serviços IdM configurados em seu servidor IdM, execute o comando ipactl status:

[root@server ~]# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
pki-tomcatd Service: RUNNING
smb Service: RUNNING
winbind Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful

A saída do comando ipactl status em seu servidor depende de sua configuração de IdM. Por exemplo, se uma implantação do IdM não inclui um servidor DNS, o serviço named não está presente na lista.

Nota

Você não pode usar a IDM web UI para visualizar o status de todos os serviços da IdM rodando em um servidor IdM em particular. Serviços kerberizados rodando em diferentes servidores podem ser visualizados na aba IdentityServices da IDM web UI.

Você pode iniciar ou parar o servidor inteiro, ou apenas um serviço individual.

Para iniciar, parar, ou reiniciar todo o servidor IdM, veja:

Para iniciar, parar ou reiniciar um serviço individual de IdM, veja:

Para exibir a versão do software IdM, veja:

2.3. Iniciando e parando todo o servidor de Gerenciamento de Identidade: o utilitário ipactl

Use o utilitário ipactl para parar, iniciar ou reiniciar todo o servidor IdM junto com todos os serviços instalados. Usar o utilitário ipactl garante que todos os serviços sejam parados, iniciados ou reiniciados na ordem apropriada. Você não precisa ter um bilhete Kerberos válido para executar os comandos ipactl.

ipactl comandos

Para iniciar todo o servidor IdM:

# ipactl start

Para parar todo o servidor IdM:

# ipactl stop

Para reiniciar todo o servidor IdM:

# ipactl restart

Para mostrar o status de todos os serviços que compõem a IdM:

# ipactl status
Importante

Você não pode usar a interface web do IdM para executar os comandos do ipactl.

2.4. Início e parada de um serviço de Gerenciamento de Identidade individual: o utilitário systemctl

A alteração manual dos arquivos de configuração do IdM geralmente não é recomendada. Entretanto, certas situações exigem que um administrador realize uma configuração manual de serviços específicos. Em tais situações, use o utilitário systemctl para parar, iniciar ou reiniciar um serviço individual da IdM.

Por exemplo, use systemctl após personalizar o comportamento do Servidor de Diretório, sem modificar os outros serviços da IdM:

# systemctl restart dirsrv@REALM-NAME.service

Além disso, ao implantar inicialmente uma confiança IdM com o Active Directory, modifique o arquivo /etc/sssd/sssd.conf, adicionando:

  • parâmetros específicos para afinar as opções de configuração de timeout em um ambiente onde os servidores remotos têm uma alta latência
  • parâmetros específicos para afinar a afinidade com o site do Active Directory
  • anulações para certas opções de configuração que não são fornecidas pelas configurações globais da IdM

Para aplicar as mudanças que você fez no arquivo /etc/sssd/sssd.conf:

# systemctl restart sssd.service

A execução do systemctl restart sssd.service é necessária porque o Daemon System Security Services (SSSD) não relê ou re-aplica automaticamente sua configuração.

Observe que para mudanças que afetam as faixas de identidade da IdM, recomenda-se uma reinicialização completa do servidor.

Importante

Para reiniciar vários serviços de domínio IdM, use sempre ipactl. Devido às dependências entre os serviços instalados com o servidor IdM, a ordem na qual eles são iniciados e parados é crítica. O utilitário ipactl garante que os serviços sejam iniciados e parados na ordem apropriada.

Comandos úteis systemctl

Para iniciar um determinado serviço IdM:

# systemctl start name.service

Para parar um determinado serviço IdM:

# systemctl stop name.service

Para reiniciar um determinado serviço IdM:

# systemctl restart name.service

Para ver o status de um determinado serviço IdM:

# systemctl status name.service
Importante

Você não pode usar a interface web do IdM para iniciar ou parar os serviços individuais executados nos servidores IdM. Você só pode usar a interface web para modificar as configurações de um serviço Kerberized navegando para IdentityServices e selecionando o serviço.

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

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

  • a IdM WebUI
  • ipa comandos
  • rpm comandos

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

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

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

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

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

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

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

Capítulo 3. Introdução às utilidades da linha de comando IdM

As seções seguintes descrevem o básico do uso das utilidades da linha de comando de Gerenciamento de Identidade (IdM).

Pré-requisitos

3.1. O que é a interface de linha de comando IPA

A interface de linha de comando IPA (CLI) é a interface básica de linha de comando para a administração do Gerenciamento de Identidade (IdM).

Ele suporta muitos subcomandos que são usados para gerenciar o IdM, como o comando ipa user-add para adicionar um novo usuário.

O IPA CLI permite que você o faça:

  • Adicionar, gerenciar ou remover usuários, grupos, hosts e outros objetos da rede.
  • Gerenciar certificados.
  • Pesquisar entradas.
  • Exibir e listar objetos.
  • Estabelecer direitos de acesso.
  • Obtenha ajuda com a sintaxe de comando correta.

3.2. O que é a ajuda do IPA

A ajuda do IPA é um sistema de documentação embutido para o servidor IdM.

A interface de linha de comando IPA (CLI) gera tópicos de ajuda disponíveis a partir de módulos plug-in IdM carregados. Se você quiser executar a ajuda IPA com sucesso, você precisa fazê-lo:

  • Ter um servidor IdM instalado e funcionando.
  • Ser autenticado com um bilhete Kerberos válido.

A execução do comando ipa help sem opções exibe informações sobre o uso básico da ajuda e os exemplos de comando mais comuns.

A execução de ajuda com opções tem a seguinte sintaxe:

$ ipa help [TOPIC | COMMAND | topics | commands]
  • [] - Brackets significa que todos os parâmetros são opcionais e você pode escrever apenas ipa help e o comando será executado.
  • | -_ The caractere do tubo significa or. Portanto, você pode usar TOPIC ou COMMAND ou tópicos ou comandos com o comando básico ipa help.
  • topics - You pode executar o comando ipa help topics e ele será executado corretamente. O comando exibe uma lista de tópicos que são cobertos pela ajuda do IPA, por exemplo, user, cert, server e muitos outros.
  • TOPIC - The TOPIC com letras maiúsculas significa variável, portanto, você pode usar o tópico específico, por exemplo, ipa help user
  • commands - You pode executar o comando ipa help commands e ele será executado corretamente. O comando exibe uma lista de comandos que são cobertos pela ajuda do IPA, por exemplo, user-add, ca-enable, server-show e muitos outros.
  • COMMAND - The COMMAND com letras maiúsculas significa variável, portanto, você pode usar o comando particular, por exemplo, ipa help user-add

3.3. Usando tópicos de ajuda IPA

O seguinte procedimento ajuda a entender o uso da ajuda IPA na interface da linha de comando.

Procedimento

  1. Abra o terminal e conecte-se ao servidor IdM.
  2. Digite ipa help topics para exibir uma lista de tópicos cobertos pela ajuda.

    $ ipa help topics
  3. Selecione um dos tópicos e crie um comando de acordo com o seguinte padrão: ipa help [topic_name], em vez da string topic_name, adicione um dos tópicos listados na etapa anterior.

    No exemplo, utilizamos o seguinte tópico user

    $ ipa help user
  4. Se o comando de ajuda IPA for muito longo e você não puder ver o texto inteiro, use a seguinte sintaxe:

    $ ipa help user | less

    Você pode então rolar para baixo e ler toda a ajuda.

O IPA CLI exibe uma página de ajuda para o tópico user. Depois de ler a visão geral, você pode ver muitos exemplos com padrões para trabalhar com comandos tópicos.

3.4. Usando os comandos de ajuda IPA

O procedimento a seguir ajuda a entender a criação dos comandos de ajuda IPA na interface da linha de comando.

Procedimento

  1. Abra o terminal e conecte-se ao servidor IdM.
  2. Digite ipa help commands para exibir uma lista de comandos cobertos pela ajuda.

    $ ipa help commands
  3. Selecione um dos comandos e crie um comando de ajuda de acordo com o seguinte padrão: ipa help <COMMAND>, em vez da string <COMMAND>, adicione um dos comandos listados no passo anterior.

    $ ipa help user-add

Recursos adicionais

  • Para detalhes, consulte a página man ipa.

3.5. Estrutura dos comandos IPA

O IPA CLI distingue os seguintes tipos de comandos:

  • Os comandos embutidos commands - Built-in estão todos disponíveis no servidor da IdM.
  • Comandos fornecidos pelo plug-in

A estrutura dos comandos IPA permite gerenciar vários tipos de objetos. Por exemplo:

  • Usuários,
  • Anfitriões,
  • Registros DNS,
  • Certificados,

e muitos outros.

Para a maioria destes objetos, o IPA CLI inclui comandos para:

  • Adicionar (add)
  • Modificar (mod)
  • Excluir (del)
  • Busca (find)
  • Mostrar (show)

Os comandos têm a seguinte estrutura:

ipa user-add, ipa user-mod, ipa user-del, ipa user-find, ipa user-show

ipa host-add, ipa host-mod, ipa host-del, ipa host-find, ipa host-show

ipa dnsrecord-add, ipa dnsrecord-mod, ipa dnsrecord-del, ipa dnsrecord-find, ipa dnrecord-show

Você pode criar um usuário com o ipa user-add [options], onde [options] é opcional. Se você usar apenas o comando ipa user-add, o script lhe pede detalhes um a um.

Para modificar um objeto existente, você precisa definir o objeto, portanto o comando inclui também o objeto: ipa user-mod USER_NAME [options].

3.6. Usando um comando IPA para adicionar uma conta de usuário à IdM

O seguinte descreve a adição de um novo usuário ao banco de dados do Gerenciamento de Identidade (IdM) usando linha de comando.

Pré-requisitos

  • Você precisa ter privilégios de administrador para adicionar contas de usuário ao servidor da IdM.

Procedimento

  1. Abra o terminal e conecte-se ao servidor IdM.
  2. Digite o comando para adicionar um novo usuário:

    $ ipa user-add

    O comando executa um script onde você pode adicionar dados básicos necessários para a criação de uma conta de usuário.

  3. No campo First name:, digite o primeiro nome do novo usuário e pressione a tecla Enter.
  4. No campo Last name:, digite o sobrenome do novo usuário e pressione a tecla Enter.
  5. No site User login [suggested user name]: digite o nome do usuário ou simplesmente pressione a tecla Enter se o nome de usuário sugerido funcionar para você.

    O nome do usuário deve ser único para todo o banco de dados da IdM. Se ocorrer um erro, de que o usuário já existe, você precisa começar do início com o comando ipa user-add e tentar um nome de usuário diferente.

Após adicionar o nome do usuário com sucesso, a conta do usuário foi adicionada ao banco de dados do IdM e a interface de linha de comando IPA (CLI) imprime na saída o seguinte log:

----------------------
Added user "euser"
----------------------
User login: euser
First name: Example
Last name: User
Full name: Example User
Display name: Example User
Initials: EU
Home directory: /home/euser
GECOS: Example User
Login shell: /bin/sh
Principal name: euser@IDM.EXAMPLE.COM
Principal alias: euser@IDM.EXAMPLE.COM
Email address: euser@idm.example.com
UID: 427200006
GID: 427200006
Password: False
Member of groups: ipausers
Kerberos keys available: False

Como você pode ver, uma senha de usuário não é definida para a conta de usuário. Se você quiser adicionar também uma senha, use o comando ipa user-add na seguinte sintaxe:

$ ipa user-add --first=Example --last=User --password

O IPA CLI então lhe pede para adicionar ou confirmar um nome de usuário e senha.

Se o usuário já foi criado, você pode adicionar somente a senha com o comando `ipa user-mod'.

Recursos adicionais

Para maiores informações sobre parâmetros, digite o seguinte comando de ajuda para a linha de comando:

$ ipa help user-add

3.7. Usando um comando IPA para modificar uma conta de usuário no IdM

Você pode alterar muitos parâmetros para cada conta de usuário. Por exemplo, você pode adicionar uma nova senha para o usuário.

A sintaxe básica de comando é diferente da sintaxe user-add porque você precisa definir a conta de usuário existente para a qual você deseja realizar mudanças, por exemplo, adicionar uma senha.

Pré-requisitos

  • Você precisa ter privilégios de administrador para modificar as contas de usuário no servidor da IdM.

Procedimento

  1. Abra o terminal e conecte-se ao servidor IdM.
  2. Digite o comando para adicionar uma senha:

    $ ipa user-mod euser --password

    O comando executa um script onde você pode adicionar a nova senha.

  3. Digite a nova senha e pressione a tecla Enter.

Após adicionar o nome do usuário com sucesso, a conta do usuário foi adicionada ao banco de dados do IdM e o IPA CLI imprime na saída o seguinte log:

----------------------
Modified user "euser"
----------------------
User login: euser
First name: Example
Last name: User
Home directory: /home/euser
Principal name: euser@IDM.EXAMPLE.COM
Principal alias: euser@IDM.EXAMPLE.COM
Email address: euser@idm.example.com
UID: 427200006
GID: 427200006
Password: True
Member of groups: ipausers
Kerberos keys available: True

A senha do usuário está agora definida para a conta e o usuário pode fazer o login na IdM.

Recursos adicionais

Para maiores informações sobre parâmetros, digite o seguinte comando de ajuda para a linha de comando:

$ ipa help user-mod

3.8. Como fornecer uma lista de valores para as concessionárias da IdM

A Gestão de Identidade (IdM) armazena valores para atributos multivalorizados em listas.

IdM apóia os seguintes métodos de fornecimento de listas multivalorizadas:

  • Usando o mesmo argumento de linha de comando várias vezes dentro da mesma invocação de comando:

    $ ipa permission-add --right=read --permissions=write --permissions=delete ...
  • Alternativamente, você pode anexar a lista em braçadeiras encaracoladas, caso em que a concha realiza a expansão:

    $ ipa permission-add --right={read,write,delete} ...

Os exemplos acima mostram um comando permission-add o que acrescenta permissões a um objeto. O objeto não é mencionado no exemplo. Ao invés de …​ você precisa adicionar o objeto para o qual você deseja adicionar permissões.

Ao atualizar tais atributos multi-valorizados a partir da linha de comando, o IdM substitui completamente a lista de valores anterior por uma nova lista. Portanto, ao atualizar um atributo multivalorizado, você deve especificar toda a nova lista, e não apenas um único valor que você deseja adicionar.

No comando acima, a lista de permissões inclui leitura, escrita e exclusão. Quando você decide atualizar a lista com o comando permission-mod você deve acrescentar todos os valores, caso contrário os não mencionados serão excluídos.

Example 1: - The ipa permission-mod atualiza todas as permissões previamente adicionadas.

$ ipa permission-mod --right=read --right=write --right=delete ...

ou

$ ipa permission-mod --right={read,write,delete} ...

Example 2 - The ipa permission-mod elimina o comando --right=delete argumento porque não está incluído no comando:

$ ipa permission-mod --right=read --right=write ...

ou

$ ipa permission-mod --right={read,write} ...

3.9. Como usar caracteres especiais com as utilidades da IdM

Ao passar argumentos de linha de comando que incluem caracteres especiais para os comandos ipa, escape desses caracteres com uma barra invertida ({\i1}). Por exemplo, os caracteres especiais comuns incluem parênteses angulares (< e >), ampersand (&), asterisco (*), ou barra vertical (|).

Por exemplo, para escapar de um asterisco (*):

$ ipa certprofile-show certificate_profile --out=exported\*profile.cfg

Os comandos que contêm caracteres especiais não escalonados não funcionam como esperado, porque a casca não pode analisar adequadamente tais caracteres.

Capítulo 4. Buscando entradas de Gerenciamento de Identidade a partir da linha de comando

As seções seguintes descrevem como usar os comandos IPA, que o ajudam a encontrar ou mostrar objetos.

4.1. Visão geral da listagem de entradas da IdM

Esta seção descreve os comandos ipa *-find, que podem ajudá-lo a pesquisar um tipo particular de entradas de IdM.

Para listar todos os comandos find, use o seguinte comando ipa help:

$ ipa help commands | grep find

Talvez seja necessário verificar se um determinado usuário está incluído no banco de dados da IdM. Você pode então listar todos os usuários com o seguinte comando:

$ ipa user-find

Para listar os grupos de usuários cujos atributos especificados contêm uma palavra-chave:

$ ipa group-find keyword

Por exemplo, o ipa group-find admin lista todos os grupos cujos nomes ou descrições incluem cadeia admin:

----------------
3 groups matched
----------------
   Group name: admins
   Description: Account administrators group
   GID: 427200002

   Group name: editors
   Description: Limited admins who can edit other users
   GID: 427200002

   Group name: trust admins
   Description: Trusts administrators group

Ao pesquisar grupos de usuários, você também pode limitar os resultados da pesquisa a grupos que contenham um determinado usuário:

$ ipa group-find --user=user_name

Procurar grupos que não contenham um determinado usuário:

$ ipa group-find --no-user=user_name

4.2. Mostrar detalhes para uma determinada entrada

Use o comando ipa *-show para exibir detalhes sobre uma determinada entrada do IdM.

Procedimento

  • Para exibir detalhes sobre um anfitrião chamado server.example.com:

    $ ipa host-show server.example.com
    
    Host name: server.example.com
    Principal name: host/server.example.com@EXAMPLE.COM
    ...

4.3. Ajustando o tamanho da busca e o limite de tempo

Algumas consultas, como solicitar uma lista de usuários da IdM, podem retornar um número muito grande de entradas. Ajustando estas operações de busca, você pode melhorar o desempenho geral do servidor ao executar os comandos ipa *-find, tais como ipa user-find, e ao exibir listas correspondentes na interface Web.

Limite de tamanho da busca

Define o número máximo de entradas retornadas para uma solicitação enviada ao servidor a partir da CLI de um cliente ou a partir de um navegador acessando a IDM Web UI.

Padrão: 100 entradas.

Tempo limite de busca

Define o tempo máximo (em segundos) que o servidor espera por buscas para executar. Uma vez que a busca atinge este limite, o servidor pára a busca e retorna as entradas descobertas nesse tempo.

Default: 2 segundos.

Se você definir os valores para -1, IdM não aplicará nenhum limite ao pesquisar.

Importante

A definição de tamanho de busca ou limites de tempo muito altos pode afetar negativamente o desempenho do servidor.

4.3.1. Ajuste do tamanho da busca e do limite de tempo na linha de comando

O texto a seguir descreve o ajuste do tamanho da busca e dos limites de tempo na linha de comando:

  • Globalmente
  • Para uma entrada específica

Procedimento

  1. Para exibir os limites atuais de tempo e tamanho de busca no CLI, use o comando ipa config-show:

    $ ipa config-show
    
    Search time limit: 2
    Search size limit: 100
  2. Para ajustar os limites globalmente para todas as consultas, use o comando ipa config-mod e adicione as opções --searchrecordslimit e --searchtimelimit. Por exemplo:

    $ ipa config-mod --searchrecordslimit=500 --searchtimelimit=5
  3. Para ajustar os limites apenas para uma consulta específica, adicione as opções --sizelimit ou --timelimit ao comando. Por exemplo:
$ ipa user-find --sizelimit=200 --timelimit=120

4.3.2. Ajustando o tamanho da busca e o limite de tempo na interface Web

O texto a seguir descreve o ajuste do tamanho da busca e dos limites de tempo na interface web da IdM:

  • Globalmente
  • Para uma entrada específica

Procedimento

Para ajustar os limites globalmente para todas as consultas:

  1. Faça o login na IDM Web UI.
  2. Clique em IPA Server.

    web ui ipaserver

  3. Na aba IPA Server, clique em Configuration.
  4. Defina os valores necessários na área Search Options.

    Os valores padrão são:

    • Limite de tamanho da busca: 100 entradas
    • Tempo limite de busca: 2 segundos
  5. Clique em Save na parte superior da página.

    limites da busca na web ui

Após salvar os valores, pesquise uma entrada e verifique o resultado.

Capítulo 5. Acesso à IDM Web UI em um navegador da web

As seções a seguir fornecem uma visão geral da interface web IdM (Identity Management) e descrevem como acessá-la.

5.1. O que é a IDM Web UI

A IDM (Identity Management) Web UI é uma aplicação web para administração da IdM, uma alternativa gráfica para as ferramentas de linha de comando da IdM.

Você pode acessar a IDM Web UI como:

  • IdM users: Um conjunto limitado de operações dependendo das permissões concedidas ao usuário no servidor da IdM. Basicamente, os usuários ativos do IdM podem entrar no servidor do IdM e configurar sua própria conta. Eles não podem alterar as configurações de outros usuários ou as configurações do servidor IdM.
  • Administrators: Direitos totais de acesso ao servidor IdM.
  • Active Directory users: Um conjunto de operações dependendo das permissões concedidas ao usuário. Os usuários do Active Directory agora podem ser administradores para Gerenciamento de Identidade. Para detalhes, consulte Habilitando usuários AD para administrar IdM.

5.2. Navegadores Web suportados para acesso à interface Web

IdM (Identity Management) suporta os seguintes navegadores para conexão com a Web UI:

  • Mozilla Firefox 38 e posteriores
  • Google Chrome 46 e posteriores

5.3. Acesso à Web UI

O procedimento a seguir descreve o primeiro log in na interface da Web IdM (Identity Management) com uma senha.

Após o primeiro login, você pode configurar seu servidor IdM para se autenticar com:

Procedimento

  1. Digite um URL de servidor IdM na barra de endereços do navegador. O nome será semelhante ao exemplo a seguir:

    https://server.example.com

    Você só precisa alterar server.example.com com um nome DNS de seu servidor IdM.

    Isto abre a tela de login da IDM Web UI em seu navegador.

    tela de login na web ui

    • Se o servidor não responder ou a tela de login não abrir, verifique as configurações do DNS no servidor IdM ao qual você está se conectando.
    • Se você usar um certificado autoassinado, o navegador emite um aviso. Verifique o certificado e aceite a exceção de segurança para proceder com o login.

      Para evitar exceções de segurança, instale um certificado assinado por uma autoridade certificadora.

  2. Na tela de login da Web UI, digite as credenciais de conta de administrador que você adicionou durante a instalação do servidor IdM.

    Para detalhes, consulte Instalação de um servidor de Gerenciamento de Identidade: Com DNS integrado, com uma CA integrada.

    Você pode inserir suas credenciais de conta pessoal também se elas já estiverem inseridas no servidor da IdM.

    senha de login da web ui

  3. Clique em Log in.

Após o login bem sucedido, você pode começar a configurar o servidor IdM.

usuários da web ui

Capítulo 6. Login no IdM na Web UI: Usando um bilhete Kerberos

As seções seguintes descrevem a configuração inicial de seu ambiente para permitir que Kerberos faça login na IDM Web UI e acesse a IdM usando a autenticação Kerberos.

Pré-requisitos

6.1. Autenticação Kerberos na Gestão da Identidade

A Gestão de Identidade (IdM) utiliza o protocolo Kerberos para apoiar o sign-on único. A autenticação single sign-on permite que você forneça o nome de usuário e a senha corretos apenas uma vez, e você pode então acessar os serviços de Gerenciamento de Identidade sem que o sistema solicite novamente credenciais.

O servidor IdM fornece autenticação Kerberos imediatamente após a instalação, se as configurações do DNS e do certificado tiverem sido configuradas corretamente. Para detalhes, consulte Instalando o Gerenciamento de Identidade.

Para usar a autenticação Kerberos em hosts, instale:

6.2. Usando kinit para fazer o log in manualmente no IdM

Este procedimento descreve o uso do utilitário kinit para autenticar manualmente para um ambiente de Gerenciamento de Identidade (IdM). O utilitário kinit obtém e armazena um bilhete de passagem Kerberos (TGT) em nome de um usuário IdM.

Nota

Use este procedimento somente se você tiver destruído seu Kerberos TGT inicial ou se ele tiver expirado. Como um usuário IdM, ao entrar em sua máquina local, você também estará automaticamente entrando na IdM. Isto significa que, após o login, você não é obrigado a usar o utilitário kinit para acessar os recursos da IdM.

Procedimento

  1. Para fazer login na IdM

    • sob o nome do usuário que está atualmente logado no sistema local, use kinit sem especificar um nome de usuário. Por exemplo, se você estiver logado como example_user no sistema local:

      [example_user@server ~]$ kinit
      Password for example_user@EXAMPLE.COM:
      [example_user@server ~]$

      Se o nome do usuário local não corresponder a nenhuma entrada de usuário no IdM, a tentativa de autenticação falha:

      [example_user@server ~]$ kinit
      kinit: Client 'example_user@EXAMPLE.COM' not found in Kerberos database while getting initial credentials
    • usando um Kerberos principal que não corresponde ao seu nome de usuário local, passe o nome de usuário requerido para o utilitário kinit. Por exemplo, para fazer o login como usuário admin:

      [example_user@server ~]$ kinit admin
      Password for admin@EXAMPLE.COM:
      [example_user@server ~]$
  2. Opcionalmente, para verificar se o login foi bem sucedido, use o utilitário klist para exibir o TGT em cache. No exemplo a seguir, o cache contém um ticket para o principal example_user, o que significa que neste host em particular, apenas example_user está atualmente autorizado a acessar os serviços da IdM:

    $ klist
    Ticket cache: KEYRING:persistent:0:0
    Default principal: example_user@EXAMPLE.COM
    
    Valid starting     	Expires            	Service principal
    11/10/2019 08:35:45  	11/10/2019 18:35:45  	krbtgt/EXAMPLE.COM@EXAMPLE.COM

6.3. Configurando o navegador para autenticação Kerberos

Para permitir a autenticação com um bilhete Kerberos, você pode precisar de uma configuração de navegador.

Os seguintes passos o ajudam a apoiar a negociação da Kerberos para acessar o domínio IdM.

Cada navegador suporta a Kerberos de uma maneira diferente e precisa de uma configuração diferente. A IDM Web UI inclui diretrizes para os seguintes navegadores:

  • Firefox
  • Cromado

Procedimento

  1. Abra o diálogo de login da IDM Web UI em seu navegador da web.
  2. Clique no link para configuração do navegador na tela de login da Web UI.

    link de configuração do navegador ipa

  3. Siga os passos na página de configuração.

    página de configuração do navegador ipa

Após a configuração, volte para a interface web da IdM e clique em Log in.

6.4. Entrar na interface web usando um bilhete Kerberos

Este procedimento descreve o log in na IDM Web UI usando um bilhete de passagem de Kerberos (TGT).

O TGT expira em um horário pré-definido. O intervalo de tempo padrão é de 24 horas e você pode alterá-lo na interface Web do IdM.

Após o intervalo de tempo expirar, você precisa renovar o bilhete:

  • Usando o comando kinit.
  • Usando as credenciais de login da IdM no diálogo de login da Web UI.

Procedimento

  • Abra a IDM Web UI.

    Se a autenticação Kerberos funcionar corretamente e você tiver um bilhete válido, você será automaticamente autenticado e a interface de usuário da Web será aberta.

    Se o bilhete expirar, é necessário autenticar-se primeiro com as credenciais. Entretanto, da próxima vez, a IDM Web UI abrirá automaticamente sem abrir o diálogo de login.

    Se você vir uma mensagem de erro Authentication with Kerberos failed, verifique se seu navegador está configurado para autenticação Kerberos. Veja Seção 6.3, “Configurando o navegador para autenticação Kerberos”.

    firefox kerb auth failed

6.5. Configuração de um sistema externo para autenticação Kerberos

Esta seção descreve como configurar um sistema externo para que os usuários do Gerenciamento de Identidade (IdM) possam fazer login no IdM a partir do sistema externo usando suas credenciais Kerberos.

Habilitar a autenticação Kerberos em sistemas externos é especialmente útil quando sua infra-estrutura inclui múltiplos reinos ou domínios sobrepostos. Também é útil se o sistema não tiver sido registrado em nenhum domínio IdM através de ipa-client-install.

Para permitir a autenticação Kerberos ao IdM a partir de um sistema que não seja membro do domínio IdM, defina um arquivo de configuração Kerberos específico do IdM no sistema externo.

Pré-requisitos

  • O pacote krb5-workstation está instalado no sistema externo.

    Para descobrir se o pacote está instalado, use o seguinte comando CLI:

    # yum list installed krb5-workstation
    Installed Packages
    krb5-workstation.x86_64    1.16.1-19.el8     @BaseOS

Procedimento

  1. Copie o arquivo /etc/krb5.conf do servidor da IdM para o sistema externo. Por exemplo:

    # scp /etc/krb5.conf root@externalsystem.example.com:/etc/krb5_ipa.conf
    Atenção

    Não sobrescreva o arquivo krb5.conf existente no sistema externo.

  2. No sistema externo, configure a sessão terminal para usar o arquivo de configuração copiado da IdM Kerberos:

    $ export KRB5_CONFIG=/etc/krb5_ipa.conf

    A variável KRB5_CONFIG existe apenas temporariamente até que você termine a sessão. Para evitar esta perda, exporte a variável com um nome de arquivo diferente.

  3. Copie os trechos de configuração Kerberos do diretório /etc/krb5.conf.d/ para o sistema externo.
  4. Configure o navegador no sistema externo, conforme descrito em Seção 6.3, “Configurando o navegador para autenticação Kerberos”.

Os usuários do sistema externo podem agora usar o utilitário kinit para se autenticar contra o servidor IdM.

6.6. Login de Usuário da Web UI para usuários do Active Directory

Para ativar o login da Web UI para usuários do Active Directory, defina uma substituição de ID para cada usuário do Active Directory na visualização padrão de confiança. Por exemplo:

[admin@server ~]$ ipa idoverrideuser-add 'Default Trust View' ad_user@ad.example.com

Capítulo 7. Login na Interface Web de Gerenciamento de Identidade usando senhas únicas

O acesso à IdM Web UI pode ser assegurado através de vários métodos. O método básico é a autenticação por senha.

Para aumentar a segurança da autenticação da senha, você pode adicionar uma segunda etapa e exigir senhas geradas automaticamente uma única vez (OTPs). O uso mais comum é combinar uma senha conectada com a conta do usuário e uma senha única limitada no tempo gerada por um token de hardware ou software.

As seções seguintes o ajudam:

  • Entenda como funciona a autenticação OTP na IdM.
  • Configurar a autenticação OTP no servidor da IdM.
  • Crie fichas OTP e sincronize-as com o aplicativo FreeOTP em seu telefone.
  • Autentique-se na IDM Web UI com a combinação de senha de usuário e senha única.
  • Re-sincronizar as fichas na interface Web.

7.1. Pré-requisitos

7.2. Autenticação de senha única (OTP) na Gestão de Identidade

As senhas únicas trazem um passo adicional à sua segurança de autenticação. A autenticação utiliza sua senha e uma senha única gerada automaticamente.

Para gerar senhas únicas, você pode usar um token de hardware ou software. IdM suporta tanto tokens de software como de hardware.

A Gestão de Identidade suporta os dois mecanismos OTP padrão a seguir:

  • O algoritmo One-Time Password (HOTP) baseado em HMAC é baseado em um contador. HMAC significa "Hashed Message Authentication Code" (Código de Autenticação de Mensagem Hachura).
  • O algoritmo de Senha Única Baseada no Tempo (TOTP) é uma extensão do HOTP para suportar o fator móvel baseado no tempo.
Importante

IdM não suporta logins OTP para usuários de confiança do Active Directory.

7.3. Habilitação da senha única na Web UI

A IDM Web UI permite configurar o dispositivo de hardware ou software para gerar senhas únicas.

A senha única é inserida logo após a senha usual no campo dedicado no diálogo de login.

Somente administradores podem habilitar a autenticação OTP nas configurações do usuário.

Pré-requisitos

  • Privilégios de administração

Procedimento

  1. Entre na IDM Web UI com seu nome de usuário e senha.
  2. Abra a aba Identity → Users → Active users.

    usuários da web ui

  3. Clique em seu nome de usuário para abrir as configurações do usuário.
  4. No site User authentication types, selecione Two factor authentication (password OTP).
  5. Clique em Save.

Neste ponto, a autenticação OTP está habilitada no servidor da IdM.

Agora você ou os próprios usuários precisam atribuir uma nova identificação simbólica para a conta de usuário.

7.4. Adicionando fichas OTP na Web UI

A seção seguinte ajuda você a adicionar token à IDM Web UI e ao seu gerador de token de software.

Pré-requisitos

  • Conta de usuário ativa no servidor da IdM.
  • O administrador habilitou o OTP para a conta de usuário em particular na interface web da IdM.
  • Um dispositivo de software que gera fichas OTP, por exemplo, FreeOTP.

Procedimento

  1. Entre na IDM Web UI com seu nome de usuário e senha.
  2. Para criar a ficha em seu telefone celular, abra a aba Authentication → OTP Tokens.
  3. Clique em Add.

    guia de fichas web ui

  4. Na caixa de diálogo Add OTP token, deixe tudo por preencher e clique em Add.

    Nesta etapa, o servidor IdM cria um token com parâmetros padrão no servidor e abre uma página com um código QR.

  5. Copie o código QR em seu telefone celular.
  6. Clique em OK para fechar o código QR.

Agora você pode gerar senhas únicas e fazer login com elas na IDM Web UI.

ficha de gratuidade

7.5. Entrar na Web UI com uma senha única

Este procedimento descreve o primeiro login na Interface Web do IdM usando uma senha única (OTP).

Pré-requisitos

  • Configuração OTP habilitada no servidor de Gerenciamento de Identidade para a conta de usuário que você está usando para a autenticação OTP. Tanto os administradores quanto os próprios usuários podem habilitar o OTP.

    Para habilitar a configuração do OTP, veja Seção 7.3, “Habilitação da senha única na Web UI”

  • Um dispositivo de hardware ou software que gera fichas OTP configuradas.

Procedimento

  1. Na tela de login do Gerenciamento de Identidade, digite seu nome de usuário ou um nome de usuário da conta do administrador do servidor IdM.
  2. Adicione a senha para o nome de usuário digitado acima.
  3. Gerar uma senha única em seu dispositivo.
  4. Digite a senha única logo após a senha (sem espaço).
  5. Clique em Log in.

    Se a autenticação falhar, sincronize os tokens OTP.

    Se sua AC usa um certificado autoassinado, o navegador emite um aviso. Verifique o certificado e aceite a exceção de segurança para proceder com o login.

    Se a IDM Web UI não abrir, verifique a configuração do DNS de seu servidor de Gerenciamento de Identidade.

Após o login bem sucedido, aparece a IDM Web UI.

usuários da web ui

7.6. Sincronização de fichas OTP usando a interface Web

Se o login com OTP (One Time Password) falhar, os tokens OTP não são sincronizados corretamente.

O texto seguinte descreve a re-sincronização simbólica.

Pré-requisitos

  • Uma tela de login foi aberta.
  • Um dispositivo gerador de fichas OTP configurado.

Procedimento

  1. Na tela de login da IDM Web UI, clique em Sync OTP Token.

    link otp para login na web ui

  2. Na tela de login, digite seu nome de usuário e a senha de Gerenciamento de Identidade.
  3. Gerar uma senha única e inseri-la no campo First OTP.
  4. Gerar outra senha de uma vez e inseri-la no campo Second OTP.
  5. Opcionalmente, digite a identificação simbólica.

    configuração de web ui login otp

  6. Clique em Sync OTP Token.

Após a sincronização bem sucedida, você pode entrar no servidor da IdM.

7.7. Mudança de senhas vencidas

Os administradores de Gerenciamento de Identidade podem fazer com que você tenha que mudar sua senha no próximo login. Isso significa que você não pode fazer o login com sucesso na IDM Web UI até que você mude a senha.

A expiração da senha pode acontecer durante seu primeiro login na Web UI.

Se o diálogo de senha de expiração aparecer, siga as instruções no procedimento.

Pré-requisitos

  • Uma tela de login foi aberta.
  • Conta ativa para o servidor da IdM.

Procedimento

  1. Na tela de login de expiração da senha, digite o nome do usuário.
  2. Adicione a senha para o nome de usuário digitado acima.
  3. No campo OTP, gere uma senha única, se você usar a autenticação da senha única.

    Se você não tiver ativado a autenticação OTP, deixe o campo vazio.

  4. Digite a nova senha duas vezes para verificação.
  5. Clique em Reset Password.

    expiração da senha de web ui

Após a mudança bem sucedida da senha, o diálogo habitual de login é exibido. Faça o login com a nova senha.

Capítulo 8. Configuração de configurações globais de IdM usando Livros de Jogadas Ansíveis

Usando o módulo Ansible config, você pode recuperar e definir parâmetros de configuração global para Gerenciamento de Identidade (IdM).

Este capítulo inclui as seguintes seções:

8.1. Recuperando a configuração do IdM usando um livro de jogo possível

O procedimento a seguir descreve como você pode usar um livro de exercícios possível para recuperar informações sobre a configuração atual do IdM global.

Pré-requisitos

  • Você sabe a senha do administrador da IdM.
  • Você instalou o pacote ansible-freeipa no controlador Ansible.

Procedimento

  1. Crie um arquivo de inventário, por exemplo inventory.file, e defina o servidor IdM a partir do qual você deseja recuperar a configuração do IdM na seção [ipaserver]. Por exemplo, para instruir a Ansible para recuperar os dados de server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  2. Abrir o arquivo /usr/share/doc/ansible-freeipa/playbooks/config/retrieve-config.yml Um possível arquivo de playbook para edição:

    ---
    - name: Playbook to handle global IdM configuration
      hosts: ipaserver
      become: no
      gather_facts: no
    
      tasks:
      - name: Query IPA global configuration
        ipaconfig:
          ipaadmin_password: Secret123
        register: serverconfig
    
      - debug:
          msg: "{{ serverconfig }}"
  3. Adapte o arquivo alterando o seguinte:

    • A senha do administrador da IdM.
    • Outros valores, se necessário.
  4. Salvar o arquivo.
  5. Execute a Pasta de reprodução possível especificando o arquivo da Pasta de reprodução e o arquivo do inventário:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/config/retrieve-config.yml
    [...]
    TASK [debug]
    ok: [server.idm.example.com] => {
        "msg": {
            "ansible_facts": {
                "discovered_interpreter_
            },
            "changed": false,
            "config": {
                "ca_renewal_master_server": "server.idm.example.com",
                "configstring": [
                    "AllowNThash",
                    "KDC:Disable Last Success"
                ],
                "defaultgroup": "ipausers",
                "defaultshell": "/bin/bash",
                "emaildomain": "idm.example.com",
                "enable_migration": false,
                "groupsearch": [
                    "cn",
                    "description"
                ],
                "homedirectory": "/home",
                "maxhostname": "64",
                "maxusername": "64",
                "pac_type": [
                    "MS-PAC",
                    "nfs:NONE"
                ],
                "pwdexpnotify": "4",
                "searchrecordslimit": "100",
                "searchtimelimit": "2",
                "selinuxusermapdefault": "unconfined_u:s0-s0:c0.c1023",
                "selinuxusermaporder": [
                    "guest_u:s0$xguest_u:s0$user_
                ],
                "usersearch": [
                    "uid",
                    "givenname",
                    "sn",
                    "telephonenumber",
                    "ou",
                    "title"
                ]
            },
            "failed": false
        }
    }

8.2. Configuração do servidor mestre de renovação da IdM CA usando um livro de exercícios possível

Em uma implantação de Gerenciamento de Identidade (IdM) que usa uma autoridade de certificado embutida (CA), o servidor mestre de renovação CA mantém e renova os certificados do sistema IdM. Ele garante implantações de IdM ininterruptas.

Para mais detalhes sobre o papel do mestre de renovação da IdM CA, consulte Usando o mestre de renovação da IdM CA.

O procedimento a seguir descreve como você pode usar um livro de exercícios possível para configurar o servidor mestre de renovação da IdM CA.

Pré-requisitos

  • Você sabe a senha do administrador da IdM.
  • Você instalou o pacote ansible-freeipa no controlador Ansible.

Procedimento

  1. Opcional: Identificar o atual mestre de renovação da IdM CA:

    $ ipa config-show | grep 'CA renewal master'
      IPA CA renewal master: server.idm.example.com
  2. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaserver no mesmo:

    [ipaserver]
    server.idm.example.com
  3. Abrir o arquivo /usr/share/doc/ansible-freeipa/playbooks/config/set-ca-renewal-master-server.yml Um possível arquivo de playbook para edição:

    ---
    - name: Playbook to handle global DNS configuration
      hosts: ipaserver
      become: no
      gather_facts: no
    
      tasks:
      - name: set ca_renewal_master_server
        ipaconfig:
          ipaadmin_password: SomeADMINpassword
          ca_renewal_master_server: carenewal.idm.example.com
  4. Adaptar o arquivo através de alterações:

    • A senha do administrador da IdM definida pela variável ipaadmin_password.
    • O nome do servidor principal da CA definido pela variável ca_renewal_master_server.
  5. Salvar o arquivo.
  6. Execute o livro de jogo Ansible playbook. Especifique o arquivo do playbook e o arquivo do inventário:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/config/set-ca-renewal-master-server.yml

Etapas de verificação

Você pode verificar se o mestre de renovação do CA foi alterado:

  1. Acesse ipaserver como administrador da IdM:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Solicitar a identidade do servidor principal do IdM CA:

    $ ipa config-show | grep ‘CA renewal master’
    IPA CA renewal master:  carenewal.idm.example.com

    A saída mostra que o servidor carenewal.idm.example.com é o novo mestre da renovação da CA.

8.3. Configuração do shell padrão para usuários do IdM usando um livro de exercícios possível

O shell é um programa que aceita e interpreta comandos. Vários shells estão disponíveis no Red Hat Enterprise Linux (RHEL), tais como bash, sh, ksh, zsh, fish, e outros. Bash, ou /bin/bash, é um shell popular na maioria dos sistemas Linux, e normalmente é o shell default para contas de usuários no RHEL.

O procedimento a seguir descreve como você pode usar um livro de jogo possível para configurar sh, uma shell alternativa, como a shell padrão para usuários do IdM.

Pré-requisitos

  • Você sabe a senha do administrador da IdM.
  • Você instalou o pacote ansible-freeipa no controlador Ansible.

Procedimento

  1. Opcional: Use o retrieve-config.yml Livro de jogo possível para identificar a concha atual para usuários da IdM. Consulte Recuperar a configuração do IdM usando um livro de reprodução possível para obter detalhes.
  2. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaserver no mesmo:

    [ipaserver]
    server.idm.example.com
  3. Abrir o arquivo /usr/share/doc/ansible-freeipa/playbooks/config/ensure-config-options-are-set.yml Um possível arquivo de playbook para edição:

    ---
    - name: Playbook to ensure some config options are set
      hosts: ipaserver
      become: true
    
      tasks:
      # Set defaultlogin and maxusername
      - ipaconfig:
          ipaadmin_password: Secret123
          defaultshell: /bin/bash
          maxusername: 64
  4. Adapte o arquivo alterando o seguinte:

    • A senha do administrador da IdM definida pela variável ipaadmin_password.
    • O shell padrão dos usuários do IdM definido pela variável defaultshell em /bin/sh.
  5. Salvar o arquivo.
  6. Execute o livro de jogo Ansible playbook. Especifique o arquivo do playbook e o arquivo do inventário:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/config/ensure-config-options-are-set.yml

Etapas de verificação

Você pode verificar se o shell de usuário padrão foi alterado iniciando uma nova sessão no IdM:

  1. Acesse ipaserver como administrador da IdM:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Mostrar a concha atual:

    [admin@server /]$ echo "$SHELL"
    /bin/sh

    O usuário logado está usando a concha sh.

Recursos adicionais

  • Você pode ver exemplos de playbooks possíveis para configuração de configurações globais de IdM e uma lista de variáveis possíveis no arquivo README-config.md Markdown disponível no diretório /usr/share/doc/ansible-freeipa/.
  • Você pode ver exemplos de playbooks possíveis para várias operações relacionadas à configuração do IdM no diretório /usr/share/doc/ansible-freeipa/playbooks/config.

Capítulo 9. Gerenciando contas de usuários usando a linha de comando

Este capítulo inclui uma descrição básica do ciclo de vida do usuário no IdM (Gerenciamento de Identidade). As seções seguintes lhe mostram como fazê-lo:

  • Criar contas de usuário
  • Ativar as contas de usuário da etapa
  • Preservar contas de usuários
  • Eliminar contas de usuário ativas, em fase ou preservadas
  • Restauração de contas de usuários preservadas

9.1. Ciclo de vida do usuário

IdM (Identity Management) suporta três estados de conta de usuário:

  • Stage os usuários não têm permissão para autenticar. Este é um estado inicial. Algumas das propriedades da conta de usuário necessárias para usuários ativos não podem ser definidas, por exemplo, a adesão em grupo.
  • Active os usuários têm permissão para autenticar. Todas as propriedades de conta de usuário necessárias devem ser definidas neste estado.
  • Preserved usuários são antigos usuários ativos que são considerados inativos e não podem se autenticar na IdM. Os usuários preservados retêm a maioria das propriedades da conta que tinham como usuários ativos, mas não fazem parte de nenhum grupo de usuários.

84 RHEL IdM 0420 ciclo de vida

Você pode excluir permanentemente as entradas do usuário do banco de dados do IdM.

Importante

As contas de usuário excluídas não podem ser restauradas. Quando você exclui uma conta de usuário, todas as informações associadas à conta são permanentemente perdidas.

Um novo administrador só pode ser criado por um usuário com direitos de administrador, tal como o usuário administrador padrão. Se você apagar acidentalmente todas as contas de administrador, o Administrador de Diretório deve criar um novo administrador manualmente no Servidor de Diretório.

Atenção

Não exclua o usuário do admin. Como admin é um usuário pré-definido exigido pela IdM, esta operação causa problemas com certos comandos. Se você quiser definir e usar um usuário administrador alternativo, desabilite o usuário admin pré-definido com ipa user-disable admin após ter concedido permissões de administrador a pelo menos um usuário diferente.

9.2. Adicionando usuários usando a linha de comando

Você pode adicionar usuário como:

  • Active - user contas que podem ser utilizadas ativamente por seus usuários.
  • Stage - users não pode usar essas contas. Use-a se você quiser preparar novas contas de usuário. Quando os usuários estiverem prontos para usar suas contas, então você poderá ativá-las.

O procedimento seguinte descreve a adição de usuários ativos ao servidor IdM com o comando ipa user-add.

Da mesma forma, você pode criar contas de usuário em palco com o comando ipa stageuser-add.

Nota

IdM atribui automaticamente um ID de usuário único (UID) para as novas contas de usuário. Você também pode fazer isto manualmente, entretanto, o servidor não valida se o número UID é único. Devido a isto, várias entradas de usuário podem ter o mesmo número de identificação atribuído. A Red Hat recomenda que se evite ter múltiplas entradas com a mesma UID.

Pré-requisitos

Procedimento

  1. Abra o terminal e conecte-se ao servidor IdM.
  2. Adicione login de usuário, nome do usuário, sobrenome e, opcionalmente, você também pode adicionar seu endereço de e-mail.

    $ ipa user-add user_login --first=first_name --last=last_name --email=email_address

    IdM suporta nomes de usuários que podem ser descritos através da seguinte expressão regular:

    [a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?
    Nota

    Os nomes dos usuários que terminam com o sinal de dólar móvel ($) são suportados para permitir o suporte da máquina Samba 3.x.

    Se você adicionar um nome de usuário contendo caracteres maiúsculos, o IdM converte automaticamente o nome em minúsculas ao salvá-lo. Portanto, o IdM sempre requer a inserção de nomes de usuário em letras minúsculas ao fazer o login. Além disso, não é possível adicionar nomes de usuário que diferem apenas em letras maiúsculas, como user e User.

    O comprimento máximo padrão para os nomes de usuário é de 32 caracteres. Para alterá-lo, use o comando ipa config-mod --maxusername. Por exemplo, para aumentar o comprimento máximo do nome do usuário para 64 caracteres:

    $ ipa config-mod --maxusername=64
     Maximum username length: 64
     ...

    O comando ipa user-add inclui uma série de parâmetros. Para listar todos eles, use o comando ipa help:

    $ ipa help user-add

    Para detalhes sobre o comando ipa help, veja Qual é a ajuda do IPA.

Você pode verificar se a nova conta de usuário é criada com sucesso, listando todas as contas de usuário da IdM:

$ ipa $ ipa user-find

Este comando lista todas as contas de usuário com detalhes.

9.3. Ativação de usuários usando a linha de comando

Para ativar uma conta de usuário movendo-a do estágio para o ativo, use o comando ipa stageuser-activate.

Pré-requisitos

Procedimento

  1. Abra o terminal e conecte-se ao servidor IdM.
  2. Ativar a conta de usuário com o seguinte comando:

    $ ipa stageuser-activate user_login
    -------------------------
    Stage user user_login activated
    -------------------------
    ...

Você pode verificar se a nova conta de usuário é criada com sucesso, listando todas as contas de usuário da IdM:

$ ipa $ ipa user-find

Este comando lista todas as contas de usuário com detalhes.

9.4. Preservação dos usuários usando a linha de comando

Para preservar uma conta de usuário, use os comandos ipa user-del ou ipa stageuser-del.

Pré-requisitos

Procedimento

  1. Abra o terminal e conecte-se ao servidor IdM.
  2. Preservar a conta do usuário com o seguinte comando:

    $ ipa user-del --preserve user_login
    --------------------
    Deleted user "user_login"
    --------------------

9.5. Eliminação de usuários usando a linha de comando

O IdM (Identity Management) permite excluir usuários permanentemente. Você pode excluir:

  • Usuários ativos com o seguinte comando ipa user-del
  • Usuários do palco com o seguinte comando ipa stageuser-del
  • Usuários preservados com o seguinte comando ipa user-del

Ao excluir vários usuários, use a opção --continue para forçar o comando a continuar, independentemente de erros. Um resumo das operações bem-sucedidas e falhadas é impresso no fluxo de saída padrão stdout quando o comando for concluído.

$ ipa user-del --continuar user1 user2 user3

Se você não usar --continue, o comando procede com a eliminação de usuários até encontrar um erro, após o qual ele pára e sai.

Pré-requisitos

Procedimento

  1. Abra o terminal e conecte-se ao servidor IdM.
  2. Eliminar a conta de usuário com o seguinte comando:

    $ ipa user-del user_login
    --------------------
    Deleted user "user_login"
    --------------------

A conta de usuário foi permanentemente excluída da IdM.

9.6. Restaurando usuários usando a linha de comando

Você pode restaurar um usuário preservado para:

  • Usuários ativos ipa user-undel
  • Usuários do palco ipa user-stage

A restauração de uma conta de usuário não restaura todos os atributos anteriores da conta. Por exemplo, a senha do usuário não é restaurada e deve ser definida novamente.

Pré-requisitos

Procedimento

  1. Abra o terminal e conecte-se ao servidor IdM.
  2. Ativar a conta de usuário com o seguinte comando:

    $ ipa user-undel user_login
    ------------------------------
    Undeleted user account "user_login"
    ------------------------------

    Alternativamente, você pode restaurar as contas dos usuários como encenadas:

    $ ipa user-stage user_login
    ------------------------------
    Staged user account "user_login"
    ------------------------------

Você pode verificar se a nova conta de usuário é criada com sucesso, listando todas as contas de usuário da IdM:

$ ipa $ ipa user-find

Este comando lista todas as contas de usuário com detalhes.

Capítulo 10. Gerenciando contas de usuários usando a IDM Web UI

O Gerenciamento de Identidade (IdM) fornece várias etapas que podem ajudá-lo a gerenciar várias situações da vida profissional do usuário:

Criação de uma conta de usuário

Criar uma conta de usuário de etapa antes de um funcionário iniciar sua carreira em sua empresa e estar preparado com antecedência para o dia em que o funcionário aparecer no escritório e quiser ativar a conta.

Você pode omitir esta etapa e criar a conta de usuário ativa diretamente. O procedimento é semelhante à criação de uma conta de usuário em fase.

Ativação de uma conta de usuário
Ativando a conta no primeiro dia útil do funcionário.
Desativação de uma conta de usuário
Se o usuário for a uma licença parental por alguns meses, precisará desativar a conta temporariamente.
Habilitação de uma conta de usuário
Quando o usuário retornar, será necessário reativar a conta.
Preservar uma conta de usuário
Se o usuário quiser deixar a empresa, será necessário apagar a conta com a possibilidade de restaurá-la, pois as pessoas podem retornar à empresa após algum tempo.
Restauração de uma conta de usuário
Dois anos depois, o usuário está de volta e você precisa restaurar a conta preservada.
Eliminação de uma conta de usuário
Se o funcionário for demitido, você apagará a conta sem um backup.

10.1. Ciclo de vida do usuário

IdM (Identity Management) suporta três estados de conta de usuário:

  • Stage os usuários não têm permissão para autenticar. Este é um estado inicial. Algumas das propriedades da conta de usuário necessárias para usuários ativos não podem ser definidas, por exemplo, a adesão em grupo.
  • Active os usuários têm permissão para autenticar. Todas as propriedades de conta de usuário necessárias devem ser definidas neste estado.
  • Preserved usuários são antigos usuários ativos que são considerados inativos e não podem se autenticar na IdM. Os usuários preservados retêm a maioria das propriedades da conta que tinham como usuários ativos, mas não fazem parte de nenhum grupo de usuários.

84 RHEL IdM 0420 ciclo de vida

Você pode excluir permanentemente as entradas do usuário do banco de dados do IdM.

Importante

As contas de usuário excluídas não podem ser restauradas. Quando você exclui uma conta de usuário, todas as informações associadas à conta são permanentemente perdidas.

Um novo administrador só pode ser criado por um usuário com direitos de administrador, tal como o usuário administrador padrão. Se você apagar acidentalmente todas as contas de administrador, o Administrador de Diretório deve criar um novo administrador manualmente no Servidor de Diretório.

Atenção

Não exclua o usuário do admin. Como admin é um usuário pré-definido exigido pela IdM, esta operação causa problemas com certos comandos. Se você quiser definir e usar um usuário administrador alternativo, desabilite o usuário admin pré-definido com ipa user-disable admin após ter concedido permissões de administrador a pelo menos um usuário diferente.

10.2. Adicionando usuários na Web UI

Normalmente, é necessário criar uma nova conta de usuário antes que um novo funcionário comece a trabalhar. Tal conta de etapa não é acessível e você precisa ativá-la mais tarde.

Nota

Alternativamente, você pode criar uma conta de usuário ativa diretamente. Para adicionar um usuário ativo, siga o procedimento abaixo e adicione a conta de usuário na guia Active users.

Pré-requisitos

  • Privilégios de administrador para gerenciar o papel de IdM ou Administrador de usuários.

Procedimento

  1. Faça o login na IDM Web UI.

    Para obter detalhes, consulte Acessando a IDM Web UI em um navegador da web.

  2. Vá para a guia Users → Stage Users.

    Alternativamente, você pode adicionar a conta de usuário no Users → Active users, entretanto, não é possível adicionar grupos de usuários à conta.

  3. Clique no ícone Add.
  4. Na caixa de diálogo Add stage user, digite First name e Last name do novo usuário.
  5. [Opcional] No campo User login, adicione um nome de login.

    Se você deixá-lo vazio, o servidor IdM cria o nome de login no seguinte padrão: A primeira letra do primeiro nome e o sobrenome. O nome de login completo pode ter até 32 caracteres.

  6. [Opcional] No menu suspenso GID, selecione os grupos nos quais o usuário deve ser incluído.
  7. [Opcional] Nos campos Password e Verify password,
  8. Clique no botão Add.

    idm usuário adicionar etapa

Neste ponto, você pode ver a conta de usuário na tabela Stage Users.

estágio de usuários idm

Nota

Se você clicar no nome do usuário, você pode editar configurações avançadas, como adicionar um número de telefone, endereço ou ocupação.

10.3. Ativação de usuários de palco na interface web da IdM

Uma conta de usuário estágio deve ser ativada antes que o usuário possa entrar na IdM e antes que o usuário possa ser adicionado a um grupo IdM. Esta seção descreve como ativar as contas de usuário de estágio.

Pré-requisitos

  • Privilégios de administrador para gerenciar a interface web da IdM ou o papel de Administrador do usuário.
  • Pelo menos uma conta de usuário encenada na IdM.

Procedimento

  1. Faça o login na IDM Web UI.

    Para obter detalhes, consulte Acessando a IDM Web UI em um navegador da web.

  2. Vá para a guia Users → Stage users.
  3. Clique na caixa de seleção da conta de usuário que você deseja ativar.
  4. Clique no botão Activate.

    estágio de usuários idm

  5. Na caixa de diálogo Confirmation, clique no botão OK.

Se a ativação for bem sucedida, a IDM Web UI exibe uma confirmação verde de que o usuário foi ativado e a conta de usuário foi movida para Active users. A conta está ativa e o usuário pode se autenticar no domínio IdM e na IDM Web UI. O usuário é solicitado a alterar sua senha no primeiro login.

idm usuário estágio ativado

Nota

Nesta fase, você pode adicionar a conta de usuário ativa aos grupos de usuários.

10.4. Desativação de contas de usuário na interface web

Você pode desativar contas de usuário ativas. Desativar uma conta de usuário desativa a conta, portanto, contas de usuário não podem ser usadas para autenticar e usar serviços IdM, tais como Kerberos, ou executar quaisquer tarefas.

As contas de usuários deficientes ainda existem dentro da IdM e todas as informações associadas permanecem inalteradas. Ao contrário das contas de usuários preservadas, as contas de usuários deficientes permanecem no estado ativo e podem ser um membro de grupos de usuários.

Nota

Após desativar uma conta de usuário, quaisquer conexões existentes permanecem válidas até a expiração do Kerberos TGT e outros bilhetes do usuário. Após a expiração do bilhete, o usuário não poderá renová-lo.

Pré-requisitos

  • Privilégios de administrador para gerenciar a interface web da IdM ou o papel de Administrador do usuário.

Procedimento

  1. Faça o login na IDM Web UI.

    Para obter detalhes, consulte Acessando a IDM Web UI em um navegador da web.

  2. Vá para a guia Users → Active users.
  3. Clique na caixa de seleção das contas de usuário que você deseja desativar.
  4. Clique no botão Disable.

    usuários do idm desativam

  5. Na caixa de diálogo Confirmation, clique no botão OK.

Se o procedimento de desativação tiver sido bem-sucedido, você pode verificar na coluna Status na tabela Active users.

usuários idm desativados

10.5. Habilitação de contas de usuário na Web UI

Com IdM você pode habilitar contas de usuários ativos desativados. A ativação de uma conta de usuário ativa a conta de usuário desativada.

Pré-requisitos

  • Privilégios de administrador para gerenciar a interface web da IdM ou o papel de Administrador do usuário.

Procedimento

  1. Faça o login na IDM Web UI.
  2. Vá para a guia Users → Active users.
  3. Clique na caixa de seleção das contas de usuário que você deseja habilitar.
  4. Clique no botão Enable.

    usuários do idm desativam

  5. Na caixa de diálogo Confirmation, clique no botão OK.

Se a mudança foi bem sucedida, você pode verificar na coluna Status na tabela Active users.

10.6. Preservação dos usuários ativos na interface web da IdM

A preservação de contas de usuário permite remover contas da guia Active users, mas mantendo estas contas na IdM.

Preservar a conta do usuário se o funcionário deixar a empresa. Se você quiser desativar a conta de usuário por algumas semanas ou meses (licença dos pais, por exemplo), desative a conta. Para maiores detalhes, veja Seção 10.4, “Desativação de contas de usuário na interface web”. As contas preservadas não estão ativas e os usuários não podem utilizá-las para acessar sua rede interna, entretanto, a conta permanece no banco de dados com todos os dados.

Você pode mover as contas restauradas de volta para o modo ativo.

Nota

A lista de usuários no estado preservado pode fornecer um histórico de contas de usuários passados.

Pré-requisitos

  • Privilégios de administrador para gerenciar a interface web IdM (Identity Management) ou a função de Administrador do usuário.

Procedimento

  1. Faça o login na IDM Web UI.

    Para obter detalhes, consulte Acessando a IDM Web UI em um navegador da web.

  2. Vá para a guia Users → Active users.
  3. Clique na caixa de seleção das contas de usuário que você deseja preservar.
  4. Clique no botão Delete.

    idm usuários ativos excluir

  5. Na caixa de diálogo Remove users, mude o botão de rádio Delete mode para preserve.
  6. Clique no botão Delete.

    idm usuários preservando

Como resultado, a conta de usuário é movida para Preserved users.

Se você precisar restaurar usuários preservados, consulte a seção Restaurando usuários na Interface Web do IdM.

10.7. Restaurando usuários na IDM Web UI

IdM (Identity Management) permite restaurar as contas de usuários preservadas no estado ativo.

Pré-requisitos

  • Privilégios de administrador para gerenciar a interface web da IdM ou o papel de Administrador do usuário.

Procedimento

  1. Faça o login na IDM Web UI.

    Para obter detalhes, consulte Acessando a IDM Web UI em um navegador da web.

  2. Vá para a guia Users → Preserved users.
  3. Clique na caixa de seleção nas contas de usuário que você deseja restaurar.
  4. Clique no botão Restore.

    idm usuários preservados restaurar

  5. Na caixa de diálogo Confirmation, clique no botão OK.

A IDM Web UI exibe uma confirmação verde e move as contas de usuário para a guia Active users.

10.8. Eliminação de usuários na IDM Web UI

A exclusão de usuários é uma operação irreversível, fazendo com que as contas de usuário sejam permanentemente excluídas do banco de dados do IdM, incluindo a filiação em grupo e as senhas. Qualquer configuração externa para o usuário, como a conta do sistema e o diretório pessoal, não é excluída, mas não é mais acessível através do IdM.

Você pode apagar:

  • Ativo users - the IdM Web UI lhe oferece as opções:

  • Etapa users - you pode simplesmente excluir usuários da etapa permanentemente.
  • Preservado users - you pode excluir usuários preservados permanentemente.

O procedimento a seguir descreve a eliminação de usuários ativos. Da mesma forma, você pode excluir contas de usuários:

  • A aba Stage users
  • A aba Preserved users

Pré-requisitos

  • Privilégios de administrador para gerenciar a interface web da IdM ou o papel de Administrador do usuário.

Procedimento

  1. Faça o login na IDM Web UI.

    Para obter detalhes, consulte Acessando a IDM Web UI em um navegador da web.

  2. Vá para a guia Users → Active users.

    Alternativamente, você pode excluir a conta do usuário no site Users → Stage users ou Users → Preserved users.

  3. Clique no ícone Delete.
  4. Na caixa de diálogo Remove users, mude o botão de rádio Delete mode para delete.
  5. Clique no botão Delete.

As contas dos usuários foram permanentemente apagadas da IdM.

Capítulo 11. Gerenciando contas de usuários usando Livros de Jogadas Ansíveis

Você pode gerenciar usuários na IdM usando Livros de Jogadas Ansíveis. Este capítulo descreve o uso de playbooks Ansible playbooks para as seguintes operações:

11.1. Garantindo a presença de um usuário IdM usando um livro de jogo possível

O procedimento a seguir descreve a garantia da presença de um usuário na IdM usando um livro de jogo possível.

Pré-requisitos

  • Você sabe a senha do administrador da IdM.
  • O pacote ansible-freeipa é instalado no controlador Ansible.

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaserver no mesmo:

    [ipaserver]
    server.idm.example.com
  2. Crie um arquivo de playbook possível com os dados do usuário cuja presença na IdM você quer garantir. Para simplificar esta etapa, você pode copiar e modificar o exemplo no arquivo /usr/share/doc/ansible-freeipa/playbooks/user/add-user.yml. Por exemplo, para criar um usuário chamado idm_user e adicionar Password123 como senha do usuário:

    ---
    - name: Playbook to handle users
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Create user idm_user
        ipauser:
          ipaadmin_password: MySecret123
          name: idm_user
          first: Alice
          last: Acme
          uid: 1000111
          gid: 10011
          phone: "+555123457"
          email: idm_user@acme.com
          passwordexpiration: "2023-01-19 23:59:59"
          password: "Password123"
          update_password: on_create

    Você deve usar as seguintes opções para adicionar um usuário:

    • name: o nome de login
    • first: a cadeia de nome próprio
    • last: a cadeia de sobrenomes

    Para a lista completa das opções de usuário disponíveis, consulte o arquivo /usr/share/doc/ansible-freeipa/README-user.md Markdown.

    Nota

    Se você usar a opção update_password: on_create, Ansible só cria a senha do usuário quando ele cria o usuário. Se o usuário já estiver criado com uma senha, o Ansible não gera uma nova senha.

  3. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-IdM-user.yml

Etapas de verificação

  • Você pode verificar se a nova conta de usuário existe na IdM usando o comando ipa user-show:

    1. Acesse ipaserver como administrador:

      $ ssh admin@server.idm.example.com
      Password:
      [admin@server /]$
    2. Solicite um bilhete Kerberos para administração:

      $ kinit admin
      Password for admin@IDM.EXAMPLE.COM:
    3. Solicite informações sobre idm_user:

      $ ipa user-show idm_user
        User login: idm_user
        First name: Alice
        Last name: Acme
        ....

    O usuário chamado idm_user está presente na IdM.

11.2. Assegurar a presença de múltiplos usuários de IdM usando Livros de Jogadas Ansíveis

O procedimento a seguir descreve a garantia da presença de múltiplos usuários na IdM usando um livro de jogo possível.

Pré-requisitos

  • Você sabe a senha do administrador da IdM.
  • Você instalou o pacote ansible-freeipa no controlador Ansible.

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaserver no mesmo:

    [ipaserver]
    server.idm.example.com
  2. Crie um arquivo de playbook possível com os dados dos usuários cuja presença você quer garantir na IdM. Para simplificar esta etapa, você pode copiar e modificar o exemplo no arquivo /usr/share/doc/ansible-freeipa/playbooks/user/ensure-users-present.yml. Por exemplo, para criar usuários idm_user_1, idm_user_2, e idm_user_3, e adicionar Password123 como senha de idm_user_1:

    ---
    - name: Playbook to handle users
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Create user idm_users
        ipauser:
          ipaadmin_password: MySecret123
          users:
          - name: idm_user_1
            first: Alice
            last: Acme
            uid: 10001
            gid: 10011
            phone: "+555123457"
            email: idm_user@acme.com
            passwordexpiration: "2023-01-19 23:59:59"
            password: "Password123"
          - name: idm_user_2
            first: Bob
            last: Acme
            uid: 100011
            gid: 10011
          - name: idm_user_3
            first: Eve
            last: Acme
            uid: 1000111
            gid: 10011
    Nota

    Se você não especificar a opção update_password: on_create, Ansible redefine a senha do usuário toda vez que o playbook é executado: se o usuário mudou a senha desde a última vez que o playbook foi executado, Ansible redefine a senha.

  3. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-users.yml

Etapas de verificação

  • Você pode verificar se a conta de usuário existe na IdM usando o comando ipa user-show:

    1. Acesse ipaserver como administrador:

      $ ssh administrator@server.idm.example.com
      Password:
      [admin@server /]$
    2. Mostrar informações sobre idm_user_1:

      $ ipa user-show idm_user_1
        User login: idm_user_1
        First name: Alice
        Last name: Acme
        Password: True
        ....

    O usuário chamado idm_user_1 está presente na IdM.

11.3. Assegurar a presença de múltiplos usuários IdM a partir de um arquivo JSON usando Livros de Jogadas Ansíveis

O procedimento seguinte descreve como você pode garantir a presença de vários usuários na IdM usando um Livro de Jogadas Anível. Os usuários são armazenados em um arquivo JSON.

Pré-requisitos

  • Você sabe a senha do administrador da IdM.
  • Você instalou o pacote ansible-freeipa no controlador Ansible.

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaserver no mesmo:

    [ipaserver]
    server.idm.example.com
  2. Crie um arquivo de playbook possível com as tarefas necessárias. Consulte o arquivo JSON com os dados dos usuários cuja presença você deseja garantir. Para simplificar esta etapa, você pode copiar e modificar o exemplo no arquivo /usr/share/doc/ansible-freeipa/ensure-users-present-ymlfile.yml:

    ---
    - name: Ensure users' presence
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Include users.json
        include_vars:
          file: users.json
    
      - name: Users present
        ipauser:
          ipaadmin_password: MySecret123
          users: "{{ users }}"
  3. Crie o arquivo users.json, e adicione os usuários do IdM a ele. Para simplificar esta etapa, você pode copiar e modificar o exemplo no arquivo /usr/share/doc/ansible-freeipa/playbooks/user/users.json. Por exemplo, para criar usuários idm_user_1, idm_user_2, e idm_user_3, e adicionar Password123 como senha de idm_user_1:

    {
      "users": [
       {
        "name": "idm_user_1",
        "first": "Alice",
        "last": "Acme",
        "password": "Password123"
       },
       {
        "name": "idm_user_2",
        "first": "Bob",
        "last": "Acme"
       },
       {
        "name": "idm_user_3",
        "first": "Eve",
        "last": "Acme"
       }
      ]
    }
  4. Execute a Pasta de reprodução possível especificando o arquivo da Pasta de reprodução e o arquivo do inventário:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-users-present-jsonfile.yml

Etapas de verificação

  • Você pode verificar se as contas de usuário estão presentes no IdM usando o comando ipa user-show:

    1. Acesse ipaserver como administrador:

      $ ssh administrator@server.idm.example.com
      Password:
      [admin@server /]$
    2. Mostrar informações sobre idm_user_1:

      $ ipa user-show idm_user_1
        User login: idm_user_1
        First name: Alice
        Last name: Acme
        Password: True
        ....

    O usuário chamado idm_user_1 está presente na IdM.

11.4. Assegurando a ausência de usuários usando Livros didáticos Ansíveis

O procedimento a seguir descreve como você pode usar um Livro de Jogadas Possível para garantir que usuários específicos estejam ausentes da IdM.

Pré-requisitos

  • Você sabe a senha do administrador da IdM.
  • Você instalou o pacote ansible-freeipa no controlador Ansible.

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaserver no mesmo:

    [ipaserver]
    server.idm.example.com
  2. Crie um arquivo de playbook possível com os usuários cuja ausência da IdM você quer garantir. Para simplificar esta etapa, você pode copiar e modificar o exemplo no arquivo /usr/share/doc/ansible-freeipa/playbooks/user/ensure-users-present.yml. Por exemplo, para excluir usuários idm_user_1, idm_user_2, e idm_user_3:

    ---
    - name: Playbook to handle users
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Delete users idm_user_1, idm_user_2, idm_user_3
        ipauser:
          ipaadmin_password: MySecret123
          users:
          - name: idm_user_1
          - name: idm_user_2
          - name: idm_user_3
          state: absent
  3. Execute a Pasta de reprodução possível especificando o arquivo da Pasta de reprodução e o arquivo do inventário:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/delete-users.yml

Etapas de verificação

Você pode verificar que as contas de usuário não existem na IdM usando o comando ipa user-show:

  1. Acesse ipaserver como administrador:

    $ ssh administrator@server.idm.example.com
    Password:
    [admin@server /]$
  2. Solicite informações sobre idm_user_1:

    $ ipa user-show idm_user_1
    ipa: ERROR: idm_user_1: user not found

    O usuário chamado idm_user_1 não existe na IdM.

Recursos adicionais

  • Você pode ver exemplos de playbooks possíveis para outras ações relacionadas ao usuário IdM, tais como preservar, excluir, habilitar, desabilitar, desbloquear e desmarcar usuários no arquivo README-user.md Markdown disponível no diretório /usr/share/doc/ansible-freeipa/. O arquivo também contém as definições das variáveis ipauser.
  • Você também pode ver exemplos de livros de exercícios possíveis no diretório /usr/share/doc/ansible-freeipa/playbooks/user.

Capítulo 12. Gerenciando grupos de usuários no IdM CLI

Este capítulo apresenta a gestão de grupos de usuários utilizando o IdM CLI.

Um grupo de usuários é um conjunto de usuários com privilégios comuns, políticas de senha e outras características.

Um grupo de usuários em Gerenciamento de Identidade (IdM) pode incluir:

  • Usuários da IdM
  • outros grupos de usuários da IdM
  • usuários externos, que são usuários que existem fora da IdM

12.1. Os diferentes tipos de grupos na IdM

IdM suporta os seguintes tipos de grupos:

Grupos POSIX (o padrão)

Os grupos POSIX suportam os atributos POSIX Linux para seus membros. Note que os grupos que interagem com o Active Directory não podem usar os atributos POSIX.

Os atributos POSIX identificam os usuários como entidades separadas. Exemplos de atributos POSIX relevantes para os usuários incluem uidNumber, um número de usuário (UID), e gidNumber, um número de grupo (GID).

Grupos não-POSIX

Os grupos não-POSIX não suportam os atributos POSIX. Por exemplo, estes grupos não têm um GID definido.

Todos os membros deste tipo de grupo devem pertencer ao domínio IdM.

Grupos externos

Use grupos externos para adicionar membros do grupo que existem em uma loja de identidade fora do domínio IdM, como por exemplo:

  • Um sistema local
  • Um domínio de Active Directory
  • Um serviço de diretório

Os grupos externos não suportam os atributos POSIX. Por exemplo, estes grupos não têm um GID definido.

Tabela 12.1. Grupos de usuários criados por padrão

Nome do grupoMembros do grupo padrão

ipausers

Todos os usuários da IdM

admins

Usuários com privilégios administrativos, incluindo o usuário padrão admin

editors

Este é um grupo legado que não tem mais nenhum privilégio especial

trust admins

Usuários com privilégios para gerenciar os trusts do Active Directory

Ao adicionar um usuário a um grupo de usuários, o usuário ganha os privilégios e as políticas associadas ao grupo. Por exemplo, para conceder privilégios administrativos a um usuário, adicione o usuário ao grupo admins.

Atenção

Não exclua o grupo admins. Como admins é um grupo pré-definido exigido pela IdM, esta operação causa problemas com certos comandos.

Além disso, o IdM cria por padrão user private groups sempre que um novo usuário é criado no IdM. Para mais informações sobre grupos privados, veja Adicionar usuários sem um grupo privado.

12.2. Membros diretos e indiretos do grupo

Os atributos do grupo de usuários no IdM aplicam-se tanto aos membros diretos quanto indiretos: quando o grupo B é um membro do grupo A, todos os usuários do grupo B são considerados membros indiretos do grupo A.

Por exemplo, no diagrama a seguir:

  • Usuário 1 e Usuário 2 são direct members do grupo A.
  • Usuário 3, Usuário 4, e Usuário 5 são indirect members do grupo A.

Figura 12.1. Participação direta e indireta em grupos

84 RHEL IdM 0420 user group

Se você definir uma política de senha para o grupo de usuários A, a política também se aplica a todos os usuários do grupo de usuários B.

12.3. Adicionando um grupo de usuários usando IdM CLI

Esta seção descreve como adicionar um grupo de usuários usando o IdM CLI.

Pré-requisitos

Procedimento

  • Adicione um grupo de usuários usando o ipa group-add group_name comando. Por exemplo, para criar o grupo_a:

    $ ipa group-add group_a
    ---------------------
    Added group "group_a"
    ---------------------
      Group name: group_a
      GID: 1133400009

    Por padrão, ipa group-add adiciona um grupo de usuários POSIX. Para especificar um tipo de grupo diferente, adicione opções a ipa group-add:

    Você pode especificar um GID personalizado ao adicionar um grupo de usuários, usando o --gid=custom_GID opção. Se você fizer isso, tenha cuidado para evitar conflitos de identificação. Se você não especificar um GID personalizado, o IdM atribui automaticamente um GID a partir da faixa de ID disponível.

12.4. Busca de grupos de usuários usando IdM CLI

Esta seção descreve como procurar por grupos de usuários existentes usando IdM CLI.

Procedimento

  • Exibir todos os grupos de usuários usando o comando ipa group-find. Para especificar um tipo de grupo, adicionar opções a ipa group-find:

    • Exibir todos os grupos POSIX usando o comando ipa group-find --posix.
    • Exibir todos os grupos não-POSIX usando o comando ipa group-find --nonposix.
    • Exibir todos os grupos externos usando o comando ipa group-find --external.

      Para mais informações sobre os diferentes tipos de grupos, consulte Os diferentes tipos de grupos na IdM.

12.5. Exclusão de um grupo de usuários usando IdM CLI

Esta seção descreve como excluir um grupo de usuários usando o IdM CLI. Note que a exclusão de um grupo não exclui os membros do grupo do IdM.

Pré-requisitos

Procedimento

  • Eliminar um grupo de usuários usando o ipa group-del group_name comando. Por exemplo, para excluir grupo_a:

    $ ipa group-del group_a
    --------------------------
    Deleted group "group_a"
    --------------------------

12.6. Adicionando um membro a um grupo de usuários usando IdM CLI

Esta seção descreve como adicionar um membro a um grupo de usuários usando o IdM CLI. Você pode adicionar tanto usuários quanto grupos de usuários como membros de um grupo de usuários. Para mais informações, veja Os diferentes tipos de grupo no IdM e Membros diretos e indiretos do grupo.

Pré-requisitos

Procedimento

  • Adicione um membro a um grupo de usuários usando o comando ipa group-add-member.

    Especifique o tipo de membro usando estas opções:

    • --users adiciona um usuário de IdM
    • --external adiciona um usuário que existe fora do domínio IdM, no formato de DOMAIN\user_name ou user_name@domain
    • --groups adiciona um grupo de usuários IdM

    Por exemplo, para adicionar group_b como membro do group_a:

    $ ipa group-add-member group_a --groups=group_b
    Group name: group_a
    GID: 1133400009
    Member users: user_a
    Member groups: group_b
    Indirect Member users: user_b
    -------------------------
    Number of members added 1
    -------------------------

    Os membros do group_b são agora membros indiretos do group_a.

Importante

Ao adicionar um grupo como membro de outro grupo, não crie grupos recursivos. Por exemplo, se o Grupo A for um membro do Grupo B, não adicione o Grupo B como um membro do Grupo A. Grupos recursivos podem causar um comportamento imprevisível.

Nota

Após adicionar um membro a um grupo de usuários, a atualização pode levar algum tempo para se espalhar a todos os clientes em seu ambiente de Gerenciamento de Identidade. Isto porque quando um determinado host resolve usuários, grupos e grupos de rede, o System Security Services Daemon (SSSD) primeiro procura em seu cache e realiza buscas no servidor apenas por registros ausentes ou expirados.

12.7. Adicionando usuários sem um grupo privado de usuários

Por padrão, IdM cria grupos privados de usuários (UPGs) sempre que um novo usuário é criado no IdM. Os UPGs são um tipo específico de grupo:

  • A UPG tem o mesmo nome que o usuário recém-criado.
  • O usuário é o único membro da UPG. A UPG não pode conter nenhum outro membro.
  • O GID do grupo privado combina com o UID do usuário.

Entretanto, é possível adicionar usuários sem criar um UPG.

12.7.1. Usuários sem um grupo privado de usuários

Se um grupo NIS ou outro grupo de sistemas já utiliza o GID que seria atribuído a um grupo privado de usuários, é necessário evitar a criação de um UPG.

Você pode fazer isso de duas maneiras:

Em ambos os casos, a IdM precisará especificar um GID ao adicionar novos usuários, caso contrário, a operação falhará. Isto porque o IdM requer um GID para o novo usuário, mas o grupo de usuários padrão ipausers é um grupo não-POSIX e, portanto, não tem um GID associado. O GID especificado pelo usuário não precisa corresponder a um grupo já existente.

Nota

A especificação do GID não cria um novo grupo. Ele apenas define o atributo GID para o novo usuário, porque o atributo é exigido pelo IdM.

12.7.2. Adicionar um usuário sem um grupo privado de usuários quando grupos privados são globalmente habilitados

Você pode adicionar um usuário sem criar um grupo privado de usuários (UPG) mesmo quando os UPGs estão habilitados no sistema. Isto requer a configuração manual de um GID para o novo usuário. Para detalhes sobre a necessidade disso, veja Seção 12.7.1, “Usuários sem um grupo privado de usuários”.

Procedimento

  • Para evitar que a IdM crie uma UPG, adicione a opção --noprivate ao comando ipa user-add.

    Note que para que o comando tenha sucesso, você deve especificar um GID personalizado. Por exemplo, para adicionar um novo usuário com GID 10000:

    $ ipa user-add jsmith --first=John --last=Smith --noprivate --gid 10000

12.7.3. Desabilitando grupos privados de usuários globalmente para todos os usuários

Você pode desativar grupos privados de usuários (UPGs) globalmente. Isto impede a criação de UPGs para todos os novos usuários. Os usuários existentes não são afetados por esta mudança.

Procedimento

  1. Obter privilégios de administrador:

    $ parentes admin
  2. IdM usa o Plug-in de Entradas Gerenciadas por Servidor de Diretório para gerenciar UPGs. Liste as instâncias do plug-in:

    $ ipa-managed-entries --lista
  3. Para garantir que a IdM não crie UPGs, desabilite a instância plug-in responsável pelo gerenciamento de grupos privados de usuários:

    $ ipa-managed-entries -e "UPG Definition" disable
    Disabling Plugin
    Nota

    Para reativar a instância UPG Definition mais tarde, use o comando ipa-managed-entries -e "UPG Definition" enable.

  4. Reinicie o Servidor de Diretório para carregar a nova configuração.

    $ sudo systemctl restart dirsrv.target

    Para adicionar um usuário após a desativação dos UPGs, é necessário especificar um GID. Para mais informações, veja Adicionar um usuário quando grupos privados de usuários são desativados globalmente

Etapas de verificação

  • Para verificar se as UPGs estão globalmente desativadas, use o comando de desativação novamente:

    $ ipa-managed-entries -e "UPG Definition" disable
    Plugin already disabled

12.7.4. Adicionar um usuário quando grupos privados de usuários são globalmente deficientes

Quando grupos privados de usuários (UPGs) são desativados globalmente, o IdM não atribui um GID a um novo usuário automaticamente. Para adicionar um usuário com sucesso, você deve atribuir um GID manualmente ou usando uma regra de membro automático. Para detalhes sobre o porquê disso, veja Seção 12.7.1, “Usuários sem um grupo privado de usuários”.

Pré-requisitos

Procedimento

  • Para garantir o sucesso da adição de um novo usuário quando a criação de UPGs estiver desativada, escolha uma das seguintes opções:

    • Especifique um GID personalizado ao adicionar um novo usuário. O GID não tem que corresponder a um grupo de usuários já existente.

      Por exemplo, ao adicionar um usuário da linha de comando, adicione a opção --gid ao comando ipa user-add.

    • Use uma regra de membro automático para adicionar o usuário a um grupo existente com um GID.

12.8. Adicionar usuários ou grupos como gerentes membros a um grupo de usuários IdM usando o IdM CLI

Esta seção descreve como adicionar usuários ou grupos como gerentes de membros a um grupo de usuários IdM usando o IdM CLI. Os gerentes membros podem adicionar usuários ou grupos aos grupos de usuários do IdM, mas não podem alterar os atributos de um grupo.

Pré-requisitos

Procedimento

  • Adicione um usuário como gerente membro a um grupo de usuários IdM usando o comando ipa group-add-member-manager.

    Por exemplo, para adicionar o usuário test como gerente membro do group_a:

    $ ipa group-add-member-manager group_a --users=test
    Group name: group_a
    GID: 1133400009
    Membership managed by users: test
    -------------------------
    Number of members added 1
    -------------------------

    O usuário test pode agora gerenciar membros do group_a.

  • Adicione um grupo como gerente membro a um grupo de usuários IdM usando o comando ipa group-add-member-manager.

    Por exemplo, para adicionar o grupo group_admins como gerente membro do group_a:

    $ ipa group-add-member-manager group_a --groups=group_admins
    Group name: group_a
    GID: 1133400009
    Membership managed by groups: group_admins
    Membership managed by users: test
    -------------------------
    Number of members added 1
    -------------------------

    O Grupo group_admins pode agora gerenciar membros do group_a.

Nota

Após adicionar um gerente membro a um grupo de usuários, a atualização pode levar algum tempo para se espalhar a todos os clientes em seu ambiente de Gerenciamento de Identidade.

Etapas de verificação

  • Using the ipa group-show command to verify the user and group were added as member managers.

    $ ipa group-show group_a
    Group name: group_a
    GID: 1133400009
    Membership managed by groups: group_admins
    Membership managed by users: test

Recursos adicionais

  • Veja ipa group-add-member-manager --help para mais detalhes.

12.9. Visualização dos membros do grupo usando IdM CLI

Esta seção descreve como visualizar os membros de um grupo usando o IdM CLI. Você pode visualizar tanto os membros diretos quanto os indiretos do grupo. Para mais informações, consulte Membros diretos e indiretos do grupo.

Procedimento:

  • Para listar os membros de um grupo, use o ipa group-show group_name comando. Por exemplo:

    $ ipa group-show group_a
      ...
      Member users: user_a
      Member groups: group_b
      Indirect Member users: user_b
    Nota

    A lista de membros indiretos não inclui usuários externos de domínios confiáveis do Active Directory. Os objetos de usuários de confiança do Active Directory não são visíveis na interface de Gerenciamento de Identidade porque não existem como objetos LDAP dentro do Gerenciamento de Identidade.

12.10. Removendo um membro de um grupo de usuários usando o IdM CLI

Esta seção descreve como remover um membro de um grupo de usuários usando o IdM CLI.

Pré-requisitos

Procedimento

  1. Optional. Use o comando ipa group-show para confirmar que o grupo inclui o membro que você deseja remover.
  2. Remover um membro de um grupo de usuários usando o comando ipa group-remove-member.

    Especifique os membros a serem removidos usando estas opções:

    • --users remove um usuário de IdM
    • --external remove um usuário que existe fora do domínio IdM, no formato de DOMAIN\user_name ou user_name@domain
    • --groups remove um grupo de usuários da IdM

    Por exemplo, para remover user1, user2, e group1 de um grupo chamado group_name:

    $ ipa group-remove-member group_name --users=user1 --users=user2 --groups=group1

12.11. Remoção de usuários ou grupos como gerentes membros de um grupo de usuários IdM usando o IdM CLI

Esta seção descreve como remover usuários ou grupos como gerentes membros de um grupo de usuários IdM usando o IdM CLI. Os gerentes membros podem remover usuários ou grupos dos grupos de usuários do IdM, mas não podem alterar os atributos de um grupo.

Pré-requisitos

Procedimento

  • Remover um usuário como gerente membro de um grupo de usuários IdM usando o comando ipa group-remove-member-manager.

    Por exemplo, para remover o usuário test como gerente membro do group_a:

    $ ipa group-remove-member-manager group_a --users=test
    Group name: group_a
    GID: 1133400009
    Membership managed by groups: group_admins
    ---------------------------
    Number of members removed 1
    ---------------------------

    O usuário test não pode mais administrar membros do group_a.

  • Remover um grupo como um gerente membro de um grupo de usuários IdM usando o comando ipa group-remove-member-manager.

    Por exemplo, para remover o grupo group_admins como gerente membro do group_a:

    $ ipa group-remove-member-manager group_a --groups=group_admins
    Group name: group_a
    GID: 1133400009
    ---------------------------
    Number of members removed 1
    ---------------------------

    O Grupo group_admins não pode mais administrar membros do group_a.

Nota

Depois de remover um gerente membro de um grupo de usuários, a atualização pode levar algum tempo para se espalhar a todos os clientes em seu ambiente de Gerenciamento de Identidade.

Etapas de verificação

  • Usando o comando ipa group-show para verificar o usuário e o grupo foram removidos como gerentes de membros.

    $ ipa group-show group_a
    Group name: group_a
    GID: 1133400009

Recursos adicionais

  • Veja ipa group-remove-member-manager --help para mais detalhes.

Capítulo 13. Gerenciando grupos de usuários na IDM Web UI

Este capítulo apresenta a gestão de grupos de usuários utilizando a interface web da IdM.

Um grupo de usuários é um conjunto de usuários com privilégios comuns, políticas de senha e outras características.

Um grupo de usuários em Gerenciamento de Identidade (IdM) pode incluir:

  • Usuários da IdM
  • outros grupos de usuários da IdM
  • usuários externos, que são usuários que existem fora da IdM

13.1. Os diferentes tipos de grupos na IdM

IdM suporta os seguintes tipos de grupos:

Grupos POSIX (o padrão)

Os grupos POSIX suportam os atributos POSIX Linux para seus membros. Note que os grupos que interagem com o Active Directory não podem usar os atributos POSIX.

Os atributos POSIX identificam os usuários como entidades separadas. Exemplos de atributos POSIX relevantes para os usuários incluem uidNumber, um número de usuário (UID), e gidNumber, um número de grupo (GID).

Grupos não-POSIX

Os grupos não-POSIX não suportam os atributos POSIX. Por exemplo, estes grupos não têm um GID definido.

Todos os membros deste tipo de grupo devem pertencer ao domínio IdM.

Grupos externos

Use grupos externos para adicionar membros do grupo que existem em uma loja de identidade fora do domínio IdM, como por exemplo:

  • Um sistema local
  • Um domínio de Active Directory
  • Um serviço de diretório

Os grupos externos não suportam os atributos POSIX. Por exemplo, estes grupos não têm um GID definido.

Tabela 13.1. Grupos de usuários criados por padrão

Nome do grupoMembros do grupo padrão

ipausers

Todos os usuários da IdM

admins

Usuários com privilégios administrativos, incluindo o usuário padrão admin

editors

Este é um grupo legado que não tem mais nenhum privilégio especial

trust admins

Usuários com privilégios para gerenciar os trusts do Active Directory

Ao adicionar um usuário a um grupo de usuários, o usuário ganha os privilégios e as políticas associadas ao grupo. Por exemplo, para conceder privilégios administrativos a um usuário, adicione o usuário ao grupo admins.

Atenção

Não exclua o grupo admins. Como admins é um grupo pré-definido exigido pela IdM, esta operação causa problemas com certos comandos.

Além disso, o IdM cria por padrão user private groups sempre que um novo usuário é criado no IdM. Para mais informações sobre grupos privados, veja Adicionar usuários sem um grupo privado.

13.2. Membros diretos e indiretos do grupo

Os atributos do grupo de usuários no IdM aplicam-se tanto aos membros diretos quanto indiretos: quando o grupo B é um membro do grupo A, todos os usuários do grupo B são considerados membros indiretos do grupo A.

Por exemplo, no diagrama a seguir:

  • Usuário 1 e Usuário 2 são direct members do grupo A.
  • Usuário 3, Usuário 4, e Usuário 5 são indirect members do grupo A.

Figura 13.1. Participação direta e indireta em grupos

84 RHEL IdM 0420 user group

Se você definir uma política de senha para o grupo de usuários A, a política também se aplica a todos os usuários do grupo de usuários B.

13.3. Adicionando um grupo de usuários usando IdM Web UI

Esta seção descreve como adicionar um grupo de usuários usando a interface web IdM.

Pré-requisitos

  • Você está logado na IDM Web UI.

Procedimento

  1. Clique em Identity → Groups, e selecione User Groups na barra lateral esquerda.
  2. Clique em Add para começar a adicionar o grupo.
  3. Preencha as informações sobre o grupo. Para mais informações sobre os tipos de grupos de usuários, consulte Os diferentes tipos de grupos na IdM.

    Você pode especificar um GID personalizado para o grupo. Se você fizer isso, tenha cuidado para evitar conflitos de ID. Se você não especificar um GID personalizado, o IdM atribui automaticamente um GID a partir da faixa de ID disponível.

    user group add dialog
  4. Clique em Add para confirmar.

13.4. Eliminação de um grupo de usuários usando IdM Web UI

Esta seção descreve como excluir um grupo de usuários usando a interface web do IdM. Note que a exclusão de um grupo não exclui os membros do grupo da IdM.

Pré-requisitos

  • Você está logado na IDM Web UI.

Procedimento

  1. Clique em Identity → Groups e selecione User Groups.
  2. Selecione o grupo a ser excluído.
  3. Clique em Delete.
  4. Clique em Delete para confirmar.

13.5. Adicionando um membro a um grupo de usuários usando a IDM Web UI

Você pode adicionar tanto usuários quanto grupos de usuários como membros de um grupo de usuários. Para mais informações, veja Os diferentes tipos de grupo em IdM e Membros diretos e indiretos do grupo.

Pré-requisitos

  • Você está logado na IDM Web UI.

Procedimento

  1. Clique em Identity → Groups e selecione User Groups na barra lateral esquerda.
  2. Clique no nome do grupo.
  3. Selecione o tipo de membro do grupo que você deseja adicionar: Users, User Groups, ou External.

    groups add member updated
  4. Clique em Add.
  5. Selecione a caixa de seleção ao lado de um ou mais membros que você deseja adicionar.
  6. Clique na seta para a direita para mover os membros selecionados para o grupo.

    groups add member dialog
  7. Clique em Add para confirmar.

13.6. Adicionar usuários ou grupos como gerentes de membros a um grupo de usuários IdM usando a interface Web

Esta seção descreve como adicionar usuários ou grupos como gerentes de membros a um grupo de usuários IdM usando a interface Web. Os gerentes membros podem adicionar usuários ou grupos a grupos de usuários IdM, mas não podem alterar os atributos de um grupo.

Pré-requisitos

  • Você está logado na IDM Web UI.
  • Você deve ter o nome do usuário ou do grupo que você está adicionando como gerentes membros e o nome do grupo que você quer que eles gerenciem.

Procedimento

  1. Clique em Identity → Groups e selecione User Groups na barra lateral esquerda.
  2. Clique no nome do grupo.
  3. Selecione o tipo de gerente do grupo que você deseja adicionar: Users ou User Groups.

    groups add member manager
  4. Clique em Add.
  5. Selecione a caixa de seleção ao lado de um ou mais membros que você deseja adicionar.
  6. Clique na seta para a direita para mover os membros selecionados para o grupo.

    groups add member managers users
  7. Clique em Add para confirmar.
Nota

Após adicionar um gerente membro a um grupo de usuários, a atualização pode levar algum tempo para se espalhar a todos os clientes em seu ambiente de Gerenciamento de Identidade.

Etapas de verificação

  • Verificar se o usuário ou grupo de usuários recentemente adicionado foi adicionado à lista de usuários ou grupos de usuários do gerente membro:

    groups member manager added

Recursos adicionais

  • Veja ipa group-add-member-manager --help para mais informações.

13.7. Visualizando os membros do grupo usando IdM Web UI

Esta seção descreve como visualizar os membros de um grupo utilizando a interface web da IdM. Você pode visualizar tanto os membros diretos quanto os indiretos do grupo. Para mais informações, consulte Membros diretos e indiretos do grupo.

Pré-requisitos

  • Você está logado na IDM Web UI.

Procedimento

  1. Selecione Identity → Groups.
  2. Selecione User Groups na barra lateral esquerda.
  3. Clique no nome do grupo que você deseja visualizar.
  4. Alternar entre Direct Membership e Indirect Membership.

    groups menu clean

13.8. Removendo um membro de um grupo de usuários usando IdM Web UI

Esta seção descreve como remover um membro de um grupo de usuários usando a IDM Web UI.

Pré-requisitos

  • Você está logado na IDM Web UI.

Procedimento

  1. Clique em Identity → Groups e selecione User Groups na barra lateral esquerda.
  2. Clique no nome do grupo.
  3. Selecione o tipo de membro do grupo que você deseja remover: Users, User Groups, ou External.

    groups add member updated
  4. Selecione a caixa de seleção ao lado do membro que você deseja remover.
  5. Clique em Delete.
  6. Clique em Delete para confirmar.

13.9. Remoção de usuários ou grupos como gerentes membros de um grupo de usuários IdM usando a interface Web

Esta seção descreve como remover usuários ou grupos como gerentes de membros de um grupo de usuários IdM usando a interface web. Os gerentes membros podem remover usuários ou grupos dos grupos de usuários IdM, mas não podem alterar os atributos de um grupo.

Pré-requisitos

  • Você está logado na IDM Web UI.
  • Você deve ter o nome do usuário ou do grupo de membros existentes que você está removendo e o nome do grupo que eles estão gerenciando.

Procedimento

  1. Clique em Identity → Groups e selecione User Groups na barra lateral esquerda.
  2. Clique no nome do grupo.
  3. Selecione o tipo de gerente membro que você deseja remover: Users ou User Groups.

    groups add member manager
  4. Selecione a caixa de seleção ao lado do gerente membro que você deseja remover.
  5. Clique em Delete.
  6. Clique em Delete para confirmar.
Nota

Depois de remover um gerente membro de um grupo de usuários, a atualização pode levar algum tempo para se espalhar a todos os clientes em seu ambiente de Gerenciamento de Identidade.

Etapas de verificação

  • Verificar se o usuário ou grupo de usuários foi removido da lista de usuários ou grupos de usuários do gerente de membros:

    groups member manager removed

Recursos adicionais

  • Veja ipa group-add-member-manager --help para mais detalhes.

Capítulo 14. Gerenciamento de Grupos de Usuários usando Livros Rápidos Ansíveis

Esta seção apresenta a gestão de grupos de usuários utilizando Livros de Jogadas Ansíveis, incluindo o seguinte:

14.1. Assegurar a presença de grupos e membros do grupo IdM usando Livros didáticos Ansíveis

O procedimento a seguir descreve como garantir a presença de grupos e membros do grupo IdM - tanto usuários como grupos de usuários - usando um livro de jogo possível.

Pré-requisitos

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaserver no mesmo:

    [ipaserver]
    server.idm.example.com
  2. Crie um arquivo de playbook possível com as informações necessárias de usuário e grupo:

    ---
    - name: Playbook to handle groups
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Create group ops with gid 1234
        ipagroup:
          ipaadmin_password: MySecret123
          name: ops
          gidnumber: 1234
    
      - name: Create group sysops
        ipagroup:
          ipaadmin_password: MySecret123
          name: sysops
          user:
          - idm_user
    
      - name: Create group appops
        ipagroup:
          ipaadmin_password: MySecret123
          name: appops
    
      - name: Add group members sysops and appops to group ops
        ipagroup:
          ipaadmin_password: MySecret123
          name: ops
          group:
          - sysops
          - appops
  3. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-group-members.yml

Etapas de verificação

Você pode verificar se o grupo ops contém sysops e appops como membros diretos e idm_user como membro indireto, usando o comando ipa group-show:

  1. Acesse ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Mostrar informações sobre ops:

    ipaserver]$ ipa group-show ops
      Group name: ops
      GID: 1234
      Member groups: sysops, appops
      Indirect Member users: idm_user

    Os grupos appops e sysops - este último incluindo o usuário idm_user - existem na IdM.

Recursos adicionais

  • Para mais informações sobre como garantir a presença de grupos de usuários usando o Ansible, consulte o arquivo /usr/share/doc/ansible-freeipa/README-group.md Markdown.

14.2. Assegurar a presença de gerentes membros em grupos de usuários da IdM usando Livros de Jogadas Ansíveis

O procedimento a seguir descreve como garantir a presença dos gerentes membros da IdM - tanto usuários como grupos de usuários - usando um livro de jogo possível.

Pré-requisitos

  • Você sabe a senha do administrador da IdM.
  • Você instalou o pacote ansible-freeipa no controlador Ansible.
  • Você deve ter o nome do usuário ou do grupo que você está adicionando como gerentes membros e o nome do grupo que você quer que eles gerenciem.

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaserver no mesmo:

    [ipaserver]
    server.idm.example.com
  2. Crie um arquivo de playbook com as informações necessárias de gerenciamento de usuários e membros do grupo:

    ---
    - name: Playbook to handle membership management
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure user test is present for group_a
        ipagroup:
          ipaadmin_password: MySecret123
          name: group_a
          membermanager_user: test
    
      - name: Ensure group_admins is present for group_a
        ipagroup:
          ipaadmin_password: MySecret123
          name: group_a
          membermanager_group: group_admins
  3. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-member-managers-user-groups.yml

Etapas de verificação

Você pode verificar se o grupo group_a contém test como gerente membro e group_admins é um gerente membro de group_a usando o comando ipa group-show:

  1. Acesse ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Mostrar informações sobre managergroup1:

    ipaserver]$ ipa group-show group_a
      Group name: group_a
      GID: 1133400009
      Membership managed by groups: group_admins
      Membership managed by users: test

Recursos adicionais

  • Ver ipa host-add-member-manager --help.
  • Veja a página de manual ipa.

14.3. Assegurar a ausência de gerentes membros em grupos de usuários da IdM usando Livros de Jogadas Ansíveis

O procedimento a seguir descreve a garantia da ausência dos gerentes membros da IdM - tanto usuários como grupos de usuários - usando um Livro de Jogadas Possível.

Pré-requisitos

  • Você sabe a senha do administrador da IdM.
  • Você instalou o pacote ansible-freeipa no controlador Ansible.
  • Você deve ter o nome do usuário ou do grupo de membros existentes que você está removendo e o nome do grupo que eles estão gerenciando.

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaserver no mesmo:

    [ipaserver]
    server.idm.example.com
  2. Crie um arquivo de playbook com as informações necessárias de gerenciamento de usuários e membros do grupo:

    ---
    - name: Playbook to handle membership management
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure member manager user and group members are absent for group_a
        ipagroup:
          ipaadmin_password: MySecret123
          name: group_a
          membermanager_user: test
          membermanager_group: group_admins
          action: member
          state: absent
  3. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-member-managers-are-absent.yml

Etapas de verificação

Você pode verificar se o grupo group_a não contém test como gerente membro e group_admins como gerente membro de group_a, usando o comando ipa group-show:

  1. Acesse ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Exibir informações sobre o grupo_a:

    ipaserver]$ ipa group-show group_a
      Group name: group_a
      GID: 1133400009

Recursos adicionais

  • Ver ipa host-remove-member-manager --help.
  • Veja a página de manual ipa.

Capítulo 15. Automatização da filiação em grupo usando IdM CLI

O uso da associação automática a grupos permite atribuir usuários e anfitriões a grupos automaticamente com base em seus atributos. Por exemplo, você pode:

  • Dividir as entradas de usuários dos funcionários em grupos com base no gerente do funcionário, local ou qualquer outro atributo.
  • Dividir os anfitriões com base em sua classe, localização, ou qualquer outro atributo.
  • Adicionar todos os usuários ou todos os anfitriões a um único grupo global.

Este capítulo cobre os seguintes tópicos:

15.1. Benefícios da associação automática em grupo

O uso da associação automática para os usuários permite que você o faça:

  • Reduce the overhead of manually managing group memberships

    Você não precisa mais designar cada usuário e hospedar grupos manualmente.

  • Improve consistency in user and host management

    Os usuários e anfitriões são designados para grupos com base em critérios estritamente definidos e avaliados automaticamente.

  • Simplify the management of group-based settings

    Várias configurações são definidas para grupos e depois aplicadas aos membros individuais do grupo, por exemplo sudo regras, montagem automática, ou controle de acesso. A adição de usuários e anfitriões aos grupos torna o gerenciamento destas configurações mais fácil.

15.2. Regras de membros automáticos

Ao configurar a adesão automática ao grupo, o administrador define as regras de adesão automática. Uma regra de membro automático se aplica a um usuário específico ou a um grupo alvo anfitrião. Ela não pode se aplicar a mais de um grupo de cada vez.

Após criar uma regra, o administrador acrescenta condições a ela. Estas especificam quais usuários ou anfitriões são incluídos ou excluídos do grupo alvo:

  • Inclusive conditions

    Quando um usuário ou anfitrião cumpre uma condição de inclusão, ele será incluído no grupo alvo.

  • Exclusive conditions

    Quando um usuário ou anfitrião cumpre uma condição exclusiva, ele não será incluído no grupo alvo.

As condições são especificadas como expressões regulares no formato Perl-compatible regular expressions (PCRE). Para mais informações sobre PCRE, consulte a página de manual pcresyntax(3).

Nota

IdM avalia as condições exclusivas antes das condições inclusivas. Em caso de conflito, as condições exclusivas prevalecem sobre as condições inclusivas.

Uma regra de membro automático se aplica a cada entrada criada no futuro. Estas entradas serão automaticamente adicionadas ao grupo alvo especificado. Se uma entrada atender às condições especificadas em várias regras de membros automáticos, ela será adicionada a todos os grupos correspondentes.

As entradas existentes são not afetadas pela nova regra. Se você quiser alterar as entradas existentes, consulte Aplicando regras de membros automáticos às entradas existentes usando o IdM CLI.

15.3. Adicionando uma regra de membro automático usando IdM CLI

Esta seção descreve a adição de uma regra de membro automático usando o IdM CLI. Para informações sobre regras de membros automáticos, consulte Regras de membros automáticos.

Depois de adicionar uma regra de membro automático, você pode adicionar condições a ela usando o procedimento descrito em Adição de uma condição a uma regra de membro automático.

Nota

As entradas existentes são not afetadas pela nova regra. Se você quiser alterar as entradas existentes, consulte Aplicando regras de membros automáticos às entradas existentes usando o IdM CLI.

Pré-requisitos

Procedimento

  1. Digite o comando ipa automember-add para adicionar uma regra de membro automático.
  2. Quando solicitado, especifique:

    • Automember rule. Este é o nome do grupo alvo.
    • Grouping Type. Isto especifica se a regra tem como alvo um grupo de usuários ou um grupo anfitrião. Para visar um grupo de usuários, digite group. Para visar um grupo de usuários, digite hostgroup.

    Por exemplo, para adicionar uma regra de membro automático para um grupo de usuários chamado user_group:

    $ ipa automember-add
    Automember Rule: user_group
    Grouping Type: group
    --------------------------------
    Added automember rule "user_group"
    --------------------------------
        Automember Rule: user_group

Etapas de verificação

15.4. Adicionando uma condição a uma regra de membro automático usando IdM CLI

Esta seção descreve como adicionar uma condição a uma regra de membro automático usando o IdM CLI. Para informações sobre regras de membros automáticos, consulte Regras de membros automáticos.

Pré-requisitos

Procedimento

  1. Definir uma ou mais condições inclusivas ou exclusivas usando o comando ipa automember-add-condition.
  2. Quando solicitado, especifique:

    • Automember rule. Este é o nome da regra alvo. Veja as regras do Automember para detalhes.
    • Attribute Key. Isto especifica o atributo de entrada ao qual o filtro será aplicado. Por exemplo, uid para usuários.
    • Grouping Type. Isto especifica se a regra tem como alvo um grupo de usuários ou um grupo anfitrião. Para visar um grupo de usuários, digite group. Para visar um grupo de usuários, digite hostgroup.
    • Inclusive regex e Exclusive regex. Estes especificam uma ou mais condições como expressões regulares. Se você quiser especificar apenas uma condição, pressione Enter quando solicitado pela outra.

    Por exemplo, a seguinte condição visa todos os usuários com qualquer valor (.*) em seu atributo de login de usuário (uid).

    $ ipa automember-add-condition
    Automember Rule: user_group
    Attribute Key: uid
    Grouping Type: group
    [Inclusive Regex]: .*
    [Exclusive Regex]:
    ----------------------------------
    Added condition(s) to "user_group"
    ----------------------------------
      Automember Rule: user_group
      Inclusive Regex: uid=.*
    ----------------------------
    Number of conditions added 1
    ----------------------------

    Como outro exemplo, você pode usar uma regra de associação automática para atingir todos os usuários Windows sincronizados a partir do Active Directory (AD). Para conseguir isso, crie uma condição que vise todos os usuários com ntUser em seu atributo objectClass, que é compartilhado por todos os usuários do AD:

    $ ipa automember-add-condition
    Automember Rule: ad_users
    Attribute Key: objectclass
    Grouping Type: group
    [Inclusive Regex]: ntUser
    [Exclusive Regex]:
    -------------------------------------
    Added condition(s) to "ad_users"
    -------------------------------------
      Automember Rule: ad_users
      Inclusive Regex: objectclass=ntUser
    ----------------------------
    Number of conditions added 1
    ----------------------------

Etapas de verificação

15.5. Visualização das regras existentes de membros automáticos usando IdM CLI

Esta seção descreve como visualizar as regras de membros automáticos existentes usando o IdM CLI.

Pré-requisitos

Procedimento

  1. Digite o comando ipa automember-find.
  2. Quando solicitado, especifique o endereço Grouping type:

    • Para visar um grupo de usuários, digite group.
    • Para visar um grupo anfitrião, digite hostgroup.

      Por exemplo:

    $ ipa automember-find
    Grouping Type: group
    ---------------
    1 rules matched
    ---------------
      Automember Rule: user_group
      Inclusive Regex: uid=.*
    ----------------------------
    Number of entries returned 1
    ----------------------------

15.6. Eliminação de uma regra de membro automático usando IdM CLI

Esta seção descreve como excluir uma regra de membro automático usando o IdM CLI.

A eliminação de uma regra de membro automático também elimina todas as condições associadas com a regra. Para remover apenas condições específicas de uma regra, consulte Remoção de uma condição de uma regra de membro automático usando o IdM CLI.

Pré-requisitos

Procedimento

  1. Digite o comando ipa automember-del.
  2. Quando solicitado, especifique:

    • Automember rule. Esta é a regra que você quer eliminar.
    • Grouping rule. Isto especifica se a regra que você deseja excluir é para um grupo de usuários ou para um grupo anfitrião. Digite group ou hostgroup.

15.7. Removendo uma condição de uma regra de membro automático usando IdM CLI

Esta seção descreve como remover uma condição específica de uma regra de membro automático.

Pré-requisitos

Procedimento

  1. Digite o comando ipa automember-remove-condition.
  2. Quando solicitado, especifique:

    • Automember rule. Este é o nome da regra da qual você quer remover uma condição.
    • Attribute Key. Este é o atributo de entrada de destino. Por exemplo, uid para usuários.
    • Grouping Type. Isto especifica se a condição que você deseja excluir é para um grupo de usuários ou para um grupo anfitrião. Digite group ou hostgroup.
    • Inclusive regex e Exclusive regex. Estes especificam as condições que você deseja remover. Se você quiser especificar apenas uma condição, pressione Enter quando solicitado pela outra.

      Por exemplo:

    $ ipa automember-remove-condition
    Automember Rule: user_group
    Attribute Key: uid
    Grouping Type: group
    [Inclusive Regex]: .*
    [Exclusive Regex]:
    -----------------------------------
    Removed condition(s) from "user_group"
    -----------------------------------
      Automember Rule: user_group
    ------------------------------
    Number of conditions removed 1
    ------------------------------

15.8. Aplicação de regras de membros automáticos às entradas existentes usando IdM CLI

As regras de membro automático se aplicam automaticamente às entradas de usuário e anfitrião criadas após a adição das regras. Elas não são aplicadas retroativamente às entradas que existiam antes de as regras serem adicionadas.

Para aplicar as regras de associação automática às entradas previamente adicionadas, você tem que reconstruir manualmente a associação automática. A reconstrução da associação automática reavalia todas as regras de associação automática existentes e as aplica ou a todas as entradas de usuário ou anfitrião, ou a entradas específicas.

Nota

Reconstruir a associação automática does not remover entradas de usuários ou anfitriões de grupos, mesmo que as entradas não correspondam mais às condições de inclusão do grupo. Para removê-las manualmente, veja Removendo um membro de um grupo de usuários usando o IdM CLI ou Removendo membros do grupo anfitrião IdM usando o CLI.

Pré-requisitos

Procedimento

  • Para reconstruir a associação automática, digite o comando ipa automember-rebuild. Use as seguintes opções para especificar as entradas a serem alvo:

    • Para reconstruir a associação automática para todos os usuários, use a opção --type=group:

      $ ipa automember-rebuild --type=group
      --------------------------------------------------------
      Automember rebuild task finished. Processed (9) entries.
      --------------------------------------------------------
    • Para reconstruir a associação automática para todos os anfitriões, use a opção --type=hostgroup.
    • Para reconstruir a associação automática para um usuário ou usuários específicos, use o --users=target_user opção:

      $ ipa automember-rebuild --users=target_user1 --users=target_user2
      --------------------------------------------------------
      Automember rebuild task finished. Processed (2) entries.
      --------------------------------------------------------
    • Para reconstruir a associação automática para um determinado anfitrião ou anfitriões, use o --hosts=client.idm.example.com opção.

15.9. Configuração de um grupo de membros automáticos padrão usando IdM CLI

Quando você configura um grupo de membros automáticos padrão, novas entradas de usuário ou host que não correspondem a nenhuma regra de membros automáticos são automaticamente adicionadas a este grupo padrão.

Pré-requisitos

Procedimento

  1. Digite o comando ipa automember-default-group-set para configurar um grupo de membros automáticos padrão.
  2. Quando solicitado, especifique:

    • Default (fallback) Group, que especifica o nome do grupo-alvo.
    • Grouping Type, que especifica se o alvo é um grupo de usuários ou um grupo anfitrião. Para visar um grupo de usuários, digite group. Para visar um grupo de usuários, digite hostgroup.

      Por exemplo:

      $ ipa automember-default-group-set
      Default (fallback) Group: default_user_group
      Grouping Type: group
      ---------------------------------------------------
      Set default (fallback) group for automember "default_user_group"
      ---------------------------------------------------
        Default (fallback) Group: cn=default_user_group,cn=groups,cn=accounts,dc=example,dc=com
    Nota

    Para remover o grupo de membros automáticos padrão atual, digite o comando ipa automember-default-group-remove.

Etapas de verificação

  • Para verificar se o grupo está configurado corretamente, digite o comando ipa automember-default-group-show. O comando exibe o grupo de membros automáticos padrão atual. Por exemplo:

    $ ipa automember-default-group-show
    Grouping Type: group
      Default (fallback) Group: cn=default_user_group,cn=groups,cn=accounts,dc=example,dc=com

Capítulo 16. Automatizando a adesão de grupos usando IdM Web UI

O uso da associação automática a grupos permite atribuir usuários e anfitriões a grupos automaticamente com base em seus atributos. Por exemplo, você pode:

  • Dividir as entradas de usuários dos funcionários em grupos com base no gerente do funcionário, local ou qualquer outro atributo.
  • Dividir os anfitriões com base em sua classe, localização, ou qualquer outro atributo.
  • Adicionar todos os usuários ou todos os anfitriões a um único grupo global.

Este capítulo cobre os seguintes tópicos:

16.1. Benefícios da associação automática em grupo

O uso da associação automática para os usuários permite que você o faça:

  • Reduce the overhead of manually managing group memberships

    Você não precisa mais designar cada usuário e hospedar grupos manualmente.

  • Improve consistency in user and host management

    Os usuários e anfitriões são designados para grupos com base em critérios estritamente definidos e avaliados automaticamente.

  • Simplify the management of group-based settings

    Várias configurações são definidas para grupos e depois aplicadas aos membros individuais do grupo, por exemplo sudo regras, montagem automática, ou controle de acesso. A adição de usuários e anfitriões aos grupos torna o gerenciamento destas configurações mais fácil.

16.2. Regras de membros automáticos

Ao configurar a adesão automática ao grupo, o administrador define as regras de adesão automática. Uma regra de membro automático se aplica a um usuário específico ou a um grupo alvo anfitrião. Ela não pode se aplicar a mais de um grupo de cada vez.

Após criar uma regra, o administrador acrescenta condições a ela. Estas especificam quais usuários ou anfitriões são incluídos ou excluídos do grupo alvo:

  • Inclusive conditions

    Quando um usuário ou anfitrião cumpre uma condição de inclusão, ele será incluído no grupo alvo.

  • Exclusive conditions

    Quando um usuário ou anfitrião cumpre uma condição exclusiva, ele não será incluído no grupo alvo.

As condições são especificadas como expressões regulares no formato Perl-compatible regular expressions (PCRE). Para mais informações sobre PCRE, consulte a página de manual pcresyntax(3).

Nota

IdM avalia as condições exclusivas antes das condições inclusivas. Em caso de conflito, as condições exclusivas prevalecem sobre as condições inclusivas.

Uma regra de membro automático se aplica a cada entrada criada no futuro. Estas entradas serão automaticamente adicionadas ao grupo alvo especificado. Se uma entrada atender às condições especificadas em várias regras de membros automáticos, ela será adicionada a todos os grupos correspondentes.

As entradas existentes são not afetadas pela nova regra. Se você quiser alterar as entradas existentes, consulte Aplicando regras de membros automáticos às entradas existentes usando a interface Web do IdM.

16.3. Adicionando uma regra de membro automático usando IdM Web UI

Esta seção descreve a adição de uma regra de membro automático usando a interface de usuário do IdM Web. Para obter informações sobre regras de membros automáticos, consulte Regras de membros automáticos.

Nota

As entradas existentes são not afetadas pela nova regra. Se você quiser alterar as entradas existentes, consulte Aplicando regras de membros automáticos às entradas existentes usando a interface Web do IdM.

Pré-requisitos

  • Você está logado na IDM Web UI.
  • Você deve ser um membro do grupo admins.
  • O grupo alvo da nova regra existe na IdM.

Procedimento

  1. Clique Identity → Automember, e selecione User group rules ou Host group rules.
  2. Clique em Add.
  3. No campo Automember rule, selecione o grupo ao qual a regra será aplicada. Este é o nome do grupo-alvo.

    automember rule add
  4. Clique em Add para confirmar.
  5. Opcional: Você pode adicionar condições à nova regra usando o procedimento descrito em Adicionar uma condição a uma regra de membro automático usando IdM Web UI.

16.4. Adicionando uma condição a uma regra de membro automático usando IdM Web UI

Esta seção descreve como adicionar uma condição a uma regra de membro automático usando a interface de usuário do IdM Web. Para informações sobre regras de membros automáticos, consulte Regras de membros automáticos.

Pré-requisitos

  • Você está logado na IDM Web UI.
  • Você deve ser um membro do grupo admins.
  • A regra do alvo existe na IdM.

Procedimento

  1. Clique Identity → Automember, e selecione User group rules ou Host group rules.
  2. Clique na regra à qual você deseja acrescentar uma condição.
  3. Nas seções Inclusive ou Exclusive, clique em Adicionar.

    automember condition add
  4. No campo Attribute, selecione o atributo desejado, por exemplo uid.
  5. No campo Expression, defina uma expressão regular.
  6. Clique em Add.

    Por exemplo, a seguinte condição visa todos os usuários com qualquer valor (.*) em seu atributo ID de usuário (uid).

    automember add

16.5. Visualizando as regras e condições de membros automáticos existentes usando IdM Web UI

Esta seção descreve como visualizar as regras e condições de membros automáticos existentes usando a IDM Web UI.

Pré-requisitos

  • Você está logado na IDM Web UI.
  • Você deve ser um membro do grupo admins.

Procedimento

  1. Clique em Identity → Automember, e selecione User group rules ou Host group rules para visualizar as respectivas regras de membros automáticos.
  2. Opcional: Clique em uma regra para ver as condições para essa regra nas seções Inclusive ou Exclusive.

    automember conditions

16.6. Eliminação de uma regra de membro automático usando IdM Web UI

Esta seção descreve como excluir uma regra de membro automático usando a interface de usuário do IdM Web.

A eliminação de uma regra de membro automático também elimina todas as condições associadas com a regra. Para remover apenas condições específicas de uma regra, consulte Removendo uma condição de uma regra de membro automático usando a IDM Web UI.

Pré-requisitos

  • Você está logado na IDM Web UI.
  • Você deve ser um membro do grupo admins.

Procedimento

  1. Clique em Identity → Automember, e selecione User group rules ou Host group rules para visualizar as respectivas regras de membros automáticos.
  2. Selecione a caixa de seleção ao lado da regra que você deseja remover.
  3. Clique em Delete.

    automember rule delete
  4. Clique em Delete para confirmar.

16.7. Removendo uma condição de uma regra de membro automático usando IdM Web UI

Esta seção descreve como remover uma condição específica de uma regra de membro automático usando a IDM Web UI.

Pré-requisitos

  • Você está logado na IDM Web UI.
  • Você deve ser um membro do grupo admins.

Procedimento

  1. Clique em Identity → Automember, e selecione User group rules ou Host group rules para visualizar as respectivas regras de membros automáticos.
  2. Clique em uma regra para ver as condições para essa regra nas seções Inclusive ou Exclusive.
  3. Selecione a caixa de seleção ao lado das condições que você deseja remover.
  4. Clique em Delete.

    automember condition remove
  5. Clique em Delete para confirmar.

16.8. Aplicação de regras de membros automáticos às entradas existentes usando a interface Web do IdM

As regras de membro automático se aplicam automaticamente às entradas de usuário e anfitrião criadas após a adição das regras. Elas não são aplicadas retroativamente às entradas que existiam antes de as regras serem adicionadas.

Para aplicar as regras de associação automática às entradas previamente adicionadas, você tem que reconstruir manualmente a associação automática. A reconstrução da associação automática reavalia todas as regras de associação automática existentes e as aplica ou a todas as entradas de usuário ou anfitrião, ou a entradas específicas.

Nota

Reconstruir a associação automática does not remover entradas de usuários ou anfitriões de grupos, mesmo que as entradas não correspondam mais às condições de inclusão do grupo. Para removê-los manualmente, veja Removendo um membro de um grupo de usuários usando a IDM Web UI ou Removendo membros do grupo anfitrião na IDM Web UI.

16.8.1. Reconstruindo a associação automática para todos os usuários ou anfitriões

Esta seção descreve como reconstruir a associação automática para todas as entradas de usuário ou anfitrião.

Pré-requisitos

  • Você está logado na IDM Web UI.
  • Você deve ser um membro do grupo admins.

Procedimento

  1. Selecione IdentityUsers ou Hosts.
  2. Clique ActionsRebuild auto membership.

    automember rebuild

16.8.2. Reconstrução de associação automática apenas para um único usuário ou host

Esta seção descreve como reconstruir a associação automática para um usuário ou host entry específico.

Pré-requisitos

  • Você está logado na IDM Web UI.
  • Você deve ser um membro do grupo admins.

Procedimento

  1. Selecione IdentityUsers ou Hosts.
  2. Clique no nome do usuário ou host desejado.
  3. Clique ActionsRebuild auto membership.

    automember rebuild single

16.9. Configuração de um grupo de usuários padrão usando o IdM Web UI

Quando você configura um grupo de usuários padrão, novas entradas de usuário que não correspondem a nenhuma regra de membro automático são automaticamente adicionadas a este grupo padrão.

Pré-requisitos

  • Você está logado na IDM Web UI.
  • Você deve ser um membro do grupo admins.
  • O grupo de usuários alvo que você deseja definir como padrão existe na IdM.

Procedimento

  1. Clique em Identity → Automember, e selecione User group rules.
  2. No campo Default user group, selecione o grupo que você deseja definir como o grupo de usuário padrão.

    Setting a default user group

16.10. Configuração de um grupo hospedeiro padrão usando o IdM Web UI

Quando você configura um grupo anfitrião padrão, novas entradas de anfitrião que não correspondem a nenhuma regra de membro automático são automaticamente adicionadas a este grupo padrão.

Pré-requisitos

  • Você está logado na IDM Web UI.
  • Você deve ser um membro do grupo admins.
  • O grupo anfitrião alvo que você deseja definir como padrão existe na IdM.

Procedimento

  1. Clique em Identity → Automember, e selecione Host group rules.
  2. No campo Default host group, selecione o grupo que você deseja definir como o grupo anfitrião padrão.

    Setting a default host group

Capítulo 17. Gerenciando regras de auto-serviço na IdM usando o CLI

Este capítulo introduz regras de auto-atendimento no Gerenciamento de Identidade (IdM) e descreve como criar e editar regras de acesso de auto-atendimento na interface de linha de comando (CLI).

17.1. Controle de acesso de auto-atendimento na IdM

As regras de controle de acesso de auto-atendimento definem quais operações uma entidade IdM pode realizar em sua entrada no Servidor de Diretório IdM: por exemplo, os usuários IdM têm a capacidade de atualizar suas próprias senhas

Este método de controle permite que uma entidade IdM autenticada possa editar atributos específicos dentro de sua entrada LDAP, mas não permite add ou delete operações em toda a entrada.

Atenção

Tenha cuidado ao trabalhar com regras de controle de acesso de auto-atendimento: configurar regras de controle de acesso de forma inadequada pode inadvertidamente elevar os privilégios de uma entidade.

17.2. Criação de regras de auto-serviço usando o CLI

Este procedimento descreve a criação de regras de acesso de auto-atendimento no IdM usando a interface de linha de comando (CLI).

Pré-requisitos

Procedimento

  • Para adicionar uma regra de auto-atendimento, use o comando ipa selfservice-add e especifique as duas opções a seguir:

    --permissions
    estabelece o read e write permissões concedidas pela Instrução de Controle de Acesso (ACI).
    --attrs
    define a lista completa de atributos aos quais esta ACI concede permissão.

Por exemplo, criar uma regra de auto-atendimento que permita aos usuários modificar seus próprios detalhes de nome

$ ipa selfservice-add "Users can manage their own name details" --permissions=write --attrs=givenname --attrs=displayname --attrs=title --attrs=initials
-----------------------------------------------------------
Added selfservice "Users can manage their own name details"
-----------------------------------------------------------
    Self-service name: Users can manage their own name details
    Permissions: write
    Attributes: givenname, displayname, title, initials

17.3. Edição de regras de auto-atendimento usando o CLI

Este procedimento descreve a edição das regras de acesso de auto-atendimento no IdM usando a interface de linha de comando (CLI).

Pré-requisitos

Procedimento

  1. Optional: Exibir as regras de auto-atendimento existentes com o comando ipa selfservice-find.
  2. Optional: Mostrar detalhes da regra de autoatendimento que você deseja modificar com o comando ipa selfservice-show.
  3. Use o comando ipa selfservice-mod para editar uma regra de auto-atendimento.

Por exemplo

$ ipa selfservice-mod "Users can manage their own name details" --attrs=givenname --attrs=displayname --attrs=title --attrs=initials --attrs=surname
--------------------------------------------------------------
Modified selfservice "Users can manage their own name details"
--------------------------------------------------------------
Self-service name: Users can manage their own name details
Permissions: write
Attributes: givenname, displayname, title, initials
Importante

Usando o comando ipa selfservice-mod sobrescreve as permissões e atributos previamente definidos, portanto sempre inclua a lista completa das permissões e atributos existentes junto com quaisquer novos que você queira definir.

Etapas de verificação

  • Use o comando ipa selfservice-show para exibir a regra de auto-atendimento que você editou.
$ ipa selfservice-show "Users can manage their own name details"
--------------------------------------------------------------
Self-service name: Users can manage their own name details
Permissions: write
Attributes: givenname, displayname, title, initials

17.4. Eliminação das regras de auto-atendimento usando o CLI

Este procedimento descreve a eliminação das regras de acesso de auto-atendimento no IdM usando a interface de linha de comando (CLI).

Pré-requisitos

Procedimento

  • Use o comando ipa selfservice-del para excluir uma regra de auto-atendimento.

Por exemplo

$ ipa selfservice-del "Users can manage their own name details"
-----------------------------------------------------------
Deleted selfservice "Users can manage their own name details"
-----------------------------------------------------------

Etapas de verificação

  • Use o comando ipa selfservice-find para exibir todas as regras de auto-atendimento. A regra que você acabou de excluir deve estar faltando.

Capítulo 18. Gerenciando regras de auto-atendimento usando a IDM Web UI

Este capítulo introduz regras de auto-atendimento em Gerenciamento de Identidade (IdM) e descreve como criar e editar regras de acesso de auto-atendimento na interface web (IdM Web UI).

18.1. Controle de acesso de auto-atendimento na IdM

As regras de controle de acesso de auto-atendimento definem quais operações uma entidade IdM pode realizar em sua entrada no Servidor de Diretório IdM: por exemplo, os usuários IdM têm a capacidade de atualizar suas próprias senhas

Este método de controle permite que uma entidade IdM autenticada possa editar atributos específicos dentro de sua entrada LDAP, mas não permite add ou delete operações em toda a entrada.

Atenção

Tenha cuidado ao trabalhar com regras de controle de acesso de auto-atendimento: configurar regras de controle de acesso de forma inadequada pode inadvertidamente elevar os privilégios de uma entidade.

18.2. Criando regras de auto-serviço usando a IDM Web UI

Este procedimento descreve como criar regras de acesso de auto-atendimento no IdM usando a interface web (IdM Web UI).

Pré-requisitos

Procedimento

  1. Abra o sub-menu Role-Based Access Control na aba IPA Server e selecione Self Service Permissions.
  2. Clique em Add na parte superior direita da lista das regras de acesso de auto-atendimento:

    Adicionando uma regra de auto-serviço

  3. A janela Add Self Service Permission se abre. Digite o nome da nova regra de auto-atendimento no campo Self-service name. Os espaços são permitidos:

    Formulário para adicionar uma regra de auto-serviço

  4. Selecione as caixas de seleção ao lado dos atributos que você deseja que os usuários sejam capazes de editar.
  5. Optional: Se um atributo ao qual você gostaria de fornecer acesso não estiver listado, você pode adicionar uma listagem para ele:

    1. Clique no botão Add.
    2. Digite o nome do atributo no campo de texto Attribute da seguinte janela Add Custom Attribute.
    3. Clique no botão OK para adicionar o atributo
    4. Verificar se o novo atributo está selecionado
  6. Clique no botão Add na parte inferior do formulário para salvar a nova regra de auto-serviço.
    Alternativamente, você pode salvar e continuar editando a regra de autoatendimento clicando no botão Add and Edit, ou salvar e adicionar outras regras clicando no botão Add and Add another.

18.3. Edição de regras de auto-serviço usando a IDM Web UI

Este procedimento descreve como editar as regras de acesso de auto-atendimento no IdM usando a interface web (IdM Web UI).

Pré-requisitos

Procedimento

  1. Abra o sub-menu Role-Based Access Control na aba IPA Server e selecione Self Service Permissions.
  2. Clique no nome da regra de auto-atendimento que você deseja modificar.

    Edição de uma regra de auto-atendimento existente

  3. A página de edição só permite editar a lista de atributos que você deseja adicionar ou remover à regra de auto-atendimento. Selecione ou desmarque as caixas de seleção apropriadas.
  4. Clique no botão Save para salvar suas mudanças na regra de auto-atendimento.

18.4. Eliminação das regras de auto-serviço usando a IDM Web UI

Este procedimento descreve como excluir as regras de acesso de auto-atendimento no IdM usando a interface web (IdM Web UI).

Pré-requisitos

Procedimento

  1. Abra o sub-menu Role-Based Access Control na aba IPA Server e selecione Self Service Permissions.
  2. Selecione a caixa de seleção ao lado da regra que você deseja excluir, depois clique no botão Delete, à direita da lista.

    Eliminação de uma regra de auto-atendimento

  3. Um diálogo se abre, clique em Delete para confirmar.

Capítulo 19. Delegar permissões sobre os usuários que utilizam o IdM CLI

A delegação é um dos métodos de controle de acesso na IdM, juntamente com regras de auto-serviço e controle de acesso baseado em papéis.

A delegação é semelhante às funções em que um grupo de usuários recebe permissão para administrar as entradas para outro grupo de usuários. Entretanto, a autoridade delegada limita-se a editar os valores de atributos específicos; ela não concede a capacidade de adicionar ou remover entradas inteiras ou controle sobre atributos não especificados. Além disso, os grupos na autoridade delegada são grupos de usuários IdM existentes ao invés de funções especificamente criadas para controles de acesso.

Este capítulo cobre os seguintes tópicos:

19.1. Regras de delegação

Você pode delegar permissões aos usuários, criando regras de delegação.

As regras de delegação permitem que um grupo específico de usuários realize operações de escrita (edição) em atributos específicos para usuários de outro grupo de usuários. Esta forma de regra de controle de acesso é limitada à edição dos valores de atributos específicos; ela não garante a capacidade de adicionar ou remover entradas inteiras ou controle sobre atributos não especificados.

As regras de delegação utilizam os grupos de usuários existentes na IdM. Você pode usar a delegação para, por exemplo, permitir que o grupo de usuários managers gerencie os atributos selecionados dos usuários no grupo de usuários employees.

19.2. Criação de uma regra de delegação utilizando o IdM CLI

Esta seção descreve como criar uma regra de delegação utilizando o IdM CLI.

Pré-requisitos

  • Você está logado como um membro do grupo admins.

Procedimento

  • Digite o comando ipa delegation-add. Especifique as seguintes opções:

    • --group: o grupo que is being granted permissions para as entradas de usuários no grupo de usuários.
    • --membergroup: o grupo whose entries can be edited pelos membros do grupo da delegação.
    • --permissions: se os usuários terão o direito de visualizar os atributos dados (read) e adicionar ou alterar os atributos dados (write). Se você não especificar as permissões, somente a permissão write será adicionada.
    • --attrs: os atributos que os usuários do grupo membro têm permissão para visualizar ou editar.

    Por exemplo:

$ ipa delegation-add "basic manager attributes" --permissions=read --permissions=write --attrs=businesscategory --attrs=departmentnumber --attrs=employeetype --attrs=employeenumber --group=managers --membergroup=employees
-------------------------------------------
Added delegation "basic manager attributes"
-------------------------------------------
  Delegation name: basic manager attributes
  Permissions: read, write
  Attributes: businesscategory, departmentnumber, employeetype, employeenumber
  Member user group: employees
  User group: managers

19.3. Visualização das regras de delegação existentes usando o IdM CLI

Esta seção descreve como visualizar as regras de delegação existentes utilizando o IdM CLI.

Pré-requisitos

  • Você está logado como um membro do grupo admins.

Procedimento

  • Digite o comando ipa delegation-find:
$ ipa delegation-find
--------------------
1 delegation matched
--------------------
  Delegation name: basic manager attributes
  Permissions: read, write
  Attributes: businesscategory, departmentnumber, employeenumber, employeetype
  Member user group: employees
  User group: managers
----------------------------
Number of entries returned 1
----------------------------

19.4. Modificando uma regra de delegação usando IdM CLI

Esta seção descreve como modificar uma regra de delegação existente usando o IdM CLI.

Importante

A opção --attrs sobrescreve qualquer que tenha sido a lista anterior de atributos suportados, portanto sempre inclua a lista completa de atributos junto com quaisquer novos atributos. Isto também se aplica à opção --permissions.

Pré-requisitos

  • Você está logado como um membro do grupo admins.

Procedimento

  • Digite o comando ipa delegation-mod com as mudanças desejadas. Por exemplo, para adicionar o atributo displayname à regra de exemplo basic manager attributes:

    $ ipa delegation-mod "basic manager attributes" --attrs=businesscategory --attrs=departmentnumber --attrs=employeetype --attrs=employeenumber --attrs=displayname
    ----------------------------------------------
    Modified delegation "basic manager attributes"
    ----------------------------------------------
      Delegation name: basic manager attributes
      Permissions: read, write
      Attributes: businesscategory, departmentnumber, employeetype, employeenumber, displayname
      Member user group: employees
      User group: managers

19.5. Eliminação de uma regra de delegação usando IdM CLI

Esta seção descreve como excluir uma regra de delegação existente usando o IdM CLI.

Pré-requisitos

  • Você está logado como um membro do grupo admins.

Procedimento

  • Digite o comando ipa delegation-del.
  • Quando solicitado, digite o nome da regra da delegação que você deseja excluir:

    $ ipa delegation-del
    Delegation name: basic manager attributes
    ---------------------------------------------
    Deleted delegation "basic manager attributes"
    ---------------------------------------------

Capítulo 20. Delegando permissões sobre usuários que utilizam IdM WebUI

A delegação é um dos métodos de controle de acesso na IdM, juntamente com regras de auto-serviço e controle de acesso baseado em papéis.

A delegação é semelhante às funções em que um grupo de usuários recebe permissão para administrar as entradas para outro grupo de usuários. Entretanto, a autoridade delegada limita-se a editar os valores de atributos específicos; ela não concede a capacidade de adicionar ou remover entradas inteiras ou controle sobre atributos não especificados. Além disso, os grupos na autoridade delegada são grupos de usuários IdM existentes ao invés de funções especificamente criadas para controles de acesso.

Este capítulo cobre os seguintes tópicos:

20.1. Regras de delegação

Você pode delegar permissões aos usuários, criando regras de delegação.

As regras de delegação permitem que um grupo específico de usuários realize operações de escrita (edição) em atributos específicos para usuários de outro grupo de usuários. Esta forma de regra de controle de acesso é limitada à edição dos valores de atributos específicos; ela não garante a capacidade de adicionar ou remover entradas inteiras ou controle sobre atributos não especificados.

As regras de delegação utilizam os grupos de usuários existentes na IdM. Você pode usar a delegação para, por exemplo, permitir que o grupo de usuários managers gerencie os atributos selecionados dos usuários no grupo de usuários employees.

20.2. Criando uma regra de delegação usando IdM WebUI

Esta seção descreve como criar uma regra de delegação utilizando a IdM WebUI.

Pré-requisitos

  • Você está logado na IDM Web UI como um membro do grupo admins.

Procedimento

  1. A partir do menu IPA Server, clique Role-Based Access ControlDelegations.
  2. Clique em Add.

    delegation list add
  3. Na janela Add delegation, faça o seguinte:

    1. Nomear a nova regra da delegação.
    2. Defina as permissões selecionando as caixas de seleção que indicam se os usuários terão o direito de visualizar os atributos dados (read) e adicionar ou alterar os atributos dados (write).
    3. No menu suspenso Grupo de usuários, selecione o grupo who is being granted permissions para visualizar ou editar as entradas dos usuários no grupo de membros.
    4. No menu suspenso Member user group, selecione o grupo whose entries can be edited pelos membros do grupo da delegação.
    5. Na caixa de atributos, selecione as caixas de seleção pelos atributos para os quais você deseja conceder permissões.

      delegation add UPDATED
    6. Clique no botão Add para salvar a nova regra da delegação.

20.3. Visualização das regras de delegação existentes usando IdM WebUI

Esta seção descreve como visualizar as regras de delegação existentes utilizando a IdM WebUI.

Pré-requisitos

  • Você está logado na IDM Web UI como um membro do grupo admins.

Procedimento

  1. A partir do menu IPA Server, clique Role-Based Access ControlDelegations.

    delegation list

20.4. Modificando uma regra de delegação usando IdM WebUI

Esta seção descreve como modificar uma regra de delegação existente usando a IdM WebUI.

Pré-requisitos

  • Você está logado na IDM Web UI como um membro do grupo admins.

Procedimento

  1. A partir do menu IPA Server, clique Role-Based Access ControlDelegations.

    delegation list
  2. Clique sobre a regra que você deseja modificar.
  3. Fazer as mudanças desejadas:

    • Mude o nome da regra.
    • Alterar as permissões concedidas selecionando as caixas de seleção que indicam se os usuários terão o direito de visualizar os atributos dados (read) e adicionar ou alterar os atributos dados (write).
    • No menu suspenso Grupo de usuários, selecione o grupo who is being granted permissions para visualizar ou editar as entradas dos usuários no grupo de membros.
    • No menu suspenso Member user group, selecione o grupo whose entries can be edited pelos membros do grupo da delegação.
    • Na caixa de atributos, selecione as caixas de seleção pelos atributos para os quais você deseja conceder permissões. Para remover permissões a um atributo, desmarque a caixa de seleção relevante.

      delegation modify
    • Clique no botão Save para salvar as mudanças.

20.5. Eliminação de uma regra de delegação usando IdM WebUI

Esta seção descreve como excluir uma regra de delegação existente usando a IdM WebUI.

Pré-requisitos

  • Você está logado na IDM Web UI como um membro do grupo admins.

Procedimento

  1. A partir do menu IPA Server, clique Role-Based Access ControlDelegations.
  2. Selecione a caixa de seleção ao lado da regra que você deseja remover.
  3. Clique em Delete.

    delegation delete
  4. Clique em Delete para confirmar.

Capítulo 21. Gerenciando controles de acesso baseados em funções na IdM usando o CLI

Este capítulo introduz o controle de acesso baseado em funções no Gerenciamento de Identidade (IdM) e descreve as seguintes operações na interface de linha de comando (CLI):

21.1. Controle de acesso baseado no papel na IdM

O controle de acesso baseado no papel (RBAC) na IdM concede um tipo muito diferente de autoridade aos usuários em comparação com o auto-serviço e os controles de acesso das delegações.

O controle de acesso baseado no papel é composto de três partes:

  • Permissions conceder o direito de realizar uma tarefa específica, como adicionar ou excluir usuários, modificar um grupo, permitir o acesso de leitura, etc.
  • Privileges combinar permissões, por exemplo, todas as permissões necessárias para adicionar um novo usuário.
  • Roles concede um conjunto de privilégios aos usuários, grupos de usuários, anfitriões ou grupos anfitriões.

21.1.1. Permissões na IdM

As permissões são a unidade de nível mais baixo de controle de acesso baseado em funções, elas definem operações junto com as entradas LDAP às quais essas operações se aplicam. Em comparação com os blocos de construção, as permissões podem ser atribuídas a tantos privilégios quantos forem necessários.
Um ou mais rights definem quais operações são permitidas:

  • write
  • read
  • search
  • compare
  • add
  • delete
  • all

Estas operações aplicam-se a três operações básicas targets:

  • subtree: um nome de domínio (DN); a sub-árvore sob este DN
  • target filter: um filtro LDAP
  • target: DN com possíveis wildcards para especificar as entradas

Além disso, as seguintes opções de conveniência definem o(s) atributo(s) correspondente(s):

  • type: um tipo de objeto (usuário, grupo, etc.); conjuntos subtree e target filter
  • memberof: membros de um grupo; estabelece um target filter
  • targetgroup: concede acesso para modificar um grupo específico (como a concessão dos direitos de administrar a adesão ao grupo); estabelece um target

Com as permissões da IdM, você pode controlar quais usuários têm acesso a quais objetos e até quais atributos desses objetos. IdM permite que você permita ou bloqueie atributos individuais ou altere toda a visibilidade de uma função IdM específica, como usuários, grupos ou sudo, para todos os usuários anônimos, todos os usuários autenticados, ou apenas um certo grupo de usuários privilegiados.
Por exemplo, a flexibilidade desta abordagem de permissões é útil para um administrador que deseja limitar o acesso de usuários ou grupos apenas às seções específicas que estes usuários ou grupos precisam acessar e tornar as outras seções completamente ocultas para eles.

Nota

Uma permissão não pode conter outras permissões.

21.1.2. Permissões gerenciadas por padrão

As permissões gerenciadas são permissões que vêm por padrão com a IdM. Elas se comportam como outras permissões criadas pelo usuário, com as seguintes diferenças:

  • Não é possível apagá-los ou modificar seu nome, localização e atributos de destino.
  • Eles têm três conjuntos de atributos:

    • Default, o usuário não pode modificá-los, pois eles são gerenciados pela IdM
    • Included atributos, que são atributos adicionais adicionados pelo usuário
    • Excluded atributos, que são atributos removidos pelo usuário

Uma permissão administrada se aplica a todos os atributos que aparecem no conjunto de atributos padrão e incluídos, mas não no conjunto excluído.

Nota

Embora você não possa excluir uma permissão administrada, a definição de seu tipo de vinculação à permissão e a remoção da permissão administrada de todos os privilégios efetivamente a desativa.

Os nomes de todas as permissões gerenciadas começam com System:, por exemplo System: Add Sudo rule ou System: Modify Services. As versões anteriores do IdM usavam um esquema diferente para as permissões padrão. Por exemplo, o usuário não podia excluí-las e só podia atribuí-las a privilégios. A maioria destas permissões padrão foi transformada em permissões gerenciadas, entretanto, as seguintes permissões ainda utilizam o esquema anterior:

  • Acrescentar a Tarefa de Associação Automember Rebuild
  • Adicionar subentendimentos de configuração
  • Adicionar Acordos de Replicação
  • Retirada de certificado de retenção
  • Obter o status dos Certificados da CA
  • Ler a gama de DNA
  • Modificar a faixa de DNA
  • Leia a configuração dos gerentes do PassSync
  • Modificar a configuração dos gerentes do PassSync
  • Ler Acordos de Replicação
  • Modificar os Acordos de Replicação
  • Remover Acordos de Replicação
  • Leia Configuração do banco de dados LDBM
  • Solicitar Certificado
  • Solicitar Certificado ignorando as ACLs CA
  • Solicitar certificados de um anfitrião diferente
  • Recuperar Certificados do CA
  • Certificado de Revogação
  • Escreva a configuração IPA
Nota

Se você tentar modificar uma permissão gerenciada da linha de comando, o sistema não permite que você altere os atributos que você não pode modificar, o comando falha. Se você tentar modificar uma permissão gerenciada da Web UI, os atributos que você não pode modificar são desativados.

21.1.3. Privilégios na IdM

Um privilégio é um grupo de permissões aplicáveis a uma função.
Enquanto uma permissão fornece os direitos de fazer uma única operação, existem certas tarefas da IdM que requerem múltiplas permissões para ter sucesso. Portanto, um privilégio combina as diferentes permissões necessárias para realizar uma tarefa específica.
Por exemplo, a adição de um usuário requer as seguintes permissões:

  • Criando uma nova entrada de usuário
  • Redefinição de uma senha de usuário
  • Adicionando o novo usuário ao grupo padrão de usuários IPA

A combinação destas três tarefas de baixo nível em uma tarefa de nível superior na forma de um privilégio chamado Add User facilita a gestão de papéis. Além de usuários e grupos de usuários, os privilégios também são atribuídos a hosts e grupos anfitriões, assim como a serviços de rede. Esta prática permite um controle de operações granulado fino por um conjunto de usuários em um conjunto de hosts que utilizam serviços de rede específicos.

Nota

Um privilégio não pode conter outros privilégios.

21.1.4. Papéis na IdM

Uma função é uma lista de privilégios que os usuários especificados para a função possuem.
Com efeito, as permissões concedem a capacidade de executar determinadas tarefas de baixo nível (criar uma entrada de usuário, adicionar uma entrada a um grupo, etc.), os privilégios combinam uma ou mais dessas permissões necessárias para uma tarefa de nível superior (como a criação de um novo usuário em um determinado grupo). As funções reúnem os privilégios conforme necessário: por exemplo, uma função de Administrador de Usuário seria capaz de adicionar, modificar e excluir usuários.

Importante

Os papéis são usados para classificar as ações permitidas. Eles não são usados como uma ferramenta para implementar a separação de privilégios ou para proteger contra a escalada de privilégios.

Nota

Os papéis não podem conter outros papéis.

21.1.5. Papéis pré-definidos na Gestão da Identidade

A Red Hat Identity Management oferece a seguinte gama de funções pré-definidas:

Tabela 21.1. Papéis pré-definidos na gestão da identidade

PapelPrivilégioDescrição

Helpdesk

Modificar Usuários e Redefinir senhas, Modificar a adesão ao Grupo

Responsável pela execução de tarefas simples de administração de usuários

Especialista em Segurança de TI

Netgroups Administrators, HBAC Administrator, Sudo Administrator

Responsável pelo gerenciamento da política de segurança, tais como controles de acesso baseados em host, regras sudo

Especialista em TI

Administradores Host, Administradores do Grupo Host, Administradores de Serviços, Administradores Automount

Responsável pelo gerenciamento dos anfitriões

Arquiteto de Segurança

Administrador de Delegação, Administrador de Replicação, Administrador de Configuração IPA, Administrador de Política de Senha

Responsável pela gestão do ambiente de Gerenciamento de Identidade, criando trusts, criando acordos de replicação

Administrador do usuário

Administradores de Usuários, Administradores de Grupo, Administradores de Etapa de Usuários

Responsável pela criação de usuários e grupos

21.2. Gerenciando as permissões de IdM no CLI

Esta seção descreve como gerenciar as permissões de Gerenciamento de Identidade (IdM) usando a interface de linha de comando (CLI).

Pré-requisitos

Procedimento

  1. Criar novas entradas de permissão com o comando ipa permission-add.
    Por exemplo, para adicionar uma permissão chamada dns admin:

    $ ipa permission-add "dns admin
  2. Especifique as propriedades da permissão com as seguintes opções

    • --bindtype especifica o tipo de regra de vinculação. Esta opção aceita os argumentos all, anonymous, e permission. O tipo de vinculação permission significa que somente os usuários a quem é concedida esta permissão através de uma função podem exercê-la.
      Por exemplo, o tipo de vinculação:

      $ ipa permission-add {\i1}"dns admin\i} --bindtype=all

      Se você não especificar --bindtype, então permission é o valor padrão.

      Nota

      Não é possível acrescentar aos privilégios permissões com um tipo de regra de vinculação sem falta. Também não é possível definir uma permissão já presente em um privilégio para um tipo de regra de vinculação sem falta.

    • --right lista os direitos concedidos pela permissão, ela substitui a opção depreciada --permissions. Os valores disponíveis são add, delete, read, search, compare, write, all.

      Você pode definir vários atributos usando várias opções do --right ou com uma lista separada por vírgula dentro de chaves de caracóis. Por exemplo:

      $ ipa permission-add {\i}"dns admin\i} --right=read --right=write
      $ ipa permission-add "dns admin" --right={read,write}
      Nota

      add e delete são operações de nível básico (por exemplo, excluir um usuário, adicionar um grupo, etc.) enquanto read, search, compare e write são mais de nível de atributo: você pode escrever para userCertificate mas não ler userPassword.

    • --attrs fornece a lista de atributos sobre os quais a permissão é concedida.
      Você pode definir múltiplos atributos usando múltiplas opções --attrs ou listando as opções em uma lista separada por vírgula dentro de chaves de caracóis. Por exemplo:

      $ ipa permission-add {\i1}"dns admin\i} --attrs=descrição --attrs=automountKey
      $ ipa permission-add "dns admin" --attrs={descrição,automountKey}

      Os atributos fornecidos com --attrs devem existir e ser atributos permitidos para o tipo de objeto em questão, caso contrário o comando falha com erros de sintaxe do esquema.

    • --type define o tipo de objeto de entrada ao qual a permissão se aplica, como usuário, host, ou serviço. Cada tipo tem seu próprio conjunto de atributos permitidos.
      Por exemplo, o tipo de objeto de entrada:

      $ ipa permission-add {\i1}"manage service}" --right=all --type=service --attrs=krbprincipalkey --attrs=krbprincipalname --attrs=managedby
    • --subtree dá uma entrada de sub-árvore; o filtro então visa cada entrada abaixo desta entrada de sub-árvore. Fornecer uma entrada de subárvore existente; --subtree não aceita wildcards ou nomes de domínio inexistentes (DNs). Inclua um DN dentro do diretório.
      Como o IdM usa uma estrutura de árvore de diretório simplificada e plana, --subtree pode ser usado para direcionar alguns tipos de entradas, como locais de montagem automática, que são containers ou entradas pai para outras configurações. Por exemplo:

      $ ipa permission-add "manage automount locations" --subtree="ldap://ldap.example.com:389/cn=automount,dc=example,dc=com --right=write --attrs=automountmapname --attrs=automountkey --attrs=automountInformation
      Nota

      As opções --type e --subtree são mutuamente exclusivas: você pode ver a inclusão de filtros para --type como uma simplificação de --subtree, com a intenção de tornar a vida mais fácil para um administrador.

    • --filter usa um filtro LDAP para identificar a quais entradas a permissão se aplica.
      O IdM verifica automaticamente a validade do filtro dado. O filtro pode ser qualquer filtro LDAP válido, por exemplo:

      $ ipa permission-add "gerenciar grupos Windows" --filter="(!(objectclass=posixgroup)){\i1}" --right=write --attrs=descrição
    • --memberof define o filtro alvo para os membros de um determinado grupo após verificar se o grupo existe. Por exemplo, para permitir que os usuários com esta permissão modifiquem a casca de login dos membros do grupo de engenheiros:

      $ ipa permission-add ManageShell --right="write" --type=user --attr=loginshell --memberof=engineers
    • --targetgroup estabelece a meta para o grupo de usuários especificado após verificar se o grupo existe. Por exemplo, deixar aqueles com a permissão escrever o atributo de membro no grupo de engenheiros (para que eles possam adicionar ou remover membros):

      $ ipa permission-add ManageMembers --right="write" --subtree=cn=groups,cn=accounts,dc=example,dc=test --attr=member --targetgroup=engineers
    • Opcionalmente, você pode especificar um nome de domínio de destino (DN)

      • --target especifica o DN a quem aplicar a permissão. Wildcards são aceitos.
      • --targetto especifica a sub-árvore DN para a qual uma entrada pode ser movida.
      • --targetfrom especifica a sub-árvore DN de onde uma entrada pode ser movida.

21.3. Opções de comando para as permissões existentes

Use as seguintes variantes para modificar as permissões existentes, conforme necessário:

  • Para editar as permissões existentes, use o comando ipa permission-mod. Você pode usar as mesmas opções de comando que para adicionar permissões.
  • Para encontrar as permissões existentes, use o comando ipa permission-find. Você pode usar as mesmas opções de comando que para adicionar permissões.
  • Para visualizar uma permissão específica, use o comando ipa permission-show.
    O argumento --raw mostra o ACI bruto 389-ds que é gerado. Por exemplo:

     $ ipa permission-show <permission> --raw
  • O comando ipa permission-del apaga completamente uma permissão.

Recursos adicionais

Para mais detalhes sobre os comandos ipa permission, consulte a página man do ipa e o comando ipa help.

21.4. Gerenciando privilégios de IdM no CLI

Esta seção descreve como gerenciar privilégios de Gerenciamento de Identidade (IdM) usando a interface de linha de comando (CLI).

Pré-requisitos

Procedimento

  1. Adicionar entradas de privilégio usando o comando ipa privilege-add
    Por exemplo, para adicionar um privilégio chamado managing filesystems com uma descrição:

    $ ipa privilege-add "gerenciando sistemas de arquivos" --desc="para sistemas de arquivos"
  2. Atribuir as permissões necessárias ao grupo de privilégios com o comando privilege-add-permission
    Por exemplo, para adicionar as permissões denominadas managing automount e managing ftp services ao privilégio managing filesystems:

    $ ipa privilegio-add-permission {\i1}"gerenciar sistemas de arquivos" --permissões="gerenciar montagem automática" --permissões="gerenciar serviços ftp"

21.5. Opções de comando para privilégios existentes

Use as seguintes variantes para modificar os privilégios existentes, conforme necessário:

  • Para modificar os privilégios existentes, use o comando ipa privilege-mod.
  • Para encontrar privilégios existentes, use o comando ipa privilege-find.
  • Para visualizar um privilégio específico, use o comando ipa privilege-show.
  • O comando ipa privilege-remove-permission retira uma ou mais permissões de um privilégio.
  • O comando ipa privilege-del elimina completamente um privilégio.

Recursos adicionais

Para mais detalhes sobre os comandos ipa privilege, consulte a página man do ipa e o comando ipa help.

21.6. Gerenciando as funções de IdM no CLI

Esta seção descreve como gerenciar as funções de Gerenciamento de Identidade (IdM) usando a interface de linha de comando (CLI).

Pré-requisitos

Procedimento

  1. Acrescentar novas entradas de funções usando o comando ipa role-add:

    $ ipa role-add --desc="User Administrator" useradmin
    ------------------------
    Added role "useradmin"
    ------------------------
    Role name: useradmin
    Description: User Administrator
  2. Acrescente os privilégios necessários à função usando o comando ipa role-add-privilege:

    $ ipa role-add-privilege --privileges="user administrators" useradmin
    Role name: useradmin
    Description: User Administrator
    Privileges: user administrators
    ----------------------------
    Number of privileges added 1
    ----------------------------
  3. Acrescentar os membros requeridos à função usando o comando ipa role-add-member. Os tipos de membros permitidos são: usuários, grupos, anfitriões e grupos de anfitriões.
    Por exemplo, para adicionar o grupo chamado useradmins à função anteriormente criada useradmin:

    $ ipa role-add-member --groups=useradmins useradmin
    Role name: useradmin
    Description: User Administrator
    Member groups: useradmins
    Privileges: user administrators
    -------------------------
    Number of members added 1
    -------------------------

21.7. Opções de comando para as funções existentes

Use as seguintes variantes para modificar as funções existentes, conforme necessário:

  • Para modificar as funções existentes, use o comando ipa role-mod.
  • Para encontrar funções existentes, use o comando ipa role-find.
  • Para visualizar uma função específica, use o comando ipa role-show.
  • Para remover um membro da função, use o comando ipa role-remove-member.
  • O comando ipa role-remove-privilege retira um ou mais privilégios de um papel.
  • O comando ipa role-del elimina completamente um papel.

Recursos adicionais

Para mais detalhes sobre os comandos ipa role, consulte a página man do ipa e o comando ipa help.

Capítulo 22. Gerenciando controles de acesso baseados em funções usando a IDM Web UI

Este capítulo introduz o controle de acesso baseado em funções no Gerenciamento de Identidade (IdM) e descreve as seguintes operações na interface web (Web UI):

22.1. Controle de acesso baseado no papel na IdM

O controle de acesso baseado no papel (RBAC) na IdM concede um tipo muito diferente de autoridade aos usuários em comparação com o auto-serviço e os controles de acesso das delegações.

O controle de acesso baseado no papel é composto de três partes:

  • Permissions conceder o direito de realizar uma tarefa específica, como adicionar ou excluir usuários, modificar um grupo, permitir o acesso de leitura, etc.
  • Privileges combinar permissões, por exemplo, todas as permissões necessárias para adicionar um novo usuário.
  • Roles concede um conjunto de privilégios aos usuários, grupos de usuários, anfitriões ou grupos anfitriões.

22.1.1. Permissões na IdM

As permissões são a unidade de nível mais baixo de controle de acesso baseado em funções, elas definem operações junto com as entradas LDAP às quais essas operações se aplicam. Em comparação com os blocos de construção, as permissões podem ser atribuídas a tantos privilégios quantos forem necessários.
Um ou mais rights definem quais operações são permitidas:

  • write
  • read
  • search
  • compare
  • add
  • delete
  • all

Estas operações aplicam-se a três operações básicas targets:

  • subtree: um nome de domínio (DN); a sub-árvore sob este DN
  • target filter: um filtro LDAP
  • target: DN com possíveis wildcards para especificar as entradas

Além disso, as seguintes opções de conveniência definem o(s) atributo(s) correspondente(s):

  • type: um tipo de objeto (usuário, grupo, etc.); conjuntos subtree e target filter
  • memberof: membros de um grupo; estabelece um target filter
  • targetgroup: concede acesso para modificar um grupo específico (como a concessão dos direitos de administrar a adesão ao grupo); estabelece um target

Com as permissões da IdM, você pode controlar quais usuários têm acesso a quais objetos e até quais atributos desses objetos. IdM permite que você permita ou bloqueie atributos individuais ou altere toda a visibilidade de uma função IdM específica, como usuários, grupos ou sudo, para todos os usuários anônimos, todos os usuários autenticados, ou apenas um certo grupo de usuários privilegiados.
Por exemplo, a flexibilidade desta abordagem de permissões é útil para um administrador que deseja limitar o acesso de usuários ou grupos apenas às seções específicas que estes usuários ou grupos precisam acessar e tornar as outras seções completamente ocultas para eles.

Nota

Uma permissão não pode conter outras permissões.

22.1.2. Permissões gerenciadas por padrão

As permissões gerenciadas são permissões que vêm por padrão com a IdM. Elas se comportam como outras permissões criadas pelo usuário, com as seguintes diferenças:

  • Não é possível apagá-los ou modificar seu nome, localização e atributos de destino.
  • Eles têm três conjuntos de atributos:

    • Default, o usuário não pode modificá-los, pois eles são gerenciados pela IdM
    • Included atributos, que são atributos adicionais adicionados pelo usuário
    • Excluded atributos, que são atributos removidos pelo usuário

Uma permissão administrada se aplica a todos os atributos que aparecem no conjunto de atributos padrão e incluídos, mas não no conjunto excluído.

Nota

Embora você não possa excluir uma permissão administrada, a definição de seu tipo de vinculação à permissão e a remoção da permissão administrada de todos os privilégios efetivamente a desativa.

Os nomes de todas as permissões gerenciadas começam com System:, por exemplo System: Add Sudo rule ou System: Modify Services. As versões anteriores do IdM usavam um esquema diferente para as permissões padrão. Por exemplo, o usuário não podia excluí-las e só podia atribuí-las a privilégios. A maioria destas permissões padrão foi transformada em permissões gerenciadas, entretanto, as seguintes permissões ainda utilizam o esquema anterior:

  • Acrescentar a Tarefa de Associação Automember Rebuild
  • Adicionar subentendimentos de configuração
  • Adicionar Acordos de Replicação
  • Retirada de certificado de retenção
  • Obter o status dos Certificados da CA
  • Ler a gama de DNA
  • Modificar a faixa de DNA
  • Leia a configuração dos gerentes do PassSync
  • Modificar a configuração dos gerentes do PassSync
  • Ler Acordos de Replicação
  • Modificar os Acordos de Replicação
  • Remover Acordos de Replicação
  • Leia Configuração do banco de dados LDBM
  • Solicitar Certificado
  • Solicitar Certificado ignorando as ACLs CA
  • Solicitar certificados de um anfitrião diferente
  • Recuperar Certificados do CA
  • Certificado de Revogação
  • Escreva a configuração IPA
Nota

Se você tentar modificar uma permissão gerenciada da linha de comando, o sistema não permite que você altere os atributos que você não pode modificar, o comando falha. Se você tentar modificar uma permissão gerenciada da Web UI, os atributos que você não pode modificar são desativados.

22.1.3. Privilégios na IdM

Um privilégio é um grupo de permissões aplicáveis a uma função.
Enquanto uma permissão fornece os direitos de fazer uma única operação, existem certas tarefas da IdM que requerem múltiplas permissões para ter sucesso. Portanto, um privilégio combina as diferentes permissões necessárias para realizar uma tarefa específica.
Por exemplo, a adição de um usuário requer as seguintes permissões:

  • Criando uma nova entrada de usuário
  • Redefinição de uma senha de usuário
  • Adicionando o novo usuário ao grupo padrão de usuários IPA

A combinação destas três tarefas de baixo nível em uma tarefa de nível superior na forma de um privilégio chamado Add User facilita a gestão de papéis. Além de usuários e grupos de usuários, os privilégios também são atribuídos a hosts e grupos anfitriões, assim como a serviços de rede. Esta prática permite um controle de operações granulado fino por um conjunto de usuários em um conjunto de hosts que utilizam serviços de rede específicos.

Nota

Um privilégio não pode conter outros privilégios.

22.1.4. Papéis na IdM

Uma função é uma lista de privilégios que os usuários especificados para a função possuem.
Com efeito, as permissões concedem a capacidade de executar determinadas tarefas de baixo nível (criar uma entrada de usuário, adicionar uma entrada a um grupo, etc.), os privilégios combinam uma ou mais dessas permissões necessárias para uma tarefa de nível superior (como a criação de um novo usuário em um determinado grupo). As funções reúnem os privilégios conforme necessário: por exemplo, uma função de Administrador de Usuário seria capaz de adicionar, modificar e excluir usuários.

Importante

Os papéis são usados para classificar as ações permitidas. Eles não são usados como uma ferramenta para implementar a separação de privilégios ou para proteger contra a escalada de privilégios.

Nota

Os papéis não podem conter outros papéis.

22.1.5. Papéis pré-definidos na Gestão da Identidade

A Red Hat Identity Management oferece a seguinte gama de funções pré-definidas:

Tabela 22.1. Papéis pré-definidos na gestão da identidade

PapelPrivilégioDescrição

Helpdesk

Modificar Usuários e Redefinir senhas, Modificar a adesão ao Grupo

Responsável pela execução de tarefas simples de administração de usuários

Especialista em Segurança de TI

Netgroups Administrators, HBAC Administrator, Sudo Administrator

Responsável pelo gerenciamento da política de segurança, tais como controles de acesso baseados em host, regras sudo

Especialista em TI

Administradores Host, Administradores do Grupo Host, Administradores de Serviços, Administradores Automount

Responsável pelo gerenciamento dos anfitriões

Arquiteto de Segurança

Administrador de Delegação, Administrador de Replicação, Administrador de Configuração IPA, Administrador de Política de Senha

Responsável pela gestão do ambiente de Gerenciamento de Identidade, criando trusts, criando acordos de replicação

Administrador do usuário

Administradores de Usuários, Administradores de Grupo, Administradores de Etapa de Usuários

Responsável pela criação de usuários e grupos

22.2. Gerenciando permissões na IDM Web UI

Esta seção descreve como gerenciar as permissões no Gerenciamento de Identidade (IdM) usando a interface web (IdM Web UI).

Pré-requisitos

Procedimento

  1. Para adicionar uma nova permissão, abra o sub-menu Role-Based Access Control na aba IPA Server e selecione Permissions:

    Tarefa de permissões

  2. A lista de permissões é aberta: Clique no botão Add no topo da lista de permissões:

    Adicionando uma nova permissão

  3. O formulário Add Permission é aberto. Especifique o nome da nova permissão e defina suas propriedades de acordo:

    Formulário para adicionar uma permissão

  4. Selecione o tipo apropriado de regra Bind:

    • permission é o tipo de permissão padrão, concedendo acesso através de privilégios e funções
    • all especifica que a permissão se aplica a todos os usuários autenticados
    • anonymous especifica que a permissão se aplica a todos os usuários, incluindo usuários não autenticados

      Nota

      Não é possível acrescentar aos privilégios permissões com um tipo de regra de vinculação sem falta. Também não é possível definir uma permissão já presente em um privilégio para um tipo de regra de vinculação sem falta.

  5. Escolha os direitos a conceder com esta permissão em Granted rights.
  6. Definir o método para identificar as entradas alvo para a permissão:

    • Type especifica um tipo de entrada, como usuário, host, ou serviço. Se você escolher um valor para a configuração Type, uma lista de todos os atributos possíveis que serão acessíveis através deste ACI para esse tipo de entrada aparece em Effective Attributes. Definindo Type define os conjuntos Subtree e Target DN como um dos valores pré-definidos.
    • Subtree (obrigatório) especifica uma entrada de sub-árvore; cada entrada abaixo dessa sub-árvore é então direcionada. Forneça uma entrada de subárvore existente, pois Subtree não aceita wildcards ou nomes de domínio inexistentes (DNs). Por exemplo cn=automount,dc=example,dc=com
    • Extra target filter usa um filtro LDAP para identificar a quais entradas a permissão se aplica. O filtro pode ser qualquer filtro LDAP válido, por exemplo: (!(objectclass=posixgroup))
      IdM verifica automaticamente a validade do filtro dado. Se você inserir um filtro inválido, o IdM o avisa sobre isso quando você tenta salvar a permissão.
    • Target DN especifica o nome de domínio (DN) e aceita wildcards. Por exemplo uid=*,cn=users,cn=accounts,dc=com
    • Member of group estabelece o filtro alvo para os membros do grupo em questão. Depois de especificar as configurações do filtro e clicar em Add, o IdM valida o filtro. Se todas as configurações de permissão estiverem corretas, o IdM realizará a busca. Se algumas das configurações de permissões estiverem incorretas, o IdM exibirá uma mensagem informando sobre qual configuração está incorreta.
  7. Acrescentar atributos à permissão:

    • Se você definir Type, escolha o Effective attributes da lista de atributos ACI disponíveis.
    • Se você não utilizou Type, adicione os atributos manualmente, escrevendo-os no campo Effective attributes. Adicione um único atributo de cada vez; para adicionar vários atributos, clique em Add para adicionar outro campo de entrada.

      Importante

      Se você não definir nenhum atributo para a permissão, então as permissões incluem todos os atributos por padrão.

  8. Termine de acrescentar as permissões com os botões Add na parte inferior do formulário:

    • Clique no botão Add para salvar a permissão e voltar para a lista de permissões.
    • Alternativamente, você pode salvar a permissão e continuar adicionando permissões adicionais na mesma forma, clicando no botão Add and Add another
    • O botão Add and Edit permite que você salve e continue editando a permissão recém-criada.
  9. Optional. Você também pode editar as propriedades de uma permissão existente clicando em seu nome na lista de permissões para exibir a página Permission settings.
  10. Optional. Se você precisar remover uma permissão existente, clique no botão Delete uma vez marcada a caixa de seleção ao lado de seu nome na lista, para exibir o diálogo Remove permissions.

    Nota

    As operações sobre as permissões gerenciadas padrão são restritas: os atributos que você não pode modificar estão desativados na interface web do IdM e você não pode excluir completamente as permissões gerenciadas.
    Entretanto, você pode efetivamente desativar uma permissão gerenciada que tenha um tipo de vínculo definido para permissão, removendo a permissão gerenciada de todos os privilégios.

Por exemplo, deixar aqueles com permissão escrever o atributo de membro no grupo de engenheiros (para que eles possam adicionar ou remover membros):
Exemplo para adicionar uma permissão

22.3. Privilégios de gestão na IdM WebUI

Esta seção descreve como gerenciar privilégios no IdM usando a interface web (IdM Web UI).

Pré-requisitos

Procedimento

  1. Para adicionar um novo privilégio, abra o sub-menu Role-Based Access Control na aba IPA Server e selecione Privileges:

    Tarefa dos privilégios

  2. A lista de privilégios é aberta. Clique no botão Add no topo da lista de privilégios:

    Adicionando um novo privilégio

  3. O formulário Add Privilege é aberto. Digite o nome e uma descrição do privilégio:

    Formulário para adicionar um privilégio

  4. Clique no botão Add and Edit para salvar o novo privilégio e continue até a página de configuração de privilégios para adicionar permissões.
  5. Edite as propriedades dos privilégios clicando no nome dos privilégios na lista de privilégios. A página de configuração de privilégios é aberta.
  6. A guia Permissions exibe uma lista de permissões incluídas no privilégio selecionado. Clique no botão Add no topo da lista para adicionar permissões ao privilégio:

    Acréscimo de permissões

  7. Marque a caixa de seleção ao lado do nome de cada permissão para adicionar, e use o botão > para mover as permissões para a coluna Prospective:

    Seleção de permissões

  8. Confirme clicando no botão Add.
  9. Optional. Se você precisar remover permissões, clique no botão Delete depois de ter marcado a caixa de seleção ao lado da permissão relevante: o diálogo Remove privileges from permissions se abre.
  10. Optional. Se você precisar excluir um privilégio existente, clique no botão Delete depois de marcar a caixa de seleção ao lado de seu nome na lista: o diálogo Remove privileges se abre.

22.4. Funções de gerenciamento na IDM Web UI

Esta seção descreve como gerenciar papéis na Gestão de Identidade (IdM) usando a interface web (IdM Web UI).

Pré-requisitos

Procedimento

  1. Para adicionar um novo papel, abra o sub-menu Role-Based Access Control na aba IPA Server e selecione Roles:

    Tarefa dos papéis

  2. A lista de papéis se abre. Clique no botão Add no topo da lista das instruções de controle de acesso baseadas em funções.

    Adicionando um novo papel

  3. O formulário Add Role é aberto. Digite o nome da função e uma descrição:

    Formulário para adicionar um papel

  4. Clique no botão Add and Edit para salvar a nova função e vá para a página de configuração de funções para adicionar privilégios e usuários.
  5. Edite as propriedades dos papéis, clicando no nome dos papéis na lista de papéis. A página de configuração de funções é aberta.
  6. Adicione membros usando as guias Users, Users Groups, Hosts, Host Groups ou Services, clicando no botão Add no topo da(s) lista(s) relevante(s).

    Adicionando usuários

  7. Na janela que se abre, selecione os membros à esquerda e use o botão > para movê-los para a coluna Prospective.

    Seleção de usuários

  8. Na parte superior da aba Privileges, clique em Add.

    Acréscimo de Privilégios

  9. Selecione os privilégios à esquerda e use o botão > para movê-los para a coluna Prospective.

    Seleção de Privilégios

  10. Clique no botão Add para salvar.
  11. Optional. Se você precisar remover privilégios ou membros de uma função, clique no botão Delete depois de ter marcado a caixa de seleção ao lado do nome da entidade que você deseja remover. Um diálogo se abre.
  12. Optional. Se você precisar remover uma função existente, clique no botão Delete depois de ter marcado a caixa de seleção ao lado de seu nome na lista, para exibir o diálogo Remove roles.

Capítulo 23. Usando uma visualização ID para anular um valor de atributo de usuário em um cliente IdM

Se um usuário de Gerenciamento de Identidade (IdM) desejar substituir alguns de seus atributos de usuário ou grupo armazenados no servidor LDAP do IdM, por exemplo o nome de login, diretório home, certificado usado para autenticação, ou chaves SSH, você como administrador do IdM pode redefinir estes valores para um cliente IdM específico, usando vistas ID do IdM. Por exemplo, você pode especificar um diretório home diferente para um usuário no cliente IdM que o usuário mais comumente usa para fazer o login no IdM.

Este capítulo descreve como redefinir um valor de atributo POSIX associado a um usuário IdM em um host inscrito na IdM como cliente. Especificamente, o capítulo descreve como redefinir o nome de login do usuário e o diretório home.

Este capítulo inclui as seguintes seções:

23.1. Vistas de identificação

Uma visão ID em Gerenciamento de Identidade (IdM) é uma visão do lado do cliente da IdM especificando as seguintes informações:

  • Novos valores para atributos de usuário ou grupo POSIX definidos centralmente
  • O cliente anfitrião ou anfitriões sobre os quais se aplicam os novos valores.

Uma vista de identificação contém uma ou mais sobreposições. Uma sobreposição é uma substituição específica de um valor de atributo POSIX definido centralmente.

Você só pode definir uma visualização de ID para um cliente IdM centralmente nos servidores IdM. Não é possível configurar localmente as sobreposições do lado do cliente para um cliente IdM.

Por exemplo, você pode usar visões de identificação para alcançar os seguintes objetivos:

  • Definir diferentes valores de atributos para diferentes ambientes. Por exemplo, você pode permitir que o administrador do IdM ou outro usuário IdM tenha diferentes diretórios home em diferentes clientes IdM: você pode configurar /home/encrypted/username para ser o diretório home deste usuário em um cliente IdM e /dropbox/username em outro cliente. O uso de visões ID nesta situação é conveniente, pois alternativamente, por exemplo, alterar fallback_homedir, override_homedir ou outras variáveis do diretório home no arquivo /etc/sssd/sssd.conf do cliente afetaria todos os usuários. Veja Adicionando uma visualização ID para substituir um diretório home de usuário IdM em um cliente IdM para um procedimento de exemplo.
  • Substituir um valor de atributo gerado anteriormente por um valor diferente, tal como anular o UID de um usuário. Esta capacidade pode ser útil quando se deseja alcançar uma mudança em todo o sistema que de outra forma seria difícil de fazer no lado do LDAP, por exemplo, fazer do 1009 o UID de um usuário IdM. As faixas de ID do IdM, que são usadas para gerar um UID de usuário IdM, nunca começam tão baixo quanto 1000 ou mesmo 10000. Se existe uma razão para um usuário IdM fazer-se passar por um usuário local com UID 1009 em todos os clientes IdM, você pode usar vistas de ID para substituir o UID deste usuário IdM que foi gerado quando o usuário foi criado no IdM.
Importante

Você só pode aplicar visões de identificação a clientes IdM, não a servidores IdM.

Recursos adicionais

  • Você também pode usar vistas de identificação em ambientes que envolvam o Active Directory (AD). Para detalhes, consulte o capítulo Vistas de ID e Migração de Ambientes Existentes para Confiança no Windows integration guide.
  • Você também pode configurar visões de identificação para hosts que não fazem parte de um domínio de gerenciamento centralizado de identidade. Para detalhes, consulte o capítulo Vistas do lado do cliente SSSD no System-level authentication guide.

23.2. Potencial impacto negativo das visões de identificação no desempenho da SSSD

Quando você define uma visualização de ID, o IdM coloca o valor de override desejado no cache do Daemon System Security Services (SSSD) do servidor IdM. O SSSD rodando em um cliente IdM então recupera o valor de sobreposição do cache do servidor.

A aplicação de uma visualização ID pode ter um impacto negativo no desempenho do System Security Services Daemon (SSSD), pois certas otimizações e visualizações de ID não podem ser executadas ao mesmo tempo. Por exemplo, as visões de ID impedem o SSSD de otimizar o processo de busca de grupos no servidor:

  • Com vistas de identificação, a SSSD deve verificar cada membro da lista de nomes de membros do grupo retornados se o nome do grupo for substituído.
  • Sem visões de identificação, o SSSD só pode coletar os nomes dos usuários do atributo de membro do objeto do grupo.

Este efeito negativo se torna mais aparente quando o cache SSSD está vazio ou depois que você limpa o cache, o que torna todas as entradas inválidas.

23.3. Atributos que uma vista de identificação pode anular

As visualizações de ID consistem em anulações de ID de usuário e de grupo. As sobreposições definem os novos valores dos atributos POSIX.

As substituições de ID de usuário e grupo podem definir novos valores para os seguintes atributos POSIX:

Atributos do usuário
  • Nome de Login (uid)
  • Entrada GECOS (gecos)
  • Número UID (uidNumber)
  • Número GID (gidNumber)
  • Concha de Login (loginShell)
  • Diretório Home (homeDirectory)
  • Chaves públicas SSH (ipaSshPubkey)
  • Certificado (userCertificate)
Atributos do grupo
  • Nome do grupo (cn)
  • Número GID do grupo (gidNumber)

23.4. Obtendo ajuda para os comandos de visualização de identificação

Você pode obter ajuda para os comandos que envolvam as visões de identificação do Gerenciamento de Identidade (IdM) na interface de linha de comando do IdM (CLI).

Pré-requisitos

  • Você obteve um bilhete Kerberos para um usuário da IdM.

Procedimento

  • Para exibir todos os comandos usados para gerenciar visualizações e sobreposições de ID:

    $ ipa help idviews
    ID Views
    
    Manage ID Views
    
    IPA allows to override certain properties of users and groups[...]
    [...]
    Topic commands:
      idoverridegroup-add          Add a new Group ID override
      idoverridegroup-del          Delete a Group ID override
    [...]
  • Para exibir ajuda detalhada para um determinado comando, adicione a opção --help ao comando:

    $ ipa idview-add --help
    Usage: ipa [global-options] idview-add NAME [options]
    
    Add a new ID View.
    Options:
      -h, --help      show this help message and exit
      --desc=STR      Description
    [...]

23.5. Usando uma visão ID para substituir o nome de login de um usuário IdM em um host específico

Esta seção descreve como criar uma visão ID para um cliente específico de Gerenciamento de Identidade (IdM) que sobrepõe um valor de atributo POSIX associado a um usuário específico de IdM. O procedimento usa o exemplo de uma visualização de ID que permite que um usuário IdM chamado idm_user faça o login em um cliente IdM chamado host1 usando o nome de login user_1234.

Pré-requisitos

  • Você está conectado como um usuário com os privilégios necessários, por exemplo admin.

Procedimento

  1. Criar uma nova visão de identificação. Por exemplo, para criar uma visualização de identificação chamada example_for_host1:

    $ ipa idview-add example_for_host1
    ---------------------------
    Added ID View "example_for_host1"
    ---------------------------
      ID View Name: example_for_host1
  2. Adicione uma substituição de usuário à visualização de ID example_for_host1. Para anular o login do usuário:

    • Digite o comando ipa idoverrideuser-add
    • Adicionar o nome da vista de identificação
    • Adicionar o nome do usuário, também chamado de âncora
    • Adicione a opção --login:

      $ ipa idoverrideuser-add example_for_host1 idm_user --login=user_1234
      -----------------------------
      Added User ID override "idm_user"
      -----------------------------
        Anchor to override: idm_user
        User login: user_1234

      Para obter uma lista das opções disponíveis, execute ipa idoverrideuser-add --help.

      Nota

      O comando ipa idoverrideuser-add --certificate substitui todos os certificados existentes para a conta na visualização de ID especificada. Para anexar um certificado adicional, use o comando ipa idoverrideuser-add-cert em seu lugar:

      $ ipa idoverrideuser-add-cert example_for_host1 user --certificate="MIIEATCC..."
  3. Opcional: Usando o comando ipa idoverrideuser-mod, você pode especificar novos valores de atributos para uma substituição de usuário existente.
  4. Aplique example_for_host1 para o anfitrião host1.idm.example.com:

    $ ipa idview-apply example_for_host1 --hosts=host1.idm.example.com
    -----------------------------
    Applied ID View "example_for_host1"
    -----------------------------
    hosts: host1.idm.example.com
    ---------------------------------------------
    Number of hosts the ID View was applied to: 1
    ---------------------------------------------
    Nota

    O comando ipa idview-apply também aceita a opção --hostgroups. A opção aplica a visão ID aos anfitriões que pertencem ao grupo anfitrião especificado, mas não associa a visão ID com o próprio grupo anfitrião. Em vez disso, a opção --hostgroups expande os membros do grupo anfitrião especificado e aplica a opção --hosts individualmente a cada um deles.

    Isto significa que se um anfitrião for adicionado ao grupo anfitrião no futuro, a visão de identificação não se aplica ao novo anfitrião.

  5. Para aplicar a nova configuração ao sistema host1.idm.example.com imediatamente:

    1. SSH para o sistema como raiz:

      $ ssh root@host1
      Password:
    2. Limpar o cache SSSD:

      root@host1 ~]# sss_cache -E
    3. Reinicie o daemon SSSD:
    root@host1 ~]# systemctl restart sssd

Etapas de verificação

  • Se você tem as credenciais do user_1234, você pode usá-las para fazer o login no IdM em host1:

    1. SSH para host1 usando user_1234 como o nome de login:

      [root@r8server ~]# ssh user_1234@host1.idm.example.com
      Password:
      
      Last login: Sun Jun 21 22:34:25 2020 from 192.168.122.229
      [user_1234@host1 ~]$
    2. Exibir o diretório de trabalho:

      [user_1234@host1 ~]$ pwd
      /home/idm_user/
  • Alternativamente, se você tiver credenciais de root em host1, você pode usá-las para verificar a saída do comando id para idm_user e user_1234:

    [root@host1 ~]# id idm_user
    uid=779800003(user_1234) gid=779800003(idm_user) groups=779800003(idm_user)
    [root@host1 ~]# user_1234
    uid=779800003(user_1234) gid=779800003(idm_user) groups=779800003(idm_user)

23.6. Modificando uma visão de ID de IdM

Uma visualização ID em Gerenciamento de Identidade (IdM) substitui um valor de atributo POSIX associado a um usuário específico de IdM. Esta seção descreve como modificar uma visualização de ID existente. Especificamente, descreve como modificar uma visualização de ID para permitir que o usuário chamado idm_user utilize o diretório /home/user_1234/ como diretório home do usuário em vez de /home/idm_user/ no cliente host1.idm.example.com IdM.

Pré-requisitos

  • Você tem acesso root a host1.idm.example.com.
  • Você está conectado como um usuário com os privilégios necessários, por exemplo admin.
  • Você tem uma visualização de identificação configurada para idm_user que se aplica ao cliente host1 IdM.

Procedimento

  1. Como root, crie o diretório que você deseja que idm_user utilize em host1.idm.example.com como o diretório home do usuário:

    [root@host1 /]# mkdir /home/user_1234/
  2. Alterar a propriedade do diretório:

    [root@host1 /]# chown idm_user:idm_user /home/user_1234/
  3. Exibir a visualização de ID, incluindo os anfitriões aos quais a visualização de ID é aplicada atualmente. Para exibir a visualização de ID com o nome example_for_host1:

    $ ipa idview-show example_for_host1 --all
      dn: cn=example_for_host1,cn=views,cn=accounts,dc=idm,dc=example,dc=com
      ID View Name: example_for_host1
      User object override: idm_user
      Hosts the view applies to: host1.idm.example.com
      objectclass: ipaIDView, top, nsContainer

    A saída mostra que a visualização de identificação se aplica atualmente a host1.idm.example.com.

  4. Modificar a substituição do usuário da visualização de ID example_for_host1. Substituir o diretório pessoal do usuário:

    • Digite o comando ipa idoverrideuser-add
    • Adicionar o nome da vista de identificação
    • Adicionar o nome do usuário, também chamado de âncora
    • Adicione a opção --homedir:

      $ ipa idoverrideuser-mod example_for_host1 idm_user --homedir=/home/user_1234
      -----------------------------
      Modified an User ID override "idm_user"
      -----------------------------
        Anchor to override: idm_user
        User login: user_1234
        Home directory: /home/user_1234/

    Para obter uma lista das opções disponíveis, execute ipa idoverrideuser-mod --help.

  5. Para aplicar a nova configuração ao sistema host1.idm.example.com imediatamente:

    1. SSH para o sistema como raiz:

      $ ssh root@host1
      Password:
    2. Limpar o cache SSSD:

      root@host1 ~]# sss_cache -E
    3. Reinicie o daemon SSSD:
    root@host1 ~]# systemctl restart sssd

Etapas de verificação

  1. SSH a host1 como idm_user:

    [root@r8server ~]# ssh idm_user@host1.idm.example.com
    Password:
    
    Last login: Sun Jun 21 22:34:25 2020 from 192.168.122.229
    [user_1234@host1 ~]$
  2. Imprimir o diretório de trabalho:

    [user_1234@host1 ~]$ pwd
    /home/user_1234/

23.7. Adicionando uma visualização ID para substituir um diretório pessoal de usuário IdM em um cliente IdM

Uma visualização ID em Gerenciamento de Identidade (IdM) substitui um valor de atributo POSIX associado a um usuário específico de IdM. Esta seção descreve como criar uma visualização de ID que se aplica a idm_user em um cliente IdM chamado host1 para permitir que o usuário utilize o diretório /home/user_1234/ como o diretório home do usuário em vez de /home/idm_user/.

Pré-requisitos

  • Você tem acesso root a host1.idm.example.com.
  • Você está conectado como um usuário com os privilégios necessários, por exemplo admin.

Procedimento

  1. Como root, crie o diretório que você deseja que idm_user utilize em host1.idm.example.com como o diretório home do usuário:

    [root@host1 /]# mkdir /home/user_1234/
  2. Alterar a propriedade do diretório:

    [root@host1 /]# chown idm_user:idm_user /home/user_1234/
  3. Criar uma visualização de identificação. Por exemplo, para criar uma visualização de identificação com o nome example_for_host1:

    $ ipa idview-add example_for_host1
    ---------------------------
    Added ID View "example_for_host1"
    ---------------------------
      ID View Name: example_for_host1
  4. Adicione uma substituição de usuário à visualização de ID example_for_host1. Para substituir o diretório pessoal do usuário:

    • Digite o comando ipa idoverrideuser-add
    • Adicionar o nome da vista de identificação
    • Adicionar o nome do usuário, também chamado de âncora
    • Adicione a opção --homedir:
    $ ipa idoverrideuser-add example_for_host1 idm_user --homedir=/home/user_1234
    -----------------------------
    Added User ID override "idm_user"
    -----------------------------
      Anchor to override: idm_user
      Home directory: /home/user_1234/
  5. Aplique example_for_host1 para o anfitrião host1.idm.example.com:

    $ ipa idview-apply example_for_host1 --hosts=host1.idm.example.com
    -----------------------------
    Applied ID View "example_for_host1"
    -----------------------------
    hosts: host1.idm.example.com
    ---------------------------------------------
    Number of hosts the ID View was applied to: 1
    ---------------------------------------------
    Nota

    O comando ipa idview-apply também aceita a opção --hostgroups. A opção aplica a visão ID aos anfitriões que pertencem ao grupo anfitrião especificado, mas não associa a visão ID com o próprio grupo anfitrião. Em vez disso, a opção --hostgroups expande os membros do grupo anfitrião especificado e aplica a opção --hosts individualmente a cada um deles.

    Isto significa que se um anfitrião for adicionado ao grupo anfitrião no futuro, a visão de identificação não se aplica ao novo anfitrião.

  6. Para aplicar a nova configuração ao sistema host1.idm.example.com imediatamente:

    1. SSH para o sistema como raiz:

      $ ssh root@host1
      Password:
    2. Limpar o cache SSSD:

      root@host1 ~]# sss_cache -E
    3. Reinicie o daemon SSSD:
    root@host1 ~]# systemctl restart sssd

Etapas de verificação

  1. SSH a host1 como idm_user:

    [root@r8server ~]# ssh idm_user@host1.idm.example.com
    Password:
    Activate the web console with: systemctl enable --now cockpit.socket
    
    Last login: Sun Jun 21 22:34:25 2020 from 192.168.122.229
    [idm_user@host1 /]$
  2. Imprimir o diretório de trabalho:

    [idm_user@host1 /]$ pwd
    /home/user_1234/

23.8. Aplicando uma visão de identificação a um grupo anfitrião da IdM

O comando ipa idview-apply aceita a opção --hostgroups. Entretanto, a opção atua como uma operação única que aplica a visão ID aos anfitriões que atualmente pertencem ao grupo hospedeiro especificado, mas não associa dinamicamente a visão ID com o próprio grupo hospedeiro. A opção --hostgroups expande os membros do grupo hospedeiro especificado e aplica a opção --hosts individualmente a cada um deles.

Se você adicionar um novo host ao grupo anfitrião mais tarde, você deve aplicar a visualização de ID ao novo host manualmente, usando o comando ipa idview-apply com a opção --hosts.

Da mesma forma, se você remover um anfitrião de um grupo anfitrião, a visão de identificação ainda é atribuída ao anfitrião após a remoção. Para desaplicar a visão ID do hospedeiro removido, você deve executar a ipa idview-unapply id_view_name --hosts=name_of_the_removed_host comando.

Esta seção descreve como atingir os seguintes objetivos:

  1. Como criar um grupo anfitrião e adicionar anfitriões a ele.
  2. Como aplicar uma visão de identificação ao grupo anfitrião.
  3. Como adicionar um novo anfitrião ao grupo anfitrião e aplicar a visão de identificação ao novo anfitrião.

Pré-requisitos

Procedimento

  1. Criar um grupo anfitrião e adicionar anfitriões a ele:

    1. Criar um grupo anfitrião. Por exemplo, para criar um grupo anfitrião chamado baltimore:

      [root@master ~]# ipa hostgroup-add --desc="Baltimore hosts" baltimore
      ---------------------------
      Added hostgroup "baltimore"
      ---------------------------
      Host-group: baltimore
      Description: Baltimore hosts
    2. Acrescentar anfitriões ao grupo anfitrião. Por exemplo, para adicionar o host102 e host103 ao grupo anfitrião baltimore:

      [root@master ~]# ipa hostgroup-add-member --hosts={host102,host103} baltimore
      Host-group: baltimore
      Description: Baltimore hosts
      Member hosts: host102.idm.example.com, host103.idm.example.com
      -------------------------
      Number of members added 2
      -------------------------
  2. Aplicar uma visão de identificação aos anfitriões do grupo anfitrião. Por exemplo, para aplicar a visualização de ID example_for_host1 ao grupo anfitrião baltimore:

    [root@master ~]# ipa idview-apply --hostgroups=baltimore
    ID View Name: example_for_host1
    -----------------------------------------
    Applied ID View "example_for_host1"
    -----------------------------------------
      hosts: host102.idm.example.com, host103.idm.example.com
    ---------------------------------------------
    Number of hosts the ID View was applied to: 2
    ---------------------------------------------
  3. Adicione um novo anfitrião ao grupo anfitrião e aplique a visão de identificação ao novo anfitrião:

    1. Acrescentar um novo anfitrião ao grupo anfitrião. Por exemplo, para adicionar o anfitrião somehost.idm.example.com ao grupo anfitrião baltimore:

      [root@master ~]# ipa hostgroup-add-member --hosts=somehost.idm.example.com baltimore
        Host-group: baltimore
        Description: Baltimore hosts
        Member hosts:  host102.idm.example.com, host103.idm.example.com,somehost.idm.example.com
      -------------------------
      Number of members added 1
      -------------------------
    2. Opcionalmente, exibir as informações de visualização de identificação. Por exemplo, para exibir os detalhes sobre a visualização da ID example_for_host1:

      [root@master ~]# ipa idview-show example_for_host1 --all
        dn: cn=example_for_host1,cn=views,cn=accounts,dc=idm,dc=example,dc=com
        ID View Name: example_for_host1
      [...]
        Hosts the view applies to: host102.idm.example.com, host103.idm.example.com
        objectclass: ipaIDView, top, nsContainer

      A saída mostra que a visão de identificação não é aplicada a somehost.idm.example.com, o recém-adicionado anfitrião no grupo anfitrião baltimore.

    3. Aplique a visão de identificação ao novo anfitrião. Por exemplo, para aplicar a visualização de ID example_for_host1 para somehost.idm.example.com:

      [root@master ~]# ipa idview-apply --host=somehost.idm.example.com
      ID View Name: example_for_host1
      -----------------------------------------
      Applied ID View "example_for_host1"
      -----------------------------------------
        hosts: somehost.idm.example.com
      ---------------------------------------------
      Number of hosts the ID View was applied to: 1
      ---------------------------------------------

Etapas de verificação

  • Exibir novamente as informações de visualização da ID:

    [root@master ~]# ipa idview-show example_for_host1 --all
      dn: cn=example_for_host1,cn=views,cn=accounts,dc=idm,dc=example,dc=com
      ID View Name: example_for_host1
    [...]
      Hosts the view applies to: host102.idm.example.com, host103.idm.example.com, somehost.idm.example.com
      objectclass: ipaIDView, top, nsContainer

    A saída mostra que a visualização de ID é agora aplicada a somehost.idm.example.com, o recém-adicionado anfitrião do grupo anfitrião baltimore.

Capítulo 24. Ajuste manual das faixas de identificação

Um mestre IdM gera números únicos de identificação de usuário (UID) e de grupo (GID). Ao criar e atribuir diferentes faixas de ID para réplicas, ele também garante que elas nunca gerem os mesmos números de ID. Por padrão, este processo é automático. Entretanto, é possível ajustar manualmente a faixa de ID do IdM durante a instalação do mestre IdM, ou definir manualmente a faixa de ID de DNA de uma réplica.

24.1. Faixas de identificação

Os números de identificação estão divididos em ID ranges. Manter intervalos numéricos separados para servidores individuais e réplicas elimina a chance de que um número de identificação emitido para uma entrada já seja utilizado por outra entrada em outro servidor ou réplica.

Observe que existem dois tipos distintos de faixas de identificação:

  • A faixa de ID do IdM, que é atribuída durante a instalação principal do IdM. Esta faixa não pode ser modificada após a sua criação. Entretanto, se for necessário, pode-se criar uma nova faixa de ID do IdM além da faixa original. Para mais informações, consulte Atribuição automática de faixas de ID e Adição de uma nova faixa de ID de IdM.
  • As faixas de ID de Atribuição Numérica Distribuída (ADN), que podem ser modificadas pelo usuário. Estes têm que se encaixar dentro de uma faixa de ID de IdM existente. Para mais informações, consulte Ajuste manual das faixas de ID de DNA.

    As réplicas também podem ter uma faixa de identificação de DNA atribuída a next. Uma réplica usa sua próxima faixa quando ficar sem IDs em sua faixa atual. As próximas faixas são atribuídas automaticamente quando uma réplica é excluída ou você pode defini-las manualmente.

Os intervalos são atualizados e compartilhados entre o master e as réplicas pelo plug-in de DNA, como parte do back end 389 Directory Server, por exemplo, para o domínio.

A definição da faixa de DNA é definida por dois atributos: o próximo número disponível do servidor (a extremidade inferior da faixa de DNA) e seu valor máximo (a extremidade superior da faixa de DNA). A faixa inferior inicial é definida durante a configuração da instância plug-in. Depois disso, o plug-in atualiza o valor inferior. A divisão dos números disponíveis em intervalos permite que os servidores atribuam continuamente números sem sobreposição entre si.

24.2. Atribuição automática de faixas de identificação

Por padrão, uma faixa de ID do IdM é automaticamente atribuída durante a instalação principal do IdM. O comando ipa-server-install seleciona e atribui aleatoriamente uma faixa de 200.000 IDs de um total de 10.000 faixas possíveis. Selecionar uma faixa aleatória desta forma reduz significativamente a probabilidade de conflitos de IDs caso você decida fundir dois domínios IdM separados no futuro.

Nota

Esta faixa de identificação IdM não pode ser modificada após a sua criação. Você só pode ajustar manualmente as faixas de ID de Atribuição Numérica Distribuída (ADN), usando os comandos descritos em Ajustando manualmente as faixas de ID de ADN. Uma faixa de DNA que corresponda à faixa de ID de IdM é criada automaticamente durante a instalação.

Se você tiver um único servidor IdM instalado, ele controla toda a faixa de ID de DNA. Quando você instala uma nova réplica e a réplica solicita sua própria faixa de ID de DNA, a faixa de ID inicial para o master se divide e é distribuída entre o master e a réplica: a réplica recebe metade da faixa de ID de DNA restante que está disponível no master inicial. O mestre e a réplica então usam suas respectivas porções da faixa de ID original para novas entradas de usuário ou grupo. Além disso, se a réplica estiver perto de esgotar sua faixa de ID atribuída e restarem menos de 100 IDs, a réplica contata os outros servidores disponíveis para solicitar uma nova faixa de ID de DNA.

Importante

Quando você instala uma réplica, ela does not recebe imediatamente uma faixa de identificação. Uma réplica recebe uma faixa de ID na primeira vez que o plug-in de DNA é usado, por exemplo, quando você adiciona um usuário pela primeira vez. Até lá, a réplica não tem faixa de ID definida.

Se o mestre inicial parar de funcionar antes que a réplica solicite uma faixa de identificação de DNA, a réplica não poderá entrar em contato com o mestre para solicitar a faixa de identificação. Tentativa de adicionar um novo usuário na réplica então falha. Em tais situações, é possível descobrir qual faixa de ID é atribuída ao mestre desabilitado e atribuir uma faixa de ID à réplica manualmente.

24.3. Atribuição manual da faixa de ID do IdM durante a instalação do servidor

Você pode anular o comportamento padrão e definir uma faixa de IDM manualmente em vez de tê-la atribuída aleatoriamente.

Importante

Não defina faixas de ID que incluam valores UID de 1000 e inferiores; estes valores são reservados para uso no sistema. Além disso, não defina uma faixa de ID que inclua o valor 0; o serviço SSSD não lida com o valor 0 de ID.

Procedimento

  • Você pode definir a faixa de ID do IdM manualmente durante a instalação do servidor, usando as duas opções a seguir com ipa-server-install:

    • --idstart dá o valor inicial para os números UID e GID.
    • --idmax fornece o número máximo de UID e GID; por padrão, o valor é o valor inicial de --idstart mais 199.999.

Etapas de verificação

  • Para verificar se a faixa de ID foi atribuída corretamente, você pode exibir a faixa de ID do IdM atribuído usando o comando ipa idrange-find:

    # ipa idrange-find
    ---------------
    1 range matched
    ---------------
      Range name: IDM.EXAMPLE.COM_id_range
      First Posix ID of the range: 882200000
      Number of IDs in the range: 200000
      Range type: local domain range
    ----------------------------
    Number of entries returned 1
    ----------------------------

24.4. Adicionando uma nova linha IdM ID

Em alguns casos, você pode querer criar uma nova faixa de IDM além da original; por exemplo, quando uma réplica ficar sem IDs e a faixa original de IDM estiver esgotada.

Importante

A adição de uma nova faixa de IDM não cria automaticamente novas faixas de ID de DNA. Você precisa atribuir novas faixas de ID de DNA manualmente, conforme necessário. Para mais informações sobre como fazer isso, consulte Ajustando as faixas de ID de DNA manualmente.

Procedimento

  • Para criar uma nova faixa de ID do IdM, use o comando ipa idrange-add. Você precisa especificar o novo nome do novo intervalo, o primeiro número de identificação do intervalo e o tamanho do intervalo:
# ipa idrange-add IDM.EXAMPLE.COM_new_range --base-id=1000000 --range-size=200000
------------------------------------------
Added ID range "IDM.EXAMPLE.COM_new_range"
------------------------------------------
  Range name: IDM.EXAMPLE.COM_new_range
  First Posix ID of the range: 1000000
  Number of IDs in the range: 200000
  Range type: local domain range

Etapas de verificação

  • Você pode verificar se a nova faixa está definida corretamente usando o comando ipa idrange-find:
# ipa idrange-find
----------------
2 ranges matched
----------------
  Range name: IDM.EXAMPLE.COM_id_range
  First Posix ID of the range: 882200000
  Number of IDs in the range: 200000
  Range type: local domain range

  Range name: IDM.EXAMPLE.COM_new_range
  First Posix ID of the range: 1000000
  Number of IDs in the range: 200000
  Range type: local domain range
----------------------------
Number of entries returned 2
----------------------------

24.5. Exibição das faixas de identificação de DNA atualmente atribuídas

Você pode exibir tanto a faixa de ID de Atribuição Numérica Distribuída (ADN) atualmente ativa em um servidor, como também sua próxima faixa de ADN, caso tenha uma atribuída.

Procedimento

  • Para exibir quais faixas de ID de DNA estão configuradas para os servidores na topologia, use os seguintes comandos:

    • ipa-replica-manage dnarange-show exibe a faixa de ID de DNA atual que está definida em todos os servidores ou, se você especificar um servidor, somente no servidor especificado, por exemplo:

      # ipa-replica-manage dnarange-show
      masterA.example.com: 1001-1500
      masterB.example.com: 1501-2000
      masterC.example.com: No range set
      
      # ipa-replica-manage dnarange-show masterA.example.com
      masterA.example.com: 1001-1500
    • ipa-replica-manage dnanextrange-show exibe a próxima faixa de ID de DNA atualmente definida em todos os servidores ou, se você especificar um servidor, apenas no servidor especificado, por exemplo:

      # ipa-replica-manage dnanextrange-show
      masterA.example.com: 2001-2500
      masterB.example.com: No on-deck range set
      masterC.example.com: No on-deck range set
      
      # ipa-replica-manage dnanextrange-show masterA.example.com
      masterA.example.com: 2001-2500

24.6. Extensão automática da faixa de DNA ID

Ao excluir uma réplica funcional, o comando ipa-replica-manage del recupera as faixas de identificação de DNA que foram atribuídas à réplica e as adiciona como uma próxima faixa a outra réplica IdM disponível. Isto assegura que as faixas de ID de DNA sejam utilizadas de forma eficiente.

Após excluir uma réplica, você pode verificar quais faixas de ID de DNA estão configuradas para outros servidores, usando os comandos descritos em Exibição de faixas de ID de DNA atualmente atribuídas.

24.7. Ajuste manual da faixa de DNA ID

Em certas situações, é necessário ajustar manualmente uma faixa de ID de Atribuição Numérica Distribuída (ADN), por exemplo, quando:

  • Uma réplica ficou sem identificação e a faixa de identificação IdM está esgotada

    Uma réplica esgotou a faixa de ID de DNA que lhe foi atribuída, e solicitar IDs adicionais falhou porque não há mais IDs gratuitas disponíveis na faixa de IDM.

    Para resolver esta situação, ampliar a faixa de identificação de DNA atribuída à réplica. Você pode fazer isso de duas maneiras:

    • Reduzir a faixa de identificação de DNA atribuída a uma réplica diferente e, em seguida, atribuir os novos valores disponíveis para a réplica esgotada.
    • Criar uma nova faixa de ID de IdM e, em seguida, definir uma nova faixa de ID de DNA para a réplica dentro desta faixa IdM criada.

      Para informações sobre como criar uma nova linha IdM ID, consulte Adicionando uma nova linha IdM ID.

  • Uma réplica deixou de funcionar

    A faixa de DNA ID de uma réplica não é automaticamente recuperada quando a réplica morre e precisa ser apagada, o que significa que a faixa de DNA ID previamente atribuída à réplica fica indisponível. Você deseja recuperar a faixa de ID de DNA e disponibilizá-la para outras réplicas.

    Se você quiser recuperar uma faixa de ID de DNA pertencente a uma réplica que parou de funcionar e atribuí-la a outro servidor, você precisa primeiro descobrir quais são os valores da faixa de ID, antes de atribuir manualmente essa faixa a um servidor diferente. Além disso, para evitar duplicação de UIDs ou GIDs, certifique-se de que nenhum valor de ID da faixa recuperada foi previamente atribuído a um usuário ou grupo; você pode fazer isso examinando as UIDs e GIDs dos usuários e grupos existentes.

Você pode ajustar manualmente uma faixa de ID de DNA para uma réplica usando os comandos em Ajustando manualmente as faixas de ID de DNA.

Nota

Se você atribuir uma nova faixa de identificação de DNA, as UIDs das entradas já existentes no servidor ou réplica permanecerão as mesmas. Isto não representa um problema porque mesmo se você mudar a faixa de ID de DNA atual, a IdM mantém um registro de quais faixas foram atribuídas no passado.

24.8. Ajuste manual das faixas de identificação de DNA

Em alguns casos, você pode precisar ajustar manualmente as faixas de ID de Atribuição Numérica Distribuída (ADN) para réplicas existentes, por exemplo, para reatribuir uma faixa de ID de ADN atribuída a uma réplica que não funciona. Para mais informações, consulte Ajuste manual da faixa de ID de DNA.

Ao ajustar uma faixa de ID de DNA manualmente, certifique-se de que a faixa recém ajustada esteja incluída na faixa de ID do IdM; você pode verificar isto usando o comando ipa idrange-find. Caso contrário, o comando irá falhar.

Importante

Tenha cuidado para não criar intervalos de identificação sobrepostos. Se qualquer um dos intervalos de ID que você atribuir a servidores ou réplicas se sobrepuserem, isso pode resultar em dois servidores diferentes atribuindo o mesmo valor de ID a entradas diferentes.

Pré-requisitos

Procedimento

  • Para definir a faixa de ID de DNA atual para um servidor específico, use o site ipa-replica-manage dnarange-set:

    # ipa-replica-gerir dnarange-set masterA.example.com 1250-1499
  • Para definir a próxima faixa de ID de DNA para um servidor específico, use o site ipa-replica-manage dnanextrange-set:

    # ipa-replica-gerir dnanextrange-set masterB.example.com 1500-5000

Etapas de verificação

Capítulo 25. Configuração de IdM para provisionamento externo dos usuários

Como administrador do sistema, você pode configurar o Gerenciamento de Identidade (IdM) para apoiar o provisionamento dos usuários por uma solução externa de gerenciamento de identidades.

Ao invés de usar o utilitário ipa, o administrador do sistema de provisionamento externo pode acessar o IdM LDAP usando o utilitário ldapmodify. O administrador pode adicionar usuários individuais da CLI usando o ldapmodify ou usando um arquivo LDIF.

A suposição é que você, como administrador da IdM, confia plenamente em seu sistema de provisionamento externo para adicionar apenas usuários validados. Entretanto, ao mesmo tempo, você não quer atribuir aos administradores do sistema de provisionamento externo o papel de IdM de User Administrator para permitir que eles adicionem novos usuários ativos diretamente.

Você pode configurar um script para mover automaticamente os usuários encenados criados pelo sistema de provisionamento externo para usuários ativos.

Este capítulo contém estas seções:

  1. Preparando o Gerenciamento de Identidade (IdM ) para usar um sistema de provisionamento externo para adicionar usuários de palco ao IdM.
  2. Criação de um script para mover os usuários adicionados pelo sistema de provisionamento externo do estágio para usuários ativos.
  3. Usando um sistema de provisionamento externo para adicionar um usuário da etapa IdM. Você pode fazer isso de duas maneiras:

Materiais adicionais

Para exemplos e modelos para usar ldapmodify como um administrador completo da IdM para realizar operações de gerenciamento de usuários e grupos que requerem maiores privilégios, veja Usando ldapmodify.

25.1. Preparação de contas IdM para ativação automática de contas de usuários de palco

Este procedimento mostra como configurar duas contas de usuário IdM para serem utilizadas por um sistema de provisionamento externo. Ao adicionar as contas a um grupo com uma política de senha apropriada, você habilita o sistema de provisionamento externo para gerenciar o provisionamento de usuários no IdM. A seguir, a conta de usuário a ser usada pelo sistema externo para adicionar usuários em estágio é denominada provisionator. A conta de usuário a ser usada para ativar automaticamente os usuários da etapa é nomeada activator.

Pré-requisitos

  • O anfitrião no qual você realiza o procedimento está inscrito na IdM.

Procedimento

  1. Entrar como administrador da IdM:

    $ parentes admin
  2. Criar um usuário chamado provisionator com os privilégios de adicionar usuários de palco.

    1. Adicionar a conta de usuário do provisionador:
    $ ipa usuário-adicionador de provisão --first=provisionamento --last=conta --palavra-palavra
    1. Conceder ao usuário do provisionador os privilégios necessários.

      1. Criar uma função personalizada, System Provisioning, para gerenciar a adição de usuários de palco:

        $ ipa role-add --desc "Responsável pelos usuários da fase de provisionamento" "Provisionamento do sistema"
      2. Acrescente o privilégio Stage User Provisioning ao papel. Este privilégio proporciona a capacidade de adicionar usuários de palco:

        $ ipa role-add-privilege" --privileges="Stage User Provisioning"
      3. Adicionar o usuário provisionador à função:

        $ ipa role-add-member --usuários=provisionador {\i1}"System Provisioning
      4. Verificar se o provisionador existe na IdM:
      $ ipa user-find provisionator --all --raw
      --------------
      1 user matched
      --------------
        dn: uid=provisionator,cn=users,cn=accounts,dc=idm,dc=example,dc=com
        uid: provisionator
        [...]
  3. Criar um usuário, activator, com os privilégios de gerenciar contas de usuário.

    1. Adicionar a conta do usuário ativador:

      $ ipa ativador-adicionado pelo usuário --first=ativação --last=conta --palavra-palavra
    2. Conceder ao usuário ativador os privilégios necessários, adicionando o usuário à função padrão User Administrator:

      $ ipa role-add-member --usuários=ativador {\i1}"Administrador de usuários
  4. Criar um grupo de usuários para contas de aplicação:

    Contas de aplicação de $ ipa group-add
  5. Atualizar a política de senhas para o grupo. A seguinte política impede a expiração e bloqueio da conta por senha, mas compensa os riscos potenciais ao exigir senhas complexas:

    $ ipa pwpolicy-add application-accounts --maxlife=10000 --minlife=0 --história=0 --minclasses=4 --minlength=8 --priority=1 --maxfail=0 --failinterval=1 --lockouttime=0
  6. (Opcional) Verificar se a política de senha existe na IdM:

    $ ipa pwpolicy-show application-accounts
      Group: application-accounts
      Max lifetime (days): 10000
      Min lifetime (hours): 0
      History size: 0
    [...]
  7. Adicionar as contas de provisionamento e ativação ao grupo para contas de aplicação:

    $ ipa grupo-add-member application-accounts --usuários={provisionador,ativador}
  8. Alterar as senhas para as contas dos usuários:

    $ kpasswd provisionator
    $ kpasswd activator

    A mudança das senhas é necessária porque as novas senhas de usuários IdM expiram imediatamente.

Recursos adicionais:

25.2. Configuração de ativação automática das contas de usuário do estágio IdM

Este procedimento mostra como criar um roteiro para ativar os usuários do palco. O sistema executa o script automaticamente em intervalos de tempo especificados. Isto assegura que novas contas de usuário sejam ativadas automaticamente e estejam disponíveis para uso logo após a sua criação.

Importante

O procedimento assume que o proprietário do sistema de provisionamento externo já validou os usuários e que eles não precisam de validação adicional no lado do IdM antes que o script os acrescente ao IdM.

É suficiente para ativar o processo em apenas um de seus servidores IdM.

Pré-requisitos

Procedimento

  1. Gerar um arquivo keytab para a conta de ativação:

    # ipa-getkeytab -s server.idm.example.com -p "activator" -k /etc/krb5.ipa-activation.keytab

    Se você quiser habilitar o processo de ativação em mais de um servidor IdM, gere o arquivo keytab em apenas um servidor. Depois copie o arquivo keytab para os outros servidores.

  2. Criar um script, /usr/local/sbin/ipa-activate-all, com o seguinte conteúdo para ativar todos os usuários:

    #!/bin/bash
    
    kinit -k -i activator
    
    ipa stageuser-find --all --raw | grep "  uid:" | cut -d ":" -f 2 | while read uid; do ipa stageuser-activate ${uid}; done
  3. Edite as permissões e a propriedade do script ipa-activate-all para torná-lo executável:

    # chmod 755 /usr/local/sbin/ipa-activate-all
    # chown root:root /usr/local/sbin/ipa-activate-all
  4. Criar um arquivo systemd unit file, /etc/systemd/system/ipa-activate-all.service, com o seguinte conteúdo:

    [Unit]
    Description=Scan IdM every minute for any stage users that must be activated
    
    [Service]
    Environment=KRB5_CLIENT_KTNAME=/etc/krb5.ipa-activation.keytab
    Environment=KRB5CCNAME=FILE:/tmp/krb5cc_ipa-activate-all
    ExecStart=/usr/local/sbin/ipa-activate-all
  5. Criar um temporizador systemd, /etc/systemd/system/ipa-activate-all.timer, com o seguinte conteúdo:

    [Unit]
    Description=Scan IdM every minute for any stage users that must be activated
    
    [Timer]
    OnBootSec=15min
    OnUnitActiveSec=1min
    
    [Install]
    WantedBy=multi-user.target
  6. Recarregar a nova configuração:

    # systemctl daemon-reload
  7. Habilitar ipa-activate-all.timer:

    # systemctl habilita ipa-activate-all.timer
  8. Iniciar ipa-activate-all.timer:

    # systemctl start ipa-activate-all.timer
  9. (Opcional) Verifique se o daemon ipa-activate-all.timer está funcionando:

    # systemctl status ipa-activate-all.timer
    ● ipa-activate-all.timer - Scan IdM every minute for any stage users that must be activated
       Loaded: loaded (/etc/systemd/system/ipa-activate-all.timer; enabled; vendor preset: disabled)
       Active: active (waiting) since Wed 2020-06-10 16:34:55 CEST; 15s ago
      Trigger: Wed 2020-06-10 16:35:55 CEST; 44s left
    
    Jun 10 16:34:55 server.idm.example.com systemd[1]: Started Scan IdM every minute for any stage users that must be activated.

25.3. Adicionando um usuário do estágio IdM definido em um arquivo LDIF

Esta seção descreve como um administrador de um sistema de provisionamento externo pode acessar o IdM LDAP e usar um arquivo LDIF para adicionar usuários de palco. Enquanto o exemplo abaixo mostra a adição de um único usuário, vários usuários podem ser adicionados em um arquivo no modo bulk.

Pré-requisitos

  • O administrador da IdM criou a conta provisionator e uma senha para ela. Para detalhes, consulte Preparação de contas IdM para ativação automática de contas de usuários em estágio.
  • Você, como administrador externo, sabe a senha da conta provisionator.
  • Você pode SSH para o servidor IdM a partir de seu servidor LDAP.
  • Você é capaz de fornecer o conjunto mínimo de atributos que um usuário da etapa IdM deve ter para permitir o processamento correto do ciclo de vida do usuário, a saber

    • O distinguished name (dn)
    • O common name (cn)
    • O last name (sn)
    • O uid

Procedimento

  1. No servidor externo, crie um arquivo LDIF que contenha informações sobre o novo usuário:

    dn: uid=stageidmuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
    changetype: add
    objectClass: top
    objectClass: inetorgperson
    uid: stageidmuser
    sn: surname
    givenName: first_name
    cn: full_name
  2. Transferir o arquivo LDIF do servidor externo para o servidor IdM:

    $ scp add-stageidmuser.ldif provisionator@server.idm.example.com:/provisionator/
    Password:
    add-stageidmuser.ldif                                                                                          100%  364   217.6KB/s   00:00
  3. Use o protocolo SSH para conectar-se ao servidor da IdM como provisionator:

    $ ssh provisionator@server.idm.example.com
    Password:
    [provisionator@server ~]$
  4. No servidor da IdM, obtenha o ticket de concessão de bilhetes Kerberos (TGT) para a conta do provisionador:

    [provisionador@servidor ~]$ parente provisionador
  5. Digite o comando ldapadd com a opção -f e o nome do arquivo LDIF. Especifique o nome do servidor IdM e o número da porta:

    ~]$ ldapadd -h server.idm.example.com -p 389 -f  add-stageidmuser.ldif
    SASL/GSSAPI authentication started
    SASL username: provisionator@IDM.EXAMPLE.COM
    SASL SSF: 256
    SASL data security layer installed.
    adding the entry "uid=stageidmuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com"

25.4. Adicionando um usuário da etapa IdM diretamente da CLI usando a ldapmodify

Esta seção descreve como um administrador de um sistema de provisionamento externo pode acessar o LDAP de Gerenciamento de Identidade (IdM) e usar o utilitário ldapmodify para adicionar um usuário em fase.

Pré-requisitos

  • O administrador da IdM criou a conta provisionator e uma senha para ela. Para detalhes, consulte Preparação de contas IdM para ativação automática das contas de usuários em estágio.
  • Você, como administrador externo, sabe a senha da conta provisionator.
  • Você pode SSH para o servidor IdM a partir de seu servidor LDAP.
  • Você é capaz de fornecer o conjunto mínimo de atributos que um usuário da etapa IdM deve ter para permitir o processamento correto do ciclo de vida do usuário, a saber

    • O distinguished name (dn)
    • O common name (cn)
    • O last name (sn)
    • O uid

Procedimento

  1. Use o protocolo SSH para conectar-se ao servidor IdM usando sua identidade e credenciais IdM:

    $ ssh provisionator@server.idm.example.com
    Password:
    [provisionator@server ~]$
  2. Obter o TGT da conta provisionator, um usuário IdM com um papel para adicionar novos usuários em palco:

    Provisor de parentesco
  3. Digite o comando ldapmodify e especifique Generic Security Services API (GSSAPI) como o mecanismo de Autenticação Simples e Camada de Segurança (SASL) a ser usado para autenticação. Especifique o nome do servidor IdM e a porta:

    # ldapmodify -h server.idm.example.com -p 389 -Y GSSAPI
    SASL/GSSAPI authentication started
    SASL username: provisionator@IDM.EXAMPLE.COM
    SASL SSF: 56
    SASL data security layer installed.
  4. Digite o dn do usuário que você está adicionando:

    dn: uid=usuário de palco,cn=usuário de palco,cn=contas,cn=provisionamento,dc=idm,dc=exemplo,dc=com
  5. Digite add como o tipo de mudança que você está realizando:

    tipo de mudança: adicionar
  6. Especificar as categorias de classe de objetos LDAP necessárias para permitir o processamento correto do ciclo de vida do usuário:

    objectClass: top
    objectClass: inetorgperson

    Você pode especificar classes de objetos adicionais.

  7. Entre no site uid do usuário:

    uid: usuário de palco
  8. Entre no site cn do usuário:

    cn: Babs Jensen
  9. Digite o sobrenome do usuário:

    sn: Jensen
  10. Pressione Enter novamente para confirmar que este é o fim da entrada:

    [Enter]
    
    adding new entry "uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com"
  11. Sair da conexão usando Ctrl C .

Etapas de verificação

Verifique o conteúdo da entrada de fase para ter certeza de que seu sistema de provisionamento adicionou todos os atributos POSIX necessários e que a entrada de fase está pronta para ser ativada.

  • Para exibir os novos atributos LDAP do usuário da etapa, digite o comando ipa stageuser-show --all --raw:

    $ ipa stageuser-show stageuser --all --raw
      dn: uid=stageuser,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
      uid: stageuser
      sn: Jensen
      cn: Babs Jensen
      has_password: FALSE
      has_keytab: FALSE
      nsaccountlock: TRUE
      objectClass: top
      objectClass: inetorgperson
      objectClass: organizationalPerson
      objectClass: person
    1. Note que o usuário é explicitamente desabilitado pelo atributo nsaccountlock.

Capítulo 26. Usando ldapmodify para gerenciar usuários IdM externamente

Você pode modificar o Gerenciamento de Identidade (IdM) LDAP diretamente da interface de linha de comando (CLI) usando os utilitários ldapmodify e ldapdelete. Os utilitários oferecem total funcionalidade para adicionar, editar e excluir o conteúdo de seu diretório. Você pode usar estes utilitários para gerenciar tanto as entradas de configuração do servidor quanto os dados nas entradas do usuário. Os utilitários também podem ser usados para escrever scripts para realizar o gerenciamento em massa de um ou mais diretórios.

26.1. Modelos para gerenciar contas de usuários IdM externamente

Esta seção descreve os modelos para várias operações de gerenciamento de usuários na IdM. Os modelos mostram quais atributos você deve modificar usando ldapmodify para alcançar os seguintes objetivos:

  • Adicionando um novo usuário em fase
  • Modificação de um atributo do usuário
  • Habilitando um usuário
  • Desabilitando um usuário
  • Preservar um usuário

Os modelos são formatados no formato LDAP Data Interchange Format (LDIF). LDIF é um formato padrão de intercâmbio de dados em texto simples para representar o conteúdo do diretório LDAP e solicitações de atualização.

Usando os modelos, você pode configurar o fornecedor LDAP de seu sistema de provisionamento para gerenciar as contas de usuários IdM.

Para exemplos de procedimentos detalhados, veja as seções seguintes:

Modelos para adicionar um novo usuário de etapa

  • Um modelo para adicionar um usuário com UID and GID assigned automatically. O nome distinto (DN) da entrada criada deve começar com uid=user_login:

    dn: uid=user_login,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
    changetype: add
    objectClass: top
    objectClass: inetorgperson
    uid: user_login
    sn: surname
    givenName: first_name
    cn: full_name
  • Um modelo para adicionar um usuário com UID and GID assigned statically:

    dn: uid=user_login,cn=staged users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
    changetype: add
    objectClass: top
    objectClass: person
    objectClass: inetorgperson
    objectClass: organizationalperson
    objectClass: posixaccount
    uid: user_login
    uidNumber: UID_number
    gidNumber: GID_number
    sn: surname
    givenName: first_name
    cn: full_name
    homeDirectory: /home/user_login

    Você não é obrigado a especificar nenhuma classe de objeto IdM ao adicionar usuários de palco. IdM adiciona estas classes automaticamente depois que os usuários são ativados.

Modelos para modificação de usuários existentes

  • Modifying a user’s attribute:

    dn: distinguished_name
    changetype: modify
    replace: attribute_to_modify
    attribute_to_modify: new_value
  • Disabling a user:

    dn: distinguished_name
    changetype: modify
    replace: nsAccountLock
    nsAccountLock: TRUE
  • Enabling a user:

    dn: distinguished_name
    changetype: modify
    replace: nsAccountLock
    nsAccountLock: FALSE

    A atualização do atributo nssAccountLock não tem nenhum efeito sobre o palco e os usuários preservados. Mesmo que a operação de atualização seja concluída com sucesso, o valor do atributo permanece nssAccountLock: TRUE.

  • Preserving a user:

    dn: distinguished_name
    changetype: modrdn
    newrdn: uid=user_login
    deleteoldrdn: 0
    newsuperior: cn=deleted users,cn=accounts,cn=provisioning,dc=idm,dc=example,dc=com
Nota

Antes de modificar um usuário, obtenha o nome distinto do usuário (DN) através de uma busca usando o login do usuário. No exemplo a seguir, o usuário user_allowed_to_modify_user_entries é um usuário autorizado a modificar informações de usuário e grupo, por exemplo activator ou administrador da IdM. A senha no exemplo é a senha deste usuário:

[...]
# ldapsearch -LLL -x -D "uid=user_allowed_to_modify_user_entries,cn=users,cn=accounts,dc=idm,dc=example,dc=com" -w "Secret123" -H ldap://r8server.idm.example.com -b "cn=users,cn=accounts,dc=idm,dc=example,dc=com" uid=test_user
dn: uid=test_user,cn=users,cn=accounts,dc=idm,dc=example,dc=com
memberOf: cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=example,dc=com

26.2. Modelos para gerenciar contas do grupo IdM externamente

Esta seção descreve os modelos para várias operações de gerenciamento de grupos de usuários na IdM. Os modelos mostram quais atributos devem ser modificados usando ldapmodify para alcançar os seguintes objetivos:

  • Criação de um novo grupo
  • Eliminação de um grupo existente
  • Acrescentar um membro a um grupo
  • Remoção de um membro de um grupo

Os modelos são formatados no formato LDAP Data Interchange Format (LDIF). LDIF é um formato padrão de intercâmbio de dados em texto simples para representar o conteúdo do diretório LDAP e solicitações de atualização.

Usando os modelos, você pode configurar o fornecedor LDAP de seu sistema de provisionamento para gerenciar as contas do grupo IdM.

Criação de um novo grupo

dn: cn=group_name,cn=groups,cn=accounts,dc=idm,dc=example,dc=com
changetype: add
objectClass: top
objectClass: ipaobject
objectClass: ipausergroup
objectClass: groupofnames
objectClass: nestedgroup
objectClass: posixgroup
uid: group_name
cn: group_name
gidNumber: GID_number

Modificação de grupos

  • Deleting an existing group:

    dn: group_distinguished_name
    changetype: delete
  • Adding a member to a group:

    dn: group_distinguished_name
    changetype: modify
    add: member
    member: uid=user_login,cn=users,cn=accounts,dc=idm,dc=example,dc=com

    Não acrescentar usuários de palco ou preservados a grupos. Mesmo que a operação de atualização seja concluída com sucesso, os usuários não serão atualizados como membros do grupo. Somente usuários ativos podem pertencer a grupos.

  • Removing a member from a group:

    dn: distinguished_name
    changetype: modify
    delete: member
    member: uid=user_login,cn=users,cn=accounts,dc=idm,dc=example,dc=com
Nota

Antes de modificar um grupo, obtenha o nome distinto do grupo (DN), pesquisando usando o nome do grupo.

# ldapsearch -YGSSAPI -H ldap://server.idm.example.com -b "cn=groups,cn=accounts,dc=idm,dc=example,dc=com" "cn=group_name"
dn: cn=group_name,cn=groups,cn=accounts,dc=idm,dc=example,dc=com
ipaNTSecurityIdentifier: S-1-5-21-1650388524-2605035987-2578146103-11017
cn: testgroup
objectClass: top
objectClass: groupofnames
objectClass: nestedgroup
objectClass: ipausergroup
objectClass: ipaobject
objectClass: posixgroup
objectClass: ipantgroupattrs
ipaUniqueID: 569bf864-9d45-11ea-bea3-525400f6f085
gidNumber: 1997010017

26.3. Preservar um usuário IdM com ldapmodify

Esta seção descreve como usar ldapmodify para preservar um usuário IdM; isto é, como desativar uma conta de usuário após o funcionário ter deixado a empresa.

Pré-requisitos

  • Você pode autenticar como um usuário IdM com um papel para preservar os usuários.

Procedimento

  1. Faça o login como um usuário IdM com um papel para preservar os usuários:

    $ parentes admin
  2. Insira o comando ldapmodify e especifique o API de Serviços Genéricos de Segurança (GSSAPI) como o mecanismo de Autenticação Simples e Camada de Segurança (SASL) a ser usado para autenticação:

    # ldapmodify -Y GSSAPI
    SASL/GSSAPI authentication started
    SASL username: admin@IDM.EXAMPLE.COM
    SASL SSF: 256
    SASL data security layer installed.
  3. Entre no site dn do usuário que você deseja preservar:

    dn: uid=user1,cn=users,cn=accounts,dc=idm,dc=example,dc=com
  4. Digite modrdn como o tipo de mudança que você deseja realizar:

    tipo de mudança: modrdn
  5. Especifique o newrdn para o usuário:

    newrdn: uid=usuário1
  6. Indicar que você deseja preservar o usuário:

    deleteoldrdn: 0
  7. Especifique o new superior DN:

    newsuperior: cn=usuários excluídos,cn=contas,cn=provisionamento,dc=idm,dc=exemplo,dc=com

    A preservação de um usuário move a entrada para um novo local na árvore de informações do diretório (DIT). Por este motivo, deve-se especificar o DN da nova entrada pai como o novo DN superior.

  8. Pressione Enter novamente para confirmar que este é o fim da entrada:

    [Enter]
    
    modifying rdn of entry "uid=user1,cn=users,cn=accounts,dc=idm,dc=example,dc=com"
  9. Sair da conexão usando Ctrl C .

Etapas de verificação

  • Verifique se o usuário foi preservado, listando todos os usuários preservados:

    $ ipa user-find --preserved=true
    --------------
    1 user matched
    --------------
      User login: user1
      First name: First 1
      Last name: Last 1
      Home directory: /home/user1
      Login shell: /bin/sh
      Principal name: user1@IDM.EXAMPLE.COM
      Principal alias: user1@IDM.EXAMPLE.COM
      Email address: user1@idm.example.com
      UID: 1997010003
      GID: 1997010003
      Account disabled: True
      Preserved user: True
    ----------------------------
    Number of entries returned 1
    ----------------------------

Capítulo 27. Administração de Anfitriões na IdM CLI

Este capítulo apresenta as entradas de anfitriões e anfitriões no Gerenciamento de Identidade (IdM), e as seguintes operações realizadas ao gerenciar as entradas de anfitriões e anfitriões no IdM CLI:

O capítulo também contém uma tabela geral dos pré-requisitos, do contexto e das conseqüências dessas operações.

27.1. Anfitriões na IdM

A Gestão de Identidade (IdM) gerencia estas identidades:

  • Usuários
  • Serviços
  • Anfitriões

Um anfitrião representa uma máquina. Como uma identidade IdM, um host tem uma entrada no IdM LDAP, ou seja, a instância 389 Directory Server do servidor IdM.

A entrada do host no IdM LDAP é usada para estabelecer relações entre outros hosts e até mesmo serviços dentro do domínio. Estas relações fazem parte da autorização e controle do delegating para hosts dentro do domínio. Qualquer host pode ser usado nas regras do host-based access control (HBAC).

O domínio IdM estabelece uma uniformidade entre as máquinas, com informações de identidade comuns, políticas comuns e serviços compartilhados. Qualquer máquina que pertença a um domínio funciona como cliente do domínio, o que significa que utiliza os serviços que o domínio oferece. O domínio IdM fornece três serviços principais especificamente para máquinas:

  • DNS
  • Kerberos
  • Gestão de certificados

Os anfitriões na IdM estão intimamente ligados com os serviços que funcionam neles:

  • As entradas de serviço estão associadas a um anfitrião.
  • Um anfitrião armazena tanto o anfitrião quanto os diretores de serviço Kerberos.

27.2. Inscrição de anfitriões

Esta seção descreve a inscrição de anfitriões como clientes da IdM e o que acontece durante e após a inscrição. A seção compara a matrícula de hospedeiros IdM e usuários IdM. A seção também descreve os tipos alternativos de autenticação disponíveis para os anfitriões.

A inscrição de um anfitrião consiste em:

  • Criação de uma entrada hospedeira no IdM LDAP: possivelmente usando o comandoipa host-add no IdM CLI, ou a operação equivalente do IdM Web UI.
  • Configurando os serviços IdM no host, por exemplo o System Security Services Daemon (SSSD), Kerberos, e certmonger, e unindo o host ao domínio IdM.

As duas ações podem ser realizadas separadamente ou em conjunto.

Se realizadas separadamente, elas permitem dividir as duas tarefas entre dois usuários com diferentes níveis de privilégio. Isto é útil para implantações em massa.

O comando ipa-client-install pode realizar as duas ações em conjunto. O comando cria uma entrada hospedeira no IdM LDAP se essa entrada ainda não existir, e configura tanto os serviços Kerberos como SSSD para o hospedeiro. O comando traz o host dentro do domínio IdM e permite que ele identifique o servidor IdM com o qual ele se conectará. Se o host pertence a uma zona DNS gerenciada pela IdM, ipa-client-install adiciona registros DNS para o host também. O comando deve ser executado no cliente.

27.2.1. Privilégios de usuário necessários para a inscrição no host

A operação de inscrição no host requer autenticação para evitar que um usuário sem privilégios acrescente máquinas indesejadas ao domínio IdM. Os privilégios requeridos dependem de vários fatores, por exemplo:

  • Se uma entrada de anfitrião for criada separadamente da execução ipa-client-install
  • Se uma senha única (OTP) for usada para a inscrição
Privilégios do usuário para, opcionalmente, criar manualmente uma entrada de host no IdM LDAP

O privilégio do usuário necessário para criar uma entrada no IdM LDAP usando o comando ipa host-add CLI ou o IdM Web UI é Host Administrators. O privilégio Host Administrators pode ser obtido através da função IT Specialist.

Privilégios do usuário para unir o cliente ao domínio IdM

Os anfitriões são configurados como clientes IdM durante a execução do comando ipa-client-install. O nível de credenciais necessárias para executar o comando ipa-client-install depende de qual dos seguintes cenários de cadastro você se encontra:

  • A entrada anfitriã no IdM LDAP não existe. Para este cenário, você precisa de uma credencial completa de administrador ou do papel Host Administrators. Um administrador pleno é um membro do grupo admins. A função Host Administrators fornece privilégios para adicionar anfitriões e cadastrar anfitriões. Para detalhes sobre este cenário, consulte Instalação de um cliente usando credenciais de usuário: instalação interativa.
  • A entrada anfitriã no IdM LDAP existe. Para este cenário, você precisa de uma credencial limitada de administrador para executar com sucesso o ipa-client-install. O administrador limitado neste caso tem o papel de Enrollment Administrator, que fornece o privilégio de Host Enrollment. Para detalhes, consulte Instalação de um cliente usando credenciais de usuário: instalação interativa.
  • A entrada do hospedeiro no IdM LDAP existe, e um OTP foi gerado para o hospedeiro por um administrador completo ou limitado. Para este cenário, você pode instalar um cliente IdM como um usuário comum se executar o comando ipa-client-install com a opção --password, fornecendo o OTP correto. Para detalhes, consulte Instalação de um cliente usando uma senha única: Instalação interativa.

Após a inscrição, os anfitriões da IdM autenticam cada nova sessão para poder acessar os recursos da IdM. A autenticação da máquina é necessária para que o servidor IdM confie na máquina e aceite conexões IdM do software cliente instalado naquela máquina. Após autenticar o cliente, o servidor IdM pode responder a suas solicitações.

27.2.2. Inscrição e autenticação de hosts e usuários IdM: comparação

Há muitas semelhanças entre usuários e anfitriões na IdM. Esta seção descreve algumas das semelhanças que podem ser observadas durante a fase de inscrição, bem como aquelas que dizem respeito à autenticação durante a fase de implantação.

  • A etapa de cadastramento (Tabela 27.1, “Inscrição de usuários e anfitriões”):

    • Um administrador pode criar uma entrada LDAP tanto para um usuário quanto para um host antes de o usuário ou host realmente entrar no IdM: para o usuário em estágio, o comando é ipa stageuser-add; para o host, o comando é ipa host-add.
    • Um arquivo contendo um key table ou, abreviado, keytab, uma chave simétrica parecida em certa medida com uma senha de usuário, é criado durante a execução do comando ipa-client-install no host, resultando na adesão do host ao reino do IdM. Analogicamente, o usuário é solicitado a criar uma senha ao ativar sua conta, juntando-se assim ao domínio do IdM.
    • Enquanto a senha do usuário é o método padrão de autenticação para um usuário, a guia de chave é o método padrão de autenticação para um host. A tabela de chaves é armazenada em um arquivo no host.

    Tabela 27.1. Inscrição de usuários e anfitriões

    AçãoUsuárioAnfitrião

    Pré-inscrição

    $ ipa stageuser-add user_name [--password]

    $ ipa host-add host_name [--random]

    Ativação da conta

    $ ipa stageuser-activate user_name

    US$ ipa-client install [--password] (deve ser executado no próprio anfitrião)

  • A etapa de implantação (Tabela 27.2, “Autenticação do usuário e do anfitrião da sessão”):

    • Quando um usuário inicia uma nova sessão, o usuário se autentica usando uma senha; da mesma forma, toda vez que é ligado, o host se autentica apresentando seu arquivo keytab. O System Security Services Daemon (SSSD) gerencia este processo em segundo plano.
    • Se a autenticação for bem sucedida, o usuário ou anfitrião obtém um bilhete Kerberos de concessão de bilhete (TGT).
    • O TGT é então utilizado para a obtenção de bilhetes específicos para serviços específicos.

    Tabela 27.2. Autenticação do usuário e do anfitrião da sessão

     UsuárioAnfitrião

    Meios padrão de autenticação

    Password

    Keytabs

    Início de uma sessão (usuário comum)

    $ kinit user_name

    [switch on the host]

    O resultado de uma autenticação bem sucedida

    TGT a ser utilizado para obter acesso a serviços específicos

    TGT a ser utilizado para obter acesso a serviços específicos

Os TGTs e outros bilhetes Kerberos são gerados como parte dos serviços e políticas Kerberos definidos pelo servidor. A concessão inicial de um bilhete Kerberos, a renovação das credenciais Kerberos e até mesmo a destruição da sessão Kerberos são todos tratados automaticamente pelos serviços da IdM.

27.2.3. Opções alternativas de autenticação para hosts IdM

Além das fichas-chave, a IdM suporta dois outros tipos de autenticação de máquinas:

  • Chaves SSH. A chave pública SSH para o host é criada e carregada para a entrada do host. A partir daí, o System Security Services Daemon (SSSD) usa IdM como um provedor de identidade e pode trabalhar em conjunto com OpenSSH e outros serviços para referenciar as chaves públicas localizadas centralmente no IdM.
  • Certificados de máquinas. Neste caso, a máquina usa um certificado SSL que é emitido pela autoridade certificadora do servidor da IdM e depois armazenado no Servidor de Diretório da IdM. O certificado é então enviado à máquina para apresentar quando ela se autentica ao servidor. No cliente, os certificados são gerenciados por um serviço chamado certmonger.

27.3. Operações de hospedagem

Esta seção lista as operações mais comuns relacionadas à inscrição e habilitação do hospedeiro, e explica os pré-requisitos, o contexto e as conseqüências da sua realização.

Tabela 27.3. Operações de hospedagem parte 1

AçãoQuais são os pré-requisitos para a ação?Quando faz sentido executar o comando?Como a ação é executada por um administrador de sistemas? Que comando(s) é(são) executado(s)?

Enrolling a client

ver Preparando o sistema para a instalação do cliente de Gerenciamento de Identidade em Installing_Identity_Management

Quando você quiser que o anfitrião se junte ao reino da IdM.

A inscrição de máquinas como clientes no domínio da IdM é um processo em duas partes. Uma entrada de host é criada para o cliente (e armazenada na instância 389 Directory Server) quando o comando ipa host-add é executado, e então é criada uma tabela de chaves para provisionar o cliente. Ambas as partes são executadas automaticamente pelo comando ipa-client-install. Também é possível executar estas etapas separadamente; isto permite aos administradores preparar as máquinas e a IdM antes de realmente configurar os clientes. Isto permite cenários de configuração mais flexíveis, incluindo implantações em massa.

Disabling a client

O anfitrião deve ter uma entrada na IdM. O anfitrião precisa ter um keytab ativo.

Quando você quiser remover temporariamente o hospedeiro do domínio da IdM, talvez para fins de manutenção.

ipa host-disable host_name

Enabling a client

O anfitrião deve ter uma entrada na IdM.

Quando você quiser que o anfitrião temporariamente incapacitado torne-se ativo novamente.

ipa-getkeytab

Re-enrolling a client

O anfitrião deve ter entrado na IdM.

Quando o anfitrião original se perdeu, mas você instalou um anfitrião com o mesmo nome de anfitrião.

ipa-client-install --keytab ou ipa-client-install --force-join

Un-enrolling a client

O anfitrião deve ter uma entrada na IdM.

Quando você quiser remover o anfitrião do reino da IdM permanentemente.

ipa-client-install --uninstall

Tabela 27.4. Operações de hospedagem parte 2

AçãoEm qual máquina o administrador pode executar o(s) comando(s)?O que acontece quando a ação é executada? Quais são as conseqüências para o funcionamento do hospedeiro na IdM? Quais limitações são introduzidas/removidas?

Enrolling a client

No caso de uma inscrição em duas etapas: ipa host-add pode ser executado em qualquer cliente IdM; a segunda etapa de ipa-client-install deve ser executada no próprio cliente

Por padrão, isto configura o SSSD para conexão a um servidor IdM para autenticação e autorização. Opcionalmente, pode-se configurar o Módulo de Autenticação Plugável (PAM) e o Serviço de Comutação de Nomes (NSS) para trabalhar com um servidor IdM sobre Kerberos e LDAP.

Disabling a client

Qualquer máquina na IdM, mesmo o próprio host

A chave Kerberos e o certificado SSL do host são invalidados, e todos os serviços executados no host são desativados.

Enabling a client

Qualquer máquina na IdM. Se rodar no host com deficiência, as credenciais LDAP precisam ser fornecidas.

A chave Kerberos do host e o certificado SSL são validados novamente, e todos os serviços IdM rodando no host são reativados.

Re-enrolling a client

O anfitrião a ser reconduzido. As credenciais LDAP precisam ser fornecidas.

Uma nova chave Kerberos é gerada para o anfitrião, substituindo a anterior.

Un-enrolling a client

O anfitrião a ser desenrolado.

O comando desfigura o IdM e tenta devolver a máquina ao seu estado anterior. Parte deste processo é desenrolar o host a partir do servidor IdM. A desinscrição consiste em desabilitar a chave principal no servidor IdM. A chave principal da máquina em /etc/krb5.keytab (host/<fqdn>@REALM) é usada para autenticar no servidor de IdM para se desenrolar. Se este principal não existir, a desinscrição falhará e um administrador precisará desabilitar o principal do host (ipa host-disable <fqdn>).

27.4. Entrada de anfitrião em IdM LDAP

Esta seção descreve como é uma entrada anfitriã em Gerenciamento de Identidade (IdM) e quais atributos ela pode conter.

Uma entrada de anfitrião LDAP contém todas as informações relevantes sobre o cliente dentro da IdM:

  • Entradas de serviço associadas com o anfitrião
  • O anfitrião e diretor de serviços
  • Regras de controle de acesso
  • Informações da máquina, tais como sua localização física e sistema operacional
Nota

Note que a guia IdM Web UI IdentityHosts não mostra todas as informações sobre um determinado host armazenado no IdM LDAP.

27.4.1. Propriedades de configuração de entrada do host

Uma entrada de host pode conter informações sobre o host que está fora de sua configuração de sistema, tais como sua localização física, endereço MAC, chaves e certificados.

Esta informação pode ser definida quando a entrada do host é criada, se for criada manualmente. Alternativamente, a maior parte destas informações pode ser adicionada à entrada do host depois que o host é registrado no domínio.

Tabela 27.5. Propriedades de configuração do host

Campo UIOpção de Linha de ComandoDescrição

Descrição

--desc=description

Uma descrição do anfitrião.

Localidade

--locality=locality

A localização geográfica do anfitrião.

Localização

--location=location

A localização física do host, tal como seu rack do centro de dados.

Plataforma

--platform=string

O hardware ou arquitetura do host.

Sistema operacional

--os=string

O sistema operacional e a versão para o host.

Endereço MAC

--macaddress=address

O endereço MAC para o anfitrião. Este é um atributo multivalorizado. O endereço MAC é usado pelo plug-in NIS para criar um mapa NIS ethers para o host.

Chaves públicas SSH

--sshpubkey=string

A chave pública SSH completa para o anfitrião. Este é um atributo multivalorizado, portanto, várias chaves podem ser definidas.

Nome principal (não editável)

--principalname=principal

O nome principal de Kerberos para o anfitrião. Este padrão é o nome principal do host durante a instalação do cliente, a menos que um nome principal diferente seja explicitamente definido no site -p. Isto pode ser alterado usando as ferramentas de linha de comando, mas não pode ser alterado na interface de usuário.

Definir senha única

--password=string

Esta opção define uma senha para o anfitrião que pode ser usada na inscrição em massa.

-

--random

Esta opção gera uma senha aleatória para ser usada na inscrição em massa.

-

--certificate=string

Uma bolha de certificado para o anfitrião.

-

--updatedns

Isto define se o host pode atualizar dinamicamente suas entradas DNS se seu endereço IP mudar.

27.5. Adicionando entradas do host IdM da IdM CLI

Esta seção descreve como adicionar entradas de host no Gerenciamento de Identidade (IdM) usando a interface de linha de comando (CLI).

As entradas do host são criadas usando o comando host-add. Este comando adiciona a entrada do host ao Servidor de Diretório IdM. Consulte o manpage ipa host digitando ipa help host em seu CLI para obter a lista completa de opções disponíveis com host-add.

Há alguns cenários diferentes quando se adiciona um anfitrião à IdM:

  • Em sua forma mais básica, especifique apenas o nome do host cliente para adicionar o cliente ao reino Kerberos e para criar uma entrada no servidor LDAP da IdM:

    $ ipa host-add client1.example.com
  • Se o servidor IdM estiver configurado para gerenciar o DNS, adicione o host aos registros de recursos DNS usando a opção --ip-address.

    Exemplo 27.1. Criação de entradas de host com endereços IP estáticos

    $ ipa host-add --ip-address=192.168.166.31 client1.example.com
  • Se o host a ser adicionado não tiver um endereço IP estático ou se o endereço IP não for conhecido no momento em que o cliente for configurado, use a opção --force com o comando ipa host-add.

    Exemplo 27.2. Criação de entradas de hospedagem com DHCP

    $ ipa host-add --force client1.example.com

    Por exemplo, os laptops podem ser pré-configurados como clientes IdM, mas eles não têm endereços IP no momento em que são configurados. O uso de --force cria essencialmente uma entrada de espaço no serviço DNS da IdM. Quando o serviço DNS atualiza dinamicamente seus registros, o endereço IP atual do host é detectado e seu registro DNS é atualizado.

27.6. Eliminação de entradas do anfitrião do IdM CLI

  • Use o comando host-del para excluir registros do host. Se seu domínio IdM tem DNS integrado, use a opção --updatedns para remover do DNS os registros associados de qualquer tipo para o host:

    $ ipa host-del --updatedns client1.example.com

27.7. Recrutamento de um cliente de Gerenciamento de Identidade

27.7.1. Recrutamento de clientes na IdM

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

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

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

Importante

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

Não é possível matricular novamente um cliente depois de renomeá-lo. Isto porque na Gestão de Identidade, 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 Seção 27.8, “Renomeação de sistemas de gerenciamento de identidade de clientes”.

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

Durante a re-inscrição, Gerenciamento de Identidade:

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

27.7.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, utilizando as credenciais de um usuário autorizado.

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

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

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

Recursos adicionais

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

Pré-requisitos

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

Procedimento

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

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

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

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

27.7.4. Teste de um cliente de Gerenciamento de Identidade após a instalação

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 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 da IdM:

[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 ~]$

27.8. Renomeação de sistemas de gerenciamento de identidade de clientes

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

Atenção

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

Renomear um cliente de Gerenciamento de Identidade envolve:

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

27.8.1. Pré-requisitos

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

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

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

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

    # find / -name "*.keytab"

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

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

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

27.8.2. Desinstalando um cliente de Gerenciamento de Identidade

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

Procedimento

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

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

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

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

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

27.8.3. Renomeando o sistema hospedeiro

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

[root@client]# hostnamectl set-hostname new-client-name.example.com

Agora você pode reinstalar o cliente de Gerenciamento de Identidade para o domínio de Gerenciamento de Identidade com o novo nome do host.

27.8.4. Re-instalação de um cliente de Gerenciamento de Identidade

Instale um cliente em seu host renomeado seguindo o procedimento descrito em Instalação de um cliente de Gerenciamento de Identidade: Cenário básico em Installing Identity Management.

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

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

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

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

27.9. Desativação e reativação de entradas de hospedagem

Esta seção descreve como desativar e reativar hospedeiros no Gerenciamento de Identidade (IdM).

27.9.1. Anfitriões incapacitantes

Complete este procedimento para desativar uma entrada de anfitrião na IdM.

Serviços de domínio, hosts e usuários podem acessar um host ativo. Pode haver situações em que é necessário remover temporariamente um host ativo, por razões de manutenção, por exemplo. A exclusão do host em tais situações não é desejada, pois remove a entrada do host e toda a configuração associada permanentemente. Ao invés disso, escolha a opção de desativar o host.

A desativação de um host impede que os usuários do domínio tenham acesso a ele sem removê-lo permanentemente do domínio. Isto pode ser feito usando o comando host-disable. A desativação de um host mata as chaves ativas e atuais do host.

Por exemplo:

$ kinit admin
$ ipa host-disable client.example.com

Como resultado da desativação de um host, o host fica indisponível para todos os usuários, hosts e serviços da IdM.

Importante

Desabilitar a entrada de um host não só desabilita esse host. Ele também desabilita todos os serviços configurados nesse host.

27.9.2. Hóspedes de reativação

Esta seção descreve como reativar um host IdM deficiente.

A desativação de um host matou suas fichas-chave ativas, que removeram o host do domínio IdM sem tocar de outra forma em sua entrada de configuração.

Para reativar um host, use o comando ipa-getkeytab, adicionando:

  • a opção -s para especificar a qual servidor IdM solicitar o keytab de
  • a opção -p para especificar o nome principal
  • a opção -k para especificar o arquivo para o qual salvar a tabela de chaves.

Por exemplo, para solicitar uma nova keytab do host server.example.com para client.example.com, e armazenar a keytab no arquivo /etc/krb5.keytab:

$  ipa-getkeytab -s server.example.com -p host/client.example.com -k /etc/krb5.keytab -D "cn=directory manager" -w password
Nota

Você também pode usar as credenciais do administrador, especificando -D "uid=admin,cn=users,cn=accounts,dc=example,dc=com". É importante que as credenciais correspondam a um usuário autorizado a criar o keytab para o host.

Se o comando ipa-getkeytab for executado em um cliente ou servidor IdM ativo, então ele pode ser executado sem nenhuma credencial LDAP (-D e -w) se o usuário tiver um TGT obtido usando, por exemplo, kinit admin. Para executar o comando diretamente no host desativado, forneça credenciais LDAP para autenticar no servidor IdM.

Capítulo 28. Adicionando entradas de host da IdM Web UI

Este capítulo apresenta os anfitriões no Gerenciamento de Identidade (IdM) e a operação de adicionar uma entrada de anfitrião na interface web do IdM.

28.1. Anfitriões na IdM

A Gestão de Identidade (IdM) gerencia estas identidades:

  • Usuários
  • Serviços
  • Anfitriões

Um anfitrião representa uma máquina. Como uma identidade IdM, um host tem uma entrada no IdM LDAP, ou seja, a instância 389 Directory Server do servidor IdM.

A entrada do host no IdM LDAP é usada para estabelecer relações entre outros hosts e até mesmo serviços dentro do domínio. Estas relações fazem parte da autorização e controle do delegating para hosts dentro do domínio. Qualquer host pode ser usado nas regras do host-based access control (HBAC).

O domínio IdM estabelece uma uniformidade entre as máquinas, com informações de identidade comuns, políticas comuns e serviços compartilhados. Qualquer máquina que pertença a um domínio funciona como cliente do domínio, o que significa que utiliza os serviços que o domínio oferece. O domínio IdM fornece três serviços principais especificamente para máquinas:

  • DNS
  • Kerberos
  • Gestão de certificados

Os anfitriões na IdM estão intimamente ligados com os serviços que funcionam neles:

  • As entradas de serviço estão associadas a um anfitrião.
  • Um anfitrião armazena tanto o anfitrião quanto os diretores de serviço Kerberos.

28.2. Inscrição de anfitriões

Esta seção descreve a inscrição de anfitriões como clientes da IdM e o que acontece durante e após a inscrição. A seção compara a matrícula de hospedeiros IdM e usuários IdM. A seção também descreve os tipos alternativos de autenticação disponíveis para os anfitriões.

A inscrição de um anfitrião consiste em:

  • Criação de uma entrada hospedeira no IdM LDAP: possivelmente usando o comandoipa host-add no IdM CLI, ou a operação equivalente do IdM Web UI.
  • Configurando os serviços IdM no host, por exemplo o System Security Services Daemon (SSSD), Kerberos, e certmonger, e unindo o host ao domínio IdM.

As duas ações podem ser realizadas separadamente ou em conjunto.

Se realizadas separadamente, elas permitem dividir as duas tarefas entre dois usuários com diferentes níveis de privilégio. Isto é útil para implantações em massa.

O comando ipa-client-install pode realizar as duas ações em conjunto. O comando cria uma entrada hospedeira no IdM LDAP se essa entrada ainda não existir, e configura tanto os serviços Kerberos como SSSD para o hospedeiro. O comando traz o host dentro do domínio IdM e permite que ele identifique o servidor IdM com o qual ele se conectará. Se o host pertence a uma zona DNS gerenciada pela IdM, ipa-client-install adiciona registros DNS para o host também. O comando deve ser executado no cliente.

28.2.1. Privilégios de usuário necessários para a inscrição no host

A operação de inscrição no host requer autenticação para evitar que um usuário sem privilégios acrescente máquinas indesejadas ao domínio IdM. Os privilégios requeridos dependem de vários fatores, por exemplo:

  • Se uma entrada de anfitrião for criada separadamente da execução ipa-client-install
  • Se uma senha única (OTP) for usada para a inscrição
Privilégios do usuário para, opcionalmente, criar manualmente uma entrada de host no IdM LDAP

O privilégio do usuário necessário para criar uma entrada no IdM LDAP usando o comando ipa host-add CLI ou o IdM Web UI é Host Administrators. O privilégio Host Administrators pode ser obtido através da função IT Specialist.

Privilégios do usuário para unir o cliente ao domínio IdM

Os anfitriões são configurados como clientes IdM durante a execução do comando ipa-client-install. O nível de credenciais necessárias para executar o comando ipa-client-install depende de qual dos seguintes cenários de cadastro você se encontra:

  • A entrada anfitriã no IdM LDAP não existe. Para este cenário, você precisa de uma credencial completa de administrador ou do papel Host Administrators. Um administrador pleno é um membro do grupo admins. A função Host Administrators fornece privilégios para adicionar anfitriões e cadastrar anfitriões. Para detalhes sobre este cenário, consulte Instalação de um cliente usando credenciais de usuário: instalação interativa.
  • A entrada anfitriã no IdM LDAP existe. Para este cenário, você precisa de uma credencial limitada de administrador para executar com sucesso o ipa-client-install. O administrador limitado neste caso tem o papel de Enrollment Administrator, que fornece o privilégio de Host Enrollment. Para detalhes, consulte Instalação de um cliente usando credenciais de usuário: instalação interativa.
  • A entrada do hospedeiro no IdM LDAP existe, e um OTP foi gerado para o hospedeiro por um administrador completo ou limitado. Para este cenário, você pode instalar um cliente IdM como um usuário comum se executar o comando ipa-client-install com a opção --password, fornecendo o OTP correto. Para detalhes, consulte Instalação de um cliente usando uma senha única: Instalação interativa.

Após a inscrição, os anfitriões da IdM autenticam cada nova sessão para poder acessar os recursos da IdM. A autenticação da máquina é necessária para que o servidor IdM confie na máquina e aceite conexões IdM do software cliente instalado naquela máquina. Após autenticar o cliente, o servidor IdM pode responder a suas solicitações.

28.2.2. Inscrição e autenticação de hosts e usuários IdM: comparação

Há muitas semelhanças entre usuários e anfitriões na IdM. Esta seção descreve algumas das semelhanças que podem ser observadas durante a fase de inscrição, bem como aquelas que dizem respeito à autenticação durante a fase de implantação.

  • A etapa de cadastramento (Tabela 28.1, “Inscrição de usuários e anfitriões”):

    • Um administrador pode criar uma entrada LDAP tanto para um usuário quanto para um host antes de o usuário ou host realmente entrar no IdM: para o usuário em estágio, o comando é ipa stageuser-add; para o host, o comando é ipa host-add.
    • Um arquivo contendo um key table ou, abreviado, keytab, uma chave simétrica parecida em certa medida com uma senha de usuário, é criado durante a execução do comando ipa-client-install no host, resultando na adesão do host ao reino do IdM. Analogicamente, o usuário é solicitado a criar uma senha ao ativar sua conta, juntando-se assim ao domínio do IdM.
    • Enquanto a senha do usuário é o método padrão de autenticação para um usuário, a guia de chave é o método padrão de autenticação para um host. A tabela de chaves é armazenada em um arquivo no host.

    Tabela 28.1. Inscrição de usuários e anfitriões

    AçãoUsuárioAnfitrião

    Pré-inscrição

    $ ipa stageuser-add user_name [--password]

    $ ipa host-add host_name [--random]

    Ativação da conta

    $ ipa stageuser-activate user_name

    US$ ipa-client install [--password] (deve ser executado no próprio anfitrião)

  • A etapa de implantação (Tabela 28.2, “Autenticação do usuário e do anfitrião da sessão”):

    • Quando um usuário inicia uma nova sessão, o usuário se autentica usando uma senha; da mesma forma, toda vez que é ligado, o host se autentica apresentando seu arquivo keytab. O System Security Services Daemon (SSSD) gerencia este processo em segundo plano.
    • Se a autenticação for bem sucedida, o usuário ou anfitrião obtém um bilhete Kerberos de concessão de bilhete (TGT).
    • O TGT é então utilizado para a obtenção de bilhetes específicos para serviços específicos.

    Tabela 28.2. Autenticação do usuário e do anfitrião da sessão

     UsuárioAnfitrião

    Meios padrão de autenticação

    Password

    Keytabs

    Início de uma sessão (usuário comum)

    $ kinit user_name

    [switch on the host]

    O resultado de uma autenticação bem sucedida

    TGT a ser utilizado para obter acesso a serviços específicos

    TGT a ser utilizado para obter acesso a serviços específicos

Os TGTs e outros bilhetes Kerberos são gerados como parte dos serviços e políticas Kerberos definidos pelo servidor. A concessão inicial de um bilhete Kerberos, a renovação das credenciais Kerberos e até mesmo a destruição da sessão Kerberos são todos tratados automaticamente pelos serviços da IdM.

28.2.3. Opções alternativas de autenticação para hosts IdM

Além das fichas-chave, a IdM suporta dois outros tipos de autenticação de máquinas:

  • Chaves SSH. A chave pública SSH para o host é criada e carregada para a entrada do host. A partir daí, o System Security Services Daemon (SSSD) usa IdM como um provedor de identidade e pode trabalhar em conjunto com OpenSSH e outros serviços para referenciar as chaves públicas localizadas centralmente no IdM.
  • Certificados de máquinas. Neste caso, a máquina usa um certificado SSL que é emitido pela autoridade certificadora do servidor da IdM e depois armazenado no Servidor de Diretório da IdM. O certificado é então enviado à máquina para apresentar quando ela se autentica ao servidor. No cliente, os certificados são gerenciados por um serviço chamado certmonger.

28.3. Entrada de anfitrião em IdM LDAP

Esta seção descreve como é uma entrada anfitriã em Gerenciamento de Identidade (IdM) e quais atributos ela pode conter.

Uma entrada de anfitrião LDAP contém todas as informações relevantes sobre o cliente dentro da IdM:

  • Entradas de serviço associadas com o anfitrião
  • O anfitrião e diretor de serviços
  • Regras de controle de acesso
  • Informações da máquina, tais como sua localização física e sistema operacional
Nota

Note que a guia IdM Web UI IdentityHosts não mostra todas as informações sobre um determinado host armazenado no IdM LDAP.

28.3.1. Propriedades de configuração de entrada do host

Uma entrada de host pode conter informações sobre o host que está fora de sua configuração de sistema, tais como sua localização física, endereço MAC, chaves e certificados.

Esta informação pode ser definida quando a entrada do host é criada, se for criada manualmente. Alternativamente, a maior parte destas informações pode ser adicionada à entrada do host depois que o host é registrado no domínio.

Tabela 28.3. Propriedades de configuração do host

Campo UIOpção de Linha de ComandoDescrição

Descrição

--desc=description

Uma descrição do anfitrião.

Localidade

--locality=locality

A localização geográfica do anfitrião.

Localização

--location=location

A localização física do host, tal como seu rack do centro de dados.

Plataforma

--platform=string

O hardware ou arquitetura do host.

Sistema operacional

--os=string

O sistema operacional e a versão para o host.

Endereço MAC

--macaddress=address

O endereço MAC para o anfitrião. Este é um atributo multivalorizado. O endereço MAC é usado pelo plug-in NIS para criar um mapa NIS ethers para o host.

Chaves públicas SSH

--sshpubkey=string

A chave pública SSH completa para o anfitrião. Este é um atributo multivalorizado, portanto, várias chaves podem ser definidas.

Nome principal (não editável)

--principalname=principal

O nome principal de Kerberos para o anfitrião. Este padrão é o nome principal do host durante a instalação do cliente, a menos que um nome principal diferente seja explicitamente definido no site -p. Isto pode ser alterado usando as ferramentas de linha de comando, mas não pode ser alterado na interface de usuário.

Definir senha única

--password=string

Esta opção define uma senha para o anfitrião que pode ser usada na inscrição em massa.

-

--random

Esta opção gera uma senha aleatória para ser usada na inscrição em massa.

-

--certificate=string

Uma bolha de certificado para o anfitrião.

-

--updatedns

Isto define se o host pode atualizar dinamicamente suas entradas DNS se seu endereço IP mudar.

28.4. Adição de entradas de hospedagem da Web UI

  1. Abra a guia Identity, e selecione a subguia Hosts.
  2. Clique em Adicionar no topo da lista de anfitriões.

    Figura 28.1. Adicionando entradas de anfitrião

    hosts list
  3. Insira o nome da máquina e selecione o domínio a partir das zonas configuradas na lista suspensa. Se o host já tiver sido atribuído um endereço IP estático, então inclua-o com a entrada do host para que a entrada DNS seja totalmente criada.

    O campo Class não tem nenhuma finalidade específica no momento.

    Figura 28.2. Adicionar Host Wizard

    host add

    As zonas DNS podem ser criadas em IdM. Se o servidor IdM não gerenciar o servidor DNS, a zona pode ser inserida manualmente na área do menu, como um campo de texto regular.

    Nota

    Selecione a caixa de seleção Force se você quiser pular a verificação se o host é resolúvel via DNS.

  4. Clique no botão Add and Edit para ir diretamente para a página de entrada expandida e inserir mais informações de atributos. Informações sobre o hardware e localização física do host podem ser incluídas com a entrada do host.

    Figura 28.3. Página de Entrada Expandida

    host attr

Capítulo 29. Gerenciamento de anfitriões usando Livros didáticos Ansíveis

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 os módulos Ansible para automatizar o gerenciamento do host.

Este capítulo descreve as seguintes operações realizadas na administração de anfitriões e entradas de anfitriões usando Livros de Brinquedos Ansíveis:

29.1. Assegurar a presença de uma entrada de um host IdM com FQDN usando Livros de Jogadas Ansíveis

Esta seção descreve como garantir a presença de entradas de anfitriões no Gerenciamento de Identidade (IdM) usando Livros de Jogadas Ansíveis. As entradas do host são definidas apenas por seus fully-qualified domain names (FQDNs).

A especificação do nome FQDN do anfitrião é suficiente se pelo menos uma das seguintes condições se aplicar:

  • O servidor IdM não está configurado para gerenciar o DNS.
  • O host não tem um endereço IP estático ou o endereço IP não é conhecido no momento em que o host é configurado. A adição de um host definido apenas por um FQDN cria essencialmente uma entrada de espaço reservado no serviço DNS do IdM. Por exemplo, os laptops podem ser pré-configurados como clientes IdM, mas não possuem endereços IP no momento em que são configurados. Quando o serviço DNS atualiza dinamicamente seus registros, o endereço IP atual do host é detectado e seu registro DNS é atualizado.
Nota

Sem Ansible, as entradas do host são criadas no IdM usando o comando ipa host-add. O resultado da adição de um host ao IdM é o estado do host que está presente no IdM. Devido à possível dependência do Idempotence, para adicionar um host ao IdM usando o Ansible, você deve criar um playbook no qual você define o estado do host como presente: state: present.

Pré-requisitos

  • Você sabe a senha do administrador da IdM.
  • O pacote ansible-freeipa é instalado no controlador Ansible.

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaserver no mesmo:

    [ipaserver]
    server.idm.example.com
  2. Crie um arquivo de playbook possível com o FQDN do anfitrião cuja presença na IdM você quer garantir. Para simplificar esta etapa, você pode copiar e modificar o exemplo no arquivo /usr/share/doc/ansible-freeipa/playbooks/host/add-host.yml:

    ---
    - name: Host present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Host host01.idm.example.com present
        ipahost:
          ipaadmin_password: MySecret123
          name: host01.idm.example.com
          state: present
          force: yes
  3. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-is-present.yml
Nota

O procedimento resulta na criação de uma entrada de host no servidor LDAP da IdM, mas não na inscrição do host no reino da IdM Kerberos. Para isso, deve-se implantar o host como um cliente IdM. Para detalhes, consulte Instalando um cliente de Gerenciamento de Identidade usando um livro de exercícios.

Etapas de verificação

  1. Faça o login em seu servidor IdM como administrador:

    $ ssh admin@server.idm.example.com
    Password:
  2. Digite o comando ipa host-show e especifique o nome do anfitrião:

    $ ipa host-show host01.idm.example.com
      Host name: host01.idm.example.com
      Principal name: host/host01.idm.example.com@IDM.EXAMPLE.COM
      Principal alias: host/host01.idm.example.com@IDM.EXAMPLE.COM
      Password: False
      Keytab: False
      Managed by: host01.idm.example.com

A saída confirma que host01.idm.example.com existe na IdM.

29.2. Assegurar a presença de uma entrada de um host IdM com informações DNS usando Livros de Jogadas Ansíveis

Esta seção descreve como garantir a presença de entradas de anfitriões no Gerenciamento de Identidade (IdM) usando Livros de Jogadas Ansíveis. As entradas do host são definidas por seus fully-qualified domain names (FQDNs) e seus endereços IP.

Nota

Sem Ansible, as entradas do host são criadas no IdM usando o comando ipa host-add. O resultado da adição de um host ao IdM é o estado do host que está presente no IdM. Devido à possível dependência do Idempotence, para adicionar um host ao IdM usando o Ansible, você deve criar um playbook no qual você define o estado do host como presente: state: present.

Pré-requisitos

  • Você sabe a senha do administrador da IdM.
  • O pacote ansible-freeipa é instalado no controlador Ansible.

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaserver no mesmo:

    [ipaserver]
    server.idm.example.com
  2. Crie um arquivo de playbook possível com o fully-qualified domain name (FQDN) do anfitrião cuja presença na IdM você quer garantir. Além disso, se o servidor IdM estiver configurado para gerenciar o DNS e você conhecer o endereço IP do host, especifique um valor para o parâmetro ip_address. O endereço IP é necessário para que o host exista nos registros de recursos DNS. Para simplificar esta etapa, você pode copiar e modificar o exemplo no arquivo /usr/share/doc/ansible-freeipa/playbooks/host/host-present.yml. Você também pode incluir outras informações adicionais:

    ---
    - name: Host present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure host01.idm.example.com is present
        ipahost:
          ipaadmin_password: MySecret123
          name: host01.idm.example.com
          description: Example host
          ip_address: 192.168.0.123
          locality: Lab
          ns_host_location: Lab
          ns_os_version: CentOS 7
          ns_hardware_platform: Lenovo T61
          mac_address:
          - "08:00:27:E3:B1:2D"
          - "52:54:00:BD:97:1E"
          state: present
  3. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-is-present.yml
Nota

O procedimento resulta na criação de uma entrada de host no servidor LDAP da IdM, mas não na inscrição do host no reino da IdM Kerberos. Para isso, deve-se implantar o host como um cliente IdM. Para detalhes, consulte Instalando um cliente de Gerenciamento de Identidade usando um livro de exercícios.

Etapas de verificação

  1. Faça o login em seu servidor IdM como administrador:

    $ ssh admin@server.idm.example.com
    Password:
  2. Digite o comando ipa host-show e especifique o nome do anfitrião:

    $ ipa host-show host01.idm.example.com
      Host name: host01.idm.example.com
      Description: Example host
      Locality: Lab
      Location: Lab
      Platform: Lenovo T61
      Operating system: CentOS 7
      Principal name: host/host01.idm.example.com@IDM.EXAMPLE.COM
      Principal alias: host/host01.idm.example.com@IDM.EXAMPLE.COM
      MAC address: 08:00:27:E3:B1:2D, 52:54:00:BD:97:1E
      Password: False
      Keytab: False
      Managed by: host01.idm.example.com

A saída confirma que host01.idm.example.com existe na IdM.

29.3. Garantir a presença de múltiplas entradas no host IdM com senhas aleatórias usando Livros de Jogadas Ansíveis

O módulo ipahost permite ao administrador do sistema garantir a presença ou ausência de múltiplas entradas no IdM usando apenas uma tarefa possível. Esta seção descreve como garantir a presença de múltiplas entradas de host que são definidas apenas por seus fully-qualified domain names (FQDNs). A execução do Ansible playbook gera senhas aleatórias para os hosts.

Nota

Sem Ansible, as entradas do host são criadas no IdM usando o comando ipa host-add. O resultado da adição de um host ao IdM é o estado do host que está presente no IdM. Devido à possível dependência do Idempotence, para adicionar um host ao IdM usando o Ansible, você deve criar um playbook no qual você define o estado do host como presente: state: present.

Pré-requisitos

  • Você sabe a senha do administrador da IdM.
  • O pacote ansible-freeipa é instalado no controlador Ansible.

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaserver no mesmo:

    [ipaserver]
    server.idm.example.com
  2. Crie um arquivo de playbook possível com o fully-qualified domain name (FQDN) dos anfitriões cuja presença na IdM você quer garantir. Para fazer com que o Ansible playbook gere uma senha aleatória para cada host mesmo quando o host já existe na IdM e update_password está limitado a on_create, adicione as opções random: yes e force: yes. Para simplificar esta etapa, você pode copiar e modificar o exemplo do arquivo Markdown de /usr/share/doc/ansible-freeipa/README-host.md:

    ---
    - name: Ensure hosts with random password
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Hosts host01.idm.example.com and host02.idm.example.com present with random passwords
        ipahost:
          ipaadmin_password: MySecret123
          hosts:
          - name: host01.idm.example.com
            random: yes
            force: yes
          - name: host02.idm.example.com
            random: yes
            force: yes
        register: ipahost
  3. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-are-present.yml
    [...]
    TASK [Hosts host01.idm.example.com and host02.idm.example.com present with random passwords]
    changed: [r8server.idm.example.com] => {"changed": true, "host": {"host01.idm.example.com": {"randompassword": "0HoIRvjUdH0Ycbf6uYdWTxH"}, "host02.idm.example.com": {"randompassword": "5VdLgrf3wvojmACdHC3uA3s"}}}

Etapas de verificação

  1. Faça o login em seu servidor IdM como administrador:

    $ ssh admin@server.idm.example.com
    Password:
  2. Digite o comando ipa host-show e especifique o nome de um dos anfitriões:

    $ ipa host-show host01.idm.example.com
      Host name: host01.idm.example.com
      Password: True
      Keytab: False
      Managed by: host01.idm.example.com

A saída confirma que host01.idm.example.com existe na IdM com uma senha aleatória.

29.4. Assegurar a presença de um host IdM com múltiplos endereços IP usando Livros de Jogadas Ansíveis

Esta seção descreve como garantir a presença de uma entrada anfitriã no Gerenciamento de Identidade (IdM) usando Livros de Brincadeiras Ansíveis. A entrada do host é definida por seu fully-qualified domain name (FQDN) e seus múltiplos endereços IP.

Nota

Em contraste com a utilidade ipa host, o módulo Ansible ipahost pode garantir a presença ou ausência de vários endereços IPv4 e IPv6 para um host. O comando ipa host-mod não pode tratar de endereços IP.

Pré-requisitos

  • Você sabe a senha do administrador da IdM.
  • O pacote ansible-freeipa é instalado no controlador Ansible.

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaserver no mesmo:

    [ipaserver]
    server.idm.example.com
  2. Crie um arquivo de livro de brincar possível. Especifique, como o name da variável ipahost, o fully-qualified domain name (FQDN) do anfitrião cuja presença na IdM você quer garantir. Especifique cada um dos múltiplos valores IPv4 e IPv6 ip_address em uma linha separada, usando o - ip_address sintaxe. Para simplificar esta etapa, você pode copiar e modificar o exemplo no arquivo /usr/share/doc/ansible-freeipa/playbooks/host/host-member-ipaddresses-present.yml. Você também pode incluir informações adicionais:

    ---
    - name: Host member IP addresses present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure host101.example.com IP addresses present
        ipahost:
          ipaadmin_password: MySecret123
          name: host01.idm.example.com
          ip_address:
          - 192.168.0.123
          - fe80::20c:29ff:fe02:a1b3
          - 192.168.0.124
          - fe80::20c:29ff:fe02:a1b4
          force: yes
  3. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-with-multiple-IP-addreses-is-present.yml
Nota

O procedimento cria uma entrada de host no servidor LDAP da IdM, mas não inscreve o host no reino da IdM Kerberos. Para isso, é necessário implantar o host como um cliente IdM. Para detalhes, consulte Instalando um cliente de Gerenciamento de Identidade usando um livro de exercícios possível.

Etapas de verificação

  1. Faça o login em seu servidor IdM como administrador:

    $ ssh admin@server.idm.example.com
    Password:
  2. Digite o comando ipa host-show e especifique o nome do anfitrião:

    $ ipa host-show host01.idm.example.com
      Principal name: host/host01.idm.example.com@IDM.EXAMPLE.COM
      Principal alias: host/host01.idm.example.com@IDM.EXAMPLE.COM
      Password: False
      Keytab: False
      Managed by: host01.idm.example.com

    A saída confirma que host01.idm.example.com existe na IdM.

  3. Para verificar se os múltiplos endereços IP do host existem nos registros DNS do IdM, digite o comando ipa dnsrecord-show e especifique as seguintes informações:

    • O nome do domínio IdM
    • O nome do anfitrião

      $ ipa dnsrecord-show idm.example.com host01
      [...]
        Record name: host01
        A record: 192.168.0.123, 192.168.0.124
        AAAA record: fe80::20c:29ff:fe02:a1b3, fe80::20c:29ff:fe02:a1b4

    A saída confirma que todos os endereços IPv4 e IPv6 especificados no playbook estão corretamente associados com a entrada do host host01.idm.example.com.

29.5. Garantir a ausência de uma entrada de um host IdM usando Livros de Jogadas Ansíveis

Esta seção descreve como garantir a ausência de entradas de anfitriões no Gerenciamento de Identidade (IdM) usando Livros de Jogadas Ansíveis.

Pré-requisitos

  • Credenciais do administrador da IdM

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaserver no mesmo:

    [ipaserver]
    server.idm.example.com
  2. Crie um arquivo de playbook possível com o fully-qualified domain name (FQDN) do anfitrião cuja ausência da IdM você quer garantir. Se seu domínio IdM tem DNS integrado, use a opção updatedns: yes para remover do DNS os registros associados de qualquer tipo para o host.

    Para simplificar esta etapa, você pode copiar e modificar o exemplo no arquivo /usr/share/doc/ansible-freeipa/playbooks/host/delete-host.yml:

    ---
    - name: Host absent
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Host host01.idm.example.com absent
        ipahost:
          ipaadmin_password: MySecret123
          name: host01.idm.example.com
          updatedns: yes
          state: absent
  3. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-host-absent.yml
Nota

O procedimento resulta em:

  • O anfitrião não estar presente no reino de IdM Kerberos.
  • A entrada do host não estar presente no servidor LDAP da IdM.

Para remover a configuração específica do IdM dos serviços do sistema, tais como System Security Services Daemon (SSSD), do próprio host do cliente, é necessário executar o comando ipa-client-install --uninstall no cliente. Para detalhes, veja Uninstalling an IdM client.

Etapas de verificação

  1. Acesse ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Mostrar informações sobre host01.idm.example.com:

    $ ipa host-show host01.idm.example.com
    ipa: ERROR: host01.idm.example.com: host not found

A saída confirma que o hospedeiro não existe na IdM.

Recursos adicionais

  • Você pode ver as definições das variáveis ipahost, bem como exemplos de playbooks possíveis para garantir a presença, ausência e desativação de anfitriões no arquivo Markdown /usr/share/doc/ansible-freeipa/README-host.md.
  • Os playbooks adicionais estão no diretório /usr/share/doc/ansible-freeipa/playbooks/host.

Capítulo 30. Gerenciamento de grupos anfitriões utilizando o IdM CLI

Este capítulo introduz grupos anfitriões no Gerenciamento de Identidade (IdM) e descreve as seguintes operações para gerenciar grupos anfitriões e seus membros na interface de linha de comando (CLI):

  • Visualização dos grupos anfitriões e seus membros
  • Criação de grupos anfitriões
  • Eliminação de grupos anfitriões
  • Acréscimo de membros do grupo anfitrião
  • Remoção de membros do grupo anfitrião
  • Acréscimo de gerentes de membros do grupo anfitrião
  • Remoção dos gerentes dos membros do grupo anfitrião

30.1. Grupos anfitriões na IdM

Os grupos anfitriões da IdM podem ser usados para centralizar o controle sobre importantes tarefas de gerenciamento, particularmente o controle de acesso.

Definição de grupos anfitriões

Um grupo anfitrião é uma entidade que contém um conjunto de anfitriões IdM com regras comuns de controle de acesso e outras características. Por exemplo, é possível definir grupos anfitriões com base nos departamentos da empresa, locais físicos ou requisitos de controle de acesso.

Um grupo anfitrião na IdM pode incluir:

  • Servidores e clientes da IdM
  • Outros grupos anfitriões da IdM

Grupos anfitriões criados por padrão

Por padrão, o servidor IdM cria o grupo hospedeiro ipaservers para todos os hospedeiros do servidor IdM.

Membros diretos e indiretos do grupo

Os atributos do grupo na IdM aplicam-se tanto aos membros diretos como indiretos: quando o grupo anfitrião B é membro do grupo anfitrião A, todos os membros do grupo anfitrião B são considerados membros indiretos do grupo anfitrião A.

30.2. Visualização de grupos anfitriões IdM usando o CLI

Esta seção descreve como visualizar grupos host IdM usando a interface de linha de comando (CLI).

Pré-requisitos

Procedimento

  1. Encontre todos os grupos anfitriões usando o comando ipa hostgroup-find.

    $ ipa hostgroup-find
    -------------------
    1 hostgroup matched
    -------------------
      Host-group: ipaservers
      Description: IPA server hosts
    ----------------------------
    Number of entries returned 1
    ----------------------------

    Para exibir todos os atributos de um grupo anfitrião, adicione a opção --all. Por exemplo:

    $ ipa hostgroup-find --all
    -------------------
    1 hostgroup matched
    -------------------
      dn: cn=ipaservers,cn=hostgroups,cn=accounts,dc=idm,dc=local
      Host-group: ipaservers
      Description: IPA server hosts
      Member hosts: xxx.xxx.xxx.xxx
      ipauniqueid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
      objectclass: top, groupOfNames, nestedGroup, ipaobject, ipahostgroup
    ----------------------------
    Number of entries returned 1
    ----------------------------

30.3. Criação de grupos anfitriões IdM usando o CLI

Esta seção descreve como criar grupos host IdM usando a interface de linha de comando (CLI).

Pré-requisitos

Procedimento

  1. Adicione um grupo anfitrião usando o comando ipa hostgroup-add.
    Por exemplo, para criar um grupo hospedeiro IdM chamado group_name e dar-lhe uma descrição:

    $ ipa hostgroup-add --desc 'My new host group' group_name
    ---------------------
    Added hostgroup "group_name"
    ---------------------
      Host-group: group_name
      Description: My new host group
    ---------------------

30.4. Eliminação de grupos anfitriões IdM usando o CLI

Esta seção descreve como excluir grupos host IdM usando a interface de linha de comando (CLI).

Pré-requisitos

Procedimento

  1. Eliminar um grupo hospedeiro usando o comando ipa hostgroup-del.
    Por exemplo, para excluir o grupo hospedeiro do IdM chamado group_name:

    $ ipa hostgroup-del group_name
    --------------------------
    Deleted hostgroup "group_name"
    --------------------------
Nota

A remoção de um grupo não exclui os membros do grupo da IdM.

30.5. Adicionando membros do grupo anfitrião IdM usando o CLI

Você pode adicionar tanto anfitriões quanto grupos anfitriões como membros de um grupo anfitrião IdM usando um único comando.

Pré-requisitos

  • Privilégios de administrador para gerenciar o papel de IdM ou Administrador de usuários.
  • Um bilhete Kerberos ativo. Para obter detalhes, consulte Utilizando o kinit para fazer o login na IdM manualmente.
  • Optional. Use o comando ipa hostgroup-find para encontrar anfitriões e grupos anfitriões.

Procedimento

  1. Para adicionar um membro a um grupo anfitrião, use o site ipa hostgroup-add-member e forneça as informações relevantes. Você pode especificar o tipo de membro a ser adicionado usando estas opções

    • Use a opção --hosts para adicionar um ou mais anfitriões a um grupo anfitrião da IdM.
      Por exemplo, para adicionar o anfitrião chamado example_member ao grupo chamado group_name:

      $ ipa hostgroup-add-member group_name --hosts example_member
      Host-group: group_name
      Description: My host group
      Member hosts: example_member
      -------------------------
      Number of members added 1
      -------------------------
    • Use a opção --hostgroups para adicionar um ou mais grupos anfitriões a um grupo anfitrião da IdM.
      Por exemplo, para adicionar o grupo de anfitriões chamado nested_group ao grupo chamado group_name:

      $ ipa hostgroup-add-member group_name --hostgroups nested_group
      Host-group: group_name
      Description: My host group
      Member host-groups: nested_group
      -------------------------
      Number of members added 1
      -------------------------
    • Você pode adicionar vários hosts e vários grupos host a um grupo host IdM em um único comando usando a seguinte sintaxe:

      $ ipa hostgroup-add-member group_name --hosts={host1,host2} --hostgroups={group1,group2}
Importante

Ao adicionar um grupo anfitrião como membro de outro grupo anfitrião, não crie grupos recursivos. Por exemplo, se o Grupo A for um membro do Grupo B, não adicione o Grupo B como um membro do Grupo A. Grupos recursivos podem causar um comportamento imprevisível.

30.6. Remoção de membros do grupo anfitrião IdM usando o CLI

Você pode remover os anfitriões, bem como os grupos anfitriões de um grupo anfitrião da IdM usando um único comando.

Pré-requisitos

  • Privilégios de administrador para gerenciar o papel de IdM ou Administrador de usuários.
  • Um bilhete Kerberos ativo. Para obter detalhes, consulte Utilizando o kinit para fazer o login na IdM manualmente.
  • Optional. Use o comando ipa hostgroup-find para confirmar que o grupo inclui o membro que você deseja remover.

Procedimento

  1. Para remover um membro do grupo anfitrião, use o comando ipa hostgroup-remove-member e forneça as informações relevantes. Você pode especificar o tipo de membro a ser removido usando estas opções

    • Use a opção --hosts para remover um ou mais anfitriões de um grupo anfitrião da IdM.
      Por exemplo, para remover o anfitrião chamado example_member do grupo chamado group_name:

      $ ipa hostgroup-remove-member group_name --hosts example_member
      Host-group: group_name
      Description: My host group
      -------------------------
      Number of members removed 1
      -------------------------
    • Use a opção --hostgroups para remover um ou mais grupos anfitriões de um grupo anfitrião da IdM.
      Por exemplo, para remover o grupo de anfitriões chamado nested_group do grupo chamado group_name:

      $ ipa hostgroup-remove-member group_name --hostgroups example_member
      Host-group: group_name
      Description: My host group
      -------------------------
      Number of members removed 1
      -------------------------
Nota

A remoção de um grupo não exclui os membros do grupo da IdM.

  • Você pode remover vários hosts e vários grupos host de um grupo host IdM em um único comando usando a seguinte sintaxe:

    $ ipa hostgroup-remove-member group_name --hosts={host1,host2} --hostgroups={group1,group2}

30.7. Adicionando os gerentes do grupo anfitrião da IdM usando o CLI

Você pode adicionar anfitriões, bem como grupos anfitriões como gerentes de membros, a um grupo anfitrião da IdM usando um único comando. Os gerentes membros podem adicionar anfitriões ou grupos de anfitriões a grupos de anfitriões IdM, mas não podem alterar os atributos de um grupo de anfitriões.

Pré-requisitos

  • Privilégios de administrador para gerenciar o papel de IdM ou Administrador de usuários.
  • Um bilhete Kerberos ativo. Para obter detalhes, consulte Utilizando o kinit para fazer o login na IdM manualmente.
  • Você deve ter o nome do grupo anfitrião ou do grupo anfitrião que você está adicionando como gerentes membros e o nome do grupo anfitrião que você quer que eles gerenciem.

Procedimento

  1. Optional. Use o comando ipa hostgroup-find para encontrar anfitriões e grupos anfitriões.
  2. Para adicionar um gerente membro a um grupo anfitrião, use o site ipa hostgroup-add-member-manager.

    Por exemplo, para adicionar o usuário example_member como gerente membro ao grupo chamado group_name:

    $ ipa hostgroup-add-member-manager group_name --user example_member
    Host-group: group_name
    Member hosts: server.idm.example.com
    Member host-groups: project_admins
    Member of netgroups: group_name
    Membership managed by users: example_member
    -------------------------
    Number of members added 1
    -------------------------
  3. Use a opção --groups para adicionar um ou mais grupos anfitriões como um gerente membro a um grupo anfitrião da IdM.

    Por exemplo, para adicionar o grupo anfitrião chamado admin_group como gerente membro ao grupo chamado group_name:

    $ ipa hostgroup-add-member-manager group_name --groups admin_group
    Host-group: group_name
    Member hosts: server.idm.example.com
    Member host-groups: project_admins
    Member of netgroups: group_name
    Membership managed by groups: admin_group
    Membership managed by users: example_member
    -------------------------
    Number of members added 1
    -------------------------
Nota

Após adicionar um gerente membro a um grupo anfitrião, a atualização pode levar algum tempo para se espalhar a todos os clientes em seu ambiente de Gerenciamento de Identidade.

Etapas de verificação

  • Usando o comando ipa group-show para verificar o usuário anfitrião e o grupo anfitrião foram adicionados como gerentes membros.

    $ ipa hostgroup-show group_name
    Host-group: group_name
    Member hosts: server.idm.example.com
    Member host-groups: project_admins
    Membership managed by groups: admin_group
    Membership managed by users: example_member

Recursos adicionais

  • Veja ipa hostgroup-add-member-manager --help para mais detalhes.
  • Veja ipa hostgroup-show --help para mais detalhes.

30.8. Removendo os gerentes do grupo anfitrião da IdM usando o CLI

Você pode remover os anfitriões, assim como os grupos anfitriões como gerentes membros de um grupo anfitrião da IdM usando um único comando. Os gerentes membros podem remover os gerentes membros do grupo anfitrião de um grupo anfitrião IdM, mas não podem alterar os atributos de um grupo anfitrião.

Pré-requisitos

  • Privilégios de administrador para gerenciar o papel de IdM ou Administrador de usuários.
  • Um bilhete Kerberos ativo. Para obter detalhes, consulte Utilizando o kinit para fazer o login na IdM manualmente.
  • Você deve ter o nome do grupo anfitrião existente que você está removendo e o nome do grupo anfitrião que eles estão gerenciando.

Procedimento

  1. Optional. Use o comando ipa hostgroup-find para encontrar anfitriões e grupos anfitriões.
  2. Para remover um gerente membro de um grupo anfitrião, use o comando ipa hostgroup-remove-member-manager.

    Por exemplo, para remover o usuário chamado example_member como gerente membro do grupo chamado group_name:

    $ ipa hostgroup-remove-member-manager group_name --user example_member
    Host-group: group_name
    Member hosts: server.idm.example.com
    Member host-groups: project_admins
    Member of netgroups: group_name
    Membership managed by groups: nested_group
    ---------------------------
    Number of members removed 1
    ---------------------------
  3. Use a opção --groups para remover um ou mais grupos anfitriões como um gerente membro de um grupo anfitrião da IdM.

    Por exemplo, para remover o grupo anfitrião chamado nested_group como gerente membro do grupo chamado group_name:

    $ ipa hostgroup-remove-member-manager group_name --groups nested_group
    Host-group: group_name
    Member hosts: server.idm.example.com
    Member host-groups: project_admins
    Member of netgroups: group_name
    ---------------------------
    Number of members removed 1
    ---------------------------
Nota

Após remover um gerente membro de um grupo anfitrião, a atualização pode levar algum tempo para se espalhar a todos os clientes em seu ambiente de Gerenciamento de Identidade.

Etapas de verificação

  • Use o comando ipa group-show para verificar se o usuário host e o grupo host foram removidos como gerentes membros.

    $ ipa hostgroup-show group_name
    Host-group: group_name
    Member hosts: server.idm.example.com
    Member host-groups: project_admins

Recursos adicionais

  • Veja ipa hostgroup-remove-member-manager --help para mais detalhes.
  • Veja ipa hostgroup-show --help para mais detalhes.

Capítulo 31. Gerenciando grupos anfitriões usando a IDM Web UI

Este capítulo apresenta os grupos anfitriões no Gerenciamento de Identidade (IdM) e descreve as seguintes operações para gerenciar grupos anfitriões e seus membros na interface Web (Web UI):

  • Visualização dos grupos anfitriões e seus membros
  • Criação de grupos anfitriões
  • Eliminação de grupos anfitriões
  • Acréscimo de membros do grupo anfitrião
  • Remoção de membros do grupo anfitrião
  • Acréscimo de gerentes de membros do grupo anfitrião
  • Remoção dos gerentes dos membros do grupo anfitrião

31.1. Grupos anfitriões na IdM

Os grupos anfitriões da IdM podem ser usados para centralizar o controle sobre importantes tarefas de gerenciamento, particularmente o controle de acesso.

Definição de grupos anfitriões

Um grupo anfitrião é uma entidade que contém um conjunto de anfitriões IdM com regras comuns de controle de acesso e outras características. Por exemplo, é possível definir grupos anfitriões com base nos departamentos da empresa, locais físicos ou requisitos de controle de acesso.

Um grupo anfitrião na IdM pode incluir:

  • Servidores e clientes da IdM
  • Outros grupos anfitriões da IdM

Grupos anfitriões criados por padrão

Por padrão, o servidor IdM cria o grupo hospedeiro ipaservers para todos os hospedeiros do servidor IdM.

Membros diretos e indiretos do grupo

Os atributos do grupo na IdM aplicam-se tanto aos membros diretos como indiretos: quando o grupo anfitrião B é membro do grupo anfitrião A, todos os membros do grupo anfitrião B são considerados membros indiretos do grupo anfitrião A.

31.2. Visualização de grupos anfitriões na IDM Web UI

Esta seção descreve como visualizar grupos host IdM usando a interface Web (Web UI).

Pré-requisitos

Procedimento

  1. Clique em Identity → Groups, e selecione a aba Host Groups.

    • A página lista os grupos anfitriões existentes e suas descrições.
    • Você pode procurar por um grupo anfitrião específico.

    grupos hospedeiros de visualização idm

  2. Clique em um grupo da lista para exibir os anfitriões que pertencem a este grupo. Você pode limitar os resultados aos membros diretos ou indiretos.

    idm vendo os membros do grupo anfitrião

  3. Selecione a guia Host Groups para exibir os grupos anfitriões que pertencem a este grupo (grupos anfitriões aninhados). Você pode limitar os resultados aos membros diretos ou indiretos.

    idm vendo os membros do grupo anfitrião aninhados no grupo

31.3. Criação de grupos anfitriões na IDM Web UI

Esta seção descreve como criar grupos anfitriões IdM usando a interface Web (Web UI).

Pré-requisitos

Procedimento

  1. Clique em Identity → Groups, e selecione a aba Host Groups.
  2. Clique em Add. O diálogo Add host group aparece.
  3. Fornecer as informações sobre o grupo: nome (obrigatório) e descrição (opcional).
  4. Clique em Add para confirmar.

    idm criando grupos anfitriões

31.4. Eliminação de grupos anfitriões na IDM Web UI

Esta seção descreve como excluir grupos host IdM usando a interface Web (Web UI).

Pré-requisitos

Procedimento

  1. Clique em Identity → Groups e selecione a guia Host Groups.
  2. Selecione o grupo hospedeiro IdM para remover, e clique em Delete. Aparece um diálogo de confirmação.
  3. Clique em Delete para confirmar

    idm apagando grupos anfitriões

Nota

A remoção de um grupo anfitrião não exclui os membros do grupo da IdM.

31.5. Acréscimo de membros do grupo anfitrião na IDM Web UI

Esta seção descreve como adicionar membros do grupo anfitrião no IdM usando a interface web (Web UI).

Pré-requisitos

Procedimento

  1. Clique em Identity → Groups e selecione a guia Host Groups.
  2. Clique no nome do grupo ao qual você deseja adicionar membros.
  3. Clique na guia Hosts ou Host groups, dependendo do tipo de membros que você deseja adicionar. O diálogo correspondente aparece.
  4. Selecione os anfitriões ou grupos de anfitriões para adicionar, e clique no botão > seta para movê-los para a coluna Prospective.
  5. Clique em Add para confirmar.

    idm adicionando membros do grupo anfitrião

31.6. Remoção de membros do grupo anfitrião na IDM Web UI

Esta seção descreve como remover membros do grupo anfitrião no IdM usando a interface web (Web UI).

Pré-requisitos

Procedimento

  1. Clique em Identity → Groups e selecione a guia Host Groups.
  2. Clique no nome do grupo do qual você deseja remover membros.
  3. Clique na guia Hosts ou Host groups, dependendo do tipo de membros que você deseja remover.
  4. Selecione a caixa de seleção ao lado do membro que você deseja remover.
  5. Clique em Excluir. Aparece um diálogo de confirmação.

    idm removendo os membros do grupo anfitrião

  6. Clique em Excluir para confirmar. Os membros selecionados são excluídos.

31.7. Adicionando gerentes de grupo anfitriões da IdM usando a interface Web

Esta seção descreve como adicionar usuários ou grupos de usuários como gerentes de membros do grupo anfitrião no IdM usando a interface web (Web UI). Os gerentes de membros podem adicionar gerentes de membros do grupo anfitrião aos grupos anfitriões do IdM, mas não podem alterar os atributos de um grupo anfitrião.

Pré-requisitos

  • Privilégios de administrador para gerenciar o papel de IdM ou Administrador de usuários.
  • Você está logado na IDM Web UI. Para obter detalhes, consulte Acessando a IDM Web UI em um navegador da web.
  • Você deve ter o nome do grupo anfitrião que você está adicionando como gerentes membros e o nome do grupo anfitrião que você quer que eles gerenciem.

Procedimento

  1. Clique em Identity → Groups e selecione a guia Host Groups.

    hostgroups
  2. Clique no nome do grupo ao qual você deseja adicionar gerentes membros.
  3. Clique na guia gerentes membros User Groups ou Users, dependendo do tipo de gerentes membros que você deseja adicionar. O diálogo correspondente aparece.
  4. Clique em Add.

    group membermanagers
  5. Selecione os usuários ou grupos de usuários para adicionar, e clique no botão > seta para movê-los para a coluna Prospective.
  6. Clique em Add para confirmar.
Nota

Após adicionar um gerente membro a um grupo anfitrião, a atualização pode levar algum tempo para se espalhar a todos os clientes em seu ambiente de Gerenciamento de Identidade.

Etapas de verificação

  • No diálogo do Grupo hospedeiro, verifique se o grupo de usuários ou usuário foi adicionado à lista de grupos ou usuários de gerentes membros.

    membermanager added

31.8. Removendo os gerentes do grupo anfitrião da IdM usando a interface Web

Esta seção descreve como remover usuários ou grupos de usuários como gerentes de membros do grupo anfitrião no IdM usando a interface web (Web UI). Os gerentes de membros podem remover os gerentes de membros do grupo anfitrião do IdM, mas não podem alterar os atributos de um grupo anfitrião.

Pré-requisitos

  • Privilégios de administrador para gerenciar o papel de IdM ou Administrador de usuários.
  • Você está logado na IDM Web UI. Para obter detalhes, consulte Acessando a IDM Web UI em um navegador da web.
  • Você deve ter o nome do grupo anfitrião existente que você está removendo e o nome do grupo anfitrião que eles estão gerenciando.

Procedimento

  1. Clique em Identity → Groups e selecione a guia Host Groups.

    hostgroup tab
  2. Clique no nome do grupo do qual você deseja remover os gerentes membros.
  3. Clique na guia gerentes membros User Groups ou Users, dependendo do tipo de gerentes membros que você deseja remover. O diálogo correspondente aparece.
  4. Selecione o usuário ou grupos de usuários a remover e clique em Delete.
  5. Clique em Delete para confirmar.

    idm removing host group member managers
    Nota

    Após remover um gerente membro de um grupo anfitrião, a atualização pode levar algum tempo para se espalhar a todos os clientes em seu ambiente de Gerenciamento de Identidade.

Etapas de verificação

  • No diálogo do Grupo hospedeiro, verifique se o grupo de usuários ou usuário foi removido da lista de membros gerentes de grupos ou usuários.

    remove membermanager verification

Capítulo 32. Gerenciamento de grupos anfitriões utilizando Livros didáticos Ansíveis

Este capítulo descreve o uso do Ansible para realizar as seguintes operações envolvendo grupos anfitriões em Gerenciamento de Identidade (IdM):

32.1. Garantindo a presença de grupos anfitriões da IdM usando Livros de Brincadeiras Ansíveis

Esta seção descreve como garantir a presença de grupos anfitriões no Gerenciamento de Identidade (IdM) usando Livros de Brincadeiras Ansíveis.

Nota

Sem Ansible, as entradas do grupo anfitrião são criadas no IdM usando o comando ipa hostgroup-add. O resultado de adicionar um grupo hospedeiro ao IdM é o estado do grupo hospedeiro que está presente no IdM. Devido à possível dependência do Idempotence, para adicionar um grupo hospedeiro ao IdM usando o Ansible, você deve criar um playbook no qual você define o estado do grupo hospedeiro como presente: state: present.

Pré-requisitos

  • Você sabe a senha do administrador da IdM.
  • Você instalou o pacote ansible-freeipa no controlador Ansible.

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaserver nele com a lista de servidores IdM a serem alvo:

    [ipaserver]
    server.idm.example.com
  2. Criar um arquivo de livro de jogo com as informações necessárias do grupo anfitrião. Por exemplo, para garantir a presença de um grupo anfitrião chamado databases, especifique name: databases na tarefa - ipahostgroup. Para simplificar esta etapa, você pode copiar e modificar o exemplo no arquivo /usr/share/doc/ansible-freeipa/playbooks/user/ensure-hostgroup-is-present.yml.

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure host-group databases is present
      - ipahostgroup:
          ipaadmin_password: MySecret123
          name: databases
          state: present

    No playbook, state: present significa um pedido para adicionar o grupo anfitrião à IdM, a menos que ele já exista lá.

  3. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hostgroup-is-present.yml

Etapas de verificação

  1. Acesse ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Solicite um bilhete Kerberos para administração:

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. Mostrar informações sobre o grupo anfitrião cuja presença na IdM você queria garantir:

    $ ipa hostgroup-show databases
      Host-group: databases

O grupo anfitrião databases existe na IdM.

32.2. Assegurar a presença de anfitriões em grupos anfitriões da IdM usando Livros de Brincadeiras Ansíveis

Esta seção descreve como garantir a presença de anfitriões em grupos anfitriões no Gerenciamento de Identidade (IdM) usando Livros de Brincadeiras Ansíveis.

Pré-requisitos

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaserver nele com a lista de servidores IdM a serem alvo:

    [ipaserver]
    server.idm.example.com
  2. Crie um arquivo de playbook possível com as informações necessárias do anfitrião. Especificar o nome do grupo hospedeiro usando o parâmetro name da variável ipahostgroup. Especificar o nome do anfitrião com o parâmetro host da variável ipahostgroup. Para simplificar esta etapa, você pode copiar e modificar os exemplos no arquivo /usr/share/doc/ansible-freeipa/playbooks/hostgroup/ensure-hosts-and-hostgroups-are-present-in-hostgroup.yml:

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure host-group databases is present
      - ipahostgroup:
          ipaadmin_password: MySecret123
          name: databases
          host:
          - db.idm.example.com
          action: member

    Este playbook acrescenta o anfitrião db.idm.example.com ao grupo anfitrião databases. A linha action: member indica que quando o playbook é executado, nenhuma tentativa é feita para adicionar o próprio grupo databases. Em vez disso, apenas é feita uma tentativa de adicionar db.idm.example.com a databases.

  3. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-or-hostgroups-are-present-in-hostgroup.yml

Etapas de verificação

  1. Acesse ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Solicite um bilhete Kerberos para administração:

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. Mostrar informações sobre um grupo anfitrião para ver quais anfitriões estão presentes no mesmo:

    $ ipa hostgroup-show databases
      Host-group: databases
      Member hosts: db.idm.example.com

O anfitrião db.idm.example.com está presente como um membro do grupo anfitrião databases.

32.3. Aninhamento de grupos hospedeiros IdM usando Livros de Brinquedos Ansíveis

Esta seção descreve como garantir a presença de grupos anfitriões aninhados em grupos anfitriões de Gerenciamento de Identidade (IdM) usando Livros de Brincadeiras Ansíveis.

Pré-requisitos

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaserver nele com a lista de servidores IdM a serem alvo:

    [ipaserver]
    server.idm.example.com
  2. Criar um arquivo de livro de jogo com as informações necessárias do grupo anfitrião. Para garantir que um grupo anfitrião aninhado A exista em um grupo anfitrião B: no Livro de jogo possível, especifique, entre as variáveis - ipahostgroup, o nome do grupo anfitrião B usando a variável name. Especificar o nome do grupo anfitrião aninhado A com a variável hostgroup. Para simplificar esta etapa, você pode copiar e modificar os exemplos no arquivo /usr/share/doc/ansible-freeipa/playbooks/hostgroup/ensure-hosts-and-hostgroups-are-present-in-hostgroup.yml:

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure hosts and hostgroups are present in existing databases hostgroup
      - ipahostgroup:
          ipaadmin_password: MySecret123
          name: databases
          hostgroup:
          - mysql-server
          - oracle-server
          action: member

    Este caderno de exercícios possível garante a presença dos grupos anfitriões myqsl-server e oracle-server no grupo anfitrião databases. A linha action: member indica que quando o playbook é executado, nenhuma tentativa é feita para adicionar o próprio grupo databases à IdM.

  3. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-or-hostgroups-are-present-in-hostgroup.yml

Etapas de verificação

  1. Acesse ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Solicite um bilhete Kerberos para administração:

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. Mostrar informações sobre o grupo anfitrião no qual os grupos anfitriões aninhados estão presentes:

    $ ipa hostgroup-show databases
      Host-group: databases
      Member hosts: db.idm.example.com
      Member host-groups: mysql-server, oracle-server

Os grupos anfitriões mysql-server e oracle-server existem no grupo anfitrião databases.

32.4. Assegurar a presença de gerentes membros em grupos anfitriões IDM usando Livros de Brincadeiras Ansíveis

O procedimento a seguir descreve como garantir a presença de gerentes membros nos anfitriões e grupos anfitriões da IdM usando um livro de jogo possível.

Pré-requisitos

  • Você sabe a senha do administrador da IdM.
  • Você instalou o pacote ansible-freeipa no controlador Ansible.
  • Você deve ter o nome do grupo anfitrião ou do grupo anfitrião que você está adicionando como gerentes membros e o nome do grupo anfitrião que você quer que eles gerenciem.

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaserver no mesmo:

    [ipaserver]
    server.idm.example.com
  2. Criar um arquivo de livro de jogo possível com as informações necessárias de gerenciamento do anfitrião e dos membros do grupo anfitrião:

    ---
    
    - name: Playbook to handle host group membership management
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure member manager user example_member is present for group_name
          ipahostgroup:
            ipaadmin_password: MySecret123
            name: group_name
            membermanager_user: example_member
    
      - name: Ensure member manager group project_admins is present for group_name
          ipahostgroup:
            ipaadmin_password: MySecret123
            name: group_name
            membermanager_group: project_admins
  3. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/add-member-managers-host-groups.yml

Etapas de verificação

Você pode verificar se o grupo group_name contém example_member e project_admins como gerentes membros, usando o comando ipa group-show:

  1. Acesse ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Mostrar informações sobre testhostgroup:

    ipaserver]$ ipa hostgroup-show group_name
      Host-group: group_name
      Member hosts: server.idm.example.com
      Member host-groups: testhostgroup2
      Membership managed by groups: project_admins
      Membership managed by users: example_member

Recursos adicionais

  • Ver ipa hostgroup-add-member-manager --help.
  • Veja a página de manual ipa.

32.5. Garantir a ausência de anfitriões de grupos anfitriões da IdM usando Livros de Brincadeiras Ansíveis

Esta seção descreve como garantir a ausência de anfitriões de grupos anfitriões no Gerenciamento de Identidade (IdM) usando Livros de Brincadeiras Ansíveis.

Pré-requisitos

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaserver nele com a lista de servidores IdM a serem alvo:

    [ipaserver]
    server.idm.example.com
  2. Criar um arquivo de livro de jogo com as informações necessárias sobre o anfitrião e o grupo anfitrião. Especificar o nome do grupo de anfitrião usando o parâmetro name da variável ipahostgroup. Especificar o nome do anfitrião cuja ausência do grupo anfitrião você deseja garantir usando o parâmetro host da variável ipahostgroup. Para simplificar esta etapa, você pode copiar e modificar os exemplos no arquivo /usr/share/doc/ansible-freeipa/playbooks/hostgroup/ensure-hosts-and-hostgroups-are-absent-in-hostgroup.yml:

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure host-group databases is absent
      - ipahostgroup:
          ipaadmin_password: MySecret123
          name: databases
          host:
          - db.idm.example.com
          action: member
          state: absent

    Este playbook garante a ausência do anfitrião db.idm.example.com do grupo anfitrião databases. A linha action: member indica que quando o playbook é executado, nenhuma tentativa é feita para remover o grupo databases em si.

  3. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-or-hostgroups-are-absent-in-hostgroup.yml

Etapas de verificação

  1. Acesse ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Solicite um bilhete Kerberos para administração:

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. Mostrar informações sobre o grupo anfitrião e os anfitriões que ele contém:

    $ ipa hostgroup-show databases
      Host-group: databases
      Member host-groups: mysql-server, oracle-server

O grupo anfitrião db.idm.example.com não existe no grupo anfitrião databases.

32.6. Assegurar a ausência de grupos anfitriões aninhados de grupos anfitriões da IdM usando Livros de Brincadeiras Ansíveis

Esta seção descreve como garantir a ausência de grupos anfitriões aninhados de grupos anfitriões externos em Gerenciamento de Identidade (IdM) usando Livros de Brincadeiras Ansíveis.

Pré-requisitos

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaserver nele com a lista de servidores IdM a serem alvo:

    [ipaserver]
    server.idm.example.com
  2. Criar um arquivo de livro de jogo com as informações necessárias do grupo anfitrião. Especifique, entre as variáveis - ipahostgroup, o nome do grupo hospedeiro externo usando a variável name. Especifique o nome do grupo de anfitrião aninhado com a variável hostgroup. Para simplificar esta etapa, você pode copiar e modificar os exemplos no arquivo /usr/share/doc/ansible-freeipa/playbooks/hostgroup/ensure-hosts-and-hostgroups-are-absent-in-hostgroup.yml:

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure hosts and hostgroups are absent in existing databases hostgroup
      - ipahostgroup:
          ipaadmin_password: MySecret123
          name: databases
          hostgroup:
          - mysql-server
          - oracle-server
          action: member
          state: absent

    Este playbook garante que os grupos anfitriões mysql-server e oracle-server estejam ausentes do grupo anfitrião databases. A linha action: member indica que quando o playbook é executado, nenhuma tentativa é feita para garantir que o próprio grupo databases seja excluído do IdM.

  3. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hosts-or-hostgroups-are-absent-in-hostgroup.yml

Etapas de verificação

  1. Acesse ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Solicite um bilhete Kerberos para administração:

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. Mostrar informações sobre o grupo anfitrião do qual os grupos anfitriões aninhados devem estar ausentes:

    $ ipa hostgroup-show databases
      Host-group: databases

A saída confirma que os grupos anfitriões mysql-server e oracle-server estão ausentes do grupo anfitrião databases externo.

32.7. Assegurando a ausência de grupos anfitriões da IdM usando Livros de Brincadeiras Ansíveis

Esta seção descreve como garantir a ausência de grupos anfitriões no Gerenciamento de Identidade (IdM) usando Livros de Brincadeiras Ansíveis.

Nota

Sem Ansible, as entradas do grupo anfitrião são removidas do IdM usando o comando ipa hostgroup-del. O resultado da remoção de um grupo hospedeiro do IdM é o estado do grupo hospedeiro estando ausente do IdM. Devido à possível dependência da idempotência, para remover um grupo hospedeiro do IdM usando o Ansible, você deve criar um playbook no qual você define o estado do grupo hospedeiro como ausente: state: absent.

Pré-requisitos

  • Você sabe a senha do administrador da IdM.
  • Você instalou o pacote ansible-freeipa no controlador Ansible.

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaserver nele com a lista de servidores IdM a serem alvo:

    [ipaserver]
    server.idm.example.com
  2. Criar um arquivo de livro de jogo com as informações necessárias do grupo anfitrião. Para simplificar esta etapa, você pode copiar e modificar o exemplo no arquivo /usr/share/doc/ansible-freeipa/playbooks/user/ensure-hostgroup-is-absent.yml.

    ---
    - name: Playbook to handle hostgroups
      hosts: ipaserver
      become: true
    
      tasks:
      - Ensure host-group databases is absent
        ipahostgroup:
          ipaadmin_password: MySecret123
          name: databases
          state: absent

    Este playbook garante a ausência do grupo anfitrião databases da IdM. O state: absent significa uma solicitação para excluir o grupo anfitrião da IdM, a menos que já tenha sido excluído.

  3. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-hostgroup-is-absent.yml

Etapas de verificação

  1. Acesse ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Solicite um bilhete Kerberos para administração:

    $ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  3. Mostrar informações sobre o grupo anfitrião cuja ausência você garantiu:

    $ ipa hostgroup-show databases
    ipa: ERROR: databases: host group not found

O grupo anfitrião databases não existe na IdM.

32.8. Assegurar a ausência dos gerentes membros dos grupos anfitriões da IdM usando Livros de Brincadeiras Ansíveis

O procedimento a seguir descreve como garantir a ausência dos gerentes membros nos anfitriões e grupos anfitriões da IdM usando um livro de jogo possível.

Pré-requisitos

  • Você sabe a senha do administrador da IdM.
  • Você instalou o pacote ansible-freeipa no controlador Ansible.
  • Você deve ter o nome do usuário ou grupo de usuários que você está removendo como gerentes membros e o nome do grupo anfitrião que eles estão gerenciando.

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaserver no mesmo:

    [ipaserver]
    server.idm.example.com
  2. Criar um arquivo de livro de jogo possível com as informações necessárias de gerenciamento do anfitrião e dos membros do grupo anfitrião:

    ---
    
    - name: Playbook to handle host group membership management
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure member manager host and host group members are absent for group_name
        ipahostgroup:
          ipaadmin_password: MySecret123
          name: group_name
          membermanager_user: example_member
          membermanager_group: project_admins
          action: member
          state: absent
  3. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-member-managers-host-groups-are-absent.yml

Etapas de verificação

Você pode verificar se o grupo group_name não contém example_member ou project_admins como gerentes membros, usando o comando ipa group-show:

  1. Acesse ipaserver como administrador:

    $ ssh admin@server.idm.example.com
    Password:
    [admin@server /]$
  2. Mostrar informações sobre testhostgroup:

    ipaserver]$ ipa hostgroup-show group_name
      Host-group: group_name
      Member hosts: server.idm.example.com
      Member host-groups: testhostgroup2

Recursos adicionais

  • Ver ipa hostgroup-add-member-manager --help.
  • Veja a página de manual ipa.

Capítulo 33. Gerenciando as políticas de ingressos da Kerberos

As políticas de bilhetes Kerberos em Gerenciamento de Identidade (IdM) estabelecem restrições ao acesso, duração e renovação dos bilhetes Kerberos. Você pode configurar as políticas de bilhetes Kerberos para o Key Distribution Center (KDC) rodando no seu servidor IdM.

Este capítulo apresenta os seguintes tópicos e tarefas de gerenciamento de bilhetes Kerberos:

33.1. O papel da IdM KDC

Os mecanismos de autenticação da Gerência de Identidade utilizam a infra-estrutura Kerberos estabelecida pelo Key Distribution Center (KDC). O KDC é a autoridade confiável que armazena informações de credenciais e garante a autenticidade dos dados provenientes de entidades dentro da rede IdM.

Cada usuário, serviço e host da IdM atua como um cliente Kerberos e é identificado por um único Kerberos principal:

  • Para usuários: identifier@REALM, tais como admin@EXAMPLE.COM
  • Para serviços: service/fully-qualified-hostname@REALM, tais como http/master.example.com@EXAMPLE.COM
  • Para anfitriões: host/fully-qualified-hostname@REALM, tais como host/client.example.com@EXAMPLE.COM

A seguinte imagem é uma simplificação da comunicação entre um cliente Kerberos, o KDC, e uma aplicação Kerberizada com a qual o cliente deseja se comunicar.

Kerberos KDC flow of communication
  1. Um cliente Kerberos se identifica com o KDC autenticando-se como um diretor Kerberos. Por exemplo, um usuário da IdM realiza kinit username e fornece sua senha.
  2. O KDC verifica o principal em seu banco de dados, autentica o cliente e avalia as políticas de ingressos da Kerberos para determinar se o pedido deve ser atendido.
  3. O KDC emite ao cliente um ticket de concessão de bilhetes (TGT) com um ciclo de vida e indicadores de autenticação de acordo com a política de bilhetes apropriada.
  4. Com o TGT, o cliente solicita um service ticket do KDC para se comunicar com um serviço Kerberized em um host alvo.
  5. O KDC verifica se o TGT do cliente ainda é válido, e avalia a solicitação de bilhetes de serviço em relação às políticas de bilhetes.
  6. O KDC emite ao cliente um service ticket.
  7. Com o bilhete de serviço, o cliente pode iniciar uma comunicação criptografada com o serviço no host alvo.

33.2. Tipos de política de bilhetes da IdM Kerberos

As políticas de bilhetes da IdM Kerberos implementam os seguintes tipos de políticas de bilhetes:

Política de conexão

Para proteger os serviços Kerberized com diferentes níveis de segurança, é possível definir políticas de conexão para aplicar regras baseadas em qual mecanismo de pré-autenticação um cliente usou para recuperar um bilhete de passagem (TGT).

Por exemplo, você pode requerer autenticação de cartão inteligente para se conectar a client1.example.com, e requerer autenticação de dois fatores para acessar o aplicativo testservice em client2.example.com.

Para impor políticas de conexão, associar authentication indicators aos serviços. Somente clientes que possuem os indicadores de autenticação necessários em suas solicitações de tíquetes de serviço podem ter acesso a esses serviços. Para mais informações, consulte os indicadores de autenticação Kerberos.

Política de ciclo de vida dos bilhetes

Cada bilhete Kerberos tem um lifetime e um potencial renewal age: você pode renovar um bilhete antes que ele atinja sua vida útil máxima, mas não depois que ele exceda sua idade máxima de renovação.

A duração padrão do bilhete global é de um dia (86400 segundos) e a idade máxima de renovação padrão global é de uma semana (604800 segundos). Para ajustar estes valores globais, consulte Configurando a política global do ciclo de vida do bilhete.

Você também pode definir suas próprias políticas de ciclo de vida de bilhetes:

33.3. Indicadores de autenticação Kerberos

O Kerberos Key Distribution Center (KDC) anexa authentication indicators a um ticket de concessão de bilhetes (TGT) com base no qual o mecanismo de pré-autenticação utilizado pelo cliente comprova sua identidade:

otp
autenticação de dois fatores (senha One-Time Password)
radius
Autenticação RADIUS (comumente para autenticação 802.1x)
pkinit
PKINIT, cartão inteligente, ou autenticação de certificado
hardened
senhas endurecidas (SPAKE ou FAST)[1]

O KDC então anexa os indicadores de autenticação do TGT a qualquer pedido de tíquetes de serviço que dele resulte. O KDC aplica políticas tais como controle de acesso a serviços, duração máxima do bilhete e idade máxima renovável com base nos indicadores de autenticação.

33.3.1. Indicadores de autenticação e serviços IdM

Se você associar um serviço ou um host com um indicador de autenticação, somente os clientes que utilizaram o mecanismo de autenticação correspondente para obter um TGT poderão acessá-lo. O KDC, não o aplicativo ou serviço, verifica os indicadores de autenticação nos pedidos de bilhetes de serviço, e concede ou nega pedidos com base nas políticas de conexão Kerberos.

Por exemplo, para exigir autenticação de dois fatores para conectar ao host secure.example.com, associar o indicador de autenticação otp ao principal host/secure.example.com@EXAMPLE.COM Kerberos. Somente usuários que utilizaram uma senha One-Time para obter seu TGT inicial do KDC poderão fazer o login.

Se um serviço ou um host não tiver indicadores de autenticação atribuídos a ele, ele aceitará bilhetes autenticados por qualquer mecanismo.

Recursos adicionais



[1] Uma senha endurecida é protegida contra ataques de dicionário de senhas de força bruta utilizando a Troca de Chaves Autenticadas por Chaves Públicas (SPAKE) pré-autenticação e/ou Autenticação Flexível via Túnel Seguro (FAST) blindagem.

33.4. Aplicação de indicadores de autenticação para um serviço IdM

Este procedimento descreve a criação de um serviço IdM e sua configuração para exigir determinados indicadores de autenticação Kerberos a partir de solicitações de tickets de serviço recebidos.

Ao associar indicadores de autenticação com um serviço IdM, somente clientes que utilizaram esses mecanismos específicos de pré-autenticação para obter seu bilhete inicial de passagem (TGT) poderão ter acesso ao serviço.

33.4.1. Criação de uma entrada de serviço IdM e seu keytab Kerberos

Adicionar uma entrada IdM service ao IdM para um serviço executado em um host IdM cria um Kerberos principal correspondente, e permite que o serviço solicite um certificado SSL, um Kerberos keytab, ou ambos.

O procedimento a seguir descreve a criação de uma entrada de serviço IdM e a geração de um keytab Kerberos associado para criptografar a comunicação com esse serviço.

Pré-requisitos

  • Seu serviço pode armazenar um Kerberos principal, um certificado SSL, ou ambos.

Procedimento

  1. Adicione um serviço IdM com o comando ipa service-add para criar um Kerberos principal associado a ele. Por exemplo, para criar a entrada do serviço IdM para a aplicação testservice que roda no host client.example.com:

    [root@client ~]# ipa service-add testservice/client.example.com
    -------------------------------------------------------------
    Modified service "testservice/client.example.com@EXAMPLE.COM"
    -------------------------------------------------------------
      Principal name: testservice/client.example.com@EXAMPLE.COM
      Principal alias: testservice/client.example.com@EXAMPLE.COM
      Managed by: client.example.com
  2. Gerar e armazenar um keytab Kerberos para o serviço no cliente.

    [root@client ~]# ipa-getkeytab -k /etc/testservice.keytab -p testservice/client.example.com
    Keytab successfully retrieved and stored in: /etc/testservice.keytab

Etapas de verificação

  1. Exibir informações sobre um serviço IdM com o comando ipa service-show.

    [root@server ~]# ipa service-show testservice/client.example.com
      Principal name: testservice/client.example.com@EXAMPLE.COM
      Principal alias: testservice/client.example.com@EXAMPLE.COM
      Keytab: True
      Managed by: client.example.com
  2. Exibir o conteúdo do keytab do serviço Kerberos com o comando klist.

    [root@server etc]# klist -ekt /etc/testservice.keytab
    Keytab name: FILE:/etc/testservice.keytab
    KVNO Timestamp           Principal
    ---- ------------------- ------------------------------------------------------
       2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (aes256-cts-hmac-sha1-96)
       2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (aes128-cts-hmac-sha1-96)
       2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (camellia128-cts-cmac)
       2 04/01/2020 17:52:55 testservice/client.example.com@EXAMPLE.COM (camellia256-cts-cmac)

33.4.2. Associando indicadores de autenticação com um serviço IdM

Este procedimento descreve a configuração de um serviço para exigir determinados indicadores de autenticação Kerberos a partir de solicitações de tickets de serviço recebidos.

Pré-requisitos

Atenção

Faça not atribuir indicadores de autenticação aos serviços internos da IdM. Os seguintes serviços de IdM não podem executar os passos de autenticação interativa exigidos pelo PKINIT e métodos de autenticação multi-fator:

host/server.example.com@EXAMPLE.COM
HTTP/server.example.com@EXAMPLE.COM
ldap/server.example.com@EXAMPLE.COM
DNS/server.example.com@EXAMPLE.COM
cifs/server.example.com@EXAMPLE.COM

Procedimento

  • Use o comando ipa service-mod para especificar um ou mais indicadores de autenticação necessários para um serviço, identificados com o argumento --auth-ind.

    Método de autenticação--auth-ind valor

    Autenticação de dois fatores

    otp

    Autenticação RADIUS

    radius

    PKINIT, cartão inteligente, ou autenticação de certificado

    pkinit

    Senhas temperadas (SPAKE ou FAST)

    hardened

    Por exemplo, para exigir que um usuário seja autenticado com cartão inteligente ou autenticação OTP para recuperar um tíquete de serviço para o principal testservice no host client.example.com:

    [root@server ~]# ipa service-mod testservice/client.example.com@EXAMPLE.COM --auth-ind otp --auth-ind pkinit
    -------------------------------------------------------------
    Modified service "testservice/client.example.com@EXAMPLE.COM"
    -------------------------------------------------------------
      Principal name: testservice/client.example.com@EXAMPLE.COM
      Principal alias: testservice/client.example.com@EXAMPLE.COM
      Authentication Indicators: otp, pkinit
      Managed by: client.example.com
Nota

Para remover todos os indicadores de autenticação de um serviço, forneça uma lista vazia de indicadores:

[root@server ~]# ipa service-mod testservice/client.example.com@EXAMPLE.COM --auth-ind ''
------------------------------------------------------
Modified service "testservice/client.example.com@EXAMPLE.COM"
------------------------------------------------------
  Principal name: testservice/client.example.com@EXAMPLE.COM
  Principal alias: testservice/client.example.com@EXAMPLE.COM
  Managed by: client.example.com

Etapas de verificação

  • Mostrar informações sobre um serviço IdM, incluindo os indicadores de autenticação necessários, com o comando ipa service-show.

    [root@server ~]# ipa service-show testservice/client.example.com
      Principal name: testservice/client.example.com@EXAMPLE.COM
      Principal alias: testservice/client.example.com@EXAMPLE.COM
      Authentication Indicators: otp, pkinit
      Keytab: True
      Managed by: client.example.com

Recursos adicionais

33.4.3. Obtenção de um bilhete de serviço Kerberos para um serviço IdM

O procedimento a seguir descreve a recuperação de um bilhete de serviço Kerberos para um serviço IdM. Você pode usar este procedimento para testar as políticas de bilhetes Kerberos.

Pré-requisitos

Procedimento

  • Use o comando kvno com a opção -S para recuperar um ticket de serviço e especifique o nome do serviço IdM e o nome de domínio totalmente qualificado do host que o administra.

    [root@server ~]# kvno -S testservice client.example.com
    testservice/client.example.com@EXAMPLE.COM: kvno = 1
Nota

Se você precisar acessar um serviço IdM e seu ticket de concessão de bilhetes (TGT) atual não possuir os indicadores de autenticação necessários associados a ele, limpe seu cache de credenciais Kerberos atual com o comando kdestroy e recupere um novo TGT:

[root@server ~]# kdestroy

Por exemplo, se você inicialmente recuperou um TGT autenticando com uma senha, e precisa acessar um serviço IdM que tenha o indicador de autenticação pkinit associado a ele, destruir seu cache de credenciais atual e re-autenticar com um cartão inteligente. Veja os indicadores de autenticação Kerberos.

Etapas de verificação

  • Use o comando klist para verificar se o ticket de serviço está no cache de credenciais padrão da Kerberos.

    [root@server etc]# klist_
    Ticket cache: KCM:1000
    Default principal: admin@EXAMPLE.COM
    
    Valid starting       Expires              Service principal
    04/01/2020 12:52:42  04/02/2020 12:52:39  krbtgt/EXAMPLE.COM@EXAMPLE.COM
    04/01/2020 12:54:07 04/02/2020 12:52:39 testservice/client.example.com@EXAMPLE.COM

33.4.4. Recursos adicionais

33.5. Configurando a política global do ciclo de vida dos bilhetes

A política global de bilhetes se aplica a todos os bilhetes de serviço e aos usuários que não têm nenhuma política de bilhetes por usuário definida.

O procedimento a seguir descreve o ajuste da duração máxima do bilhete e da idade máxima de renovação do bilhete para a política global de bilhetes da Kerberos usando o comando ipa krbtpolicy-mod.

Ao utilizar o comando ipa krbtpolicy-mod, especifique pelo menos um dos seguintes argumentos:

  • --maxlife para a vida útil máxima do bilhete em segundos
  • --maxrenew para a idade máxima renovável em segundos

Procedimento

  1. Modificar a política global de bilhetes:

    [root@server ~]# ipa krbtpolicy-mod --maxlife=$((8*60*60)) --maxrenew=$((24*60*60))
      Max life: 28800
      Max renew: 86400

    In this example, the maximum lifetime is set to eight hours (8 * 60 minutes * 60 seconds) and the maximum renewal age is set to one day (24 * 60 minutes * 60 seconds).

  2. Opcional: Para redefinir a política global de ingressos Kerberos para os valores padrão de instalação:

    [root@server ~]# ipa krbtpolicy-reset
      Max life: 86400
      Max renew: 604800

Etapas de verificação

  • Exibir a política global de bilhetes:

    [root@server ~]# ipa krbtpolicy-show
      Max life: 28800
      Max renew: 86640

Recursos adicionais

33.6. Configuração de políticas de bilhetes globais por indicador de autenticação

Este procedimento descreve o ajuste da duração máxima global do bilhete e da idade máxima renovável para cada indicador de autenticação. Estas configurações se aplicam aos usuários que não têm políticas de bilhetes por usuário definidas.

Use o comando ipa krbtpolicy-mod para especificar a duração máxima global ou a idade máxima renovável para os bilhetes Kerberos, dependendo dos indicadores de autenticação anexados a eles.

Procedimento

  • Por exemplo, para definir os valores globais de dois fatores de duração e idade de renovação do bilhete para uma semana, e os valores globais de duração e idade de renovação do bilhete de cartão inteligente para duas semanas:

    [root@server ~]# ipa krbtpolicy-mod --otp-maxlife=604800 --otp-maxrenew=604800 --pkinit-maxlife=172800 --pkinit-maxrenew=172800

Etapas de verificação

  • Exibir a política global de bilhetes:

    [root@server ~]# ipa krbtpolicy-show
      Max life: 86400
      OTP max life: 604800
      PKINIT max life: 172800
      Max renew: 604800
      OTP max renew: 604800
      PKINIT max renew: 172800

    Observe que os valores OTP e PKINIT são diferentes dos valores padrão globais Max life e Max renew.

Recursos adicionais

33.7. Configurando a política padrão de bilhetes para um usuário

Você pode definir uma política única de bilhetes Kerberos que se aplica somente a um único usuário. Estas configurações por usuário substituem a política global de bilhetes, para todos os indicadores de autenticação.

Use o ipa krbtpolicy-mod username e especificar pelo menos um dos seguintes argumentos:

  • --maxlife para a vida útil máxima do bilhete em segundos
  • --maxrenew para a idade máxima renovável em segundos

Procedimento

  1. Por exemplo, para definir a vida útil máxima do bilhete do usuário do IdM admin para dois dias e a idade máxima de renovação para duas semanas:

    [root@server ~]# ipa krbtpolicy-mod admin --maxlife=172800 --maxrenew=1209600
      Max life: 172800
      Max renew: 1209600
  2. Opcional: Para redefinir a política de ingressos para um usuário:

    [root@server ~]# ipa krbtpolicy-reset admin

Etapas de verificação

  • Exibir a política eficaz de bilhetes Kerberos que se aplica a um usuário:

    [root@server ~]# ipa krbtpolicy-show admin
      Max life: 172800
      Max renew: 1209600

Recursos adicionais

33.8. Configuração de políticas de bilhetes indicadores de autenticação individuais para um usuário

Como administrador, você pode definir políticas de bilhetes Kerberos para um usuário que diferem por indicador de autenticação. Por exemplo, você pode configurar uma política para permitir ao usuário do IdM admin renovar um bilhete por dois dias se ele foi obtido com autenticação OTP, e por uma semana se foi obtido com autenticação por cartão inteligente.

Estas configurações de indicadores de autenticação por autenticação anularão a política de bilhetes padrão user’s, a política de bilhetes padrão global, e qualquer política de bilhetes indicadores de autenticação global.

Use o ipa krbtpolicy-mod username para definir valores máximos personalizados de vida útil e de idade máxima renovável para os bilhetes Kerberos de um usuário, dependendo dos indicadores de autenticação anexados a eles.

Procedimento

  1. Por exemplo, para permitir ao usuário do IdM admin renovar um bilhete Kerberos por dois dias se ele foi obtido com autenticação One-Time Password, defina a opção --otp-maxrenew:

    [root@server ~]# ipa krbtpolicy-mod admin --otp-maxrenew=$((2*24*60*60))
      OTP max renew: 172800
  2. Opcional: Para redefinir a política de ingressos para um usuário:

    [root@server ~]# ipa krbtpolicy-reset username

Etapas de verificação

  • Exibir a política eficaz de bilhetes Kerberos que se aplica a um usuário:

    [root@server ~]# ipa krbtpolicy-show admin
      Max life: 28800
      Max renew: 86640

Recursos adicionais

33.9. Opções de indicadores de autenticação para o comando krbtpolicy-mod

Especificar valores para os indicadores de autenticação com os seguintes argumentos.

Tabela 33.1. Opções de indicadores de autenticação para o comando krbtpolicy-mod

Indicador de autenticaçãoArgumento para uma vida útil máximaArgumento para a idade máxima de renovação

otp

--otp-maxlife

--otp-maxrenew

radius

--radius-maxlife

--radius-maxrenew

pkinit

--pkinit-maxlife

--pkinit-maxrenew

hardened

--hardened-maxlife

--hardened-maxrenew

Capítulo 34. Definindo as políticas de senhas da IdM

Este capítulo descreve as políticas de senha do Gerenciamento de Identidade (IdM) e como adicionar uma nova política de senha no IdM usando um livro de exercícios.

34.1. O que é uma política de senha

Uma política de senhas é um conjunto de regras que as senhas devem cumprir. Por exemplo, uma política de senha pode definir a duração mínima e a duração máxima da senha. Todos os usuários afetados por esta política são obrigados a definir uma senha suficientemente longa e alterá-la com freqüência suficiente para atender às condições especificadas. Desta forma, as políticas de senhas ajudam a reduzir o risco de alguém descobrir e usar indevidamente a senha de um usuário.

34.2. Políticas de senhas na IdM

As senhas são a forma mais comum de autenticação dos usuários do Gerenciamento de Identidade (IdM) para o domínio IdM Kerberos. As políticas de senhas definem os requisitos que estas senhas de usuários IdM devem atender.

Nota

A política de senha da IdM é definida no diretório LDAP subjacente, mas o Kerberos Key Distribution Center (KDC) reforça a política de senha.

Os atributos da política de senha listam os atributos que você pode usar para definir uma política de senha na IdM.

Tabela 34.1. Atributos da política de senhas

AtributoExplicaçãoExemplo

Vida útil máxima

A quantidade máxima de tempo em dias que uma senha é válida antes de um usuário ter que redefini-la.

Vida útil máxima = 90

As senhas de usuário são válidas somente por 90 dias. Depois disso, a IdM solicita aos usuários que as alterem.

Vida útil mínima

A quantidade mínima de tempo em horas que deve passar entre duas operações de troca de senha.

Vida útil mínima = 1

Após os usuários trocarem suas senhas, eles devem esperar pelo menos 1 hora antes de mudá-las novamente.

Tamanho da história

O número de senhas anteriores que são armazenadas. Um usuário não pode reutilizar uma senha de seu histórico de senhas, mas pode reutilizar senhas antigas que não estão armazenadas.

Tamanho da história = 0

Neste caso, o histórico de senhas está vazio e os usuários podem reutilizar qualquer uma de suas senhas anteriores.

Classes de caracteres

O número de diferentes classes de caracteres que o usuário deve usar na senha. As classes de caracteres são:

* Caracteres em caixa alta

* Caracteres em letras minúsculas

* Dígitos

* Caracteres especiais, como vírgula (,), período (.), asterisco (*)

* Outros caracteres UTF-8

O uso de um personagem três ou mais vezes seguidas diminui a classe do personagem em uma. Por exemplo:

* Secret1 tem 3 classes de caracteres: maiúsculas, minúsculas, dígitos

* Secret111 tem 2 classes de caracteres: maiúsculas, minúsculas, dígitos e uma penalidade de -1 por usar 1 repetidamente

Classes de caracteres = 0

O número padrão de classes necessárias é 0. Para configurar o número, execute o comando ipa pwpolicy-mod com a opção --minclasses.

Veja também a nota Importante abaixo desta tabela.

Comprimento mínimo

O número mínimo de caracteres em uma senha.

Comprimento mínimo = 8

Os usuários não podem usar senhas com menos de 8 caracteres.

Máximo de falhas

O número máximo de tentativas de login falhadas antes de a IdM bloquear a conta do usuário.

Máximo de falhas = 6

IdM bloqueia a conta de usuário quando o usuário digita uma senha errada 7 vezes seguidas.

Intervalo de reinicialização de falhas

A quantidade de tempo em segundos após o qual o IdM redefine o número atual de tentativas de login falhadas.

Intervalo de reinicialização de falhas = 60

Se o usuário esperar mais de 1 minuto após o número de tentativas de login falhadas definido em Max failures, o usuário pode tentar fazer o login novamente sem arriscar um bloqueio de conta de usuário.

Duração do Lockout

A quantidade de tempo em segundos que a conta do usuário é bloqueada após o número de tentativas de login falhadas definido em Max failures.

Duração do Lockout = 600

Os usuários com contas bloqueadas não podem fazer login por 10 minutos.

Importante

Use o alfabeto inglês e símbolos comuns para os requisitos de classes de caracteres se você tiver um conjunto diversificado de hardware que pode não ter acesso a caracteres e símbolos internacionais. Para mais informações sobre as políticas de classes de caracteres em senhas, veja Quais caracteres são válidos em uma senha? na Red Hat Knowledgebase.

34.3. Assegurar a presença de uma política de senha na IdM usando um livro de exercícios possível

Esta seção descreve como garantir a presença de uma política de senha no Gerenciamento de Identidade (IdM) usando um Livro de Exercícios Anível.

Na política de senha padrão global_policy no IdM, o número de diferentes classes de caracteres na senha é definido como 0. O tamanho do histórico também é definido como 0.

Complete este procedimento para impor uma política de senha mais forte para um grupo IdM usando um Livro de Jogadas Ansivel.

Nota

Você só pode definir uma política de senha para um grupo IdM. Você não pode definir uma política de senhas para um usuário individual.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible.
  • Você sabe a senha do administrador da IdM.
  • O grupo para o qual você está garantindo a presença de uma política de senha existe na IdM.

Procedimento

  1. Crie um arquivo de inventário, por exemplo inventory.file, e defina o FQDN de seu servidor IdM na seção [ipaserver]:

    [ipaserver]
    server.idm.example.com
  2. Crie seu arquivo de Livro de Jogadas Ansíveis que define a política de senha cuja presença você deseja garantir. Para simplificar esta etapa, copie e modifique o exemplo no arquivo /usr/share/doc/ansible-freeipa/playbooks/pwpolicy/pwpolicy_present.yml:

    ---
    - name: Tests
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure presence of pwpolicy for group ops
        ipapwpolicy:
          ipaadmin_password: MySecret123
          name: ops
          minlife: 7
          maxlife: 49
          history: 5
          priority: 1
          lockouttime: 300
          minlength: 8
          minclasses: 4
          maxfail: 3
          failinterval: 5

    Para obter detalhes sobre o significado das variáveis individuais, consulte Atributos da política de senhas.

  3. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory_/new_pwpolicy_present.yml

Você utilizou com sucesso um Livro de Jogadas Anível para garantir que uma política de senha para o grupo ops esteja presente na IdM.

Importante

A prioridade da política de senhas ops está definida para 1, enquanto a política de senhas global_policy não tem prioridade definida. Por este motivo, a política ops substitui automaticamente global_policy para o grupo ops e é aplicada imediatamente.

global_policy serve como uma política de recurso quando nenhuma política de grupo é definida para um usuário, e nunca pode ter precedência sobre uma política de grupo.

Recursos adicionais

  • Para mais detalhes sobre o uso do Ansible to define políticas de senha no IdM e sobre variáveis de playbook, consulte o arquivo README-pwpolicy.md Markdown disponível no diretório /usr/share/doc/ansible-freeipa/.
  • Para mais detalhes sobre como as prioridades da política de senhas funcionam na IdM, consulte as prioridades da política de senhas na documentação RHEL 7.

Capítulo 35. Gerenciamento de notificações de senhas expirando

Você pode usar a ferramenta Notificação de senha expirando (EPN), fornecida pelo pacote ipa-client-epn, para construir uma lista de usuários de Gerenciamento de Identidade (IdM) cujas senhas estão expirando em um período de tempo configurado. Para instalar, configurar e usar a ferramenta EPN, consulte as seções pertinentes.

35.1. O que é a ferramenta de Notificação de Senha Vitalícia

A ferramenta Notificação de Senha de Expiração (EPN) é uma ferramenta autônoma que você pode usar para construir uma lista de usuários de Gerenciamento de Identidade (IdM) cujas senhas estão expirando em um período de tempo configurado.

Os administradores da IdM podem usar EPN para:

  • Exibir uma lista de usuários afetados no formato JSON, que é criada quando executada em modo de funcionamento a seco.
  • Calcule quantos e-mails serão enviados para um determinado dia ou intervalo de datas.
  • Enviar notificações de expiração de senha por e-mail aos usuários.
  • Configurar o ipa-epn.timer para executar a ferramenta EPN diariamente e enviar um e-mail aos usuários cujas senhas estão expirando dentro das faixas de datas futuras definidas.
  • Personalize a notificação por e-mail para enviar aos usuários.
Nota

Se uma conta de usuário for desativada, nenhuma notificação por e-mail será enviada se a senha expirar.

35.2. Instalando a ferramenta de notificação de senha expirada

Este procedimento descreve como instalar a ferramenta Notificação de Senha Vitalícia (EPN).

Pré-requisitos

  • Instale a ferramenta EPN em uma réplica de Gerenciamento de Identidade (IdM) ou em um cliente IdM com um servidor local Postfix SMTP configurado como um host inteligente.

Procedimento

  • Instalar a ferramenta EPN:

    # dnf instalar ipa-client-epn

35.3. Executar a ferramenta EPN para enviar e-mails aos usuários cujas senhas estão expirando

Este procedimento descreve como executar a ferramenta Notificação de Senha Vazio (EPN) para enviar e-mails aos usuários cujas senhas estão expirando.

Nota

A ferramenta EPN é sem Estado. Se a ferramenta EPN não enviar um e-mail a nenhum dos usuários cujas senhas estão expirando em um determinado dia, a ferramenta EPN não salva uma lista desses usuários.

Pré-requisitos

Procedimento

  1. Atualize o arquivo de configuração epn.conf para definir as opções da ferramenta EPN para notificar os usuários sobre a expiração da senha a ser enviada.

    # vi /etc/ipa/epn.conf
  2. Atualizar o notify_ttls conforme necessário. O padrão é notificar os usuários cujas senhas expiram em 28, 14, 7, 3, e 1 dia(s).

    notify_ttls = 28, 14, 7, 3, 1
  3. Configure seu servidor SMTP e porta:

    smtp_server = localhost
    smtp_port = 25
  4. Especifique o endereço de e-mail a partir do qual a notificação de expiração do e-mail é enviada. Quaisquer e-mails enviados sem sucesso são devolvidos a este endereço.

    mail_from =admin-email@example.com
  5. Salvar o arquivo /etc/ipa/epn.conf.
  6. Execute a ferramenta EPN no modo de funcionamento a seco para gerar uma lista dos usuários aos quais a notificação de expiração da senha seria enviada por e-mail se você executasse a ferramenta sem a opção --dry-run.

    ipa-epn --dry-run
    [
        {
         "uid": "user5",
         "cn": "user 5",
         "krbpasswordexpiration": "2020-04-17 15:51:53",
         "mail": "['user5@ipa.test']"
        }
    ]
    [
        {
         "uid": "user6",
         "cn": "user 6",
         "krbpasswordexpiration": "2020-12-17 15:51:53",
         "mail": "['user5@ipa.test']"
         }
    ]
    The IPA-EPN command was successful
    Nota

    Se a lista de usuários retornados for muito grande e você executar a ferramenta sem a opção --dry-run, isto pode causar um problema com seu servidor de e-mail.

  7. Execute a ferramenta EPN sem a opção --dry-run para enviar e-mails de expiração para a lista de todos os usuários retornados quando você executou a ferramenta EPN no modo de funcionamento a seco:

    ipa-epn
    [
      {
         "uid": "user5",
         "cn": "user 5",
         "krbpasswordexpiration": "2020-10-01 15:51:53",
         "mail": "['user5@ipa.test']"
      }
    ]
    [
      {
        "uid": "user6",
        "cn": "user 6",
        "krbpasswordexpiration": "2020-12-17 15:51:53",
        "mail": "['user5@ipa.test']"
      }
    ]
    The IPA-EPN command was successful
  8. Você pode adicionar EPN a qualquer sistema de monitoramento e invocá-la com as opções --from-nbdays e --to-nbdays para determinar quantas senhas de usuários vão expirar dentro de um período de tempo específico:

    # ipa-epn --de-ndias 8 --para-ndias 12
    Nota

    Se você invocar a ferramenta EPN com as opções --from-nbdays e --to-nbdays, ela é automaticamente executada em modo de funcionamento a seco.

Etapas de verificação

  • Execute a ferramenta EPN e verifique se foi enviada uma notificação por e-mail.

Recursos adicionais

  • Consulte a página ipa-epn man page.
  • Consulte a página epn.conf man page.

35.4. Habilitação do ipa-epn.timer para enviar um e-mail a todos os usuários cujas senhas estão expirando

Este procedimento descreve como usar ipa-epn.timer para executar a ferramenta Notificação de Senha Vazio (EPN) para enviar e-mails aos usuários cujas senhas estão expirando. O ipa-epn.timer analisa o arquivo epn.conf e envia um e-mail para os usuários cujas senhas estão expirando dentro dos intervalos definidos de datas futuras configurados nesse arquivo.

Pré-requisitos

Procedimento

  • Inicie o ipa-epn.timer:

    systemctl start ipa-epn.timer

Uma vez iniciado o temporizador, por padrão, a ferramenta EPN é executada todos os dias à uma da manhã.

Recursos adicionais

  • Veja a página de manual ipa-epn.

35.5. Modificando o modelo de e-mail de notificação de senha expirada

Este procedimento descreve como personalizar o modelo de mensagem de e-mail de Notificação de Senha Vitalícia (EPN).

Pré-requisitos

  • O pacote ipa-client-epn está instalado.

Procedimento

  1. Abra o modelo de mensagem EPN:

    # vi /etc/ipa/epn/expire_msg.template
  2. Atualizar o texto modelo, conforme necessário.

    Hi {{ fullname }},
    
    Your password will expire on {{ expiration }}.
    
    Please change it as soon as possible.

    Você pode usar as seguintes variáveis no modelo.

    • ID do usuário: uid
    • Nome completo: Fullname
    • Primeiro nome: primeiro
    • Sobrenome: sobrenome
    • Data de expiração da senha: expiração
  3. Salvar o arquivo de modelo de mensagem.

Etapas de verificação

  • Execute a ferramenta EPN e verifique se a notificação por e-mail contém o texto atualizado.

Recursos adicionais

  • Veja a página de manual ipa-epn.

Capítulo 36. Conceder acesso sudo a um usuário da IdM em um cliente da IdM

36.1. Acesso ao judô em um cliente da IdM

Os administradores do sistema podem conceder acesso a sudo para permitir que usuários não root executem comandos administrativos que normalmente são reservados ao usuário root. Consequentemente, quando os usuários precisam executar um comando administrativo normalmente reservado para o usuário root, eles precedem esse comando com sudo. Após digitar sua senha, o comando é executado como se fosse o usuário root.

Se um host Red Hat Enterprise Linux (RHEL) 8 estiver registrado como cliente de Gerenciamento de Identidade (IdM), você pode especificar as regras sudo definindo quais usuários IdM podem executar quais comandos no host das seguintes maneiras:

  • Localmente no arquivo /etc/sudoers
  • De forma centralizada na IdM

Este capítulo descreve a criação de uma regra central sudo para um cliente IdM usando IdM Web UI. Para detalhes sobre a criação de regras sudo locais em um host RHEL 8, consulte Gerenciando o acesso sudo.

Note que você também pode definir regras centrais do IdM sudo usando a interface de linha de comando do IdM.

36.2. Conceder acesso sudo a um usuário IdM em um cliente IdM usando a IDM Web UI

Em Gerenciamento de Identidade (IdM), você pode conceder acesso a sudo para um comando específico para uma conta de usuário IdM em um host IdM específico. Primeiro, adicione um comando sudo e depois crie uma regra sudo para um ou mais comandos.

Complete este procedimento para criar a regra idm_user_reboot sudo para conceder a idm_user a permissão para executar o comando /usr/sbin/reboot na máquina idmclient.

Pré-requisitos

  • Você está logado como administrador da IdM.
  • Você criou uma conta de usuário para idm_user no IdM e desbloqueou a conta criando uma senha para o usuário. Para detalhes sobre como adicionar um novo usuário do IdM usando a interface de linha de comando, veja Adicionar usuários usando a linha de comando.
  • Nenhuma conta idm_user local foi criada em idmclient. O usuário idm_user não está listado no arquivo local /etc/passwd.

Procedimento

  1. Adicione o comando /usr/sbin/reboot ao banco de dados do IdM de sudo comandos:

    1. Navegue para PolicySudoSudo Commands.
    2. Clique em Add no canto superior direito para abrir a caixa de diálogo Add sudo command.
    3. Digite o comando que você quer que o usuário seja capaz de executar usando sudo: /usr/sbin/reboot.

      Figura 36.1. Adicionando o comando sudo IdM

      adding IdM sudo command
    4. Clique em Add.
  2. Use o novo comando sudo para criar uma regra sudo para permitir idm_user para reiniciar a máquina idmclient:

    1. Navegue para PolicySudoSudo rules.
    2. Clique em Add no canto superior direito para abrir a caixa de diálogo Add sudo rule.
    3. Digite o nome da regra sudo: idm_user_reboot.
    4. Clique em Add and Edit.
    5. Especifique o usuário:

      1. Na seção Who, verifique o botão de rádio Specified Users and Groups.
      2. Na subseção User category the rule applies to, clique em Add para abrir a caixa de diálogo Add users into sudo rule "idm_user_reboot".
      3. Na caixa de diálogo Add users into sudo rule "idm_user_reboot", na coluna Available, marque a caixa de seleção idm_user, e mova para a coluna Prospective.
      4. Clique em Add.
    6. Especifique o anfitrião:

      1. Na seção Access this host, verifique o botão de rádio Specified Hosts and Groups.
      2. Na subseção Host category this rule applies to, clique em Add para abrir a caixa de diálogo Add hosts into sudo rule "idm_user_reboot".
      3. Na caixa de diálogo Add hosts into sudo rule "idm_user_reboot", na coluna Available, marque a caixa de seleção idmclient.idm.example.com, e mova para a coluna Prospective.
      4. Clique em Add.
      1. Especifique os comandos:

        1. Na subseção Command category the rule applies to da seção Run Commands, verifique o botão de rádio Specified Commands and Groups.
        2. Na subseção Sudo Allow Commands, clique em Add para abrir a caixa de diálogo Add allow sudo commands into sudo rule "idm_user_reboot".
        3. Na caixa de diálogo Add allow sudo commands into sudo rule "idm_user_reboot", na coluna Available, marque a caixa de seleção /usr/sbin/reboot, e mova para a coluna Prospective.
        4. Clique em Add para retornar à página idm_sudo_reboot.

          Figura 36.2. Adicionando a regra do sudo IdM

          IdM sudo rule WebUI
    7. Clique em Save, no canto superior esquerdo.

A nova regra é ativada por padrão.

Etapas de verificação

Teste que a regra sudo que você estabeleceu no servidor IdM funciona em idmclient, verificando que idm_user pode agora reiniciar idmclient usando sudo. Note que a propagação das mudanças do servidor para o cliente pode levar alguns minutos.

  1. Acesse idmclient como idm_user.
  2. Reinicie a máquina usando sudo. Digite a senha para idm_user quando solicitado:

    $ sudo /usr/sbin/reboot
    [sudo] password for idm_user:

Se o sudo for configurado corretamente, a máquina é reinicializada.

36.3. Utilização de um livro de jogo possível para garantir o acesso sudo para um usuário IdM em um cliente IdM

No Gerenciamento de Identidade (IdM), você pode garantir que sudo tenha acesso a um comando específico concedido a uma conta de usuário IdM em um host IdM específico.

Complete este procedimento para garantir a existência de uma regra chamada idm_user_reboot no site sudo. A regra concede a idm_user a permissão para executar o comando /usr/sbin/reboot na máquina idmclient.

Pré-requisitos

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaservers no mesmo:

    [ipaservers]
    server.idm.example.com
  2. Adicione um ou mais comandos em sudo:

    1. Criar um livro de exercícios ensure-reboot-sudocmd-is-present.yml que garanta a presença do comando /usr/sbin/reboot no banco de dados do IdM de sudo comandos. Para simplificar esta etapa, você pode copiar e modificar o exemplo no arquivo /usr/share/doc/ansible-freeipa/playbooks/sudocmd/ensure-sudocmd-is-present.yml:

      ---
      - name: Playbook to manage sudo command
        hosts: ipaserver
        become: true
      
        tasks:
        # Ensure sudo command is present
        - ipasudocmd:
            ipaadmin_password: MySecret123
            name: /usr/sbin/reboot
            state: present
    2. Execute o livro de brincadeiras:

      $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-reboot-sudocmd-is-present.yml
  3. Criar uma regra sudo que faça referência aos comandos:

    1. Criar um livro de jogo ensure-sudorule-for-idmuser-on-idmclient-is-present.yml que utiliza o comando sudo para garantir a presença de uma regra de sudo. A regra sudo permite que idm_user reinicie a máquina idmclient. Para simplificar esta etapa, você pode copiar e modificar o exemplo no arquivo /usr/share/doc/ansible-freeipa/playbooks/sudorule/ensure-sudorule-is-present.yml:

      ---
      - name: Tests
        hosts: ipaserver
        become: true
      
        tasks:
        # Ensure a sudorule is present granting idm_user the permission to run /usr/sbin/reboot on idmclient
        - ipasudorule:
            ipaadmin_password: MySecret123
            name: idm_user_reboot
            description: A test sudo rule.
            allow_sudocmd: /usr/sbin/reboot
            host: idmclient.idm.example.com
            user: idm_user
            state: present
    2. Execute o livro de brincadeiras:

      $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-sudorule-for-idmuser-on-idmclient-is-present.yml

Etapas de verificação

Teste que a regra sudo cuja presença você garantiu no servidor IdM funciona em idmclient, verificando que idm_user pode reiniciar idmclient usando sudo. Note que pode levar alguns minutos para que as mudanças feitas no servidor tenham efeito sobre o cliente.

  1. Acesse idmclient como idm_user.
  2. Reinicie a máquina usando sudo. Digite a senha para idm_user quando solicitado:

    $ sudo /usr/sbin/reboot
    [sudo] password for idm_user:

Se sudo estiver configurado corretamente, a máquina é reinicializada.

Materiais adicionais

  • Para mais detalhes sobre como aplicar os comandos sudo, grupos de comando e regras no IdM usando um livro de jogo possível, incluindo as descrições das variáveis do livro de jogo, veja os arquivos README-sudocmd.md, README-sudocmdgroup.md e README-sudorule.md Markdown disponíveis no diretório /usr/share/doc/ansible-freeipa/.

Capítulo 37. Assegurar a presença de regras de controle de acesso baseadas em host na IdM usando Livros de Jogadas Ansíveis

Este capítulo descreve as políticas de acesso baseadas em host management (IdM) e como defini-las usando o Ansible.

Ansible é uma ferramenta de automação usada para configurar sistemas, implantar software e realizar atualizações rolantes. Ela inclui suporte para Gerenciamento de Identidade (IdM).

37.1. Regras de controle de acesso baseadas no host na IdM

As regras de controle de acesso baseado em host (HBAC) definem quais usuários ou grupos de usuários podem acessar quais host ou grupos de host usando quais serviços ou serviços de um grupo de serviços. Como administrador do sistema, você pode usar as regras do HBAC para alcançar os seguintes objetivos:

  • Limite o acesso a um sistema especificado em seu domínio aos membros de um grupo de usuários específico.
  • Permita que apenas um serviço específico seja utilizado para acessar sistemas em seu domínio.

Por padrão, o IdM é configurado com uma regra padrão da HBAC chamada allow_all, que significa acesso universal a cada host para cada usuário através de todos os serviços relevantes em todo o domínio IdM.

Você pode ajustar o acesso a diferentes anfitriões substituindo a regra padrão allow_all por seu próprio conjunto de regras HBAC. Para uma gestão centralizada e simplificada do controle de acesso, você pode aplicar as regras HBAC a grupos de usuários, grupos de host ou grupos de serviços em vez de usuários individuais, hosts ou serviços.

37.2. Assegurar a presença de uma regra HBAC na IdM usando um livro de jogo possível

Esta seção descreve como garantir a presença de uma regra de controle de acesso baseada em host (HBAC) na Gestão de Identidade (IdM) usando um livro de exercícios possível.

Pré-requisitos

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file, e definir ipaserver no mesmo:

    [ipaserver]
    server.idm.example.com
  2. Crie seu arquivo de Livro de Jogadas Possível que define a política do HBAC cuja presença você quer garantir. Para simplificar esta etapa, você pode copiar e modificar o exemplo no arquivo /usr/share/doc/ansible-freeipa/playbooks/hbacrule/ensure-hbacrule-allhosts-present.yml:

    ---
    - name: Playbook to handle hbacrules
      hosts: ipaserver
      become: true
    
      tasks:
      # Ensure idm_user can access client.idm.example.com via the sshd service
      - ipahbacrule:
          ipaadmin_password: MySecret123
          name: login
          user: idm_user
          host: client.idm.example.com
          hbacsvc:
          - sshd
          state: present
  3. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file path_to_playbooks_directory/ensure-new-hbacrule-present.yml

Etapas de verificação

  1. Entrar na IDM Web UI como administrador.
  2. Navegue para PolicyHost-Based-Access-ControlHBAC Test.
  3. Na aba Who, selecione idm_user.
  4. Na guia Accessing, selecione client.idm.example.com.
  5. Na guia Via service, selecione sshd.
  6. Na aba Rules, selecione login.
  7. Na aba Run test, clique no botão Run test. Se você vir ACESSO CONCEDIDO, a regra HBAC é implementada com sucesso.

Recursos adicionais

  • Para mais detalhes e exemplos sobre a configuração de serviços HBAC, grupos de serviços e regras usando Ansible, veja os arquivos README-hbacsvc.md, README-hbacsvcgroup.md e README-hbacrule.md Markdown. Estes arquivos estão disponíveis no diretório /usr/share/doc/ansible-freeipa. Veja também os playbooks disponíveis nos subdiretórios relevantes do diretório /usr/share/doc/ansible-freeipa/playbooks.

Capítulo 38. Certificados de chave pública na Gestão da Identidade

Este capítulo descreve os certificados de chave pública X.509, que são usados para autenticar usuários, hosts e serviços em Gerenciamento de Identidade (IdM). Além da autenticação, os certificados X.509 também permitem a assinatura digital e a criptografia para proporcionar privacidade, integridade e não repúdio.

Um certificado contém as seguintes informações:

  • O assunto que o certificado autentica.
  • O emissor, ou seja, a CA que assinou o certificado.
  • A data de início e fim da validade do certificado.
  • Os usos válidos do certificado.
  • A chave pública do assunto.

Uma mensagem criptografada pela chave pública só pode ser descriptografada por uma chave privada correspondente. Enquanto um certificado e a chave pública que ele inclui podem ser disponibilizados publicamente, o usuário, host ou serviço deve manter sua chave privada em segredo.

38.1. Autoridades certificadoras na IdM

As autoridades certificadoras operam em uma hierarquia de confiança. Em um ambiente IdM com uma Autoridade Certificadora (CA) interna, todos os hospedeiros, usuários e serviços da IdM confiam nos certificados que foram assinados pela CA. Além desta CA raiz, o IdM suporta sub-CAs às quais a CA raiz concedeu a capacidade de assinar certificados por sua vez. Freqüentemente, os certificados que tais sub-CAs são capazes de assinar são certificados de um tipo específico, por exemplo, certificados VPN. Finalmente, o IdM suporta o uso de ACs externas. A tabela abaixo apresenta as especificidades do uso dos tipos individuais de CA no IdM.

Tabela 38.1. Comparação do uso de CAs integrados e externos na IdM

Nome do CADescriçãoUseLinks úteis

O ipa CA

Uma CA integrada baseada no projeto Dogtag upstream

Os CAs integrados podem criar, revogar e emitir certificados para usuários, hosts e serviços.

Usando a ipa CA para solicitar um novo certificado de usuário e exportá-lo para o cliente

Sub-CAs IdM

Uma CA integrada que está subordinada à CA ipa

As sub-CAs de IdM são CAs às quais a CA ipa concedeu a possibilidade de assinar certificados. Freqüentemente, estes certificados são de um tipo específico, por exemplo, certificados VPN.

Restringindo um pedido de confiança apenas a um subconjunto de certificados

ACs externos

Uma CA externa é uma CA diferente da CA IdM integrada ou suas sub-CAs.

Usando ferramentas IdM, você adiciona certificados emitidos por estas CAs aos usuários, serviços ou hosts, assim como os remove.

Gestão de certificados emitidos por CAs externas na documentação RHEL 7

Do ponto de vista do certificado, não há diferença entre ser assinado por uma IdM CA autoassinada e ser assinado externamente.

O papel do CA inclui os seguintes propósitos:

  • Ela emite certificados digitais.
  • Ao assinar um certificado, ele certifica que o sujeito mencionado no certificado possui uma chave pública. O assunto pode ser um usuário, host ou serviço.
  • Ele pode revogar certificados e fornece o status de revogação através de Listas de Revogação de Certificados (CRLs) e Protocolo Online de Status de Certificados (OCSP).

Recursos adicionais

38.2. Comparação de certificados e Kerberos

Os certificados desempenham uma função semelhante àquela desempenhada pelos bilhetes Kerberos. Kerberos é um protocolo de autenticação de rede de computadores que funciona com base em bilhetes para permitir que os nós que se comunicam através de uma rede não segura possam provar sua identidade uns aos outros de forma segura. A tabela a seguir mostra uma comparação dos certificados Kerberos e X.509:

Tabela 38.2. Comparação de certificados e Kerberos

Characteristic

Kerberos

X.509

Authentication

Sim

Sim

Privacy

Opcional

Sim

Integrity

Opcional

Sim

Type of cryptography involved

Simétrico

Assimétrico

Default validity

Curto (1 dia)

Longo(2 anos)

Por padrão, Kerberos em Gerenciamento de Identidade somente garante a identidade das partes comunicantes.

38.3. Os prós e contras do uso de certificados para autenticar usuários na IdM

As vantagens de usar certificados para autenticar usuários na IdM incluem os seguintes pontos:

  • Um PIN que protege a chave privada em um cartão inteligente é normalmente menos complexo e mais fácil de lembrar do que uma senha comum.
  • Dependendo do dispositivo, uma chave privada armazenada em um cartão inteligente não pode ser exportada. Isto proporciona segurança adicional.
  • Cartões inteligentes podem fazer logout automático: O IdM pode ser configurado para logout de usuários quando eles retiram o cartão inteligente do leitor.
  • Roubar a chave privada requer acesso físico real a um Cartão Smart Card, tornando os Cartões Smart Card seguros contra ataques de hacking.
  • A autenticação por cartão inteligente é um exemplo de autenticação de dois fatores: requer tanto algo que você tem (o cartão) quanto algo que você conhece (o PIN).
  • Os cartões inteligentes são mais flexíveis que as senhas porque fornecem as chaves que podem ser usadas para outros fins, como criptografia de e-mails.
  • O uso de cartões inteligentes em máquinas compartilhadas que são clientes da IdM normalmente não apresenta problemas adicionais de configuração para os administradores do sistema. Na verdade, a autenticação de cartões inteligentes é a escolha ideal para máquinas compartilhadas.

As desvantagens de usar certificados para autenticar usuários na IdM incluem os seguintes pontos:

  • Os usuários podem perder ou esquecer de trazer seu cartão inteligente ou certificado e ser efetivamente bloqueados.
  • Digitar um PIN várias vezes pode resultar no bloqueio de um cartão.
  • Geralmente há um passo intermediário entre o pedido e a autorização de algum tipo de oficial de segurança ou aprovador. Na IdM, o oficial de segurança ou administrador deve executar o comando ipa cert-request.
  • Os cartões inteligentes e os leitores tendem a ser específicos do fornecedor e do motorista: embora muitos leitores possam ser usados para cartões diferentes, um cartão inteligente de um fornecedor específico pode não funcionar no leitor de outro fornecedor ou no tipo de leitor para o qual ele não foi projetado.
  • Os certificados e cartões inteligentes têm uma curva de aprendizado íngreme para os administradores.

Capítulo 39. Gerenciamento de certificados para usuários, hosts e serviços usando o IdM CA integrado

Este capítulo descreve como gerenciar certificados em Gerenciamento de Identidade (IdM) usando a CA integrada, a CA ipa, e suas sub-CAs.

Este capítulo contém as seguintes seções:

Você também pode solicitar novos certificados para um serviço da IdM CA usando o utilitário certmonger. Para mais informações, consulte Solicitação de novos certificados para um serviço da IdM CA usando o certmonger.

Pré-requisitos

39.1. Solicitação de novos certificados para um usuário, host ou serviço usando IdM Web UI

Esta seção descreve como usar a Interface Web de Gerenciamento de Identidade (IdM) para solicitar um novo certificado para qualquer entidade de IdM das autoridades de certificado de IdM integrado (CAs): a CA ipa ou qualquer uma de suas sub-CAs.

As entidades da IdM incluem:

  • Usuários
  • Anfitriões
  • Serviços
Importante

Os serviços normalmente são executados em nós de serviço dedicados nos quais as chaves privadas são armazenadas. A cópia da chave privada de um serviço para o servidor da IdM é considerada insegura. Portanto, ao solicitar um certificado para um serviço, crie a solicitação de assinatura de certificado (CSR) no nó de serviço.

Pré-requisitos

  • Sua implantação de IdM contém uma CA integrada.
  • Você está logado na IdM Web UI como administrador da IdM.

Procedimento

  1. Na guia Identity, selecione a subguia Users, Hosts, ou Services.
  2. Clique no nome do usuário, host, ou serviço para abrir sua página de configuração.

    Figura 39.1. Lista de Anfitriões

    hosts list
  3. Clique AçõesNovo certificado.
  4. Opcional: Selecione a CA emissora e a identificação do perfil.
  5. Siga as instruções para usar o utilitário de linha de comando (CLI) certutil na tela.
  6. Clique em Issue.

39.2. Solicitação de novos certificados para um usuário, host ou serviço da IdM CA usando certutil

Você pode usar o utilitário certutil para solicitar um certificado para um usuário, host ou serviço de Gerenciamento de Identidade (IdM) em situações padrão de IdM. Para garantir que um host ou serviço Kerberos possa usar um certificado, use o utilitário openssl para solicitar um certificado em seu lugar.

Esta seção descreve como solicitar um certificado para um usuário, host ou serviço da IdM a ipa, a autoridade certificadora da IdM (CA), usando certutil.

Importante

Os serviços normalmente são executados em nós de serviço dedicados nos quais as chaves privadas são armazenadas. A cópia da chave privada de um serviço para o servidor da IdM é considerada insegura. Portanto, ao solicitar um certificado para um serviço, crie a solicitação de assinatura de certificado (CSR) no nó de serviço.

Pré-requisitos

  • Sua implantação de IdM contém uma CA integrada.
  • Você está logado na interface de linha de comando do IdM (CLI) como administrador do IdM.

Procedimento

  1. Criar um diretório temporário para o banco de dados de certificados:

    # mkdir ~/certdb/
  2. Criar um novo banco de dados de certificados temporários, por exemplo:

    # certutil -N -d ~/certdb/
  3. Criar o CSR e redirecionar a saída para um arquivo. Por exemplo, para criar um CSR para um certificado de 4096 bit e para definir o assunto para CN=server.example.com,O=EXAMPLE.COM:

    # certutil -R -d ~/certdb/ -a -g 4096 -s "CN=server.example.com,O=EXAMPLE.COM-8 server.example.com > certificate_request.csr
  4. Enviar o arquivo de pedido de certificado para a CA em execução no servidor da IdM. Especificar o Kerberos principal a ser associado com o certificado recém-emitido:

    # ipa cert-request certificate_request.csr --principal=host/server.example.com

    O comando ipa cert-request no IdM usa os seguintes padrões:

    • O perfil do certificado caIPAserviceCert

      Para selecionar um perfil personalizado, use a opção --profile-id.

    • A raiz integrada da IdM CA, ipa

      Para selecionar uma sub-CA, use a opção --ca.

Recursos adicionais

39.3. Solicitação de novos certificados para um usuário, host ou serviço da IdM CA usando o openssl

Você pode usar o utilitário openssl para solicitar um certificado para um host ou serviço de Gerenciamento de Identidade (IdM) se quiser garantir que o Kerberos alias do host ou serviço possa usar o certificado. Em situações padrão, considere a possibilidade de solicitar um novo certificado usando o utilitário certutil em seu lugar.

Esta seção descreve como solicitar um certificado para um host da IdM, ou serviço da ipa, a autoridade certificadora da IdM, usando openssl.

Importante

Os serviços normalmente são executados em nós de serviço dedicados nos quais as chaves privadas são armazenadas. A cópia da chave privada de um serviço para o servidor da IdM é considerada insegura. Portanto, ao solicitar um certificado para um serviço, crie a solicitação de assinatura de certificado (CSR) no nó de serviço.

Pré-requisitos

  • Sua implantação de IdM contém uma CA integrada.
  • Você está logado na interface de linha de comando do IdM (CLI) como administrador do IdM.

Procedimento

  1. Crie um ou mais pseudônimos para seu Kerberos principal test/server.example.com. Por exemplo, test1/server.example.com e test2/server.example.com.
  2. No CSR, adicionar um assuntoAltName para dnsName (server.example.com) e outroName (test2/server.example.com). Para isso, configure o arquivo openssl.conf para incluir a seguinte linha especificando o UPN otherName e o subjectAltName:

    otherName=1.3.6.1.4.1.311.20.2.3;UTF8:test2/server.example.com@EXAMPLE.COM
    DNS.1 = server.example.com
  3. Crie um pedido de certificado usando openssl:

    openssl req -new -newkey rsa:2048 -keyout test2service.key -sha256 -nodes -out certificate_request.csr -config openssl.conf
  4. Enviar o arquivo de pedido de certificado para a CA em execução no servidor da IdM. Especificar o Kerberos principal a ser associado com o certificado recém-emitido:

    # ipa cert-request certificate_request.csr --principal=host/server.example.com

    O comando ipa cert-request no IdM usa os seguintes padrões:

    • O perfil do certificado caIPAserviceCert

      Para selecionar um perfil personalizado, use a opção --profile-id.

    • A raiz integrada da IdM CA, ipa

      Para selecionar uma sub-CA, use a opção --ca.

Recursos adicionais

39.4. Recursos adicionais

Capítulo 40. Conversão de formatos de certificados para trabalhar com IdM

Esta história de usuário descreve como garantir que você como administrador do sistema IdM esteja usando o formato correto de um certificado com comandos específicos de IdM. Isto é útil, por exemplo, nas seguintes situações:

40.1. Formatos e codificações de certificados na IdM

A autenticação do certificado incluindo a autenticação do cartão inteligente no IdM prossegue comparando o certificado que o usuário apresenta com o certificado, ou dados do certificado, que são armazenados no perfil de IdM do usuário.

Configuração do sistema

O que está armazenado no perfil do IdM é apenas o certificado, não a chave privada correspondente. Durante a autenticação, o usuário também deve mostrar que está de posse da chave privada correspondente. O usuário faz isso apresentando um arquivo PKCS #12 que contém tanto o certificado como a chave privada ou apresentando dois arquivos: um que contém o certificado e o outro que contém a chave privada.

Portanto, processos como carregar um certificado em um perfil de usuário só aceitam arquivos de certificado que não contenham a chave privada.

Da mesma forma, quando um administrador de sistema lhe fornece um certificado CA externo, ele fornecerá apenas os dados públicos: o certificado sem a chave privada. O utilitário ipa-advise para configurar o servidor IdM ou o cliente IdM para autenticação de cartão inteligente espera que o arquivo de entrada contenha o certificado da CA externa, mas não a chave privada.

Codificações de certificados

Há duas codificações comuns de certificados: Correio Eletrônico Privativo (PEM) e Regras de Codificação Distintas (DER). O formato base64 é quase idêntico ao formato PEM, mas não contém o cabeçalho e rodapé -----BEGIN CERTIFICATE-----/-----END CERTIFICATE-----.

Um certificado que foi codificado usando DER é um arquivo de certificado digital binário X509. Como um arquivo binário, o certificado não é legível por humanos. DER arquivos às vezes usam a extensão .der, mas arquivos com as extensões .crt e .cer também às vezes contêm certificados DER. DER arquivos contendo chaves podem ser nomeados .key.

Um certificado que foi codificado usando PEM Base64 é um arquivo legível por humanos. O arquivo contém dados blindados ASCII (Base64) prefixados com uma linha " .key BEGIN ...". PEM arquivos às vezes usam a extensão de nome de arquivo .pem, mas arquivos com as extensões de nome de arquivo .crt e .cer às vezes também contêm certificados PEM. PEM arquivos contendo chaves podem ser nomeados ----- .

Diferentes comandos ipa têm diferentes limitações em relação aos tipos de certificados que aceitam. Por exemplo, o comando ipa user-add-cert só aceita certificados codificados no formato base64, mas ipa-server-certinstall aceita PEM, DER, PKCS #7, PKCS #8 e PKCS #12 certificados.

Tabela 40.1. Codificações de certificados

Formato de codificaçãoLegível para humanosExtensões de nomes de arquivos comunsExemplo de comandos IdM aceitando o formato de codificação

PEM/base64

Sim

.pem, .crt, .cer

ipa user-add-cert, ipa-server-certinstall, ..

DER

Não

.der, .crt, .cer

ipa-server-certinstall, ..

Seção 40.4, “Comandos e formatos relacionados a certificados no IdM” lista ainda ipa comandos com os formatos de certificado que os comandos aceitam.

Autenticação do usuário

Ao utilizar a interface web para acessar o IdM, o usuário prova que está de posse da chave privada correspondente ao certificado, tendo ambas armazenadas no banco de dados do navegador.

Ao utilizar o CLI para acessar o IdM, o usuário prova que está de posse da chave privada correspondente ao certificado por um dos seguintes métodos:

  • O usuário acrescenta, como valor do parâmetro X509_user_identity do comando kinit -X, o caminho para o módulo smart card que está conectado ao smart card que contém tanto o certificado quanto a chave:

    $ kinit -X X509_user_identity='PKCS11:opensc-pkcs11.so' idm_user
  • O usuário adiciona dois arquivos como os valores do parâmetro X509_user_identity do comando kinit -X, um contendo o certificado e o outro a chave privada:

    $ kinit -X X509_user_identity='FILE:`/path/to/cert.pem,/path/to/cert.key`' idm_user

Comandos de certificados úteis

Para visualizar os dados do certificado, tais como o sujeito e o emissor:

$ openssl x509 -noout -text -in ca.pem

Para comparar em que linhas dois certificados diferem:

$ diff cert1.crt cert2.crt

Para comparar em quais linhas dois certificados diferem com a saída exibida em duas colunas:

$ diff cert1.crt cert2.crt -y

40.2. Conversão de um certificado externo para carregar em uma conta de usuário IdM

Esta seção descreve como garantir que um certificado externo seja codificado e formatado corretamente antes de adicioná-lo a uma entrada do usuário.

Pré-requisitos

  • Se seu certificado foi emitido por uma autoridade certificadora do Active Directory e utiliza a codificação PEM, certifique-se de que o arquivo PEM tenha sido convertido para o formato UNIX. Para converter um arquivo, use o utilitário dos2unix fornecido pelo pacote epônimo.

40.2.1. Conversão de um certificado externo no IdM CLI e seu carregamento em uma conta de usuário IdM

O IdM CLI só aceita um certificado PEM do qual a primeira e última linhas (-----BEGIN CERTIFICATE----- e -----END CERTIFICATE-----) foram removidas.

Procedimento

  1. Converta o certificado para o formato PEM:

    • Se seu certificado estiver no formato DER:

      $ openssl x509 -in cert.crt -inform der -outform pem -out cert.pem
    • Se seu arquivo está no formato PKCS #12, cujas extensões comuns são .pfx e .p12, e contém um certificado, uma chave privada, e possivelmente outros dados, extraia o certificado usando o utilitário openssl pkcs12. Quando solicitado, digite a senha que protege a chave privada armazenada no arquivo:

      $ openssl pkcs12 -in cert_and_key.p12 -clcerts -nokeys -out cert.pem
      Enter Import Password:
  2. Obter as credenciais do administrador:

    $ kinit admin
  3. Adicione o certificado à conta do usuário usando o IdM CLI seguindo um dos seguintes métodos:

    • Remova a primeira e última linhas (-----BEGIN CERTIFICATE----- e -----END CERTIFICATE-----) do arquivo PEM usando o utilitário sed antes de adicionar a string ao comando ipa user-add-cert:

      $ ipa user-add-cert some_user --certificate="$(sed -e '/BEGIN CERTIFICATE/d;/END CERTIFICATE/d' cert.pem)"
    • Copie e cole o conteúdo do arquivo do certificado sem a primeira e última linhas (-----BEGIN CERTIFICATE----- e -----END CERTIFICATE-----) no comando ipa user-add-cert:

      $ ipa user-add-cert some_user --certificate=MIIDlzCCAn gAwIBAgIBATANBgkqhki...
      Nota

      Você não pode passar um arquivo PEM contendo o certificado como entrada para o comando ipa user-add-cert diretamente, sem primeiro remover a primeira e última linhas (-----BEGIN CERTIFICATE----- e -----END CERTIFICATE-----):

      $ ipa user-add-cert some_user --cert=some_user_cert.pem

      Este comando resulta na "ipa: ERROR: A decodificação da base64 falhou: Mensagem de erro "Padding Incorrector".

  4. Opcionalmente, para verificar se o certificado foi aceito pelo sistema:

    [idm_user@r8server]$ ipa user-show some_user

40.2.2. Conversão de um certificado externo na interface web do IdM para carregamento em uma conta de usuário IdM:

Procedimento

  1. Usando o CLI, converta o certificado para o formato PEM:

    • Se seu certificado estiver no formato DER:

      $ openssl x509 -in cert.crt -inform der -outform pem -out cert.pem
    • Se seu arquivo está no formato PKCS #12, cujas extensões comuns são .pfx e .p12, e contém um certificado, uma chave privada, e possivelmente outros dados, extraia o certificado usando o utilitário openssl pkcs12. Quando solicitado, digite a senha que protege a chave privada armazenada no arquivo:

      $ openssl pkcs12 -in cert_and_key.p12 -clcerts -nokeys -out cert.pem
      Enter Import Password:
  2. Abra o certificado em um editor e copie o conteúdo. Você pode incluir as linhas de cabeçalho e rodapé do "-----BEGIN CERTIFICATE-----" e "-----END CERTIFICATE-----", mas não é necessário, pois tanto o formato PEM como o base64 são aceitos pela IDM web UI.
  3. Na IDM web UI, faça o login como oficial de segurança.
  4. Ir para IdentityUserssome_user.
  5. Clique em Add ao lado de Certificates.
  6. Colar o conteúdo do certificado no formato PEM na janela que se abre.
  7. Clique em Add.

Se o certificado foi aceito pelo sistema, você pode vê-lo listado entre o Certificates no perfil do usuário.

40.3. Preparação para carregar um certificado no navegador

Antes de importar um certificado de usuário para o navegador, certifique-se de que o certificado e a chave privada correspondente estejam no formato PKCS #12. Há duas situações comuns que requerem trabalho preparatório extra:

Depois, para importar tanto o certificado da CA no formato PEM quanto o certificado do usuário no formato PKCS #12 para o navegador, siga os procedimentos em Configurando um navegador para habilitar a autenticação do certificado e Autenticando para a Interface Web de Gerenciamento de Identidade com um Certificado como Usuário de Gerenciamento de Identidade.

40.3.1. Exportação de um certificado e chave privada de um banco de dados NSS para um arquivo PKCS #12

Procedimento

  1. Use o comando pk12util para exportar o certificado do banco de dados do NSS para o formato PKCS12. Por exemplo, para exportar o certificado com o nickname some_user do banco de dados NSS armazenado no diretório ~/certdb para o arquivo ~/some_user.p12:

    $ pk12util -d ~/certdb -o ~/some_user.p12 -n some_user
    Enter Password or Pin for "NSS Certificate DB":
    Enter password for PKCS12 file:
    Re-enter password:
    pk12util: PKCS12 EXPORT SUCCESSFUL
  2. Defina as permissões apropriadas para o arquivo .p12:

    # chmod 600 ~/some_user.p12

    Como o arquivo PKCS #12 também contém a chave privada, ele deve ser protegido para impedir que outros usuários utilizem o arquivo. Caso contrário, eles seriam capazes de se fazer passar pelo usuário.

40.3.2. Combinação de arquivos PEM certificados e chaves privadas em um arquivo PKCS #12

Esta seção descreve como combinar um certificado e a chave correspondente armazenada em arquivos PEM separados em um arquivo PKCS #12.

Procedimento

  • Para combinar um certificado armazenado em certfile.cer e uma chave armazenada em certfile.key em um arquivo certfile.p12 que contém tanto o certificado quanto a chave:

    $ openssl pkcs12 -export -in certfile.cer -inkey certfile.key -out certfile.p12

40.4. Comandos e formatos relacionados a certificados no IdM

A tabela de comandos e formatos do certificado IdM exibe comandos relacionados ao certificado no IdM com formatos aceitáveis.

Tabela 40.2. Comandos e formatos do certificado IdM

ComandoFormatos aceitáveisNotas

ipa user-add-cert some_user --certificate

certificado PEM base64

 

ipa-server-certinstall

Certificado PEM e DER; cadeia de certificados PKCS#7; PKCS#8 e chave privada bruta; certificado PKCS#12 e chave privada

 

ipa-cacert-manage install

DER; PEM; PKCS#7

 

ipa-cacert-manage renew --external-cert-file

Certificado PEM e DER; cadeia de certificados PKCS#7

 

ipa-ca-install --external-cert-file

Certificado PEM e DER; cadeia de certificados PKCS#7

 

ipa cert-show <cert serial> --certificate-out /path/to/file.pem

N/A

Cria o arquivo PEM-encoded file.pem com o certificado com o número de série <cert_serial>.

ipa cert-show <cert serial> --certificate-out /path/to/file.pem

N/A

Cria o arquivo PEM-encoded file.pem com o certificado com o número de série <cert_serial>. Se for utilizada a opção --chain, o arquivo PEM contém o certificado incluindo a cadeia de certificados.

ipa cert-request --certificate-out=FILE /path/to/req.csr

N/A

Cria o arquivo req.csr no formato PEM com o novo certificado.

ipa cert-request --certificate-out=FILE /path/to/req.csr

N/A

Cria o arquivo req.csr no formato PEM com o novo certificado. Se for utilizada a opção --chain, o arquivo PEM contém o certificado incluindo a cadeia de certificados.

Capítulo 41. Criação e gerenciamento de perfis de certificados em Gerenciamento de Identidade

Os modelos de certificado são usados pela Autoridade Certificadora (CA) ao assinar certificados para determinar se um pedido de assinatura de certificado (CSR) é aceitável e, em caso afirmativo, quais características e extensões estão presentes no certificado. Um perfil de certificado está associado à emissão de um tipo particular de certificado. Ao combinar perfis de certificado e listas de controle de acesso (ACLs) da CA, é possível definir e controlar o acesso a perfis de certificado personalizados.

Ao descrever como criar perfis de certificados, os procedimentos utilizam os certificados S/MIME como exemplo. Alguns programas de e-mail suportam e-mail assinado digitalmente e criptografado usando o protocolo Secure Multipurpose Internet Mail Extension (S/MIME). Usar S/MIME para assinar ou criptografar mensagens de e-mail requer que o remetente da mensagem tenha um certificado S/MIME.

41.1. O que é um perfil de certificado?

Você pode usar perfis de certificados para determinar o conteúdo dos certificados, bem como restrições para a emissão dos certificados, tais como os seguintes:

  • O algoritmo de assinatura a ser usado para cifrar o pedido de assinatura do certificado.
  • A validade padrão do certificado.
  • As razões de revogação que podem ser usadas para revogar um certificado.
  • Se o nome comum do principal for copiado para o campo de nome alternativo ao assunto.
  • As características e extensões que devem estar presentes no certificado.

Um único modelo de certificado está associado à emissão de um determinado tipo de certificado. É possível definir diferentes perfis de certificados para usuários, serviços e hosts na IdM. O IdM inclui os seguintes perfis de certificado por padrão:

  • caIPAserviceCert
  • IECUserRoles
  • KDCs_PKINIT_Certs (utilizado internamente)

Além disso, você pode criar e importar perfis personalizados, que lhe permitem emitir certificados para fins específicos. Por exemplo, você pode restringir o uso de um determinado perfil a apenas um usuário ou grupo, impedindo que outros usuários e grupos usem esse perfil para emitir um certificado para autenticação. Para criar perfis de certificados personalizados, use o comando ipa certprofile.

Recursos adicionais

  • Para obter informações sobre o comando ipa certprofile, execute o comando ipa help certprofile.

41.2. Criação de um perfil de certificado

Este procedimento descreve como criar um perfil de certificado através da linha de comando, criando um arquivo de configuração de perfil para solicitar certificados S/MIME.

Procedimento

  1. Criar um perfil personalizado, copiando um perfil padrão existente:

    $ ipa certprofile-show --out smime.cfg caIPAserviceCert
    ------------------------------------------------
    Profile configuration stored in file 'smime.cfg'
    ------------------------------------------------
      Profile ID: caIPAserviceCert
      Profile description: Standard profile for network services
      Store issued certificates: TRUE
  2. Abra o arquivo de configuração de perfil recém-criado em um editor de texto.

    $ vi  smime.cfg
  3. Mude o Profile ID para um nome que reflita o uso do perfil, por exemplo smime.

    Nota

    Quando você estiver importando um perfil recém-criado, o campo profileId, se presente, deve corresponder ao ID especificado na linha de comando.

  4. Atualizar a configuração de uso estendido da chave. A configuração padrão da Extended Key Usage Extension é para autenticação de servidor e cliente TLS. Por exemplo, para S/MIME, a configuração da Extended Key Usage deve ser configurada para proteção de e-mail:

    policyset.serverCertSet.7.default.params.exKeyUsageOIDs=1.3.6.1.5.5.7.3.4
  5. Importar o novo perfil:

    $ ipa certprofile-import smime --file smime.cfg \
      --desc "S/MIME certificates" --store TRUE
    
    ------------------------
    Imported profile "smime"
    ------------------------
      Profile ID: smime
      Profile description: S/MIME certificates
      Store issued certificates: TRUE

Etapas de verificação

  • Verificar se o novo modelo de certificado foi importado:

    $ ipa certprofile-find
    
    ------------------
    4 profiles matched
    ------------------
      Profile ID: caIPAserviceCert
      Profile description: Standard profile for network services
      Store issued certificates: TRUE
    
      Profile ID: IECUserRoles
      Profile description: User profile that includes IECUserRoles extension from request
      Store issued certificates: TRUE
    
      Profile ID: KDCs_PKINIT_Certs
      Profile description: Profile for PKINIT support by KDCs
      Store issued certificates: TRUE
    
      Profile ID: smime
      Profile description: S/MIME certificates
      Store issued certificates: TRUE
    ----------------------------
    Number of entries returned 4
    ----------------------------

Recursos adicionais

  • Para obter detalhes sobre o plug-in certprofile, execute o comando ipa help certprofile.
  • Para mais informações sobre a extensão do uso da chave estendida, veja RFC 5280, seção 4.2.1.12.

41.3. O que é uma lista de controle de acesso CA?

As regras da Lista de Controle de Acesso de Autoridade de Certificados (CA ACL) definem quais perfis podem ser usados para emitir certificados para quais mandantes. Você pode usar CA ACLs para fazer isto, por exemplo:

  • Determinar qual usuário, host ou serviço pode ser emitido um certificado com um determinado perfil
  • Determinar qual autoridade ou sub-CA do certificado IdM é permitida para emitir o certificado

Por exemplo, usando CA ACLs, você pode restringir o uso de um perfil destinado aos funcionários que trabalham a partir de um escritório localizado em Londres somente aos usuários que são membros do grupo de usuários de IdM relacionados ao escritório de Londres.

O utilitário ipa caacl para gerenciamento das regras ACL da CA permite aos usuários privilegiados adicionar, exibir, modificar ou excluir uma CA ACL específica.

Recursos adicionais

  • Para obter informações sobre o comando ipa caacl, execute o comando ipa help caacl.

41.4. Definição de uma ACL CA para controlar o acesso aos perfis de certificado

Este procedimento descreve como usar o utilitário caacl para definir uma regra da CA Access Control List (ACL) para permitir aos usuários em um grupo o acesso a um perfil de certificado personalizado. Neste caso, o procedimento descreve como criar um grupo de usuários S/MIME e uma ACL da CA para permitir aos usuários nesse grupo acesso ao perfil de certificado smime.

Pré-requisitos

  • Certifique-se de ter obtido as credenciais do administrador da IdM.

Procedimento

  1. Criar um novo grupo para os usuários do modelo de certificado:

    $ ipa group-add smime_users_group
    ---------------------------------
    Added group "smime users group"
    ---------------------------------
      Group name: smime_users_group
      GID: 75400001
  2. Criar um novo usuário para adicionar ao grupo smime_user_group:

    $ ipa user-add smime_user
    First name: smime
    Last name: user
    ----------------------
    Added user "smime_user"
    ----------------------
      User login: smime_user
      First name: smime
      Last name: user
      Full name: smime user
      Display name: smime user
      Initials: TU
      Home directory: /home/smime_user
      GECOS: smime user
      Login shell: /bin/sh
      Principal name: smime_user@IDM.EXAMPLE.COM
      Principal alias: smime_user@IDM.EXAMPLE.COM
      Email address: smime_user@idm.example.com
      UID: 1505000004
      GID: 1505000004
      Password: False
      Member of groups: ipausers
      Kerberos keys available: False
  3. Acrescente o smime_user ao grupo smime_users_group:

    $ ipa group-add-member smime_users_group --users=smime_user
      Group name: smime_users_group
      GID: 1505000003
      Member users: smime_user
    -------------------------
    Number of members added 1
    -------------------------
  4. Criar a CA ACL para permitir que os usuários do grupo tenham acesso ao perfil do certificado:

    $ ipa caacl-add smime_acl
    ------------------------
    Added CA ACL "smime_acl"
    ------------------------
      ACL name: smime_acl
      Enabled: TRUE
  5. Adicione o grupo de usuários ao CA ACL:

    $ ipa caacl-add-user smime_acl --group smime_users_group
      ACL name: smime_acl
      Enabled: TRUE
      User Groups: smime_users_group
    -------------------------
    Number of members added 1
    -------------------------
  6. Adicionar o perfil do certificado ao CA ACL:

    $ ipa caacl-add-profile smime_acl --certprofile smime
      ACL name: smime_acl
      Enabled: TRUE
      Profiles: smime
      User Groups: smime_users_group
    -------------------------
    Number of members added 1
    -------------------------

Etapas de verificação

  • Veja os detalhes da ACL CA que você criou:

    $ ipa caacl-show smime_acl
      ACL name: smime_acl
      Enabled: TRUE
      Profiles: smime
      User Groups: smime_users_group
    ...

Recursos adicionais

  • Consulte a página ipa man page.
  • Para mais detalhes sobre o comando ipa caacl, consulte o comando ipa help caacl.

41.5. Usando perfis de certificados e ACLs CA para emitir certificados

Você pode solicitar certificados usando um perfil de certificado quando permitido pelas listas de controle de acesso da Autoridade de Certificados (CA ACLs). Este procedimento descreve como solicitar um certificado S/MIME para um usuário usando um modelo de certificado personalizado que foi concedido acesso através de uma CA ACL.

Pré-requisitos

  • Seu perfil de certificado foi criado.
  • Foi criado um CA ACL que permite ao usuário utilizar o perfil de certificado exigido para solicitar um certificado.
Nota

Você pode contornar a verificação ACL CA se o usuário executa o comando cert-request:

  • É o usuário admin.
  • Tem a permissão Request Certificate ignoring CA ACLs.

Procedimento

  1. Gerar um pedido de certificado para o usuário. Por exemplo, utilizando o OpenSSL:

    $ openssl req -new -newkey rsa:2048 -days 365 -nodes -keyout private.key -out cert.csr -subj '/CN=smime_user'
  2. Solicite um novo certificado para o usuário da IdM CA:

    $ ipa cert-request cert.csr --principal=smime_user --profile-id=smime

    Opcionalmente, passe a opção --ca sub-CA_name para o comando para solicitar o certificado de um sub-CA em vez da CA raiz.

Etapas de verificação

  • Verificar se o certificado recém-emitido está atribuído ao usuário:

    $ ipa user-show user
      User login: user
      ...
      Certificate: MIICfzCCAWcCAQA...
      ...

Recursos adicionais

  • Consulte a página ipa(a) man page.
  • Para mais detalhes sobre o comando ipa user-show, consulte o comando ipa help user-show.
  • Para mais detalhes sobre o comando ipa cert-request, consulte o comando ipa help cert-request.
  • Consulte a página openssl(lssl) man page.

41.6. Modificando um perfil de certificado

Este procedimento descreve como modificar os perfis de certificados diretamente através da linha de comando, usando o comando ipa certprofile-mod.

Procedimento

  1. Determine o ID do modelo de certificado para o modelo de certificado que você está modificando. Para exibir todos os perfis de certificado atualmente armazenados na IdM:

    # ipa certprofile-find
    
    ------------------
    4 profiles matched
    ------------------
      Profile ID: caIPAserviceCert
      Profile description: Standard profile for network services
      Store issued certificates: TRUE
    
      Profile ID: IECUserRoles
      ...
    
      Profile ID: smime
      Profile description: S/MIME certificates
      Store issued certificates: TRUE
    --------------------------
    Number of entries returned
    --------------------------
  2. Modificar a descrição do perfil do certificado. Por exemplo, se você criou um modelo de certificado personalizado para certificados S/MIME usando um modelo existente, altere a descrição de acordo com o novo uso:

    # ipa certprofile-mod smime --desc "New certificate profile description"
    ------------------------------------
    Modified Certificate Profile "smime"
    ------------------------------------
        Profile ID: smime
        Profile description: New certificate profile description
        Store issued certificates: TRUE
  3. Abra seu arquivo de perfil de certificado de cliente em um editor de texto e modifique para atender às suas exigências:

    # vi smime.cfg

    Para detalhes sobre as opções que podem ser configuradas no arquivo de configuração do modelo de certificado, consulte Parâmetros de configuração do modelo de certificado.

  4. Atualizar o arquivo de configuração do perfil de certificado existente:

    # ipa certprofile-mod _profile_ID_ --file=smime.cfg

Etapas de verificação

  • Verificar se o perfil do certificado foi atualizado:

    $ ipa certprofile-show smime
      Profile ID: smime
      Profile description: New certificate profile description
      Store issued certificates: TRUE

Recursos adicionais

  • Consulte a página ipa(a) man page.
  • Para mais detalhes sobre o comando ipa certprofile-mod, consulte o comando ipa help certprofile-mod.

41.7. Parâmetros de configuração do perfil do certificado

Os parâmetros de configuração do perfil do certificado são armazenados em um arquivo profile_name.cfg no diretório de perfis da CA, /var/lib/pki/pki-tomcat/ca/profiles/ca. Todos os parâmetros para um perfil - padrões, entradas, saídas e restrições - são configurados dentro de um único conjunto de políticas. Um conjunto de políticas para um perfil de certificado tem o nome policyset.policyName.policyNumber. Por exemplo, para o conjunto de políticas serverCertSet:

policyset.list=serverCertSet
policyset.serverCertSet.list=1,2,3,4,5,6,7,8
policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl
policyset.serverCertSet.1.constraint.name=Subject Name Constraint
policyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+
policyset.serverCertSet.1.constraint.params.accept=true
policyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl
policyset.serverCertSet.1.default.name=Subject Name Default
policyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$, OU=pki-ipa, O=IPA
policyset.serverCertSet.2.constraint.class_id=validityConstraintImpl
policyset.serverCertSet.2.constraint.name=Validity Constraint
policyset.serverCertSet.2.constraint.params.range=740
policyset.serverCertSet.2.constraint.params.notBeforeCheck=false
policyset.serverCertSet.2.constraint.params.notAfterCheck=false
policyset.serverCertSet.2.default.class_id=validityDefaultImpl
policyset.serverCertSet.2.default.name=Validity Default
policyset.serverCertSet.2.default.params.range=731
policyset.serverCertSet.2.default.params.startTime=0

Cada conjunto de políticas contém uma lista de políticas configuradas para o perfil do certificado por número de identificação da política, na ordem em que devem ser avaliadas. O servidor avalia cada conjunto de políticas para cada solicitação que recebe. Quando uma única solicitação de certificado é recebida, um conjunto é avaliado, e quaisquer outros conjuntos no perfil são ignorados. Quando pares de chaves duplos são emitidos, o primeiro conjunto de apólices é avaliado para a primeira solicitação de certificado, e o segundo conjunto é avaliado para a segunda solicitação de certificado. Não é necessário mais de um conjunto de apólices ao emitir certificados simples ou mais de dois conjuntos ao emitir pares de chaves duplos.

Tabela 41.1. Parâmetros do arquivo de configuração do perfil do certificado

ParâmetroDescrição

desc

Uma descrição em texto livre do perfil do certificado, que é mostrada na página final das entidades. Por exemplo, desc=This certificate profile is for enrolling server certificates with agent authentication.

habilitar

Permite que o perfil seja acessível através da página das entidades finais. Por exemplo, enable=true.

auth.instance_id

Define o plug-in do gerenciador de autenticação a ser usado para autenticar o pedido de certificado. Para inscrição automática, a CA emite um certificado imediatamente se a autenticação for bem sucedida. Se a autenticação falhar ou não houver um plug-in de autenticação especificado, o pedido é enfileirado para ser aprovado manualmente por um agente. Por exemplo, auth.instance_id=AgentCertAuth.

authz.acl

Especifica a restrição de autorização. Esta é usada predominantemente para definir a lista de controle de acesso (ACL) de avaliação de grupo. Por exemplo, o parâmetro caCMCUserCert exige que o signatário da solicitação CMC pertença ao grupo de Agentes Gerentes de Certificados:

authz.acl=group="Certificate Manager Agents

Na renovação do certificado de usuário baseado em diretório, esta opção é utilizada para garantir que o requerente original e o usuário atualmente autenticado sejam o mesmo. Uma entidade deve autenticar (vincular ou, essencialmente, entrar no sistema) antes que a autorização possa ser avaliada.

nome

O nome do perfil do certificado. Por exemplo, name=Agent-Authenticated Server Certificate Enrollment. Este nome é exibido na página de inscrição ou renovação do usuário final.

input.list

Lista as entradas permitidas para o perfil do certificado pelo nome. Por exemplo, input.list=i1,i2.

input.input_id.class_id

Indica o nome da classe java para a entrada por ID de entrada (o nome da entrada listada em input.list). Por exemplo, input.i1.class_id=certReqInputImpl.

output.list

Lista os formatos de saída possíveis para o perfil do certificado pelo nome. Por exemplo, output.list=o1.

output.output_id.class_id

Especifica o nome da classe java para o formato de saída nomeado no output.list. Por exemplo, output.o1.class_id=certOutputImpl.

policyset.list

Lista as regras do perfil de certificado configurado. Para certificados duplos, um conjunto de regras se aplica à chave de assinatura e o outro à chave de criptografia. Certificados únicos usam apenas um conjunto de regras de modelo de certificado. Por exemplo, policyset.list=serverCertSet.

policyset.policyset_id.list

Lista as políticas dentro do conjunto de políticas configurado para o perfil do certificado por número de identificação da política, na ordem em que devem ser avaliadas. Por exemplo, policyset.serverCertSet.list=1,2,3,4,5,6,7,8.

policyset.policyset_id.policy_number.constraint.class_id

Indica o nome da classe java do plug-in de restrição definido para o padrão configurado na regra de perfil. Por exemplo, policyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl.

policyset.policyset_id.policy_number.constraint.name

Dá o nome definido pelo usuário da restrição. Por exemplo, policyset.serverCertSet.1.constraint.name=Subject Name Constraint.

policyset.policyset_id.policy_number.constraint.params.attribute

Especifica um valor para um atributo permitido para a restrição. Os atributos possíveis variam de acordo com o tipo de restrição. Por exemplo, policyset.serverCertSet.1.constraint.params.pattern=CN=.*.

policyset.policyset_id.policy_number.default.class_id

Dá o nome da classe java para o padrão definido na regra de perfil. Por exemplo, policyset.serverCertSet.1.default.class_id=userSubjectNameDefaultImpl

policyset.policyset_id.policy_number.default.name

Dá o nome definido pelo usuário do padrão. Por exemplo, policyset.serverCertSet.1.default.name=Subject Name Default

policyset.policyset_id.policy_number.default.params.attribute

Especifica um valor para um atributo permitido para o padrão. Os atributos possíveis variam de acordo com o tipo de padrão. Por exemplo, policyset.serverCertSet.1.default.params.name=CN=(Name)$request.requestor_name$.

Capítulo 42. Gerenciando a validade dos certificados na IdM

No Gerenciamento de Identidade (IdM), você pode gerenciar a validade tanto de certificados já existentes quanto de certificados que deseja emitir no futuro, mas os métodos são diferentes.

Gerenciando a validade de um certificado existente que foi emitido pela IdM CA

Na IdM, estão disponíveis os seguintes métodos de visualização da data de validade de um certificado:

Você pode administrar a validade de um certificado já existente que foi emitido pela IdM CA das seguintes maneiras:

Gerenciando a validade de futuros certificados emitidos pela IdM CA

Para administrar a validade de futuros certificados emitidos pela IdM CA, modificar, importar ou criar um perfil de certificado. Para detalhes, consulte Criação e gerenciamento de perfis de certificados em Gerenciamento de Identidade.

42.1. Visualizando a data de expiração de um certificado

42.1.1. Visualizando a data de validade de um certificado na IdM WebUI

Você pode usar IdM WebUI para visualizar a data de validade de todos os certificados que foram emitidos pela IdM CA.

Pré-requisitos

  • Certifique-se de que você obteve as credenciais do administrador.

Procedimento

  1. No menu Authentication, clique em Certificates > Certificates.
  2. Clique no número de série do certificado para abrir a página de informações do certificado.

    Figura 42.1. Lista de Certificados

    host cert list
  3. Na página de informações sobre certificados, localizar as informações em Expires On.

42.1.2. Visualização da data de expiração de um certificado no CLI

Você pode usar a interface de linha de comando (CLI) para visualizar a data de validade de um certificado.

Procedimento

  • Use o utilitário openssl para abrir o arquivo em um formato legível por humanos:

    $ openssl x509 -noout -text -in ca.pem
    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number: 1 (0x1)
            Signature Algorithm: sha256WithRSAEncryption
            Issuer: O = IDM.EXAMPLE.COM, CN = Certificate Authority
            Validity
                Not Before: Oct 30 19:39:14 2017 GMT
                Not After : Oct 30 19:39:14 2037 GMT

42.2. Revogação de certificados com os CAs de IdM integrados

42.2.1. Motivos de revogação de certificados

Um certificado revogado é inválido e não pode ser usado para autenticação. Todas as revogações são permanentes, exceto pelo motivo 6: Certificate Hold.

O motivo padrão para a revogação é 0: unspecified.

Tabela 42.1. Motivos da revogação

IDMotivoExplicação

0

Não especificado

 

1

Chave Compromissada

A chave que emitiu o certificado não é mais confiável.

Causas possíveis: ficha perdida, arquivo acessado de forma inadequada.

2

CA Compromissado

A CA que emitiu o certificado não é mais confiável.

3

Afiliação Mudou

Possíveis causas:

* Uma pessoa deixou a empresa ou se mudou para outro departamento.

* Um anfitrião ou serviço está sendo aposentado.

4

Substituída

Um certificado mais recente substituiu o certificado atual.

5

Cessação de operação

O hospedeiro ou serviço está sendo desativado.

6

Certificado

O certificado é revogado temporariamente. O certificado pode ser restaurado posteriormente.

8

Remover da CRL

O certificado não está incluído na lista de revogação de certificados (CRL).

9

Privilégio Retirado

O usuário, hospedeiro ou serviço não está mais autorizado a usar o certificado.

10

Autoridade de Atributos (AA) Compromisso

O certificado AA não é mais confiável.

42.2.2. Revogação de certificados com o IdM CAs integrado usando o IdM WebUI

Se você sabe que perdeu a chave privada para seu certificado, você deve revogar o certificado para evitar seu abuso. Complete este procedimento para usar a IdM WebUI para revogar um certificado emitido pela IdM CA.

Procedimento

  1. Clique Authentication > Certificates > Certificates.
  2. Clique no número de série do certificado para abrir a página de informações do certificado.

    Figura 42.2. Lista de Certificados

    host cert list
  3. Na página de informações sobre certificados, clique em AçõesCertificado de Revogação.
  4. Selecione o motivo da revogação e clique em Revogar. Veja Seção 42.2.1, “Motivos de revogação de certificados” para detalhes.

42.2.3. Revogação de certificados com o IdM CAs integrado usando o IdM CLI

Se você sabe que perdeu a chave privada para seu certificado, você deve revogar o certificado para evitar seu abuso. Complete este procedimento para usar o IdM CLI para revogar um certificado emitido pelo IdM CA.

Procedimento

Por exemplo, para revogar o certificado com o número de série 1032 por causa do motivo 1: Key Compromised, entre:

$ ipa cert-revoke 1032 --revocation-reason=1

Para obter detalhes sobre como solicitar um novo certificado, consulte a seguinte documentação:

42.3. Restauração de certificados com o IdM CAs integrado

Se você revogou um certificado por causa do motivo 6: Certificate Hold, você pode restaurá-lo novamente se a chave privada para o certificado não tiver sido comprometida. Para restaurar um certificado, use um dos procedimentos a seguir:

42.3.1. Restaurando certificados com as CAs IdM integradas usando IdM WebUI

Complete este procedimento para usar o IdM WebUI para restaurar um certificado IdM que foi revogado por causa da Razão 6: Certificate Hold.

Procedimento

  1. No menu Authentication, clique em Certificates > Certificates.
  2. Clique no número de série do certificado para abrir a página de informações do certificado.

    Figura 42.3. Lista de Certificados

    host cert list
  3. Na página de informações sobre certificados, clique em AçõesCertificado de Restauração.

42.3.2. Restauração de certificados com o IdM CAs integrado usando o IdM CLI

Complete este procedimento para usar o IdM CLI para restaurar um certificado IdM que foi revogado por causa da Razão 6: Certificate Hold.

Procedimento

  • Use o comando ipa cert-remove-hold e especifique o número de série do certificado. Por exemplo:

    $ ipa cert-remove-hold 1032

Capítulo 43. Configuração de regras de mapeamento de certificados na Gestão de Identidade

43.1. Regras de mapeamento de certificados para configuração de autenticação em Cartões Smart Card

As regras de mapeamento de certificados são uma forma conveniente de permitir aos usuários autenticar usando certificados em cenários em que o administrador de Gerenciamento de Identidade (IdM) não tem acesso a certos certificados dos usuários. Esta falta de acesso é normalmente causada pelo fato de os certificados terem sido emitidos por uma autoridade de certificados externa. Um caso de uso especial é representado por certificados emitidos pelo Sistema de Certificados de um Diretório Ativo (AD) com o qual o domínio IdM está em uma relação de confiança.

As regras de mapeamento de certificados também são convenientes se o ambiente IdM for grande com muitos usuários usando cartões inteligentes. Nesta situação, a adição de certificados completos pode ser complicada. O assunto e o emissor são previsíveis na maioria dos cenários e, portanto, mais fáceis de adicionar antes do que o certificado completo. Como administrador do sistema, você pode criar uma regra de mapeamento de certificados e adicionar dados de mapeamento de certificados a uma entrada de usuário mesmo antes de um certificado ser emitido para um determinado usuário. Uma vez emitido o certificado, o usuário pode entrar usando o certificado, mesmo que o certificado completo ainda não tenha sido carregado para a entrada do usuário.

Além disso, como os certificados têm que ser renovados a intervalos regulares, as regras de mapeamento de certificados reduzem as despesas administrativas. Quando um certificado de usuário é renovado, o administrador não tem que atualizar a entrada do usuário. Por exemplo, se o mapeamento for baseado nos valores Subject e Issuer, e se o novo certificado tiver o mesmo assunto e emissor que o antigo, o mapeamento ainda se aplica. Se, em contraste, o certificado completo fosse utilizado, então o administrador teria que carregar o novo certificado para a entrada do usuário para substituir o antigo.

Para estabelecer o mapeamento de certificados:

  1. Um administrador tem que carregar os dados de mapeamento do certificado (normalmente o emissor e o sujeito) ou o certificado completo em uma conta de usuário.
  2. Um administrador tem que criar uma regra de mapeamento de certificados para permitir o login bem sucedido no IdM para um usuário

    1. cuja conta contém um certificado de mapeamento de entrada de dados
    2. cuja entrada de dados de mapeamento de certificado corresponda às informações do certificado

    Para detalhes sobre os componentes individuais que compõem uma regra de mapeamento e como obtê-los e utilizá-los, consulte Componentes de uma regra de mapeamento de identidade em IdM e Obtenção do emissor de um certificado para uso em uma regra de correspondência.

Posteriormente, quando o usuário final apresenta o certificado, armazenado no sistema de arquivos ou em um cartão inteligente, a autenticação é bem sucedida.

43.1.1. Regras de mapeamento de certificados para trusts com domínios do Active Directory

Esta seção descreve os diferentes casos de uso de mapeamento de certificados que são possíveis se uma implantação de IdM estiver em uma relação de confiança com um domínio do Active Directory (AD).

As regras de mapeamento de certificados são uma forma conveniente de permitir o acesso aos recursos de IdM para usuários que possuem certificados de cartão inteligente que foram emitidos pelo confiável Sistema de Certificados AD. Dependendo da configuração do AD, os seguintes cenários são possíveis:

43.1.2. Componentes de uma regra de mapeamento de identidade na IdM

Esta seção descreve os componentes de um identity mapping rule em IdM e como configurá-los. Cada componente tem um valor padrão que você pode ignorar. Você pode definir os componentes tanto na interface web como na CLI. Na CLI, a regra de mapeamento de identidade é criada usando o comando ipa certmaprule-add.

Regra de mapeamento

O componente de regra de mapeamento associa (ou maps) um certificado com uma ou mais contas de usuário. A regra define um filtro de busca LDAP que associa um certificado com a conta de usuário pretendida.

Os certificados emitidos por diferentes autoridades certificadoras (CAs) podem ter propriedades diferentes e podem ser usados em domínios diferentes. Portanto, a IdM não aplica incondicionalmente as regras de mapeamento, mas somente aos certificados apropriados. Os certificados apropriados são definidos usando matching rules.

Observe que se você deixar a opção de regra de mapeamento vazia, os certificados são pesquisados no atributo userCertificate como um arquivo binário codificado com DER.

Definir a regra de mapeamento na CLI usando a opção --maprule.

Regra de correspondência

O componente de regra de correspondência seleciona um certificado ao qual você deseja aplicar a regra de mapeamento. A regra de correspondência padrão corresponde aos certificados com o uso do digitalSignature key e o uso do clientAuth extended key.

Definir a regra de correspondência na CLI usando a opção --matchrule.

Lista de domínios

A lista de domínios especifica os domínios de identidade nos quais você quer que a IdM procure os usuários ao processar regras de mapeamento de identidade. Se você deixar a opção não especificada, a IdM busca os usuários somente no domínio local ao qual o cliente IdM pertence.

Defina o domínio na CLI usando a opção --domain.

Prioridade

Quando múltiplas regras são aplicáveis a um certificado, a regra com a maior prioridade tem precedência. Todas as outras regras são ignoradas.

  • Quanto menor o valor numérico, maior será a prioridade da regra de mapeamento de identidade. Por exemplo, uma regra com prioridade 1 tem prioridade mais alta do que uma regra com prioridade 2.
  • Se uma regra não tem um valor de prioridade definido, ela tem a prioridade mais baixa.

Definir a prioridade da regra de mapeamento na CLI usando a opção --priority.

Exemplo de regra de mapeamento de certificados

Para definir, usando a CLI, uma regra de mapeamento de certificados chamada simple_rule que permite autenticação para um certificado emitido pelo Smart Card CA da organização EXAMPLE.ORG desde que o Subject desse certificado corresponda a uma entrada certmapdata em uma conta de usuário no IdM:

# ipa certmaprule-add simple_rule --matchrule '<ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG' --maprule '(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})'

43.1.3. Obtenção do emissor de um certificado para uso em uma regra de correspondência

Este procedimento descreve como obter a informação do emissor de um certificado para que você possa copiá-lo e colá-lo na regra de correspondência de uma regra de mapeamento de certificado. Para obter o formato do emissor exigido por uma regra de correspondência, use o utilitário openssl x509.

Pré-requisitos

  • Você tem o certificado de usuário em um formato .pem ou .crt

Procedimento

  1. Obter as informações do usuário do certificado. Use o utilitário de exibição e assinatura do certificado openssl x509:

    • a opção -noout para evitar a saída de uma versão codificada do pedido
    • a opção -issuer para emitir o nome do emissor
    • a opção -in para especificar o nome do arquivo de entrada para ler o certificado de
    • a opção -nameopt com o valor RFC2253 para exibir primeiro a saída com o nome distinto relativo mais específico (RDN)

      Se o arquivo de entrada contiver um certificado de Gerenciamento de Identidade, a saída do comando mostra que o Emissor é definido usando as informações do Organisation:

      # openssl x509 -noout -issuer -in idm_user.crt -nameopt RFC2253
      issuer=CN=Certificate Authority,O=REALM.EXAMPLE.COM

      Se o arquivo de entrada contiver um certificado do Active Directory, a saída do comando mostra que o Emissor está definido usando as informações do Domain Component:

      # openssl x509 -noout -issuer -in ad_user.crt -nameopt RFC2253
      issuer=CN=AD-WIN2012R2-CA,DC=AD,DC=EXAMPLE,DC=COM
  2. Opcionalmente, para criar uma nova regra de mapeamento na CLI baseada em uma regra de correspondência que especifica que o emissor do certificado deve ser o AD-WIN2012R2-CA extraído do domínio ad.example.com e o assunto no certificado deve corresponder à entrada certmapdata em uma conta de usuário no IdM:

    # ipa certmaprule-add simple_rule --matchrule '<ISSUER>CN=AD-WIN2012R2-CA,DC=AD,DC=EXAMPLE,DC=COM' --maprule '(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})'

Informações adicionais

Para obter detalhes sobre os formatos suportados para a regra de correspondência e a regra de mapeamento, e uma explicação dos campos de prioridade e domínio, consulte a página de manual sss-certmap(5).

43.2. Configuração de mapeamento de certificados para usuários armazenados no IdM

Esta história de usuário descreve os passos que um administrador de sistema deve tomar para habilitar o mapeamento de certificados no IdM se o usuário para quem a autenticação de certificados está sendo configurada estiver armazenada no IdM.

Pré-requisitos

  • O usuário tem uma conta na IdM.
  • O administrador tem o certificado completo ou os dados de mapeamento do certificado para adicionar à entrada do usuário.

43.2.1. Adicionando uma regra de mapeamento de certificados no IdM

Esta seção descreve como configurar uma regra de mapeamento de certificados para que os usuários do IdM com certificados que correspondam às condições especificadas na regra de mapeamento e em suas entradas de dados de mapeamento de certificados possam se autenticar no IdM.

43.2.1.1. Adicionando uma regra de mapeamento de certificados na IDM web UI

  1. Entrar na IDM web UI como administrador.
  2. Navegue para AuthenticationCertificate Identity Mapping RulesCertificate Identity Mapping Rules.
  3. Clique em Add.

    Figura 43.1. Adicionando uma nova regra de mapeamento de certificados na interface web do IdM

    new certmaprule add
  4. Digite o nome da regra.
  5. Insira a regra de mapeamento. Por exemplo, para fazer a pesquisa IdM para as entradas Issuer e Subject em qualquer certificado apresentado a eles, e basear sua decisão de autenticar ou não nas informações encontradas nestas duas entradas do certificado apresentado:

    (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})
  6. Insira a regra de correspondência. Por exemplo, permitir somente certificados emitidos pelo Smart Card CA da organização EXAMPLE.ORG para autenticar usuários à IdM:

    <ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG

    Figura 43.2. Entrada dos detalhes para uma regra de mapeamento de certificados na interface web do IdM

    certmaprule add details1
  7. Clique em Add na parte inferior da caixa de diálogo para adicionar a regra e fechar a caixa.
  8. O System Security Services Daemon (SSSD) relê periodicamente as regras de mapeamento de certificados. Para forçar a regra recém-criada a ser carregada imediatamente, reinicie o SSSD:

    # systemctl restart sssd

Agora você tem uma regra de mapeamento de certificado estabelecida que compara o tipo de dados especificados na regra de mapeamento que ela encontra em um certificado de cartão inteligente com os dados de mapeamento de certificado em suas entradas de usuário do IdM. Uma vez encontrada uma correspondência, ela autentica o usuário correspondente.

43.2.1.2. Adição de uma regra de mapeamento de certificados no IdM CLI

  1. Obter as credenciais do administrador:

    # kinit admin
  2. Insira a regra de mapeamento e a regra de correspondência na qual a regra de mapeamento se baseia. Por exemplo, para fazer a busca do IdM para as entradas Issuer e Subject em qualquer certificado apresentado, e basear sua decisão de autenticar ou não nas informações encontradas nestas duas entradas do certificado apresentado, reconhecendo apenas os certificados emitidos pela Smart Card CA da organização EXAMPLE.ORG:

    # ipa certmaprule-add rule_name --matchrule '<ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG' --maprule '(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})'
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "rule_name"
    -------------------------------------------------------
      Rule name: rule_name
      Mapping rule: (ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})
      Matching rule: <ISSUER>CN=Smart Card CA,O=EXAMPLE.ORG
      Enabled: TRUE
  3. O System Security Services Daemon (SSSD) relê periodicamente as regras de mapeamento de certificados. Para forçar a regra recém-criada a ser carregada imediatamente, reinicie o SSSD:

    # systemctl restart sssd

Agora você tem uma regra de mapeamento de certificado estabelecida que compara o tipo de dados especificados na regra de mapeamento que ela encontra em um certificado de cartão inteligente com os dados de mapeamento de certificado em suas entradas de usuário do IdM. Uma vez encontrada uma correspondência, ela autentica o usuário correspondente.

43.2.2. Adicionando dados de mapeamento de certificados a uma entrada de usuário no IdM

Esta seção descreve como inserir dados de mapeamento de certificados para uma entrada de usuário IdM para que o usuário possa autenticar usando múltiplos certificados, desde que todos contenham os valores especificados na entrada de dados de mapeamento de certificados.

43.2.2.1. Adicionando dados de mapeamento de certificados a uma entrada do usuário na interface web do IdM

  1. Entre na IDM web UI como administrador.
  2. Navegue para UsersActive usersidm_user.
  3. Encontre a opção Certificate mapping data e clique em Add.
  4. Se você tiver o certificado de idm_user à sua disposição:

    1. Na Interface da Linha de Comando, exibir o certificado usando o utilitário cat ou um editor de texto:

      [root@server ~]# cat idm_user_certificate.pem
      -----BEGIN CERTIFICATE-----
      MIIFFTCCA/2gAwIBAgIBEjANBgkqhkiG9w0BAQsFADA6MRgwFgYDVQQKDA9JRE0u
      RVhBTVBMRS5DT00xHjAcBgNVBAMMFUNlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0x
      ODA5MDIxODE1MzlaFw0yMDA5MDIxODE1MzlaMCwxGDAWBgNVBAoMD0lETS5FWEFN
      [...output truncated...]
    2. Copie o certificado.
    3. Na interface web da IdM, clique em Add ao lado de Certificate e cole o certificado na janela que se abre.

      Figura 43.3. Adicionando dados de mapeamento de certificados do usuário: certificado

      user add cert

      Alternativamente, se você não tem o certificado de idm_user à sua disposição, mas conhece o Issuer e o Subject do certificado, verifique o botão de rádio de Issuer and subject e digite os valores nas duas respectivas caixas.

      Figura 43.4. Adicionando dados de mapeamento de certificados de usuário: emissor e sujeito

      user add certdata
  5. Clique em Add.
  6. Opcionalmente, se você tiver acesso a todo o certificado no formato .pem, verifique se o usuário e o certificado estão vinculados:

    1. Use o utilitário sss_cache para invalidar o registro de idm_user no cache do SSSD e forçar uma recarga das informações de idm_user:

      # sss_cache -u idm_user
    2. Execute o comando ipa certmap-match com o nome do arquivo contendo o certificado do usuário do IdM:

      # ipa certmap-match idm_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: IDM.EXAMPLE.COM
       User logins: idm_user
      ----------------------------
      Number of entries returned 1
      ----------------------------

      A saída confirma que agora você tem dados de mapeamento de certificados adicionados a idm_user e que existe uma regra de mapeamento correspondente. Isto significa que você pode usar qualquer certificado que corresponda aos dados de mapeamento de certificado definidos para autenticar como idm_user.

43.2.2.2. Adicionando dados de mapeamento de certificados a uma entrada de usuário no IdM CLI

  1. Obter as credenciais do administrador:

    # kinit admin
  2. Se você tiver o certificado de idm_user à sua disposição, adicione o certificado à conta de usuário usando o comando ipa user-add-cert:

    # CERT=`cat idm_user_cert.pem | tail -n +2| head -n -1 | tr -d '\r\n'\`
    # ipa user-add-certmapdata idm_user --certificate $CERT

    Alternativamente, se você não tem o certificado de idm_user à sua disposição, mas conhece o Issuer e o Subject do certificado do idm_user:

    # ipa user-add-certmapdata idm_user --subject "O=EXAMPLE.ORG,CN=test" --issuer "CN=Smart Card CA,O=EXAMPLE.ORG"
    --------------------------------------------
    Added certificate mappings to user "idm_user"
    --------------------------------------------
      User login: idm_user
      Certificate mapping data: X509:<I>O=EXAMPLE.ORG,CN=Smart Card CA<S>CN=test,O=EXAMPLE.ORG
  3. Opcionalmente, se você tiver acesso a todo o certificado no formato .pem, verifique se o usuário e o certificado estão vinculados:

    1. Use o utilitário sss_cache para invalidar o registro de idm_user no cache do SSSD e forçar uma recarga das informações de idm_user:

      # sss_cache -u idm_user
    2. Execute o comando ipa certmap-match com o nome do arquivo contendo o certificado do usuário do IdM:

      # ipa certmap-match idm_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: IDM.EXAMPLE.COM
       User logins: idm_user
      ----------------------------
      Number of entries returned 1
      ----------------------------

      A saída confirma que agora você tem dados de mapeamento de certificados adicionados a idm_user e que existe uma regra de mapeamento correspondente. Isto significa que você pode usar qualquer certificado que corresponda aos dados de mapeamento de certificado definidos para autenticar como idm_user.

43.3. Configuração do mapeamento de certificados para usuários cuja entrada de usuário AD contém o certificado completo

Esta história de usuário descreve os passos necessários para habilitar o mapeamento de certificados no IdM se a implantação do IdM estiver em confiança com o Active Directory (AD), o usuário é armazenado no AD e a entrada do usuário no AD contém o certificado completo.

Pré-requisitos

  • O usuário não tem uma conta na IdM.
  • O usuário tem uma conta no AD que contém um certificado.
  • O administrador do IdM tem acesso aos dados nos quais a regra de mapeamento de certificados IdM pode ser baseada.

43.3.1. Adicionando uma regra de mapeamento de certificados para usuários cuja entrada AD contém certificados inteiros

43.3.1.1. Adicionando uma regra de mapeamento de certificados na IDM web UI

  1. Entre na IDM web UI como administrador.
  2. Navegue para AuthenticationCertificate Identity Mapping RulesCertificate Identity Mapping Rules.
  3. Clique em Add.

    Figura 43.5. Adicionando uma nova regra de mapeamento de certificados na interface web do IdM

    new certmaprule add
  4. Digite o nome da regra.
  5. Insira a regra de mapeamento. Ter todo o certificado que é apresentado à IdM para autenticação, em comparação com o que está disponível no AD:

    (userCertificate;binary={cert!bin})
  6. Insira a regra de correspondência. Por exemplo, para permitir somente a autenticação de certificados emitidos pelo AD-ROOT-CA do domínio AD.EXAMPLE.COM:

    <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com

    Figura 43.6. Regra de mapeamento de certificados para um usuário com um certificado armazenado no AD

    certmaprule add details ad cert
  7. Clique em Add.
  8. O System Security Services Daemon (SSSD) relê periodicamente as regras de mapeamento de certificados. Para forçar a regra recém-criada a ser carregada imediatamente, reinicie o SSSD no CLI::

    # systemctl restart sssd

43.3.1.2. Adição de uma regra de mapeamento de certificados no IdM CLI

  1. Obter as credenciais do administrador:

    # kinit admin
  2. Insira a regra de mapeamento e a regra de correspondência na qual a regra de mapeamento se baseia. Ter todo o certificado que é apresentado para autenticação em comparação com o que está disponível no AD, permitindo apenas que os certificados emitidos pelo AD-ROOT-CA do domínio AD.EXAMPLE.COM se autentiquem:

    # ipa certmaprule-add simpleADrule --matchrule '<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' --maprule '(userCertificate;binary={cert!bin})' --domain ad.example.com
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "simpleADrule"
    -------------------------------------------------------
      Rule name: simpleADrule
      Mapping rule: (userCertificate;binary={cert!bin})
      Matching rule: <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
      Domain name: ad.example.com
      Enabled: TRUE
  3. O System Security Services Daemon (SSSD) relê periodicamente as regras de mapeamento de certificados. Para forçar a regra recém-criada a ser carregada imediatamente, reinicie o SSSD:

    # systemctl restart sssd

43.4. Configuração do mapeamento de certificados se o AD estiver configurado para mapear certificados de usuários para contas de usuários

Esta história de usuário descreve os passos necessários para habilitar o mapeamento de certificados no IdM se a implantação do IdM estiver em confiança com o Active Directory (AD), o usuário é armazenado no AD e a entrada do usuário no AD contém dados de mapeamento de certificados.

Pré-requisitos

  • O usuário não tem uma conta na IdM.
  • O usuário tem uma conta no AD que contém o atributo altSecurityIdentities, o equivalente do AD do atributo IdM certmapdata.
  • O administrador do IdM tem acesso aos dados nos quais a regra de mapeamento de certificados IdM pode ser baseada.

43.4.1. Adicionar uma regra de mapeamento de certificados se o domínio AD confiável estiver configurado para mapear certificados de usuários

43.4.1.1. Adicionando uma regra de mapeamento de certificados na IDM web UI

  1. Entre na IDM web UI como administrador.
  2. Navegue para AuthenticationCertificate Identity Mapping RulesCertificate Identity Mapping Rules.
  3. Clique em Add.

    Figura 43.7. Adicionando uma nova regra de mapeamento de certificados na interface web do IdM

    new certmaprule add
  4. Digite o nome da regra.
  5. Insira a regra de mapeamento. Por exemplo, para fazer a pesquisa AD DC para as entradas Issuer e Subject em qualquer certificado apresentado, e basear sua decisão de autenticar ou não nas informações encontradas nestas duas entradas do certificado apresentado:

    (altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500})
  6. Insira a regra de correspondência. Por exemplo, permitir somente certificados emitidos pelo AD-ROOT-CA do domínio AD.EXAMPLE.COM para autenticar usuários ao IdM:

    <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
  7. Entre no domínio:

    ad.example.com

    Figura 43.8. Regra de mapeamento de certificados se o AD estiver configurado para mapeamento

    certmaprule add details ad map
  8. Clique em Add.
  9. O System Security Services Daemon (SSSD) relê periodicamente as regras de mapeamento de certificados. Para forçar a regra recém-criada a ser carregada imediatamente, reinicie o SSSD no CLI::

    # systemctl restart sssd

43.4.1.2. Adição de uma regra de mapeamento de certificados no IdM CLI

  1. Obter as credenciais do administrador:

    # kinit admin
  2. Insira a regra de mapeamento e a regra de correspondência na qual a regra de mapeamento se baseia. Por exemplo, para fazer a pesquisa AD para as entradas Issuer e Subject em qualquer certificado apresentado, e permitir somente os certificados emitidos pelo AD-ROOT-CA do domínio AD.EXAMPLE.COM:

    # ipa certmaprule-add ad_configured_for_mapping_rule --matchrule '<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' --maprule '(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500})' --domain=ad.example.com
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "ad_configured_for_mapping_rule"
    -------------------------------------------------------
      Rule name: ad_configured_for_mapping_rule
      Mapping rule: (altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500})
      Matching rule: <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
      Domain name: ad.example.com
      Enabled: TRUE
  3. O System Security Services Daemon (SSSD) relê periodicamente as regras de mapeamento de certificados. Para forçar a regra recém-criada a ser carregada imediatamente, reinicie o SSSD:

    # systemctl restart sssd

43.4.2. Verificação dos dados de mapeamento do certificado no lado AD

O atributo altSecurityIdentities é o equivalente ao Active Directory (AD) de certmapdata atributo de usuário no IdM. Ao configurar o mapeamento de certificados no IdM no cenário em que um domínio AD confiável é configurado para mapear certificados de usuários para contas de usuários, o administrador do sistema IdM precisa verificar se o atributo altSecurityIdentities está configurado corretamente nas entradas de usuário no AD.

Para verificar se o AD contém as informações corretas para o usuário armazenado no AD, use o comando ldapsearch.

  • Por exemplo, digite o comando abaixo para verificar com o servidor adserver.ad.example.com que as seguintes condições se aplicam:

    • O atributo altSecurityIdentities é definido na entrada do usuário de ad_user.
    • A regra de fósforo estipula que as seguintes condições são aplicáveis:

      • O certificado que ad_user usa para autenticar para AD foi emitido por AD-ROOT-CA do domínio ad.example.com.
      • O assunto é <S>DC=com,DC=example,DC=ad,CN=Users,CN=ad_user:
    $ ldapsearch -o ldif-wrap=no -LLL -h adserver.ad.example.com \
    -p 389 -D cn=Administrator,cn=users,dc=ad,dc=example,dc=com \
    -W -b cn=users,dc=ad,dc=example,dc=com "(cn=ad_user)" \
    altSecurityIdentities
    Enter LDAP Password:
    dn: CN=ad_user,CN=Users,DC=ad,DC=example,DC=com
    altSecurityIdentities: X509:<I>DC=com,DC=example,DC=ad,CN=AD-ROOT-CA<S>DC=com,DC=example,DC=ad,CN=Users,CN=ad_user

43.5. Configuração de mapeamento de certificados se a entrada do usuário AD não contiver nenhum certificado ou dados de mapeamento

Esta história de usuário descreve os passos necessários para habilitar o mapeamento de certificados no IdM se a implantação do IdM estiver em confiança com o Active Directory (AD), o usuário é armazenado no AD e a entrada do usuário no AD não contém o certificado inteiro nem os dados de mapeamento do certificado.

Pré-requisitos

  • O usuário não tem uma conta na IdM.
  • O usuário tem uma conta no AD que não contém nem o certificado completo nem o atributo altSecurityIdentities, o equivalente do AD do atributo IdM certmapdata.
  • O administrador do IdM tem todo o certificado de usuário do AD para adicionar ao do usuário do AD user ID override no IdM.

43.5.1. Adicionar uma regra de mapeamento de certificados se a entrada do usuário AD não contiver nenhum certificado ou dados de mapeamento

43.5.1.1. Adicionando uma regra de mapeamento de certificados na IDM web UI

  1. Entre na IDM web UI como administrador.
  2. Navegue para AuthenticationCertificate Identity Mapping RulesCertificate Identity Mapping Rules.
  3. Clique em Add.

    Figura 43.9. Adicionando uma nova regra de mapeamento de certificados na interface web do IdM

    new certmaprule add
  4. Digite o nome da regra.
  5. Insira a regra de mapeamento. Ter todo o certificado que é apresentado ao IdM para autenticação em comparação com o certificado armazenado na entrada de substituição do ID do usuário AD no IdM:

    (userCertificate;binary={cert!bin})
  6. Insira a regra de correspondência. Por exemplo, para permitir somente a autenticação de certificados emitidos pelo AD-ROOT-CA do domínio AD.EXAMPLE.COM:

    <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
  7. Digite o nome do domínio. Por exemplo, para pesquisar usuários no domínio ad.example.com:

    Figura 43.10. Regra de mapeamento de certificados para um usuário sem certificado ou dados cartográficos armazenados no AD

    certmaprule add details ad cert
  8. Clique em Add.
  9. O System Security Services Daemon (SSSD) relê periodicamente as regras de mapeamento de certificados. Para forçar a regra recém-criada a ser carregada imediatamente, reinicie o SSSD no CLI:

    # systemctl restart sssd

43.5.1.2. Adição de uma regra de mapeamento de certificados no IdM CLI

  1. Obter as credenciais do administrador:

    # kinit admin
  2. Insira a regra de mapeamento e a regra de correspondência na qual a regra de mapeamento se baseia. Ter todo o certificado que é apresentado para autenticação comparado com o certificado armazenado no ID do usuário, substituindo a entrada do usuário AD no IdM, permitindo somente a autenticação de certificados emitidos pelo AD-ROOT-CA do domínio AD.EXAMPLE.COM:

    # ipa certmaprule-add simpleADrule --matchrule '<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' --maprule '(userCertificate;binary={cert!bin})' --domain ad.example.com
    -------------------------------------------------------
    Added Certificate Identity Mapping Rule "simpleADrule"
    -------------------------------------------------------
      Rule name: simpleADrule
      Mapping rule: (userCertificate;binary={cert!bin})
      Matching rule: <ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com
      Domain name: ad.example.com
      Enabled: TRUE
  3. O System Security Services Daemon (SSSD) relê periodicamente as regras de mapeamento de certificados. Para forçar a regra recém-criada a ser carregada imediatamente, reinicie o SSSD:

    # systemctl restart sssd

43.5.2. Adicionar um certificado à substituição da ID de um usuário AD se a entrada do usuário no AD não contiver nenhum certificado ou dados de mapeamento

43.5.2.1. Adicionando um certificado à substituição da ID de um usuário AD na interface web do IdM

  1. Navegue para IdentityID ViewsDefault Trust View.
  2. Clique em Add.

    Figura 43.11. Adicionando uma nova substituição de ID de usuário na interface web do IdM

    new useridoverride add
  3. No campo User to override, digite ad_user@ad.example.com.
  4. Copie e cole o certificado de ad_user no campo Certificate.

    Figura 43.12. Configurando a substituição do ID de usuário para um usuário AD

    useridoverride add details
  5. Clique em Add.
  6. Opcionalmente, verificar se o usuário e o certificado estão ligados:

    1. Use o utilitário sss_cache para invalidar o registro de ad_user@ad.example.com no cache do SSSD e forçar uma recarga das informações de ad_user@ad.example.com:

      # sss_cache -u ad_user@ad.example.com
    2. Execute o comando ipa certmap-match com o nome do arquivo contendo o certificado do usuário AD:

      # ipa certmap-match ad_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: AD.EXAMPLE.COM
       User logins: ad_user@ad.example.com
      ----------------------------
      Number of entries returned 1
      ----------------------------

      A saída confirma que você tem dados de mapeamento de certificado adicionados a ad_user@ad.example.com e que uma regra de mapeamento correspondente definida em Adicionar uma regra de mapeamento de certificado se a entrada do usuário AD não contiver nenhum certificado ou dados de mapeamento existentes. Isto significa que você pode usar qualquer certificado que corresponda aos dados de mapeamento de certificado definidos para autenticar como ad_user@ad.example.com.

43.5.2.2. Adicionar um certificado à substituição da ID de um usuário AD no CLI do IdM

  1. Obter as credenciais do administrador:

    # kinit admin
  2. Adicione o certificado de ad_user@ad.example.com à conta do usuário usando o comando ipa idoverrideuser-add-cert:

    # CERT=`cat ad_user_cert.pem | tail -n +2| head -n -1 | tr -d '\r\n'\`
    # ipa idoverrideuser-add-cert ad_user@ad.example.com --certificate $CERT
  3. Opcionalmente, verificar se o usuário e o certificado estão ligados:

    1. Use o utilitário sss_cache para invalidar o registro de ad_user@ad.example.com no cache do SSSD e forçar uma recarga das informações de ad_user@ad.example.com:

      # sss_cache -u ad_user@ad.example.com
    2. Execute o comando ipa certmap-match com o nome do arquivo contendo o certificado do usuário AD:

      # ipa certmap-match ad_user_cert.pem
      --------------
      1 user matched
      --------------
       Domain: AD.EXAMPLE.COM
       User logins: ad_user@ad.example.com
      ----------------------------
      Number of entries returned 1
      ----------------------------

      A saída confirma que você tem dados de mapeamento de certificado adicionados a ad_user@ad.example.com e que uma regra de mapeamento correspondente definida em Adicionar uma regra de mapeamento de certificado se a entrada do usuário AD não contiver nenhum certificado ou dados de mapeamento existentes. Isto significa que você pode usar qualquer certificado que corresponda aos dados de mapeamento de certificado definidos para autenticar como ad_user@ad.example.com.

43.6. Combinando várias regras de mapeamento de identidade em uma

Para combinar várias regras de mapeamento de identidade em uma regra combinada, use o caracter | (ou) para preceder as regras de mapeamento individuais, e separe as regras usando parênteses (), por exemplo:

Exemplo de filtro de mapeamento de certificados 1

$ ipa certmaprule-add ad_cert_for_ipa_and_ad_users \ --maprule='(|(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' \ --matchrule='<ISSUER>CN=AD-ROOT-CA,DC=ad,DC=example,DC=com' \ --domain=ad.example.com

No exemplo acima, a definição do filtro na opção --maprule inclui estes critérios:

A definição do filtro na opção --maprule aceita o operador lógico | (ou), para que você possa especificar múltiplos critérios. Neste caso, a regra mapeia todas as contas de usuário que atendam pelo menos um dos critérios.

Exemplo de filtro de mapeamento de certificados 2

$ ipa certmaprule-add ipa_cert_for_ad_users \
  --maprule='(|(userCertificate;binary={cert!bin})(ipacertmapdata=X509:<I>{issuer_dn!nss_x500}<S>{subject_dn!nss_x500})(altSecurityIdentities=X509:<I>{issuer_dn!ad_x500}<S>{subject_dn!ad_x500}))' \
  --matchrule='<ISSUER>CN=Certificate Authority,O=REALM.EXAMPLE.COM' \
  --domain=idm.example.com --domain=ad.example.com

No exemplo acima, a definição do filtro na opção --maprule inclui estes critérios:

A definição do filtro na opção --maprule aceita o operador lógico | (ou), para que você possa especificar múltiplos critérios. Neste caso, a regra mapeia todas as contas de usuário que atendam pelo menos um dos critérios.

Capítulo 44. Configuração da autenticação com um certificado armazenado na área de trabalho de um cliente IdM

Ao configurar o Gerenciamento de Identidade (IdM), os administradores do sistema IdM podem permitir que os usuários se autentiquem na UI web e na interface de linha de comando (CLI) do IdM usando um certificado que uma Autoridade Certificadora (CA) emitiu para os usuários.

O navegador web pode ser executado em um sistema que não faz parte do domínio IdM.

Esta história de usuário fornece instruções sobre como configurar e testar de forma eficaz o logon no Gerenciamento de Identidade da web UI e CLI com um certificado armazenado na área de trabalho de um cliente IdM. Ao seguir esta história de usuário,

Nota

Somente usuários de Gerenciamento de Identidade podem entrar na interface web usando um certificado. Os usuários do Active Directory podem fazer o login com seu nome de usuário e senha.

44.1. Configuração do Servidor de Gerenciamento de Identidade para Autenticação de Certificado na Interface Web

Como administrador de Gerenciamento de Identidade (IdM), você pode permitir que os usuários utilizem certificados para autenticar em seu ambiente IdM.

Procedimento

Como administrador da Administração de Identidade:

  1. Em um servidor de Gerenciamento de Identidade, obtenha privilégios de administrador e crie um script de shell para configurar o servidor.

    1. Execute o comando ipa-advise config-server-for-smart-card-auth e salve sua saída em um arquivo, por exemplo server_certificate_script.sh:

      # kinit admin
      # ipa-advise config-server-for-smart-card-auth > server_certificate_script.sh
    2. Adicione permissões de execução ao arquivo usando o utilitário chmod:

      # chmod x server_certificate_script.sh
  2. Em todos os servidores no domínio da Gestão de Identidade, execute o script server_certificate_script.sh

    1. com o caminho do certificado do IdM Certificate Authority, /etc/ipa/ca.crt, como entrada se o IdM CA for a única autoridade certificadora que emitiu os certificados dos usuários para os quais você deseja habilitar a autenticação do certificado:

      # ./server_certificate_script.sh /etc/ipa/ca.crt
    2. com os caminhos que levam aos certificados CA relevantes como entrada se diferentes CAs externas assinassem os certificados dos usuários para os quais se deseja habilitar a autenticação do certificado:

      # ./server_certificate_script.sh /tmp/ca1.pem /tmp/ca2.pem
Nota

Não se esqueça de executar o script em cada nova réplica que você adicionar ao sistema no futuro se quiser ter autenticação de certificado para usuários habilitados em toda a topologia.

44.2. Solicitar um novo certificado de usuário e exportá-lo para o cliente

Como administrador de Gerenciamento de Identidade (IdM), você pode criar certificados para usuários em seu ambiente IdM e exportá-los para os clientes IdM nos quais você deseja habilitar a autenticação de certificados para usuários.

Nota

Você pode pular esta seção se o usuário que você deseja autenticar usando um certificado já tem um certificado.

Procedimento

  1. Opcionalmente, criar um novo diretório, por exemplo ~/certdb/, e torná-lo um banco de dados temporário de certificados. Quando solicitado, crie uma senha NSS Certificate DB para criptografar as chaves do certificado a ser gerado em uma etapa posterior:

    # mkdir ~/certdb/
    # certutil -N -d ~/certdb/
    Enter a password which will be used to encrypt your keys.
    The password should be at least 8 characters long,
    and should contain at least one non-alphabetic character.
    
    Enter new password:
    Re-enter password:
  2. Criar o pedido de assinatura de certificado (CSR) e redirecionar a saída para um arquivo. Por exemplo, para criar um CSR com o nome certificate_request.csr para um certificado de bit 4096 para o usuário idm_user no reino IDM.EXAMPLE.COM, definindo o apelido das chaves privadas do certificado para idm_user para facilitar a busca, e definindo o assunto para CN=idm_user,O=IDM.EXAMPLE.COM:

    # certutil -R -d ~/certdb/ -a -g 4096 -n idm_user -s "CN=idm_user,O=IDM.EXAMPLE.COM" > certificate_request.csr
  3. Quando solicitado, digite a mesma senha que você digitou ao utilizar certutil para criar o banco de dados temporário. Em seguida, continue digitando randlomly até que lhe seja dito para parar:

    Enter Password or Pin for "NSS Certificate DB":
    
    A random seed must be generated that will be used in the
    creation of your key.  One of the easiest ways to create a
    random seed is to use the timing of keystrokes on a keyboard.
    
    To begin, type keys on the keyboard until this progress meter
    is full.  DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!
    
    
    Continue typing until the progress meter is full:
  4. Submeta o arquivo de pedido de certificado ao servidor. Especificar o Kerberos principal para associar com o certificado recém-emitido, o arquivo de saída para armazenar o certificado e, opcionalmente, o perfil do certificado. Por exemplo, para obter um certificado do perfil IECUserRoles, um perfil com extensão de funções de usuário adicional, para o idm_user@IDM.EXAMPLE.COM principal, e salvá-lo no arquivo ~/idm_user.pem:

    # ipa cert-request certificate_request.csr --principal=idm_user@IDM.EXAMPLE.COM --profile-id=IECUserRoles --certificate-out=~/idm_user.pem
  5. Adicionar o certificado ao banco de dados do NSS. Use a opção -n para definir o mesmo apelido que você usou ao criar o CSR anteriormente, para que o certificado corresponda à chave privada no banco de dados do NSS. A opção -t define o nível de confiança. Para detalhes, consulte a página de manual certutil(1). A opção -i especifica o arquivo do certificado de entrada. Por exemplo, para adicionar ao banco de dados do NSS um certificado com o apelido idm_user que é armazenado no arquivo ~/idm_user.pem no banco de dados ~/certdb/:

    # certutil -A -d ~/certdb/ -n idm_user -t "P,,\i ~/idm_user.pem
  6. Verifique se a chave no banco de dados do NSS não mostra (orphan) como seu apelido. Por exemplo, para verificar se o certificado armazenado no banco de dados ~/certdb/ não é órfão:

    # certutil -K -d ~/certdb/
    < 0> rsa      5ad14d41463b87a095b1896cf0068ccc467df395   NSS Certificate DB:idm_user
  7. Use o comando pk12util para exportar o certificado do banco de dados NSS para o formato PKCS12. Por exemplo, para exportar o certificado com o nickname idm_user do banco de dados /root/certdb NSS para o arquivo ~/idm_user.p12:

    # pk12util -d ~/certdb -o ~/idm_user.p12 -n idm_user
    Enter Password or Pin for "NSS Certificate DB":
    Enter password for PKCS12 file:
    Re-enter password:
    pk12util: PKCS12 EXPORT SUCCESSFUL
  8. Transfira o certificado para o host no qual você deseja que a autenticação do certificado para idm_user seja habilitada:

    # scp ~/idm_user.p12 idm_user@client.idm.example.com:/home/idm_user/
  9. No host para o qual o certificado foi transferido, tornar o diretório no qual o arquivo .pkcs12 é armazenado inacessível ao grupo 'outro' por razões de segurança:

    # chmod o-rwx /home/idm_user/
  10. Por razões de segurança, remova o banco de dados temporário do NSS e o arquivo .pkcs12 do servidor:

    # rm ~/certdb/
    # rm ~/idm_user.p12

44.3. Assegurar que o certificado e o usuário estejam ligados entre si

Nota

Você pode pular esta seção se o certificado do usuário tiver sido emitido pela IDM CA.

Para que a autenticação do certificado funcione, é preciso ter certeza de que o certificado está vinculado ao usuário que o utilizará para autenticar no Gerenciamento de Identidade (IdM).

44.4. Configuração de um navegador para permitir a autenticação de certificados

Para poder autenticar com um certificado ao usar a WebUI para entrar no Gerenciamento de Identidade (IdM), você precisa importar o usuário e os certificados de autoridade de certificado (CA) relevantes para o navegador Mozilla Firefox ou Google Chrome. O próprio host no qual o navegador está rodando não tem que fazer parte do domínio IdM.

IdM suporta os seguintes navegadores para conexão com a WebUI:

  • Mozilla Firefox 38 e posteriores
  • Google Chrome 46 e posteriores

O procedimento seguinte mostra como configurar o navegador Mozilla Firefox 57.0.1.

Pré-requisitos

Procedimento

  1. Abra o Firefox, depois navegue para PreferencesPrivacy & Security.

    Figura 44.1. Seção de Privacidade e Segurança em Preferências

    privacy and security
  2. Clique em Ver Certificados.

    Figura 44.2. Ver Certificados em Privacidade e Segurança

    view certificates
  3. Na guia Your Certificates, clique em Importar. Localize e abra o certificado do usuário no formato PKCS12, depois clique em OK e OK.
  4. Certifique-se de que a Autoridade de Certificado de Gerenciamento de Identidade seja reconhecida pela Firefox como uma autoridade confiável:

    1. Salvar o certificado da IdM CA localmente:

      • Navegue até a IDM web UI escrevendo o nome do seu servidor IdM na barra de endereços do Firefox. Clique em Advanced na página de aviso de conexão insegura.

        Figura 44.3. Conexão insegura

        connection not secure idm
      • Add Exception. Clique View.

        Figura 44.4. Veja os detalhes de um certificado

        view ca certificate idm
      • Na aba Details, destaque os campos Certificate Authority.

        Figura 44.5. Exportação do certificado CA

        exporting ca cert idm
      • Clique em Exportar. Salve o certificado da CA, por exemplo, como o arquivo CertificateAuthority.crt, depois clique em Fechar, e Cancelar.
    2. Importar o certificado IdM CA para a Firefox como um certificado de autoridade certificadora confiável:

      • Abra o Firefox, navegue até Preferências e clique em Privacidade & Segurança.

        Figura 44.6. Seção de Privacidade e Segurança em Preferências

        privacy and security
      • Clique em Ver Certificados.

        Figura 44.7. Ver Certificados em Privacidade e Segurança

        view certificates
      • Na guia Authorities, clique em Importar. Localize e abra o certificado da CA que você salvou no passo anterior no arquivo CertificateAuthority.crt. Confie no certificado para identificar os sites, depois clique em OK e OK.
  5. Continuar a Autenticação à Identity Management Web UI com um Certificado como Usuário de Gerenciamento de Identidade.

44.5. Autenticação para a interface web de gerenciamento de identidade com um certificado como usuário de gerenciamento de identidade

Este procedimento descreve a autenticação como usuário à interface web de Gerenciamento de Identidade (IdM) usando um certificado armazenado na área de trabalho de um cliente de Gerenciamento de Identidade.

Procedimento

  1. No navegador, navegue para a interface web de gerenciamento de identidade, por exemplo, https://server.idm.example.com/ipa/ui.
  2. Clique em Login Usando Certificado.

    .Login Usando Certificado na interface web de Gerenciamento de Identidade

    smart card login
  3. O certificado do usuário já deve ter sido selecionado. Desmarque Lembre-se desta decisão, depois clique em OK.

Agora você está autenticado como o usuário que corresponde ao certificado.

Recursos adicionais

  • Para informações sobre autenticação para a interface web do IdM usando um certificado armazenado em um cartão inteligente, veja

44.6. Configuração de um cliente IdM para permitir a autenticação ao CLI usando um certificado

Para fazer a autenticação do certificado funcionar para um usuário IdM na Interface de Linha de Comando (CLI) de seu cliente IdM, importe o certificado do usuário IdM e a chave privada para o cliente IdM. Para detalhes sobre a criação e transferência do certificado do usuário, veja Seção 44.2, “Solicitar um novo certificado de usuário e exportá-lo para o cliente”.

Procedimento

  • Entre no cliente IdM e tenha o arquivo .p12 contendo o certificado do usuário e a chave privada pronta. Para obter e armazenar em cache o ticket de concessão de bilhetes Kerberos (TGT), execute o comando kinit com o principal do usuário, usando a opção -X com o atributo X509_username:/path/to/file.p12 para especificar onde encontrar as informações de identidade do usuário X509. Por exemplo, para obter o TGT para idm_user usando as informações de identidade do usuário armazenadas no arquivo ~/idm_user.p12:

    $ kinit -X X509_idm_user='PKCS12:~/idm_user.p12' idm_user
    Nota

    O comando também suporta o formato de arquivo .pem kinit -X X509_username='FILE:/path/to/cert.pem,/path/to/key' user_principal

Capítulo 45. Usando o mestre de renovação da IdM CA

45.1. Explicação do mestre de renovação da IdM CA

Em uma implantação de Gerenciamento de Identidade (IdM) que usa uma autoridade de certificado embutida (CA), o servidor mestre de renovação CA mantém e renova os certificados do sistema IdM. Ele garante implantações de IdM ininterruptas.

Os certificados do sistema IdM incluem:

  • IdM CA certificado
  • OCSP assinatura do certificado
  • IdM CA subsystem certificados
  • IdM CA audit signing certificado
  • IdM renewal agent (RA) certificado
  • KRA certificados de transporte e armazenamento

O que caracteriza os certificados de sistema é que suas chaves são compartilhadas por todas as réplicas CA. Em contraste, os certificados de serviço IdM (por exemplo, LDAP, HTTP e PKINIT certificados), têm diferentes pares de chaves e nomes de assunto em diferentes servidores IdM CA.

Na topologia da IdM, por padrão, o primeiro servidor mestre da IdM CA é o mestre da renovação da CA.

Nota

Na documentação a montante, a IdM CA é chamada Dogtag.

O papel do servidor mestre de renovação CA

Os certificados IdM CA, IdM CA subsystem, e IdM RA são cruciais para a implantação da IdM. Cada certificado é armazenado em um banco de dados do NSS no diretório /etc/pki/pki-tomcat/ e também como uma entrada no banco de dados LDAP. O certificado armazenado no LDAP deve corresponder ao certificado armazenado no banco de dados do NSS. Se eles não corresponderem, falhas de autenticação ocorrem entre a estrutura do IdM e o IdM CA, e entre o IdM CA e o LDAP.

Todas as réplicas da IdM CA têm pedidos de rastreamento para cada certificado de sistema. Se uma implantação de IdM com CA integrada não contém um mestre de renovação de CA, cada servidor de IdM CA solicita a renovação de certificados de sistema de forma independente. Isto resulta em diferentes réplicas de CA com vários certificados de sistema e falhas de autenticação ocorrendo.

A nomeação de uma réplica do CA como mestre de renovação permite que os certificados do sistema sejam renovados exatamente uma vez, quando necessário, e assim evita falhas de autenticação.

O papel do certmonger nas réplicas do CA

O serviço certmonger executado em todas as réplicas da IdM CA usa o helper de renovação dogtag-ipa-ca-renew-agent para manter o controle dos certificados do sistema IdM. O programa ajudante de renovação lê a configuração mestre de renovação da CA. Em cada réplica do CA que não é o mestre de renovação do CA, o programa ajudante de renovação recupera os certificados mais recentes do sistema a partir das entradas do ca_renewal LDAP. Devido à não determinação de quando exatamente certmonger tentativas de renovação ocorrem, o ajudante dogtag-ipa-ca-renew-agent às vezes tenta atualizar um certificado de sistema antes que o mestre de renovação da CA tenha realmente renovado o certificado. Se isto acontecer, o certificado antigo, em breve expirado, é devolvido ao certmonger na réplica da CA. O certmonger, percebendo que é o mesmo certificado que já está armazenado em seu banco de dados, continua tentando renovar o certificado com algum atraso entre tentativas individuais até que consiga recuperar o certificado atualizado da mestre de renovação da CA.

O funcionamento correto do mestre de renovação da IdM CA

Uma implantação IdM com uma CA embutida é uma implantação IdM que foi instalada com uma IdM CA - ou cujo servidor mestre IdM CA foi instalado mais tarde. Uma implementação de IdM com uma CA embutida deve ter sempre exatamente uma réplica da CA configurada como o master de renovação. O servidor mestre de renovação deve estar online e totalmente funcional, e deve se replicar corretamente com os outros servidores.

Se o servidor mestre atual de renovação da CA estiver sendo excluído usando os comandos ipa server-del, ipa-replica-manage del, ipa-csreplica-manage del ou ipa-server-install --uninstall, uma réplica da CA é automaticamente atribuída como servidor mestre de renovação da CA. Esta política assegura que a configuração do servidor mestre de renovação permaneça válida.

Esta política não cobre as seguintes situações:

  • Offline renewal master

    • Se o mestre de renovação estiver offline por um período prolongado, ele pode perder uma janela de renovação. Nesta situação, todos os servidores mestre não renovados continuam a reinstalar os certificados do sistema atual até que os certificados expirem. Quando isto ocorre, a implantação do IdM é interrompida porque mesmo um certificado expirado pode causar falhas de renovação para outros certificados. Para evitar esta situação: se seu master de renovação atual estiver offline e indisponível por um período de tempo prolongado, considere a possibilidade de atribuir um novo master de renovação CA manualmente.
  • Replication problems

    • Se existirem problemas de replicação entre o mestre de renovação e outras réplicas CA, a renovação pode ser bem sucedida, mas as outras réplicas CA podem não ser capazes de recuperar os certificados atualizados antes que eles expirem. Para evitar esta situação, certifique-se de que seus acordos de replicação estejam funcionando corretamente. Para obter detalhes, consulte as diretrizes gerais ou específicas de solução de problemas de réplicas no RHEL 7 Linux Domain Identity, Authentication, and Policy Guide.

45.2. Mudando e reiniciando o mestre de renovação do IdM CA

Quando uma autoridade de renovação de certificados (CA) está sendo desativada, a Administração de Identidade (IdM) seleciona automaticamente uma nova autoridade de renovação de CA a partir da lista de servidores da IdM CA. O administrador do sistema não pode influenciar a seleção.

Para poder selecionar o novo servidor mestre de renovação da IdM CA, o administrador do sistema deve realizar a substituição manualmente. Selecionar o master antes de iniciar o processo de desativação do master de renovação atual.

Se a configuração atual do mestre de renovação CA for inválida, reinicie o mestre de renovação do IdM CA.

Complete este procedimento para alterar ou reiniciar o mestre de renovação do CA.

Pré-requisitos

  • Você tem as credenciais do administrador da IdM.

Procedimento

  1. Obter as credenciais do administrador da IdM:

    ~]$ kinit admin
    Password for admin@IDM.EXAMPLE.COM:
  2. Opcionalmente, para descobrir quais servidores IdM na implantação têm o papel de CA necessário para serem elegíveis para se tornar o novo mestre da renovação de CA:

    ~]$ ipa server-role-find --role 'CA server'
    ----------------------
    2 server roles matched
    ----------------------
      Server name: server.idm.example.com
      Role name: CA server
      Role status: enabled
    
      Server name: replica.idm.example.com
      Role name: CA server
      Role status: enabled
    ----------------------------
    Number of entries returned 2
    ----------------------------

    Há dois servidores CA na implantação.

  3. Opcionalmente, para descobrir qual servidor CA é o atual mestre da renovação CA, entre:

    ~]$ ipa config-show | grep 'CA renewal master'
      IPA CA renewal master: server.idm.example.com

    O atual mestre de renovação é server.idm.example.com.

  4. Para alterar a configuração mestre de renovação, use o utilitário ipa config-mod com a opção --ca-renewal-master-server:

    ~]$ ipa config-mod --ca-renewal-master-server replica.idm.example.com | grep 'CA renewal master'
      IPA CA renewal master: replica.idm.example.com
    Importante

    Você também pode mudar para um novo mestre de renovação de CA usando:

    • o comando ipa-cacert-manage --renew. Este comando tanto renova o certificado da CA and faz do servidor da CA no qual se executa o comando o novo mestre de renovação da CA.
    • o comando ipa-cert-fix. Este comando recupera o desdobramento quando certificados vencidos estão causando falhas. Ele também torna o servidor CA no qual se executa o comando o novo mestre de renovação CA.

      Para detalhes, veja Renovação de certificados de sistema expirados quando a IdM está offline.

45.3. Mudando de uma CA externa para uma CA autoassinada em IdM

Complete este procedimento para mudar de um certificado assinado externamente para um certificado autoassinado da autoridade certificadora (CA) da Identity Management (IdM). Com uma CA autoassinada, a renovação do certificado da CA é gerenciada automaticamente: um administrador de sistema não precisa submeter um pedido de assinatura de certificado (CSR) a uma autoridade externa.

A mudança de uma CA assinada externamente para uma CA autoassinada substitui apenas o certificado da CA. Os certificados assinados pela AC anterior ainda são válidos e ainda estão em uso. Por exemplo, a cadeia de certificados para o certificado LDAP permanece inalterada mesmo após a mudança para uma CA autoassinada:

external_CA certificado > IdM CA certificado > LDAP certificado

Pré-requisitos

  • Você tem acesso root ao mestre de renovação da IdM CA.
  • Você tem as credenciais do administrador da IdM.

Procedimento

  1. No mestre de renovação da IdM CA, renovar o certificado da CA como autoassinado:

    ~]# ipa-cacert-manage renew --self-signed
    Renewing CA certificate, please wait
    CA certificate successfully renewed
    The ipa-cacert-manage command was successful
  2. Em todos os servidores e clientes da IdM, atualizar os bancos de dados locais de certificados da IdM com os certificados do servidor:

    [client ~]$ kinit admin
    [client ~]$ ipa-certupdate
    Systemwide CA database updated.
    Systemwide CA database updated.
    The ipa-certupdate command was successful
  3. Opcionalmente, para verificar se sua atualização foi bem sucedida e o novo certificado da CA foi adicionado ao arquivo /etc/ipa/ca.crt:

    [client ~]$ openssl crl2pkcs7 -nocrl -certfile /etc/ipa/ca.crt | openssl pkcs7 -print_certs -text -noout
    [...]
    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number: 39 (0x27)
            Signature Algorithm: sha256WithRSAEncryption
            Issuer: O=IDM.EXAMPLE.COM, CN=Certificate Authority
            Validity
                Not Before: Jul  1 16:32:45 2019 GMT
                Not After : Jul  1 16:32:45 2039 GMT
            Subject: O=IDM.EXAMPLE.COM, CN=Certificate Authority
    [...]

    A saída mostra que a atualização foi bem sucedida, uma vez que o novo certificado da CA é listado com os certificados mais antigos da CA.

45.4. Renovação do mestre de renovação da IdM CA com um certificado assinado externamente

Esta seção descreve como renovar o certificado de autoridade de gerenciamento de identidade (IdM) usando uma CA externa para assinar o pedido de assinatura de certificado (CSR). Nesta configuração, seu servidor IdM CA é uma subCA da CA externa. A CA externa pode, mas não precisa, ser um Servidor de Certificado do Active Directory (AD CS).

Se a autoridade externa do certificado for AD CS, você pode especificar no CSR o modelo que você deseja para o certificado da IdM CA. Um modelo de certificado define as políticas e regras que uma CA usa quando uma solicitação de certificado é recebida. Os modelos de certificado no AD correspondem aos modelos de certificado no IdM.

Você pode definir um modelo específico de AD CS por seu Identificador de Objeto (OID). Os OIDs são valores numéricos únicos emitidos por várias autoridades emissoras para identificar de forma única elementos de dados, sintaxe e outras partes de aplicações distribuídas.

Alternativamente, você pode definir um modelo específico de AD CS pelo seu nome. Por exemplo, o nome do perfil padrão usado em um CSR submetido por uma IDM CA a um AD CS é subCA.

Para definir um perfil especificando seu OID ou nome na RSE, use a opção external-ca-profile. Para detalhes, consulte a página de manual ipa-cacert-manage.

Além de usar um modelo de certificado pronto, você também pode criar um modelo de certificado personalizado no AD CS, e usá-lo no CSR.

Pré-requisitos

  • Você tem acesso root ao mestre de renovação da IdM CA.
  • Você tem as credenciais do administrador da IdM.

Procedimento

Concluir este procedimento para renovar o certificado da IDM CA com assinatura externa, independentemente de o certificado atual da CA ser autoassinado ou assinado externamente.

  1. Criar uma RSE a ser submetida à CA externa:

    • Se a CA externa for um AD CS, use a opção --external-ca-type=ms-cs. Se você quiser um modelo diferente do modelo padrão subCA, especifique-o usando a opção --external-ca-profile:

      ~]# ipa-cacert-manage renew --external-ca --external-ca-type=ms-cs [--external-ca-profile=PROFILE]
      Exporting CA certificate signing request, please wait
      The next step is to get /var/lib/ipa/ca.csr signed by your CA and re-run ipa-cacert-manage as:
      ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate
      The ipa-cacert-manage command was successful
    • Se a CA externa não for um AD CS:

      ~]# ipa-cacert-manage renew --external-ca
      Exporting CA certificate signing request, please wait
      The next step is to get /var/lib/ipa/ca.csr signed by your CA and re-run ipa-cacert-manage as:
      ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate
      The ipa-cacert-manage command was successful

      A saída mostra que foi criada uma RSC e está armazenada no arquivo /var/lib/ipa/ca.csr.

  2. Submeter a RSE localizada em /var/lib/ipa/ca.csr à CA externa. O processo difere dependendo do serviço a ser usado como a CA externa.
  3. Recuperar o certificado emitido e a cadeia de certificados da CA para a CA emissora em uma bolha codificada de base 64, que é:

    • um arquivo PEM se a CA externa não for um AD CS.
    • um certificado Base_64 se a CA externa for um AD CS.

      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.

      Se a CA externa for um AD CS e você tiver submetido o CSR com um modelo conhecido através da janela de gerenciamento da Autoridade de Certificação Microsoft Windows, o AD CS emite o certificado imediatamente e o diálogo Salvar Certificado aparece na interface web do AD CS, perguntando onde salvar o certificado emitido.

  4. Execute o comando ipa-cacert-manage renew novamente, adicionando todos os arquivos de certificados da CA necessários para fornecer uma cadeia completa de certificados. Especifique quantos arquivos você precisar, usando a opção --external-cert-file várias vezes:

    ~]# ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate_1 --external-cert-file=/path/to/external_ca_certificate_2
  5. Em todos os servidores e clientes da IdM, atualizar os bancos de dados locais de certificados da IdM com os certificados do servidor:

    [client ~]$ kinit admin
    [client ~]$ ipa-certupdate
    Systemwide CA database updated.
    Systemwide CA database updated.
    The ipa-certupdate command was successful
  6. Opcionalmente, para verificar se sua atualização foi bem sucedida e o novo certificado da CA foi adicionado ao arquivo /etc/ipa/ca.crt:

    [client ~]$ openssl crl2pkcs7 -nocrl -certfile /etc/ipa/ca.crt | openssl pkcs7 -print_certs -text -noout
    [...]
    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number: 39 (0x27)
            Signature Algorithm: sha256WithRSAEncryption
            Issuer: O=IDM.EXAMPLE.COM, CN=Certificate Authority
            Validity
                Not Before: Jul  1 16:32:45 2019 GMT
                Not After : Jul  1 16:32:45 2039 GMT
            Subject: O=IDM.EXAMPLE.COM, CN=Certificate Authority
    [...]

    A saída mostra que a atualização foi bem sucedida, uma vez que o novo certificado da CA é listado com os certificados mais antigos da CA.

Capítulo 46. Renovação de certificados de sistema expirados quando a IdM está offline

Quando um certificado de sistema expira, o Gerenciamento de Identidade (IdM) não inicia. O IdM suporta a renovação de certificados de sistema quando o IdM está offline, usando a ferramenta ipa-cert-fix.

Pré-requisitos

  • IdM é instalado somente no Red Hat Enterprise Linux 8.1 ou posterior

46.1. Renovação de certificados de sistema expirados em um CA Renewal Master

Esta seção descreve como aplicar a ferramenta ipa-cert-fix em certificados IdM vencidos.

Importante

Se você executar a ferramenta ipa-cert-fix em um host CA (Autoridade Certificadora) que não é o CA Renewal Master, e o utilitário renova certificados compartilhados, esse host se torna automaticamente o novo CA Renewal Master no domínio. Deve haver sempre apenas um CA Renewal Master no domínio para evitar inconsistências.

Pré-requisitos

  • Entrar no servidor com direitos de administração

Procedimento

  1. Iniciar a ferramenta ipa-cert-fix para analisar o sistema e listar os certificados vencidos que requerem renovação:

    # ipa-cert-fix
    ...
    The following certificates will be renewed:
    
    Dogtag sslserver certificate:
      Subject: CN=ca1.example.com,O=EXAMPLE.COM 201905222205
      Serial:  13
      Expires: 2019-05-12 05:55:47
    ...
    Enter "yes" to proceed:
  2. Entre em yes para iniciar o processo de renovação:

    Enter "yes" to proceed: yes
    Proceeding.
    Renewed Dogtag sslserver certificate:
      Subject: CN=ca1.example.com,O=EXAMPLE.COM 201905222205
      Serial:  268369925
      Expires: 2021-08-14 02:19:33
    ...
    
    Becoming renewal master.
    The ipa-cert-fix command was successful

    Pode levar até um minuto antes de ipa-cert-fix renovar todos os certificados vencidos.

  3. Opcionalmente, verifique se todos os serviços estão funcionando agora:

    # ipactl status
    Directory Service: RUNNING
    krb5kdc Service: RUNNING
    kadmin Service: RUNNING
    httpd Service: RUNNING
    ipa-custodia Service: RUNNING
    pki-tomcatd Service: RUNNING
    ipa-otpd Service: RUNNING
    ipa: INFO: The ipactl command was successful

Neste momento, os certificados foram renovados e os serviços estão funcionando. O próximo passo é verificar outros servidores no domínio IdM.

46.2. Verificação de outros servidores IdM no domínio IdM após a renovação

Após a renovação dos certificados do CA Renewal Master com a ferramenta ipa-cert-fix, você deve:

  • Reinicie todos os outros servidores de Gerenciamento de Identidade (IdM) no domínio.
  • Verificar se os certificados certmonger foram renovados.
  • Se houver outras réplicas da Autoridade Certificadora (CA) com certificados de sistema vencidos, renovar esses certificados também com a ferramenta ipa-cert-fix.

Pré-requisitos

  • Faça o login no servidor com direitos de administração.

Procedimento

  1. Reinicie o IdM com o parâmetro --force:

    # reinício do ipactl --force

    Com o parâmetro --force, o utilitário ipactl ignora falhas individuais na inicialização do serviço. Por exemplo, se o servidor também for uma CA com certificados vencidos, o serviço pki-tomcat não inicia. Isto é esperado e ignorado devido ao uso do parâmetro --force.

  2. Após o reinício, verifique se o serviço certmonger renovou os certificados (o status do certificado diz MONITORING):

    # getcert list | egrep '^Request|status:|subject:'
    Request ID '20190522120745':
            status: MONITORING
            subject: CN=IPA RA,O=EXAMPLE.COM 201905222205
    Request ID '20190522120834':
            status: MONITORING
            subject: CN=Certificate Authority,O=EXAMPLE.COM 201905222205
    ...

    Pode levar algum tempo até que certmonger renove os certificados compartilhados na réplica.

  3. Se o servidor também for uma CA, o comando anterior informa CA_UNREACHABLE para o certificado que o serviço pki-tomcat utiliza:

    Request ID '20190522120835':
            status: CA_UNREACHABLE
            subject: CN=ca2.example.com,O=EXAMPLE.COM 201905222205
    ...
  4. Para renovar este certificado, use o utilitário ipa-cert-fix:

    # ipa-cert-fix
    Dogtag sslserver certificate:
      Subject: CN=ca2.example.com,O=EXAMPLE.COM
      Serial:  3
      Expires: 2019-05-11 12:07:11
    
    Enter "yes" to proceed: yes
    Proceeding.
    Renewed Dogtag sslserver certificate:
      Subject: CN=ca2.example.com,O=EXAMPLE.COM 201905222205
      Serial:  15
      Expires: 2019-08-14 04:25:05
    
    The ipa-cert-fix command was successful

Agora, todos os certificados da IdM foram renovados e funcionam corretamente.

Capítulo 47. Geração de CRL no servidor da IdM CA

Se sua implantação de IdM usa uma autoridade de certificado (CA) incorporada, você pode precisar mover a geração da Lista de Revogação de Certificado (CRL) de um servidor de Gerenciamento de Identidade (IdM) para outro. Pode ser necessário, por exemplo, quando você quiser migrar o servidor para outro sistema.

Apenas um servidor deve gerar CRL. A função de geração de CRL é normalmente co-localizada com o mestre de renovação da IdM CA, mas isto não é obrigatório. Antes que o CRL Generation Master seja desativado, um novo CRL Generation Master deve ser selecionado pelo administrador e configurado.

Este capítulo descreve:

  • Parando a geração de CRL no mestre da IdM.
  • Começando a gerar CRL na réplica da IdM.

47.1. Parando a geração de CRL em um servidor IdM

Para parar de gerar a Lista de Revogação de Certificado (CRL) no servidor do editor da IdM CRL, use o comando ipa-crlgen-manage. Antes de desativar a geração, verifique se o servidor realmente gera a CRL. Você pode então desabilitá-la.

Pré-requisitos

  • O servidor de Gerenciamento de Identidade (IdM) é instalado no sistema RHEL 8.1 ou mais recente.
  • Você deve estar logado como raiz.

Procedimento

  1. Verifique se seu servidor está gerando a CRL:

    [root@server ~]# ipa-crlgen-manage status
    CRL generation: enabled
    Last CRL update: 2019-10-31 12:00:00
    Last CRL Number: 6
    The ipa-crlgen-manage command was successful
  2. Pare de gerar a CRL no servidor:

    [root@server ~]# ipa-crlgen-manage disable
    Stopping pki-tomcatd
    Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
    Starting pki-tomcatd
    Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
    Restarting httpd
    CRL generation disabled on the local host. Please make sure to configure CRL generation on another master with ipa-crlgen-manage enable.
    The ipa-crlgen-manage command was successful
  3. Verifique se o servidor parou de gerar CRL:

    [root@server ~]# ipa-crlgen-manage status

O servidor parou de gerar a CRL. O próximo passo é permitir a geração da CRL no novo servidor RHEL 8.

47.2. Início da geração de CRL em um servidor de réplicas IdM

Você pode começar a gerar a Lista de Revogação de Certificado (CRL) em um servidor da IdM CA com o comando ipa-crlgen-manage.

Pré-requisitos

  • O servidor de Gerenciamento de Identidade (IdM) é instalado no sistema RHEL 8.1 ou mais recente.
  • O sistema RHEL deve ser um servidor da Autoridade Certificadora IdM.
  • Você deve estar logado como raiz.

Procedimento

  1. Comece a gerar a CRL:

    [root@replica1 ~]# ipa-crlgen-manage enable
    Stopping pki-tomcatd
    Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
    Starting pki-tomcatd
    Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
    Restarting httpd
    Forcing CRL update
    CRL generation enabled on the local host. Please make sure to have only a single CRL generation master.
    The ipa-crlgen-manage command was successful
  2. Verifique se a CRL é gerada:

    [root@replica1 ~]# 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

Capítulo 48. Obtenção de um certificado IdM para um serviço utilizando o certmonger

48.1. Visão geral da Certmonger

O que faz certmonger

Quando a Gestão de Identidade (IdM) é instalada com uma Autoridade de Certificação IdM (CA) integrada, ela usa o serviço certmonger para rastrear e renovar certificados de sistema e de serviço. Quando o certificado está atingindo sua data de validade, certmonger gerencia o processo de renovação até:

  • regenerando um pedido de assinatura de certificado (CSR) usando as opções fornecidas no pedido original.
  • submetendo o CSR à IdM CA usando o comando IdM API cert-request.
  • recebendo o certificado da IdM CA.
  • executar um comando de pré-venda, se especificado pelo pedido original.
  • instalar o novo certificado no local especificado no pedido de renovação: ou em um banco de dados NSS ou em um arquivo.
  • executar um comando pós-venda, se especificado pelo pedido original. Por exemplo, o comando pós-venda pode instruir certmonger a reiniciar um serviço relevante, para que o serviço pegue o novo certificado.

Tipos de certificados certmonger faixas

Os certificados podem ser divididos em certificados de sistema e de serviço.

Ao contrário dos certificados de serviço (por exemplo, para HTTP, LDAP e PKINIT), que têm diferentes pares de chaves e nomes de assunto em diferentes servidores, os certificados do sistema IdM e suas chaves são compartilhados por todas as réplicas do CA. Os certificados do sistema IdM incluem:

  • IdM CA certificado
  • OCSP assinatura do certificado
  • IdM CA subsystem certificados
  • IdM CA audit signing certificado
  • IdM renewal agent (RA) certificado
  • KRA certificados de transporte e armazenamento

O serviço certmonger rastreia o sistema IdM e certificados de serviço que foram solicitados durante a instalação do ambiente IdM com uma CA integrada. Certmonger também rastreia certificados que foram solicitados manualmente pelo administrador do sistema para outros serviços executados no host do IdM. Certmonger não rastreia certificados externos da CA ou certificados de usuário.

Componentes Certmonger

O serviço certmonger consiste em dois componentes principais:

  • O certmonger daemon, que é o motor que rastreia a lista de certificados e comandos de renovação de lançamento
  • O utilitário getcert para o command-line interface (CLI), que permite ao administrador do sistema enviar comandos ativamente para o daemon certmonger.

Mais especificamente, o administrador do sistema pode usar o utilitário getcert para:

48.2. Obtenção de um certificado IdM para um serviço utilizando o certmonger

Para garantir que a comunicação entre os navegadores e o serviço web executado em seu cliente de Gerenciamento de Identidade (IdM) seja segura e criptografada, use um certificado TLS. Obtenha o certificado TLS para seu serviço web junto à Autoridade de Certificação IdM (CA).

Esta seção descreve como usar certmonger para obter um certificado IdM para um serviço (HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM) executado em um cliente IdM.

Usar certmonger para solicitar o certificado automaticamente significa que certmonger gerencia e renova o certificado quando ele deve ser renovado.

Para uma representação visual do que acontece quando certmonger solicita um certificado de serviço, veja Seção 48.3, “Fluxo de comunicação para o certmonger solicitando um certificado de serviço”.

Pré-requisitos

  • O servidor web está inscrito como cliente da IdM.
  • Você tem acesso root ao cliente IdM no qual você está executando o procedimento.
  • O serviço para o qual você está solicitando um certificado não tem que existir previamente na IdM.

Procedimento

  1. No cliente my_company.idm.example.com IdM no qual o serviço HTTP está funcionando, solicite um certificado para o serviço correspondente ao principal HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM, e especifique que

    • O certificado deve ser armazenado no arquivo local /etc/pki/tls/certs/httpd.pem
    • A chave privada deve ser armazenada no arquivo local /etc/pki/tls/private/httpd.key
    • Que uma extensãoRequest para um SubjectAltName seja adicionada ao pedido de assinatura com o nome DNS de my_company.idm.example.com:

      # ipa-getcert request -K HTTP/my_company.idm.example.com -k /etc/pki/tls/private/httpd.key -f /etc/pki/tls/certs/httpd.pem -g 2048 -D my_company.idm.example.com -C "systemctl restart httpd"
      New signing request "20190604065735" added.

      No comando acima:

      • O comando ipa-getcert request especifica que o certificado deve ser obtido junto à IdM CA. O comando ipa-getcert request é um atalho para getcert request -c IPA.
      • A opção -g especifica o tamanho da chave a ser gerada se ainda não existir uma.
      • A opção -D especifica o valor do DNS SubjectAltName a ser adicionado à solicitação.
      • A opção -C instrui certmonger a reiniciar o serviço httpd após a obtenção do certificado.
      • Para especificar que o certificado seja emitido com um determinado perfil, use a opção -T.
      • Para solicitar um certificado usando o emissor nomeado da CA especificada, use a opção -X ISSUER.
      Nota

      O RHEL 8 utiliza um módulo SSL diferente no Apache do que o utilizado no RHEL 7. O módulo SSL se baseia no OpenSSL e não no NSS. Por este motivo, no RHEL 8 não é possível usar um banco de dados NSS para armazenar o certificado HTTPS e a chave privada.

  2. Opcionalmente, para verificar o status de seu pedido:

    # ipa-getcert list -f /etc/pki/tls/certs/httpd.pem
    Number of certificates and requests being tracked: 3.
    Request ID '20190604065735':
        status: MONITORING
        stuck: no
        key pair storage: type=FILE,location='/etc/pki/tls/private/httpd.key'
        certificate: type=FILE,location='/etc/pki/tls/certs/httpd.crt'
        CA: IPA
    [...]

    A saída mostra que o pedido está no status MONITORING, o que significa que um certificado foi obtido. Os locais do par de chaves e do certificado são aqueles solicitados.

48.3. Fluxo de comunicação para o certmonger solicitando um certificado de serviço

Os diagramas nesta seção mostram as etapas do que acontece quando certmonger solicita um certificado de serviço ao servidor de autoridade de certificado (CA) da Identity Management (IdM). A seqüência consiste nestes diagramas:

Figura 48.1, “Comunicação não criptografada” mostra a situação inicial: sem um certificado HTTPS, a comunicação entre o servidor web e o navegador não está criptografada.

Figura 48.1. Comunicação não criptografada

84 RHEL IdM 0420 1


Figura 48.2, “Certmonger solicitando um certificado de serviço” mostra o administrador do sistema usando certmonger para solicitar manualmente um certificado HTTPS para o servidor web Apache. Observe que ao solicitar um certificado de servidor web, o certificador não se comunica diretamente com a CA. Ele faz proxy através do IdM.

Figura 48.2. Certmonger solicitando um certificado de serviço

84 RHEL IdM 0420 2


Figura 48.3, “IdM CA emitindo o certificado de serviço” mostra uma CA IdM que emite um certificado HTTPS para o servidor web.

Figura 48.3. IdM CA emitindo o certificado de serviço

84 RHEL IdM 0420 3


Figura 48.4, “Certmonger aplicando o certificado de serviço” mostra certmonger colocando o certificado HTTPS em locais apropriados no cliente IdM e, se instruído a fazê-lo, reiniciando o serviço httpd. O servidor Apache posteriormente usa o certificado HTTPS para criptografar o tráfego entre ele e o navegador.

Figura 48.4. Certmonger aplicando o certificado de serviço

84 RHEL IdM 0420 4


Figura 48.5, “Certmonger solicitando um novo certificado quando o antigo está quase expirando” mostra certmonger solicitando automaticamente uma renovação do certificado de serviço da IdM CA antes da expiração do certificado. A IdM CA emite um novo certificado.

Figura 48.5. Certmonger solicitando um novo certificado quando o antigo está quase expirando

84 RHEL IdM 0420 5


48.4. Visualização dos detalhes de um pedido de certificado rastreado pelo certmonger

O serviço certmonger monitora pedidos de certificados. Quando uma solicitação de certificado é assinada com sucesso, resulta em um certificado. Certmonger gerencia as solicitações de certificado incluindo os certificados resultantes. Esta seção descreve como visualizar os detalhes de uma determinada solicitação de certificado gerenciada por certmonger.

Procedimento

  • Se você souber como especificar o pedido de certificado, liste os detalhes apenas daquele pedido de certificado em particular. Você pode, por exemplo, especificar:

    • O ID do pedido
    • A localização do certificado
    • O apelido do certificado

      Por exemplo, para visualizar os detalhes do certificado cujo ID de pedido é 20190408143846, usando a opção -v para visualizar todos os detalhes de erros caso seu pedido de certificado não tenha sido bem sucedido:

      # getcert list -i 20190408143846 -v
      Number of certificates and requests being tracked: 16.
      Request ID '20190408143846':
      	status: MONITORING
      	stuck: no
      	key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-IDM-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt'
      	certificate: type=NSSDB,location='/etc/dirsrv/slapd-IDM-EXAMPLE-COM',nickname='Server-Cert',token='NSS Certificate DB'
      	CA: IPA
      	issuer: CN=Certificate Authority,O=IDM.EXAMPLE.COM
      	subject: CN=r8server.idm.example.com,O=IDM.EXAMPLE.COM
      	expires: 2021-04-08 16:38:47 CEST
      	dns: r8server.idm.example.com
      	principal name: ldap/server.idm.example.com@IDM.EXAMPLE.COM
      	key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
      	eku: id-kp-serverAuth,id-kp-clientAuth
      	pre-save command:
      	post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv IDM-EXAMPLE-COM
      	track: yes
      	auto-renew: yes

    A saída exibe várias informações sobre o certificado, por exemplo:

    • o local do certificado; no exemplo acima, é o banco de dados do NSS no diretório /etc/dirsrv/slapd-IDM-EXAMPLE-COM
    • o apelido do certificado; no exemplo acima, ele é Server-Cert
    • o arquivo que armazena o pino; no exemplo acima, ele é /etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt
    • a Autoridade Certificadora (AC) que será usada para renovar o certificado; no exemplo acima, é a AC IPA
    • a data de expiração; no exemplo acima, é 2021-04-08 16:38:47 CEST
    • o status do certificado; no exemplo acima, o status MONITORING significa que o certificado é válido e está sendo rastreado
    • o comando pós-venda; no exemplo acima, é o reinício do serviço LDAP
  • Se você não souber como especificar o pedido de certificado, liste os detalhes de todos os certificados que certmonger está monitorando ou tentando obter:

    # getcert list

Informações adicionais

  • Para ver as diferentes opções de como especificar o pedido de certificado exibido, consulte a página de manual getcert list.

48.5. Iniciar e parar o rastreamento de certificados

Esta seção descreve como você pode usar os comandos getcert stop-tracking e getcert start-tracking para monitorar os certificados. Os dois comandos são fornecidos pelo serviço certmonger. Habilitar o rastreamento de certificados é especialmente útil se você tiver importado um certificado emitido pela autoridade certificadora (CA) da Identity Management (IdM) para a máquina a partir de um cliente IdM diferente. A habilitação do rastreamento de certificados também pode ser a etapa final do seguinte cenário de provisionamento:

  1. No servidor da IdM, você cria um certificado para um sistema que ainda não existe.
  2. Você cria o novo sistema.
  3. Você cadastra o novo sistema como um cliente IdM.
  4. Você importa o certificado e a chave do servidor da IdM para o cliente da IdM.
  5. Você começa a rastrear o certificado usando certmonger para garantir que ele seja renovado quando estiver para expirar.

Procedimento

  • Para desativar o monitoramento de um certificado com o Request ID de 20190408143846:

    # getcert stop-tracking -i 20190408143846

    Para mais opções, consulte a página de manual getcert stop-tracking.

  • Para permitir o monitoramento de um certificado armazenado no arquivo /tmp/some_cert.crt, cuja chave privada é armazenada no arquivo /tmp/some_key.key:

    # getcert start-tracking -c IPA -f /tmp/some_cert.crt -k /tmp/some_key.key

    Certmonger não pode identificar automaticamente o tipo de CA que emitiu o certificado. Por este motivo, adicione a opção -c com o valor IPA ao comando getcert start-tracking se o certificado tiver sido emitido pela IDM CA. Omitir a adição da opção -c resulta em certmonger entrando no estado NEED_CA.

    Para mais opções, consulte a página de manual getcert start-tracking.

Nota

Os dois comandos não manipulam o certificado. Por exemplo, getcert stop-tracking não apaga o certificado ou o remove do banco de dados do NSS ou do sistema de arquivos, mas simplesmente remove o certificado da lista de certificados monitorados. Da mesma forma, getcert start-tracking apenas adiciona um certificado à lista de certificados monitorados.

48.6. Renovação manual de um certificado

Quando um certificado está próximo de sua data de validade, o daemon certmonger emite automaticamente um comando de renovação usando o helper da autoridade certificadora (CA), obtém um certificado renovado e substitui o certificado anterior pelo novo certificado.

Também é possível renovar manualmente um certificado com antecedência, usando o comando getcert resubmit. Desta forma, você pode atualizar as informações contidas no certificado, por exemplo, adicionando um Nome Alternativo de Assunto (SAN).

Esta seção descreve como renovar um certificado manualmente.

Procedimento

  • Renovar um certificado com o Request ID de 20190408143846:

    # getcert resubmit -i 20190408143846

    Para obter o Request ID para um certificado específico, use o comando getcert list. Para obter detalhes, consulte a página de manual getcert list.

48.7. Fazendo o certmonger retomar o rastreamento de certificados IdM em uma réplica do CA

Este procedimento mostra como fazer certmonger retomar o rastreamento de certificados do sistema de Gerenciamento de Identidade (IdM) que são cruciais para uma implantação de IdM com uma autoridade de certificados integrada após a interrupção do rastreamento de certificados. A interrupção pode ter sido causada pela desconexão do host do IdM durante a renovação dos certificados do sistema ou por uma topologia de replicação que não funciona corretamente. O procedimento também mostra como fazer certmonger retomar o rastreamento dos certificados do serviço IdM, ou seja, os certificados HTTP, LDAP e PKINIT.

Pré-requisitos

  • O host no qual você quer retomar os certificados do sistema de rastreamento é um servidor IdM que também é uma autoridade de certificados IdM (CA), mas não o mestre de renovação IdM CA.

Procedimento

  1. Obtenha o PIN para os certificados do subsistema CA:

    # grep 'internal=' /var/lib/pki/pki-tomcat/conf/password.conf
  2. Adicionar rastreamento aos certificados do subsistema CA, substituindo [internal PIN] nos comandos abaixo pelo PIN obtido na etapa anterior:

    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "caSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "caSigningCert cert-pki-ca"'
    
    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "auditSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca"'
    
    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "ocspSigningCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca"'
    
    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "subsystemCert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca"'
    
    # getcert start-tracking -d /etc/pki/pki-tomcat/alias -n "Server-Cert cert-pki-ca" -c 'dogtag-ipa-ca-renew-agent' -P [internal PIN] -B /usr/libexec/ipa/certmonger/stop_pkicad -C '/usr/libexec/ipa/certmonger/renew_ca_cert "Server-Cert cert-pki-ca"'
  3. Adicione rastreamento para os certificados IdM restantes, os certificados HTTP, LDAP, IPA renewal agent e PKINIT:

    # getcert start-tracking -f /var/lib/ipa/certs/httpd.crt -k /var/lib/ipa/private/httpd.key -p /var/lib/ipa/passwds/idm.example.com-443-RSA -c IPA -C /usr/libexec/ipa/certmonger/restart_httpd
    
    # getcert start-tracking -d /etc/dirsrv/slapd-IDM-EXAMPLE-COM -n "Server-Cert" -c IPA -p /etc/dirsrv/slapd-IDM-EXAMPLE-COM/pwdfile.txt -C '/usr/libexec/ipa/certmonger/restart_dirsrv "IDM-EXAMPLE-COM"'
    
    # getcert start-tracking -f /var/lib/ipa/ra-agent.pem -k /var/lib/ipa/ra-agent.key -c dogtag-ipa-ca-renew-agent -B /usr/libexec/ipa/certmonger/renew_ra_cert_pre -C /usr/libexec/ipa/certmonger/renew_ra_cert
    
    # getcert start-tracking -f /var/kerberos/krb5kdc/kdc.crt -k /var/kerberos/krb5kdc/kdc.key -c dogtag-ipa-ca-renew-agent -B /usr/libexec/ipa/certmonger/renew_ra_cert_pre -C /usr/libexec/ipa/certmonger/renew_kdc_cert
  4. Reinicie certmonger:

    # systemctl restart certmonger
  5. Aguarde um minuto após o início do certmonger e depois verifique os status dos novos certificados:

    # getcert list

Recursos adicionais

  • Se todos os certificados do sistema IdM expiraram, siga o procedimento descrito nesta solução Knowledge Centered Support (KCS) para renovar manualmente os certificados do sistema IdM no master do IdM CA que também é o master de renovação CA e o master de geração CRL. Então, siga o procedimento descrito nesta solução KCS para renovar manualmente os certificados do sistema IdM em todos os outros servidores CA na topologia.

Capítulo 49. Solicitação de certificados usando os papéis do Sistema RHEL

Com o Papel do Sistema de Certificado, você pode usar o Red Hat Ansible Engine para emitir e gerenciar certificados.

Este capítulo cobre os seguintes tópicos:

49.1. O papel do sistema de certificados

Usando a função de Sistema de Certificado, você pode gerenciar a emissão e renovação de certificados TLS e SSL usando o Red Hat Ansible Engine.

O papel usa certmonger como fornecedor de certificados, e atualmente apóia a emissão e renovação de certificados autoassinados e o uso da autoridade de certificação integrada (CA) da IdM.

Você pode usar as seguintes variáveis em seu Livro de Jogadas com o Papel do Sistema de Certificado:

  • certificate_wait para especificar se a tarefa deve aguardar a emissão do certificado.
  • certificate_requests para representar cada certificado a ser emitido e seus parâmetros.

Recursos adicionais

  • Para detalhes sobre os parâmetros usados na variável certificate_requests e informações adicionais sobre a função do sistema certificate, consulte o arquivo /usr/share/ansible/roles/rhel-system-roles.certificate/README.md.
  • Para detalhes sobre as funções do Sistema RHEL e como aplicá-las, consulte Introdução às funções do Sistema RHEL.

49.2. Solicitação de um novo certificado autoassinado usando o Sistema de Certificado Função

Com o Papel do Sistema de Certificado, você pode usar o Red Hat Ansible Engine para emitir certificados autoassinados.

Este processo utiliza o provedor certmonger e solicita o certificado através do comando getcert.

Nota

Por padrão, certmonger tenta automaticamente renovar o certificado antes que ele expire. Você pode desabilitar isto definindo o parâmetro auto_renew no livro de jogo Ansible playbook para no.

Pré-requisitos

  • Você tem o Red Hat Ansible Engine instalado no sistema a partir do qual você deseja executar o playbook.

    Nota

    Você não precisa ter o Ansible instalado nos sistemas nos quais você deseja implantar a solução certificate.

  • Você tem o pacote rhel-system-roles instalado no sistema a partir do qual você deseja executar o playbook.

    Para detalhes sobre as funções do Sistema RHEL e como aplicá-las, consulte Introdução às funções do Sistema RHEL.

Procedimento

  1. Optional: Criar um arquivo de inventário, por exemplo inventory.file:

    inventário.file $ touch
  2. Abra seu arquivo de inventário e defina os anfitriões sobre os quais você deseja solicitar o certificado, por exemplo:

    [webserver]
    server.idm.example.com
  3. Criar um arquivo de playbook, por exemplo request-certificate.yml:

    • Defina hosts para incluir os anfitriões sobre os quais você deseja solicitar o certificado, como webserver.
    • Defina a variável certificate_requests para incluir o seguinte:

      • Ajuste o parâmetro name para o nome desejado do certificado, tal como mycert.
      • Defina o parâmetro dns para o domínio a ser incluído no certificado, tal como *.example.com.
      • Ajustar o parâmetro ca para self-sign.
    • Definir o papel do rhel-system-roles.certificate em roles.

      Este é o arquivo do playbook para este exemplo:

      ---
      - hosts: webserver
      
        vars:
          certificate_requests:
            - name: mycert
              dns: *.example.com
              ca: self-sign
      
        roles:
          - rhel-system-roles.certificate
  4. Salvar o arquivo.
  5. Execute o livro de brincadeiras:

    $ ansible-playbook -i inventory.file request-certificate.yml

Recursos adicionais

  • Para detalhes sobre os parâmetros usados na variável certificate_requests e informações adicionais sobre a função do sistema certificate, consulte o arquivo /usr/share/ansible/roles/rhel-system-roles.certificate/README.md.
  • Para obter detalhes sobre o comando ansible-playbook, consulte a página de manual ansible-playbook(1).

49.3. Solicitação de um novo certificado da IdM CA usando a função de Sistema de Certificado

Com a função de Sistema de Certificado, você pode usar o Red Hat Ansible Engine para emitir certificados enquanto usa um servidor IdM com uma autoridade de certificado integrada (CA). Portanto, você pode gerenciar eficiente e consistentemente a cadeia de confiança de certificados para múltiplos sistemas ao usar o IdM como a CA.

Este processo utiliza o provedor certmonger e solicita o certificado através do comando getcert.

Nota

Por padrão, certmonger tenta automaticamente renovar o certificado antes que ele expire. Você pode desabilitar isto definindo o parâmetro auto_renew no livro de jogo Ansible playbook para no.

Pré-requisitos

  • Você tem o Red Hat Ansible Engine instalado no sistema a partir do qual você deseja executar o playbook.

    Nota

    Você não precisa ter o Ansible instalado nos sistemas nos quais você deseja implantar a solução certificate.

  • Você tem o pacote rhel-system-roles instalado no sistema a partir do qual você deseja executar o playbook.

    Para detalhes sobre as funções do Sistema RHEL e como aplicá-las, consulte Introdução às funções do Sistema RHEL.

Procedimento

  1. Optional: Criar um arquivo de inventário, por exemplo inventory.file:

    inventário.file $ touch
  2. Abra seu arquivo de inventário e defina os anfitriões sobre os quais você deseja solicitar o certificado, por exemplo:

    [webserver]
    server.idm.example.com
  3. Criar um arquivo de playbook, por exemplo request-certificate.yml:

    • Defina hosts para incluir os anfitriões sobre os quais você deseja solicitar o certificado, como webserver.
    • Defina a variável certificate_requests para incluir o seguinte:

      • Ajuste o parâmetro name para o nome desejado do certificado, tal como mycert.
      • Defina o parâmetro dns para o domínio a ser incluído no certificado, tal como www.example.com.
      • Definir o parâmetro principal para especificar o principal Kerberos, tal como HTTP/www.example.com@EXAMPLE.COM.
      • Ajustar o parâmetro ca para ipa.
    • Definir o papel do rhel-system-roles.certificate em roles.

      Este é o arquivo do playbook para este exemplo:

      ---
      - hosts: webserver
        vars:
          certificate_requests:
            - name: mycert
              dns: www.example.com
              principal: HTTP/www.example.com@EXAMPLE.COM
              ca: ipa
      
        roles:
          - rhel-system-roles.certificate
  4. Salvar o arquivo.
  5. Execute o livro de brincadeiras:

    $ ansible-playbook -i inventory.file request-certificate.yml

Recursos adicionais

  • Para detalhes sobre os parâmetros usados na variável certificate_requests e informações adicionais sobre a função do sistema certificate, consulte o arquivo /usr/share/ansible/roles/rhel-system-roles.certificate/README.md.
  • Para obter detalhes sobre o comando ansible-playbook, consulte a página de manual ansible-playbook(1).

49.4. Especificação de comandos para executar antes ou depois da emissão do certificado usando a função do Sistema de Certificado

Com a função de Sistema de Certificado, você pode usar o Red Hat Ansible Engine para executar um comando antes e depois que um certificado seja emitido ou renovado.

No exemplo a seguir, o administrador garante a interrupção do serviço httpd antes que um certificado autoassinado para www.example.com seja emitido ou renovado, e o reinício do serviço posteriormente.

Nota

Por padrão, certmonger tenta automaticamente renovar o certificado antes que ele expire. Você pode desabilitar isto definindo o parâmetro auto_renew no livro de jogo Ansible playbook para no.

Pré-requisitos

  • Você tem o Red Hat Ansible Engine instalado no sistema a partir do qual você deseja executar o playbook.

    Nota

    Você não precisa ter o Ansible instalado nos sistemas nos quais você deseja implantar a solução certificate.

  • Você tem o pacote rhel-system-roles instalado no sistema a partir do qual você deseja executar o playbook.

    Para detalhes sobre as funções do Sistema RHEL e como aplicá-las, consulte Introdução às funções do Sistema RHEL.

Procedimento

  1. Optional: Criar um arquivo de inventário, por exemplo inventory.file:

    inventário.file $ touch
  2. Abra seu arquivo de inventário e defina os anfitriões sobre os quais você deseja solicitar o certificado, por exemplo:

    [webserver]
    server.idm.example.com
  3. Criar um arquivo de playbook, por exemplo request-certificate.yml:

    • Defina hosts para incluir os anfitriões sobre os quais você deseja solicitar o certificado, como webserver.
    • Defina a variável certificate_requests para incluir o seguinte:

      • Ajuste o parâmetro name para o nome desejado do certificado, tal como mycert.
      • Defina o parâmetro dns para o domínio a ser incluído no certificado, tal como www.example.com.
      • Defina o parâmetro ca para a CA que você deseja usar para emitir o certificado, tal como self-sign.
      • Ajuste o parâmetro run_before para o comando que você deseja executar antes da emissão ou renovação deste certificado, tal como systemctl stop httpd.service.
      • Ajuste o parâmetro run_after para o comando que você deseja executar após a emissão ou renovação deste certificado, tal como systemctl start httpd.service.
    • Definir o papel do rhel-system-roles.certificate em roles.

      Este é o arquivo do playbook para este exemplo:

      ---
      - hosts: webserver
        vars:
          certificate_requests:
            - name: mycert
              dns: www.example.com
              ca: self-sign
              run_before: systemctl stop httpd.service
              run_after: systemctl start httpd.service
      
        roles:
          - linux-system-roles.certificate
  4. Salvar o arquivo.
  5. Execute o livro de brincadeiras:

    $ ansible-playbook -i inventory.file request-certificate.yml

Recursos adicionais

  • Para detalhes sobre os parâmetros usados na variável certificate_requests e informações adicionais sobre a função do sistema certificate, consulte o arquivo /usr/share/ansible/roles/rhel-system-roles.certificate/README.md.
  • Para obter detalhes sobre o comando ansible-playbook, consulte a página de manual ansible-playbook(1).

Capítulo 50. Restringindo um pedido de confiança apenas a um subconjunto de certificados

Se sua instalação de Gerenciamento de Identidade (IdM) estiver configurada com a autoridade de certificação (CA) do Sistema de Certificado (CS) integrado, você será capaz de criar sub-CAs leves. Todas as sub-CAs que você criar estão subordinadas à CA primária do sistema de certificado, a CA ipa.

Um lightweight sub-CA neste contexto significa a sub-CA issuing certificates for a specific purpose. Por exemplo, um sub-CA leve permite que você configure um serviço, como um gateway de rede privada virtual (VPN) e um navegador web, para aceitar apenas certificados emitidos por sub-CA A. Ao configurar outros serviços para aceitar certificados emitidos apenas por sub-CA B, você impede que eles aceitem certificados emitidos por sub-CA A, a CA primária, ou seja, a ipa CA, e qualquer sub-CA intermediária entre os dois.

Se você revogar o certificado intermediário de uma sub-CA, todos os certificados emitidos por esta sub-CA são automaticamente considerados inválidos pelos clientes corretamente configurados. Todos os outros certificados emitidos diretamente pela CA raiz, ipa, ou por outra sub-CA, permanecem válidos.

Esta seção usa o exemplo do servidor web Apache para ilustrar como restringir uma aplicação para confiar apenas em um subconjunto de certificados. Complete esta seção para restringir o servidor web executado em seu cliente IdM para usar um certificado emitido pela sub-CA webserver-ca IdM, e para exigir que os usuários se autentiquem ao servidor web usando certificados de usuário emitidos pela sub-CA webclient-ca IdM.

As medidas que você precisa tomar são:

50.1. Criação de um sub-CA leve

Para detalhes sobre a criação de um sub-CA, veja:

50.1.1. Criando um sub-CA da IdM WebUI

Este procedimento descreve como usar IdM WebUI para criar novas sub-CAs com o nome webserver-ca e webclient-ca.

Pré-requisitos

  • Certifique-se de ter obtido as credenciais do administrador.

Procedimento

  1. No menu Authentication, clique em Certificates.
  2. Selecione Certificate Authorities e clique em Add.
  3. Digite o nome da sub-CA webserver-ca. Digite o Subject DN, por exemplo CN=WEBSERVER,O=IDM.EXAMPLE.COM, no campo Subject DN. Observe que o Subject DN deve ser único na infra-estrutura da IdM CA.
  4. Digite o nome da sub-CA webclient-ca. Digite o Subject DN CN=WEBCLIENT,O=IDM.EXAMPLE.COM no campo Subject DN.
  5. Na interface da linha de comando, execute o comando ipa-certupdate para criar um pedido de rastreamento certmonger para os certificados das sub-CAs webserver-ca e webclient-ca:

    [root@ipaserver ~]# ipa-certupdate
    Importante

    Esquecer de executar o comando ipa-certupdate após criar uma sub-CA significa que se o certificado de sub-CA expirar, os certificados de entidade final emitidos pela sub-CA são considerados inválidos mesmo que o certificado de entidade final não tenha expirado.

  6. Opcionalmente, para verificar se o certificado de assinatura do novo sub-CA foi adicionado ao banco de dados do IdM, entre:

    [root@ipaserver ~]# certutil -d /etc/pki/pki-tomcat/alias/ -L
    
    Certificate Nickname                      Trust Attributes
                                              SSL,S/MIME,JAR/XPI
    
    caSigningCert cert-pki-ca                 CTu,Cu,Cu
    Server-Cert cert-pki-ca                   u,u,u
    auditSigningCert cert-pki-ca              u,u,Pu
    caSigningCert cert-pki-ca ba83f324-5e50-4114-b109-acca05d6f1dc u,u,u
    ocspSigningCert cert-pki-ca               u,u,u
    subsystemCert cert-pki-ca                 u,u,u
    Nota

    O novo certificado de sub-CA é transferido automaticamente para todas as réplicas que têm uma instância de sistema de certificado instalada.

50.1.2. Criação de um sub-CA da IdM CLI

Este procedimento descreve como usar o IdM CLI para criar novas sub-CAs com o nome webserver-ca e webclient-ca.

Pré-requisitos

  • Certifique-se de que você obteve as credenciais do administrador.
  • Certifique-se de estar logado em um servidor IdM que seja um servidor CA.

Procedimento

  1. Digite o comando ipa ca-add e especifique o nome da sub-CA webserver-ca e seu Nome Distinto do Assunto (DN):

    [root@ipaserver ~]# ipa ca-add webserver-ca --subject="CN=WEBSERVER,O=IDM.EXAMPLE.COM"
    -------------------
    Created CA "webserver-ca"
    -------------------
      Name: webserver-ca
      Authority ID: ba83f324-5e50-4114-b109-acca05d6f1dc
      Subject DN: CN=WEBSERVER,O=IDM.EXAMPLE.COM
      Issuer DN: CN=Certificate Authority,O=IDM.EXAMPLE.COM
    Nome
    Nome do CA.
    Identificação da autoridade
    Criado automaticamente, identificação individual para a CA.
    Assunto DN
    Nome do Assunto Distinguido (DN). O DN do Assunto deve ser único na infra-estrutura da IdM CA.
    Emissor DN
    A matriz CA que emitiu o certificado de sub-CA. Todas as sub-CAs são criadas como uma criança da raiz do IdM CA.
  2. Criar o sub-CA webclient-ca para emissão de certificados para clientes web:

    [root@ipaserver ~]# ipa ca-add webclient-ca --subject="CN=WEBCLIENT,O=IDM.EXAMPLE.COM"
    -------------------
    Created CA "webclient-ca"
    -------------------
      Name: webclient-ca
      Authority ID: 8a479f3a-0454-4a4d-8ade-fd3b5a54ab2e
      Subject DN: CN=WEBCLIENT,O=IDM.EXAMPLE.COM
      Issuer DN: CN=Certificate Authority,O=IDM.EXAMPLE.COM
  3. Na interface da linha de comando, execute o comando ipa-certupdate para criar um pedido de rastreamento certmonger para os certificados das sub-CAs webserver-ca e webclient-ca:

    [root@ipaserver ~]# ipa-certupdate
    Importante

    Esquecer de executar o comando ipa-certupdate após criar uma sub-CA significa que se o certificado de sub-CA expirar, os certificados de entidade final emitidos pela sub-CA são considerados inválidos mesmo que o certificado de entidade final não tenha expirado.

  4. Opcionalmente, para verificar se o certificado de assinatura do novo sub-CA foi adicionado ao banco de dados do IdM, entre:

    [root@ipaserver ~]# certutil -d /etc/pki/pki-tomcat/alias/ -L
    
    Certificate Nickname                      Trust Attributes
                                              SSL,S/MIME,JAR/XPI
    
    caSigningCert cert-pki-ca                 CTu,Cu,Cu
    Server-Cert cert-pki-ca                   u,u,u
    auditSigningCert cert-pki-ca              u,u,Pu
    caSigningCert cert-pki-ca ba83f324-5e50-4114-b109-acca05d6f1dc u,u,u
    ocspSigningCert cert-pki-ca               u,u,u
    subsystemCert cert-pki-ca                 u,u,u
    Nota

    O novo certificado de sub-CA é transferido automaticamente para todas as réplicas que têm uma instância de sistema de certificado instalada.

50.2. Baixando o certificado de sub-CA da IdM WebUI

Pré-requisitos

  • Certifique-se de que você obteve as credenciais do administrador da IdM.

Procedimento

  1. No menu Authentication, clique em Certificates > Certificates.

    Figura 50.1. sub-CA certificado na lista de certificados

    download sub CA certificate
  2. Clique no número de série do certificado de sub-CA para abrir a página de informações do certificado.
  3. Na página de informações sobre certificados, clique em Actions > Download.
  4. No CLI, mova o certificado de sub-CA para o diretório /etc/pki/tls/private/:

    # mv path/to/the/downloaded/certificate /etc/pki/tls/private/sub-ca.crt

50.3. Criação de CA ACLs para autenticação de servidor web e cliente

As regras da CA ACL (Certificate Authority Access Control List) definem quais perfis podem ser usados para emitir certificados para quais usuários, serviços ou anfitriões. Ao associar perfis, diretores e grupos, as CA ACLs permitem que os diretores ou grupos solicitem certificados usando perfis particulares.

Por exemplo, usando ACLs CA, o administrador pode restringir o uso de um perfil destinado aos funcionários que trabalham a partir de um escritório localizado em Londres apenas aos usuários que são membros do grupo relacionado ao escritório de Londres.

50.3.1. Visualizando ACLs CA em IdM CLI

Complete esta seção para ver a lista de listas de controle de acesso de autoridade de certificados (CA ACLs) disponíveis em sua implantação de IDM e os detalhes de uma CA ACL específica.

Procedimento

  1. Para visualizar todas as ACLs CA em seu ambiente IdM, digite o comando ipa caacl-find:

    $ ipa caacl-find
    -----------------
    1 CA ACL matched
    -----------------
      ACL name: hosts_services_caIPAserviceCert
      Enabled: TRUE
  2. Para ver os detalhes de uma CA ACL, digite o comando ipa caacl-show, e especifique o nome da CA ACL. Por exemplo, para ver os detalhes da CA ACL hosts_services_caIPAserviceCert, digite:

    $ ipa caacl-show hosts_services_caIPAserviceCert
      ACL name: hosts_services_caIPAserviceCert
      Enabled: TRUE
      Host category: all
      Service category: all
      CAs: ipa
      Profiles: caIPAserviceCert
      Users: admin

50.3.2. Criação de uma ACL CA para servidores web autenticados a clientes web usando certificados emitidos por webserver-ca

Esta seção descreve como criar uma ACL CA que requer que o administrador do sistema utilize o sub-CA webserver-ca e o perfil caIPAserviceCert ao solicitar um certificado para o serviço HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM. Se o usuário solicitar um certificado de uma sub-CA diferente ou de um perfil diferente, a solicitação falha. A única exceção é quando há outra CA ACL correspondente que está habilitada. Para visualizar as ACLs CA disponíveis, consulte Visualizando as ACLs CA em IdM CLI.

Pré-requisitos

  • Certifique-se de que o serviço HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM seja parte da IdM.
  • Certifique-se de ter obtido as credenciais do administrador da IdM.

Procedimento

  1. Criar uma CA ACL usando o comando ipa caacl, e especificar seu nome:

    $ ipa caacl-add TLS_web_server_authentication
    --------------------------------------------
    Added CA ACL "TLS_web_server_authentication"
    --------------------------------------------
      ACL name: TLS_web_server_authentication
      Enabled: TRUE
  2. Modificar a CA ACL usando o comando ipa caacl-mod para especificar a descrição da CA ACL:

    $ ipa caacl-mod TLS_web_server_authentication --desc="CAACL for web servers authenticating to web clients using certificates issued by webserver-ca"
    -----------------------------------------------
    Modified CA ACL "TLS_web_server_authentication"
    -----------------------------------------------
      ACL name: TLS_web_server_authentication
      Description: CAACL for web servers authenticating to web clients using certificates issued by webserver-ca
      Enabled: TRUE
  3. Adicione o sub-CA webserver-ca ao CA ACL:

    $ ipa caacl-add-ca TLS_web_server_authentication --ca=webserver-ca
      ACL name: TLS_web_server_authentication
      Description: CAACL for web servers authenticating to web clients using certificates issued by webserver-ca
      Enabled: TRUE
      CAs: webserver-ca
    -------------------------
    Number of members added 1
    -------------------------
  4. Use o ipa caacl-add-service para especificar o serviço cujo diretor poderá solicitar um certificado:

    $ ipa caacl-add-service TLS_web_server_authentication --service=HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM
      ACL name: TLS_web_server_authentication
      Description: CAACL for web servers authenticating to web clients using certificates issued by webserver-ca
      Enabled: TRUE
      CAs: webserver-ca
      Services: HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM
    -------------------------
    Number of members added 1
    -------------------------
  5. Use o comando ipa caacl-add-profile para especificar o modelo de certificado para o certificado solicitado:

    $ ipa caacl-add-profile TLS_web_server_authentication --certprofiles=caIPAserviceCert
      ACL name: TLS_web_server_authentication
      Description: CAACL for web servers authenticating to web clients using certificates issued by webserver-ca
      Enabled: TRUE
      CAs: webserver-ca
      Profiles: caIPAserviceCert
      Services: HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM
    -------------------------
    Number of members added 1
    -------------------------

    Você pode usar imediatamente a ACL recém-criada CA ACL. Ela é habilitada após sua criação por padrão.

Nota

O objetivo dos ACLs CA é especificar quais CA e combinações de perfis são permitidas para pedidos vindos de determinados diretores ou grupos. As CA ACLs não afetam a validação de certificados ou a confiança. Elas não afetam a forma como os certificados emitidos serão utilizados.

50.3.3. Criação de uma ACL CA para navegadores web de usuários autenticados em servidores web usando certificados emitidos pela webclient-ca

Esta seção descreve como criar uma ACL CA que requer que o administrador do sistema utilize o sub-CA webclient-ca e o perfil IECUserRoles ao solicitar um certificado. Se o usuário solicitar um certificado de uma sub-CA diferente ou de um perfil diferente, a solicitação falha. A única exceção é quando há outra CA ACL correspondente que esteja habilitada. Para visualizar as ACLs CA disponíveis, consulte Visualizando as ACLs CA em IdM CLI.

Pré-requisitos

  • Certifique-se de ter obtido as credenciais do administrador da IdM.

Procedimento

  1. Criar uma CA ACL usando o comando ipa caacl e especificar seu nome:

    $ ipa caacl-add TLS_web_client_authentication
    --------------------------------------------
    Added CA ACL "TLS_web_client_authentication"
    --------------------------------------------
      ACL name: TLS_web_client_authentication
      Enabled: TRUE
  2. Modificar a CA ACL usando o comando ipa caacl-mod para especificar a descrição da CA ACL:

    $ ipa caacl-mod TLS_web_client_authentication --desc="CAACL for user web browsers authenticating to web servers using certificates issued by webclient-ca"
    -----------------------------------------------
    Modified CA ACL "TLS_web_client_authentication"
    -----------------------------------------------
      ACL name: TLS_web_client_authentication
      Description: CAACL for user web browsers authenticating to web servers using certificates issued by webclient-ca
      Enabled: TRUE
  3. Adicione o sub-CA webclient-ca ao CA ACL:

    $ ipa caacl-add-ca TLS_web_client_authentication --ca=webclient-ca
      ACL name: TLS_web_client_authentication
      Description: CAACL for user web browsers authenticating to web servers using certificates issued by webclient-ca
      Enabled: TRUE
      CAs: webclient-ca
    -------------------------
    Number of members added 1
    -------------------------
  4. Use o comando ipa caacl-add-profile para especificar o modelo de certificado para o certificado solicitado:

    $ ipa caacl-add-profile TLS_web_client_authentication --certprofiles=IECUserRoles
      ACL name: TLS_web_client_authentication
      Description: CAACL for user web browsers authenticating to web servers using certificates issued by webclient-ca
      Enabled: TRUE
      CAs: webclient-ca
      Profiles: IECUserRoles
    -------------------------
    Number of members added 1
    -------------------------
  5. Modificar a CA ACL usando o comando ipa caacl-mod para especificar que a CA ACL se aplica a todos os usuários da IdM:

    $ ipa caacl-mod TLS_web_client_authentication --usercat=all
    -----------------------------------------------
    Modified CA ACL "TLS_web_client_authentication"
    -----------------------------------------------
      ACL name: TLS_web_client_authentication
      Description: CAACL for user web browsers authenticating to web servers using certificates issued by webclient-ca
      Enabled: TRUE
      User category: all
      CAs: webclient-ca
      Profiles: IECUserRoles

    Você pode usar imediatamente a ACL recém-criada CA ACL. Ela é habilitada após sua criação por padrão.

Nota

O objetivo dos ACLs CA é especificar quais CA e combinações de perfis são permitidas para pedidos vindos de determinados diretores ou grupos. As CA ACLs não afetam a validação de certificados ou a confiança. Elas não afetam a forma como os certificados emitidos serão utilizados.

50.4. Obtenção de um certificado IdM para um serviço utilizando o certmonger

Para garantir que a comunicação entre os navegadores e o serviço web rodando em seu cliente IdM seja segura e criptografada, use um certificado TLS. Se você quiser restringir os navegadores web a certificados de confiança emitidos pela sub-CA webserver-ca, mas nenhuma outra sub-CA da IdM, obtenha o certificado TLS para seu serviço web na sub-CA webserver-ca.

Esta seção descreve como usar certmonger para obter um certificado IdM para um serviço (HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM) executado em um cliente IdM.

Usar certmonger para solicitar o certificado automaticamente significa que certmonger gerencia e renova o certificado quando ele deve ser renovado.

Para uma representação visual do que acontece quando certmonger solicita um certificado de serviço, veja Seção 50.5, “Fluxo de comunicação para o certmonger solicitando um certificado de serviço”.

Pré-requisitos

  • O servidor web está inscrito como cliente da IdM.
  • Você tem acesso root ao cliente IdM no qual você está executando o procedimento.
  • O serviço para o qual você está solicitando um certificado não tem que existir previamente na IdM.

Procedimento

  1. No cliente my_company.idm.example.com IdM no qual o serviço HTTP está funcionando, solicite um certificado para o serviço correspondente ao principal HTTP/my_company.idm.example.com@IDM.EXAMPLE.COM, e especifique que

    • O certificado deve ser armazenado no arquivo local /etc/pki/tls/certs/httpd.pem
    • A chave privada deve ser armazenada no arquivo local /etc/pki/tls/private/httpd.key
    • O sub-CA webserver-ca deve ser a autoridade emissora do certificado
    • Que uma extensãoRequest para um SubjectAltName seja adicionada ao pedido de assinatura com o nome DNS de my_company.idm.example.com:

      # ipa-getcert request -K HTTP/my_company.idm.example.com -k /etc/pki/tls/private/httpd.key -f /etc/pki/tls/certs/httpd.pem -g 2048 -D my_company.idm.example.com -X webserver-ca -C "systemctl restart httpd"
      New signing request "20190604065735" added.

      No comando acima:

      • O comando ipa-getcert request especifica que o certificado deve ser obtido junto à IdM CA. O comando ipa-getcert request é um atalho para getcert request -c IPA.
      • A opção -g especifica o tamanho da chave a ser gerada se ainda não existir uma.
      • A opção -D especifica o valor do DNS SubjectAltName a ser adicionado à solicitação.
      • A opção -X especifica que o emissor do certificado deve ser webserver-ca, e não ipa.
      • A opção -C instrui certmonger a reiniciar o serviço httpd após a obtenção do certificado.
      • Para especificar que o certificado seja emitido com um determinado perfil, use a opção -T.
      Nota

      O RHEL 8 utiliza um módulo SSL diferente no Apache do que o utilizado no RHEL 7. O módulo SSL se baseia no OpenSSL e não no NSS. Por este motivo, no RHEL 8 não é possível usar um banco de dados NSS para armazenar o certificado HTTPS e a chave privada.

  2. Opcionalmente, para verificar o status de seu pedido:

    # ipa-getcert list -f /etc/pki/tls/certs/httpd.pem
    Number of certificates and requests being tracked: 3.
    Request ID '20190604065735':
        status: MONITORING
        stuck: no
        key pair storage: type=FILE,location='/etc/pki/tls/private/httpd.key'
        certificate: type=FILE,location='/etc/pki/tls/certs/httpd.crt'
        CA: IPA
        issuer: CN=WEBSERVER,O=IDM.EXAMPLE.COM
    
    [...]

    A saída mostra que o pedido está no status MONITORING, o que significa que um certificado foi obtido. Os locais do par de chaves e do certificado são aqueles solicitados.

50.5. Fluxo de comunicação para o certmonger solicitando um certificado de serviço

Os diagramas nesta seção mostram as etapas do que acontece quando certmonger solicita um certificado de serviço ao servidor de autoridade de certificado (CA) da Identity Management (IdM). A seqüência consiste nestes diagramas:

Nos diagramas, o sub-CA webserver-ca é representado pelo genérico IdM CA server.

Figura 50.2, “Comunicação não criptografada” mostra a situação inicial: sem um certificado HTTPS, a comunicação entre o servidor web e o navegador não está criptografada.

Figura 50.2. Comunicação não criptografada

84 RHEL IdM 0420 1


Figura 50.3, “Certmonger solicitando um certificado de serviço” mostra o administrador do sistema usando certmonger para solicitar manualmente um certificado HTTPS para o servidor web Apache. Observe que ao solicitar um certificado de servidor web, o certificador não se comunica diretamente com a CA. Ele faz proxy através do IdM.

Figura 50.3. Certmonger solicitando um certificado de serviço

84 RHEL IdM 0420 2


Figura 50.4, “IdM CA emitindo o certificado de serviço” mostra uma CA IdM que emite um certificado HTTPS para o servidor web.

Figura 50.4. IdM CA emitindo o certificado de serviço

84 RHEL IdM 0420 3


Figura 50.5, “Certmonger aplicando o certificado de serviço” mostra certmonger colocando o certificado HTTPS em locais apropriados no cliente IdM e, se instruído a fazê-lo, reiniciando o serviço httpd. O servidor Apache posteriormente usa o certificado HTTPS para criptografar o tráfego entre ele e o navegador.

Figura 50.5. Certmonger aplicando o certificado de serviço

84 RHEL IdM 0420 4


Figura 50.6, “Certmonger solicitando um novo certificado quando o antigo está quase expirando” mostra certmonger solicitando automaticamente uma renovação do certificado de serviço da IdM CA antes da expiração do certificado. A IdM CA emite um novo certificado.

Figura 50.6. Certmonger solicitando um novo certificado quando o antigo está quase expirando

84 RHEL IdM 0420 5


50.6. Configuração de um Servidor HTTP Apache de uma única instância

Esta seção descreve como configurar um Servidor HTTP Apache de uma única instância para servir conteúdo HTML estático.

Siga o procedimento desta seção se o servidor web deve fornecer o mesmo conteúdo para todos os domínios associados com o servidor. Se você quiser fornecer conteúdo diferente para domínios diferentes, estabeleça hosts virtuais baseados em nomes. Para detalhes, consulte Configuração de hosts virtuais baseados em nomes Apache.

Procedimento

  1. Instale o pacote httpd:

    # yum instalar httpd
  2. Abra a porta TCP 80 no firewall local:

    # firewall-cmd --permanent --add-port=80/tcp
    # firewall-cmd --reload
  3. Habilite e inicie o serviço httpd:

    # systemctl enable --now httpd
  4. Opcional: Adicionar arquivos HTML ao diretório /var/www/html/.

    Nota

    Ao adicionar conteúdo a /var/www/html/, arquivos e diretórios devem ser legíveis pelo usuário, sob o qual httpd é executado por padrão. O proprietário do conteúdo pode ser o usuário root e o grupo de usuários root, ou outro usuário ou grupo da escolha do administrador. Se o proprietário do conteúdo for o usuário root e o grupo de usuários root, os arquivos devem ser legíveis por outros usuários. O contexto SELinux para todos os arquivos e diretórios deve ser httpd_sys_content_t, que é aplicado por padrão a todo o conteúdo dentro do diretório /var/www.

Etapas de verificação

  • Conecte-se com um navegador da web a http://my_company.idm.example.com/ ou http://server_IP/.

    Se o diretório /var/www/html/ estiver vazio ou não contiver um arquivo index.html ou index.htm, o Apache exibe o Red Hat Enterprise Linux Test Page. Se /var/www/html/ contém arquivos HTML com um nome diferente, você pode carregá-los inserindo a URL para esse arquivo, como por exemplo http://server_IP/example.html ou http://my_company.idm.example.com/example.html.

Recursos adicionais

  • Para maiores detalhes sobre como configurar o Apache e adaptar o serviço ao seu ambiente, consulte o manual do Apache. Para detalhes sobre a instalação do manual, consulte o manual Instalando o Servidor HTTP Apache.
  • Para detalhes sobre o uso ou ajuste do serviço httpd systemd , consulte a página de manual httpd.service(8).

50.7. Adicionando criptografia TLS a um Servidor HTTP Apache

Esta seção descreve como ativar a criptografia TLS no Servidor HTTP Apache my_company.idm.example.com para o domínio idm.example.com.

Pré-requisitos

  • O Servidor HTTP Apache my_company.idm.example.com está instalado e funcionando.
  • Você obteve o certificado TLS no sub-CA webserver-ca, e o armazenou no arquivo /etc/pki/tls/certs/httpd.pem, conforme descrito em Seção 50.4, “Obtenção de um certificado IdM para um serviço utilizando o certmonger”. Se você usar um caminho diferente, adapte as etapas correspondentes do procedimento.
  • A chave privada correspondente é armazenada no arquivo /etc/pki/tls/private/httpd.key. Se você usar um caminho diferente, adapte as etapas correspondentes do procedimento.
  • O certificado webserver-ca CA é armazenado no arquivo /etc/pki/tls/private/sub-ca.crt. Se você usar um caminho diferente, adapte as etapas correspondentes do procedimento.
  • Os clientes e o servidor web my_company.idm.example.com resolvem o nome do anfitrião do servidor para o endereço IP do servidor web.

Procedimento

  1. Instale o pacote mod_ssl:

    # dnf install mod_ssl
  2. Edite o arquivo /etc/httpd/conf.d/ssl.conf e adicione as seguintes configurações à diretiva <VirtualHost _default_:443>:

    1. Defina o nome do servidor:

      ServerName my_company.idm.example.com
      Importante

      O nome do servidor deve corresponder à entrada definida no campo Common Name do certificado.

    2. Opcional: Se o certificado contiver nomes de host adicionais no campo Subject Alt Names (SAN), você pode configurar mod_ssl para fornecer criptografia TLS também para esses nomes de host. Para configurar isto, adicione o parâmetro ServerAliases com os nomes correspondentes:

      ServerAlias www.my_company.idm.example.com server.my_company.idm.example.com
    3. Defina os caminhos para a chave privada, o certificado do servidor e o certificado da CA:

      SSLCertificateKeyFile "/etc/pki/tls/private/httpd.key"
      SSLCertificateFile "/etc/pki/tls/certs/httpd.pem"
      SSLCACertificateFile "/etc/pki/tls/certs/ca.crt"
  3. Por razões de segurança, configure que somente o usuário root possa acessar o arquivo de chave privada:

    # chown root:root /etc/pki/tls/private/httpd.key
    # chmod 600 //etc/pki/tls/private/httpd.key
    Atenção

    Se a chave privada foi acessada por usuários não autorizados, revogar o certificado, criar uma nova chave privada e solicitar um novo certificado. Caso contrário, a conexão TLS não é mais segura.

  4. Abra a porta 443 no firewall local:

    # firewall-cmd --permanent --add-port=443
    # firewall-cmd --reload
  5. Reinicie o serviço httpd:

    # systemctl restart httpd
    Nota

    Se você protegeu o arquivo de chave privada com uma senha, você deve digitar esta senha toda vez que o serviço httpd for iniciado.

    • Use um navegador e conecte-se a https://my_company.idm.example.com.

Recursos adicionais

  • Para mais detalhes sobre a configuração do TLS, consulte a documentação SSL/TLS Encryption no manual do Apache. Para detalhes sobre a instalação do manual, consulte o manual Instalando o Servidor HTTP Apache.

50.8. Configuração das versões do protocolo TLS suportadas em um Servidor HTTP Apache

Por padrão, o Servidor HTTP Apache no RHEL 8 utiliza a política de criptografia de todo o sistema que define valores seguros padrão, que também são compatíveis com navegadores recentes. Por exemplo, a política DEFAULT define que somente as versões do protocolo TLSv1.2 e TLSv1.3 são habilitadas no Apache.

Esta seção descreve como configurar manualmente quais versões do protocolo TLS seu my_company.idm.example.com Apache HTTP Server suporta. Siga o procedimento se seu ambiente exigir que somente versões específicas do protocolo TLS sejam habilitadas, por exemplo:

  • Se seu ambiente exige que os clientes também possam utilizar o fraco protocolo TLS1 (TLSv1.0) ou TLS1.1.
  • Se você quiser configurar que o Apache suporta apenas o protocolo TLSv1.2 ou TLSv1.3.

Pré-requisitos

Procedimento

  1. Edite o arquivo /etc/httpd/conf/httpd.conf, e adicione a seguinte configuração à diretiva <VirtualHost> para a qual você deseja definir a versão do protocolo TLS. Por exemplo, para habilitar somente o protocolo TLSv1.3:

    SSLProtocol -Todos os TLSv1.3
  2. Reinicie o serviço httpd:

    # systemctl restart httpd

Etapas de verificação

  1. Use o seguinte comando para verificar se o servidor suporta TLSv1.3:

    # openssl s_client -connect example.com:443 -tls1_3
  2. Use o seguinte comando para verificar se o servidor não suporta TLSv1.2:

    # openssl s_client -connect example.com:443 -tls1_2

    Se o servidor não suportar o protocolo, o comando retorna um erro:

    140111600609088:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:ssl/record/rec_layer_s3.c:1543:SSL alert number 70
  3. Opcional: Repetir o comando para outras versões do protocolo TLS.

Recursos adicionais

50.9. Configurando as cifras suportadas em um Servidor HTTP Apache

Por padrão, o Servidor HTTP Apache no RHEL 8 utiliza a política de criptografia de todo o sistema que define valores seguros padrão, que também são compatíveis com navegadores recentes. Para a lista de cifras que a criptografia em todo o sistema permite, veja o arquivo /etc/crypto-policies/back-ends/openssl.config.

Esta seção descreve como configurar manualmente quais cifras o servidor HTTP Apache my_company.idm.example.com suporta. Siga o procedimento se seu ambiente exigir cifras específicas.

Pré-requisitos

Procedimento

  1. Edite o arquivo /etc/httpd/conf/httpd.conf, e adicione o parâmetro SSLCipherSuite à diretiva <VirtualHost> para a qual você deseja definir as cifras TLS:

    SSLCipherSuite "EECDH AESGCM:EDH AESGCM:AES256 EECDH:AES256 EDH:!SHA1:!SHA256"

    Este exemplo permite apenas as cifras EECDH AESGCM, EDH AESGCM, AES256 EECDH e AES256 EDH e desativa todas as cifras que utilizam o código de autenticação de mensagens (MAC) SHA1 e SHA256.

  2. Reinicie o serviço httpd:

    # systemctl restart httpd

Etapas de verificação

  1. Para exibir a lista de cifras que o Servidor HTTP Apache suporta:

    1. Instale o pacote nmap:

      nmap # yum instalar nmap
    2. Use o utilitário nmap para exibir as cifras suportadas:

      # nmap --script ssl-enum-ciphers -p 443 example.com
      ...
      PORT    STATE SERVICE
      443/tcp open  https
      | ssl-enum-ciphers:
      |   TLSv1.2:
      |     ciphers:
      |       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
      |       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
      |       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
      ...

Recursos adicionais

50.10. Configuração da autenticação do certificado de cliente TLS

A autenticação do certificado do cliente permite aos administradores permitir que somente usuários que se autenticam usando um certificado acessem recursos no servidor web my_company.idm.example.com. Esta seção descreve como configurar a autenticação do certificado de cliente para o diretório /var/www/html/Example/.

Importante

Se o servidor my_company.idm.example.com Apache usa o protocolo TLS 1.3, certos clientes requerem configuração adicional. Por exemplo, no Firefox, defina o parâmetro security.tls.enable_post_handshake_auth no menu about:config para true. Para mais detalhes, veja Transport Layer Security versão 1.3 no Red Hat Enterprise Linux 8.

Pré-requisitos

Procedimento

  1. Edite o arquivo /etc/httpd/conf/httpd.conf e adicione as seguintes configurações à diretiva <VirtualHost> para a qual você deseja configurar a autenticação do cliente:

    <Directory "/var/www/html/Example/">
      SSLVerifyClient require
    </Directory>

    A configuração SSLVerifyClient require define que o servidor deve validar com sucesso o certificado do cliente antes que o cliente possa acessar o conteúdo no diretório /var/www/html/Example/.

  2. Reinicie o serviço httpd:

    # systemctl restart httpd

Etapas de verificação

  1. Use o utilitário curl para acessar a URL https://my_company.idm.example.com/Example/ sem autenticação do cliente:

    $ curl https://my_company.idm.example.com/Example/
    curl: (56) OpenSSL SSL_read: error:1409445C:SSL routines:ssl3_read_bytes:tlsv13 alert certificate required, errno 0

    O erro indica que o servidor web my_company.idm.example.com requer uma autenticação de certificado de cliente.

  2. Passe a chave privada e o certificado do cliente, assim como o certificado da CA para curl para acessar a mesma URL com a autenticação do cliente:

    $ enrolado --cacert ca.crt --key client.key --cert client.crt https://my_company.idm.example.com/Example/

    Se a solicitação for bem sucedida, curl exibe o arquivo index.html armazenado no diretório /var/www/html/Example/.

Recursos adicionais

  • Para mais detalhes sobre autenticação de clientes, consulte a documentação mod_ssl Configuration How-To no manual Apache. Para detalhes sobre a instalação do manual, consulte o manual Instalando o Servidor HTTP Apache.

50.11. Solicitar um novo certificado de usuário e exportá-lo para o cliente

Como administrador de Gerenciamento de Identidade (IdM), você pode configurar um servidor web rodando em um cliente IdM para solicitar aos usuários que usam navegadores web para acessar o servidor para autenticar com certificados emitidos por uma sub-CA específica da IdM. Complete esta seção para solicitar um certificado de usuário de uma sub-CA específica de IdM e para exportar o certificado e a chave privada correspondente para o host a partir do qual o usuário deseja acessar o servidor web usando um navegador web. Em seguida, importe o certificado e a chave privada para o navegador.

Procedimento

  1. Opcionalmente, criar um novo diretório, por exemplo ~/certdb/, e torná-lo um banco de dados temporário de certificados. Quando solicitado, crie uma senha NSS Certificate DB para criptografar as chaves do certificado a ser gerado em uma etapa posterior:

    # mkdir ~/certdb/
    # certutil -N -d ~/certdb/
    Enter a password which will be used to encrypt your keys.
    The password should be at least 8 characters long,
    and should contain at least one non-alphabetic character.
    
    Enter new password:
    Re-enter password:
  2. Criar o pedido de assinatura de certificado (CSR) e redirecionar a saída para um arquivo. Por exemplo, para criar um CSR com o nome certificate_request.csr para um certificado de bit 4096 para o usuário idm_user no reino IDM.EXAMPLE.COM, definindo o apelido das chaves privadas do certificado para idm_user para facilitar a busca, e definindo o assunto para CN=idm_user,O=IDM.EXAMPLE.COM:

    # certutil -R -d ~/certdb/ -a -g 4096 -n idm_user -s "CN=idm_user,O=IDM.EXAMPLE.COM" > certificate_request.csr
  3. Quando solicitado, digite a mesma senha que você digitou ao utilizar certutil para criar o banco de dados temporário. Em seguida, continue digitando randlomly até que lhe seja dito para parar:

    Enter Password or Pin for "NSS Certificate DB":
    
    A random seed must be generated that will be used in the
    creation of your key.  One of the easiest ways to create a
    random seed is to use the timing of keystrokes on a keyboard.
    
    To begin, type keys on the keyboard until this progress meter
    is full.  DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!
    
    
    Continue typing until the progress meter is full:
  4. Submeta o arquivo de pedido de certificado ao servidor. Especificar o Kerberos principal para associar com o certificado recém-emitido, o arquivo de saída para armazenar o certificado e, opcionalmente, o perfil do certificado. Especifique a sub-CA do IdM que você deseja emitir o certificado. Por exemplo, para obter um certificado do perfil IECUserRoles, um perfil com extensão de funções de usuário adicional, para o idm_user@IDM.EXAMPLE.COM principal de webclient-ca, e salvar o certificado no arquivo ~/idm_user.pem:

    # ipa cert-request certificate_request.csr --principal=idm_user@IDM.EXAMPLE.COM --profile-id=IECUserRoles --ca=webclient-ca --certificate-out=~/idm_user.pem
  5. Adicionar o certificado ao banco de dados do NSS. Use a opção -n para definir o mesmo apelido que você usou ao criar o CSR anteriormente, para que o certificado corresponda à chave privada no banco de dados do NSS. A opção -t define o nível de confiança. Para detalhes, consulte a página de manual certutil(1). A opção -i especifica o arquivo do certificado de entrada. Por exemplo, para adicionar ao banco de dados do NSS um certificado com o apelido idm_user que é armazenado no arquivo ~/idm_user.pem no banco de dados ~/certdb/:

    # certutil -A -d ~/certdb/ -n idm_user -t "P,,\i ~/idm_user.pem
  6. Verifique se a chave no banco de dados do NSS não mostra (orphan) como seu apelido. Por exemplo, para verificar se o certificado armazenado no banco de dados ~/certdb/ não é órfão:

    # certutil -K -d ~/certdb/
    < 0> rsa      5ad14d41463b87a095b1896cf0068ccc467df395   NSS Certificate DB:idm_user
  7. Use o comando pk12util para exportar o certificado do banco de dados NSS para o formato PKCS12. Por exemplo, para exportar o certificado com o nickname idm_user do banco de dados /root/certdb NSS para o arquivo ~/idm_user.p12:

    # pk12util -d ~/certdb -o ~/idm_user.p12 -n idm_user
    Enter Password or Pin for "NSS Certificate DB":
    Enter password for PKCS12 file:
    Re-enter password:
    pk12util: PKCS12 EXPORT SUCCESSFUL
  8. Transfira o certificado para o host no qual você deseja que a autenticação do certificado para idm_user seja habilitada:

    # scp ~/idm_user.p12 idm_user@client.idm.example.com:/home/idm_user/
  9. No host para o qual o certificado foi transferido, tornar o diretório no qual o arquivo .pkcs12 é armazenado inacessível ao grupo 'outro' por razões de segurança:

    # chmod o-rwx /home/idm_user/
  10. Por razões de segurança, remova o banco de dados temporário do NSS e o arquivo .pkcs12 do servidor:

    # rm ~/certdb/
    # rm ~/idm_user.p12

50.12. Configuração de um navegador para permitir a autenticação de certificados

Para poder autenticar com um certificado ao usar a WebUI para entrar no Gerenciamento de Identidade (IdM), você precisa importar o usuário e os certificados de autoridade de certificado (CA) relevantes para o navegador Mozilla Firefox ou Google Chrome. O próprio host no qual o navegador está rodando não tem que fazer parte do domínio IdM.

IdM suporta os seguintes navegadores para conexão com a WebUI:

  • Mozilla Firefox 38 e posteriores
  • Google Chrome 46 e posteriores

O procedimento seguinte mostra como configurar o navegador Mozilla Firefox 57.0.1.

Pré-requisitos

Procedimento

  1. Abra o Firefox, depois navegue para PreferencesPrivacy & Security.

    Figura 50.7. Seção de Privacidade e Segurança em Preferências

    privacy and security
  2. Clique em Ver Certificados.

    Figura 50.8. Ver Certificados em Privacidade e Segurança

    view certificates
  3. Na guia Your Certificates, clique em Importar. Localize e abra o certificado do usuário no formato PKCS12, depois clique em OK e OK.
  4. Para garantir que seu sub-CA IdM seja reconhecido pela Firefox como uma autoridade de confiança, importe o certificado do sub-CA IdM que você salvou em Seção 50.2, “Baixando o certificado de sub-CA da IdM WebUI” como um certificado de autoridade de confiança:

    1. Abra o Firefox, navegue até Preferências e clique em Privacidade & Segurança.

      Figura 50.9. Seção de Privacidade e Segurança em Preferências

      privacy and security
    2. Clique em Ver Certificados.

      Figura 50.10. Ver Certificados em Privacidade e Segurança

      view certificates
    3. Na guia Authorities, clique em Importar. Localize e abra o certificado de sub-CA. Confie no certificado para identificar os sites, depois clique em OK e OK.

Capítulo 52. Cofre em IdM

Este capítulo descreve os cofres em Gerenciamento de Identidade (IdM). Ele introduz os seguintes tópicos:

52.1. Os abóbadas e seus benefícios

Um cofre é um recurso útil para os usuários do Gerenciamento de Identidade (IdM) que desejam manter todos os seus dados sensíveis armazenados de forma segura, mas convenientemente em um único lugar. Esta seção explica os vários tipos de cofres e seus usos, e qual cofres você deve escolher com base em suas exigências.

Um cofre é um local seguro em (IdM) para armazenar, recuperar, compartilhar e recuperar um segredo. Um segredo é um dado sensível à segurança, geralmente credenciais de autenticação, que somente um grupo limitado de pessoas ou entidades pode acessar. Os segredos incluem, por exemplo:

  • senhas
  • PINs
  • chaves SSH privadas

Um cofre é comparável a um gerenciador de senhas. Assim como um gerenciador de senhas, um cofre normalmente requer que um usuário gere e lembre uma senha mestra para desbloquear e acessar qualquer informação armazenada no cofre. Entretanto, um usuário também pode decidir por ter um cofre padrão. Um cofre padrão não exige que o usuário insira qualquer senha para acessar os segredos armazenados no cofre.

Nota

O objetivo dos cofres na IdM é armazenar credenciais de autenticação que permitem autenticar para serviços externos não relacionados à IdM.

Outras características importantes dos cofres da IdM são:

  • Os cofres só são acessíveis ao proprietário do cofre e aos usuários da IdM que o proprietário do cofre seleciona para serem os membros do cofre. Além disso, o administrador da IdM tem acesso ao cofre.
  • Se um usuário não tem privilégios suficientes para criar um cofre, um administrador da IdM pode criar o cofre e definir o usuário como seu proprietário.
  • Os usuários e serviços podem acessar os segredos armazenados em um cofre a partir de qualquer máquina registrada no domínio da IdM.
  • Um cofre só pode conter um segredo, por exemplo, um arquivo. Entretanto, o arquivo em si pode conter vários segredos, como senhas, chaves ou certificados.
Nota

O cofre só está disponível a partir da linha de comando IdM (CLI), e não a partir da interface Web da IdM.

52.2. Proprietários, membros e administradores de abóbadas

O Gerenciamento de Identidade (IdM) distingue os seguintes tipos de usuários de abóbadas:

Proprietário do cofre

O proprietário de um cofre é um usuário ou serviço com privilégios básicos de gerenciamento sobre o cofre. Por exemplo, o proprietário de um cofre pode modificar as propriedades do cofre ou adicionar novos membros ao cofre.

Cada cofre deve ter pelo menos um proprietário. Um cofre também pode ter vários proprietários.

Membro da Caixa-forte
Um membro do cofre é um usuário ou serviço que pode acessar um cofre criado por outro usuário ou serviço.
Administrador do cofre

Os administradores de cofres têm acesso irrestrito a todos os cofres e estão autorizados a realizar todas as operações de cofres.

Nota

Os cofres simétricos e assimétricos são protegidos com uma senha ou chave e aplicam regras especiais de controle de acesso (ver Tipos de cofres). O administrador deve atender a estas regras:

  • Segredos de acesso em abóbadas simétricas e assimétricas.
  • Alterar ou redefinir a senha ou chave do cofre.

Um administrador de cofre é qualquer usuário com o privilégio Vault Administrators. No contexto do controle de acesso baseado em funções (RBAC) na IdM, um privilégio é um grupo de permissões que você pode aplicar a uma função.

Usuário da Caixa-forte

O usuário do cofre representa o usuário em cujo container o cofre está localizado. A informação Vault user é exibida na saída de comandos específicos, tais como ipa vault-show:

$ ipa vault-show my_vault
  Vault name: my_vault
  Type: standard
  Owner users: user
  Vault user: user

Para obter detalhes sobre os contêineres abobadados e os cofres do usuário, consulte Contêineres abobadados.

Recursos adicionais

52.3. Abóbadas padrão, simétricas e assimétricas

Com base no nível de segurança e controle de acesso, IdM classifica os cofres nos seguintes tipos:

Abóbadas padrão
Os proprietários e membros do cofre podem arquivar e recuperar os segredos sem ter que usar uma senha ou chave.
Cofres simétricos
Os segredos no cofre são protegidos com uma chave simétrica. Os proprietários e membros do cofre podem arquivar e recuperar os segredos, mas eles devem fornecer a senha do cofre.
Cofres assimétricos
Os segredos no cofre são protegidos com uma chave assimétrica. Os usuários arquivam o segredo usando uma chave pública e o recuperam usando uma chave privada. Os membros do cofre só podem arquivar segredos, enquanto os donos do cofre podem fazer ambos, arquivar e recuperar os segredos.

52.4. Cofre para usuários, serviços e cofres compartilhados

Com base na propriedade, IdM classifica os cofres em vários tipos. A tabela abaixo contém informações sobre cada tipo, seu proprietário e uso.

Tabela 52.1. Cofres IdM baseados na propriedade

TipoDescriçãoProprietárioNota

User vault

Um cofre particular para um usuário

Um único usuário

Qualquer usuário pode possuir um ou mais cofres de usuário se permitido pelo administrador da IdM

Service vault

Um cofre privado para um serviço

Um único serviço

Qualquer serviço pode possuir um ou mais cofres de usuário, se permitido pelo administrador da IdM

Shared vault

Um cofre compartilhado por vários usuários e serviços

O administrador do cofre que criou o cofre

Os usuários e serviços podem possuir um ou mais cofres de usuários, se permitido pelo administrador da IdM. Os administradores do cofre além daquele que criou o cofre também têm acesso total ao cofre.

52.5. Contentores abobadados

Um recipiente abobadado é uma coleção de abóbadas. A tabela abaixo lista as abóbadas padrão que a Gestão de Identidade (IdM) fornece.

Tabela 52.2. Contêineres padrão em IdM

TipoDescriçãoObjetivo

Container do usuário

Um contêiner privado para um usuário

Armazena cofres de usuários para um determinado usuário

Recipiente de serviço

Um container privado para um serviço

Armazena cofres de serviço para um determinado serviço

Container compartilhado

Um contêiner para múltiplos usuários e serviços

Armazena cofres que podem ser compartilhados por múltiplos usuários ou serviços

IdM cria automaticamente containers de usuário e serviço para cada usuário ou serviço quando o primeiro cofre privado para o usuário ou serviço é criado. Depois que o usuário ou serviço é excluído, o IdM remove o container e seu conteúdo.

52.6. Comandos básicos do cofre IdM

Esta seção descreve os comandos básicos que você pode usar para gerenciar os cofres de Gerenciamento de Identidade (IdM). A tabela abaixo contém uma lista de comandos ipa vault-* com a explicação de seu propósito.

Nota

Antes de executar qualquer comando ipa vault-*, instale o componente do sistema de certificado da Key Recovery Authority (KRA) em um ou mais servidores em seu domínio IdM. Para detalhes, consulte Instalando a Autoridade de Recuperação de Chaves no IdM.

Tabela 52.3. Comandos básicos do Cofre de IdM com explicações

ComandoObjetivo

ipa help vault

Exibe informações conceituais sobre cofres do IdM e exemplos de comandos de cofres.

ipa vault-add --help, ipa vault-find --help

Adicionar a opção --help a um comando específico ipa vault-* exibe as opções e a ajuda detalhada disponível para esse comando.

ipa vault-show user_vault --user idm_user

Ao acessar um cofre como membro do cofre, você deve especificar o proprietário do cofre. Se você não especificar o proprietário do cofre, a IdM o informa que não encontrou o cofre:

[admin@server ~]$ ipa vault-show user_vault
ipa: ERROR: user_vault: vault not found

ipa vault-show shared_vault --shared

Ao acessar um cofre compartilhado, você deve especificar que o cofre que você deseja acessar é um cofre compartilhado. Caso contrário, a IdM o informa que não encontrou o cofre:

[admin@server ~]$ ipa vault-show shared_vault
ipa: ERROR: shared_vault: vault not found

52.7. Instalando a Autoridade de Recuperação de Chaves na IdM

Esta seção descreve como você pode habilitar cofres no Gerenciamento de Identidade (IdM) instalando o componente Sistema de Certificado de Autoridade de Recuperação de Chaves (KRA) (CS).

Pré-requisitos

  • Você está logado como administrador da IdM.
  • Você está logado como root em um cliente IdM.

Procedimento

  • Instalar o KRA:

    # ipa-kra-install
Nota

Para tornar o serviço de cofre altamente disponível, instale o KRA em dois servidores IdM ou mais.

Capítulo 53. Usando os cofres do usuário IdM: armazenando e recuperando segredos

Este capítulo descreve como utilizar os cofres dos usuários na Gestão da Identidade. Especificamente, descreve como um usuário pode armazenar um segredo em um cofre de IdM e como o usuário pode recuperá-lo. O usuário pode fazer o armazenamento e a recuperação a partir de dois clientes diferentes de IdM.

Pré-requisitos

53.1. Armazenando um segredo em um cofre de usuário

Esta seção mostra como um usuário pode criar um container com um ou mais cofres privados para armazenar com segurança arquivos com informações sensíveis. No exemplo utilizado no procedimento abaixo, o usuário idm_user cria um cofre do tipo padrão. O tipo de cofre padrão garante que idm_user não será obrigado a autenticar ao acessar o arquivo. idm_user será capaz de recuperar o arquivo de qualquer cliente IdM no qual o usuário esteja logado.

No procedimento:

  • idm_user é o usuário que deseja criar o cofre.
  • my_vault é o cofre usado para armazenar o certificado do usuário.
  • O tipo de cofre é standard, de modo que o acesso ao certificado arquivado não exige que o usuário forneça uma senha do cofre.
  • secret.txt é o arquivo que contém o certificado que o usuário deseja armazenar no cofre.

Pré-requisitos

  • Você sabe a senha do site idm_user.
  • Você está logado em um host que é cliente da IdM.

Procedimento

  1. Obter o bilhete de concessão do bilhete Kerberos (TGT) para idm_user:

    $ kinit idm_user
  2. Use o comando ipa vault-add com a opção --type standard para criar um cofre padrão:

    $ ipa vault-add my_vault --type standard
    ----------------------
    Added vault "my_vault"
    ----------------------
      Vault name: my_vault
      Type: standard
      Owner users: idm_user
      Vault user: idm_user
    Importante

    Certifique-se de que o primeiro cofre para um usuário seja criado pelo mesmo usuário. A criação do primeiro cofre para um usuário também cria o recipiente do cofre do usuário. O agente da criação torna-se o proprietário do contêiner do cofre.

    Por exemplo, se outro usuário, como admin, criar o primeiro cofre de usuário para user1, o proprietário do cofre do usuário também será admin, e user1 não poderá acessar o cofre do usuário ou criar novos cofres de usuário.

  3. Use o comando ipa vault-archive com a opção --in para arquivar o arquivo secret.txt no cofre:

    $ ipa vault-archive my_vault --in secret.txt
    -----------------------------------
    Archived data into vault "my_vault"
    -----------------------------------

53.2. Recuperando um segredo de um cofre de usuário

Como um Gerenciamento de Identidade (IdM), você pode recuperar um segredo de seu cofre particular de usuário em qualquer cliente IdM no qual você esteja logado.

Esta seção mostra como recuperar, como um usuário IdM chamado idm_user, um segredo do cofre privado do usuário chamado my_vault em idm_client.idm.example.com.

Pré-requisitos

  • idm_user é o proprietário de my_vault.
  • idm_user arquivou um segredo na caixa-forte.
  • my_vault é um cofre padrão, o que significa que idm_user não tem que digitar nenhuma senha para acessar o conteúdo do cofre.

Procedimento

  1. SSH para idm_client como idm_user:

    $ ssh idm_user@idm_client.idm.example.com
  2. Faça o login como idm_user:

    $ kinit user
  3. Use o comando ipa vault-retrieve --out com a opção --out para recuperar o conteúdo do cofre e salvá-lo no arquivo secret_exported.txt.

    $ ipa vault-retrieve my_vault --out secret_exported.txt
    --------------------------------------
    Retrieved data from vault "my_vault"
    --------------------------------------

Recursos adicionais

Capítulo 54. Usando Ansible to manage IdM user vaults: armazenando e recuperando segredos

Este capítulo descreve como gerenciar os cofres dos usuários em Gerenciamento de Identidade usando o módulo vault. Especificamente, ele descreve como um usuário pode usar os livros de exercícios Ansible para realizar as três seguintes ações consecutivas:

O usuário pode fazer o armazenamento e a recuperação a partir de dois clientes diferentes da IdM.

Pré-requisitos

54.1. Garantindo a presença de um cofre de usuário padrão na IdM usando Ansible

Esta seção mostra como um usuário de Gerenciamento de Identidade (IdM) pode usar um Livro de Jogadas Ansioso para criar um container com um ou mais cofres privados para armazenar informações sensíveis com segurança. No exemplo utilizado no procedimento abaixo, o usuário idm_user cria um cofre do tipo padrão chamado my_vault. O tipo de cofre padrão garante que idm_user não será necessário autenticar ao acessar o arquivo. idm_user será capaz de recuperar o arquivo de qualquer cliente IdM no qual o usuário esteja logado.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible, ou seja, o host no qual você executa as etapas do procedimento.
  • Você sabe a senha do site idm_user.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/vault:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. Criar um arquivo de inventário, por exemplo inventory.file:

    $ touch inventory.file
  3. Abra inventory.file e defina o servidor IdM que você deseja configurar na seção [ipaserver]. Por exemplo, para instruir a Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  4. Faça uma cópia do arquivo do livro de jogo ensure-standard-vault-is-present.yml. Por exemplo:

    $ cp ensure-standard-vault-is-present.yml ensure-standard-vault-is-present-copy.yml
  5. Abra o arquivo ensure-standard-vault-is-present-copy.yml para edição.
  6. Adapte o arquivo definindo as seguintes variáveis na seção de tarefas ipavault:

    • Defina a variável ipaadmin_principal para idm_user.
    • Defina a variável ipaadmin_password com a senha de idm_user.
    • Defina a variável user para idm_user.
    • Defina a variável name para my_vault.
    • Defina a variável vault_type para standard.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Tests
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      - ipavault:
          ipaadmin_principal: idm_user
          ipaadmin_password: idm_user_password
          user: idm_user
          name: my_vault
          vault_type: standard
  7. Salvar o arquivo.
  8. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file ensure-standard-vault-is-present-copy.yml

54.2. Arquivando um segredo em um cofre de usuário padrão na IdM usando o Ansible

Esta seção mostra como um usuário de Gerenciamento de Identidade (IdM) pode usar um Livro de Jogadas Ansivel para armazenar informações sensíveis em um cofre pessoal. No exemplo utilizado, o usuário idm_user arquiva um arquivo com informações sensíveis chamado password.txt em um cofre chamado my_vault.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible, ou seja, o host no qual você executa as etapas do procedimento.
  • Você sabe a senha do site idm_user.
  • idm_user é o proprietário, ou pelo menos um usuário membro de my_vault.
  • Você tem acesso a password.txt, o segredo que você quer arquivar em my_vault.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/vault:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. Abra seu arquivo de inventário e certifique-se de que o servidor IdM que você deseja configurar esteja listado na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo data-archive-in-symmetric-vault.yml. Substitua "symmetric" por "standard". Por exemplo:

    $ cp data-archive-in-symmetric-vault.yml data-archive-in-standard-vault-copy.yml
  4. Abra o arquivo data-archive-in-standard-vault-copy.yml para edição.
  5. Adapte o arquivo definindo as seguintes variáveis na seção de tarefas ipavault:

    • Defina a variável ipaadmin_principal para idm_user.
    • Defina a variável ipaadmin_password com a senha de idm_user.
    • Defina a variável user para idm_user.
    • Defina a variável name para my_vault.
    • Defina a variável in para o caminho completo para o arquivo com informações sensíveis.
    • Defina a variável action para member.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Tests
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      - ipavault:
          ipaadmin_principal: idm_user
          ipaadmin_password: idm_user_password
          user: idm_user
          name: my_vault
          in: /usr/share/doc/ansible-freeipa/playbooks/vault/password.txt
          action: member
  6. Salvar o arquivo.
  7. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file data-archive-in-standard-vault-copy.yml

54.3. Recuperando um segredo de um cofre de usuário padrão na IdM usando o Ansible

Esta seção mostra como um usuário de Gerenciamento de Identidade (IdM) pode usar um Livro de Jogadas Ansivel para recuperar um segredo do cofre pessoal do usuário. No exemplo utilizado no procedimento abaixo, o usuário idm_user recupera um arquivo com dados confidenciais de um cofre do tipo padrão chamado my_vault em um cliente IdM chamado host01. idm_user não precisa se autenticar ao acessar o arquivo. idm_user pode usar o Ansible para recuperar o arquivo de qualquer cliente IdM no qual o Ansible esteja instalado.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible. Este é o host no qual você executa as etapas do procedimento.
  • Você sabe a senha do site idm_user.
  • idm_user é o proprietário de my_vault.
  • idm_user guardou um segredo em my_vault.
  • Ansible pode escrever no diretório no host do IdM no qual você quer recuperar o segredo.
  • idm_user pode ler a partir do diretório no host do IdM no qual você quer recuperar o segredo.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/vault:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. Abra seu arquivo de inventário e mencione, em uma seção claramente definida, o cliente IdM no qual você quer recuperar o segredo. Por exemplo, para instruir a Ansible a recuperar o segredo em host01.idm.example.com, entre:

    [ipahost]
    host01.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo retrive-data-symmetric-vault.yml. Substitua "simétrico" por "padrão". Por exemplo:

    $ cp retrive-data-symmetric-vault.yml retrieve-data-standard-vault.yml-copy.yml
  4. Abra o arquivo retrieve-data-standard-vault.yml-copy.yml para edição.
  5. Adapte o arquivo, definindo a variável hosts para ipahost.
  6. Adapte o arquivo definindo as seguintes variáveis na seção de tarefas ipavault:

    • Defina a variável ipaadmin_principal para idm_user.
    • Defina a variável ipaadmin_password com a senha de idm_user.
    • Defina a variável user para idm_user.
    • Defina a variável name para my_vault.
    • Defina a variável out para o caminho completo do arquivo para o qual você deseja exportar o segredo.
    • Defina a variável state para retrieved.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Tests
      hosts: ipahost
      become: true
      gather_facts: false
    
      tasks:
      - ipavault:
          ipaadmin_principal: idm_user
          ipaadmin_password: idm_user_password
          user: idm_user
          name: my_vault
          out: /tmp/password_exported.txt
          state: retrieved
  7. Salvar o arquivo.
  8. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file retrieve-data-standard-vault.yml-copy.yml

Etapas de verificação

  1. SSH a host01 como user01:

    $ ssh user01@host01.idm.example.com
  2. Veja o arquivo especificado pela variável out no arquivo do Ansible playbook:

    $ vim /tmp/password_exported.txt

Agora você pode ver o segredo exportado.

  • Para mais informações sobre o uso do Ansible to manage IdM vaults and user secrets e sobre variáveis de playbook, consulte o arquivo README-vault.md Markdown disponível no diretório /usr/share/doc/ansible-freeipa/ e os exemplos de playbooks disponíveis no diretório /usr/share/doc/ansible-freeipa/playbooks/vault/.

Capítulo 55. Gerenciamento de segredos de serviço IdM: armazenamento e recuperação de segredos

Esta seção mostra como um administrador pode usar o módulo ansible-freeipa vault para armazenar com segurança um segredo de serviço em um local centralizado. O cofre utilizado no exemplo é assimétrico, o que significa que, para utilizá-lo, o administrador precisa realizar os seguintes passos:

  1. Gerar uma chave privada usando, por exemplo, o utilitário openssl.
  2. Gerar uma chave pública com base na chave privada.

O segredo do serviço é criptografado com a chave pública quando um administrador o arquiva no cofre. Em seguida, uma instância de serviço hospedada em uma máquina específica no domínio recupera o segredo usando a chave privada. Somente o serviço e o administrador têm permissão para acessar o segredo.

Se o segredo for comprometido, o administrador pode substituí-lo no cofre de serviço e depois redistribuí-lo para aquelas instâncias de serviço individuais que não foram comprometidas.

Pré-requisitos

Esta seção inclui estes procedimentos

Terminologia utilizada

Nos procedimentos:

  • admin é o administrador que administra a senha de serviço.
  • private-key-to-an-externally-signed-certificate.pem é o arquivo que contém o segredo do serviço, neste caso uma chave privada para um certificado assinado externamente. Não confunda esta chave privada com a chave privada utilizada para recuperar o segredo do cofre.
  • secret_vault é o cofre criado para o serviço.
  • HTTP/webserver.idm.example.com é o serviço cujo segredo está sendo arquivado.
  • service-public.pem é a chave pública de serviço utilizada para criptografar a senha armazenada em password_vault.
  • service-private.pem é a chave privada de serviço utilizada para decifrar a senha armazenada em secret_vault.

55.1. Armazenando um segredo de serviço IdM em um cofre assimétrico

Esta seção descreve como criar um cofre assimétrico e usá-lo para arquivar um segredo de serviço.

Pré-requisitos

  • Você sabe a senha do administrador da IdM.

Procedimento

  1. Faça o login como administrador:

    $ kinit admin
  2. Obter a chave pública da instância de serviço. Por exemplo, utilizando a utilidade openssl:

    1. Gerar a chave privada service-private.pem.

      $ openssl genrsa -out service-private.pem 2048
      Generating RSA private key, 2048 bit long modulus
      .+++
      ...........................................+++
      e is 65537 (0x10001)
    2. Gerar a chave pública service-public.pem com base na chave privada.

      $ openssl rsa -in service-private.pem -out service-public.pem -pubout
      writing RSA key
  3. Criar um cofre assimétrico como instância de serviço, e fornecer a chave pública:

    $ ipa vault-add secret_vault --service HTTP/webserver.idm.example.com --type asymmetric --public-key-file service-public.pem
    ----------------------------
    Added vault "secret_vault"
    ----------------------------
    Vault name: secret_vault
    Type: asymmetric
    Public key: LS0tLS1C...S0tLS0tCg==
    Owner users: admin
    Vault service: HTTP/webserver.idm.example.com@IDM.EXAMPLE.COM

    A senha arquivada no cofre será protegida com a chave.

  4. Arquivar o segredo do serviço no cofre de serviço:

    $ ipa vault-archive secret_vault --service HTTP/webserver.idm.example.com --in private-key-to-an-externally-signed-certificate.pem
    -----------------------------------
    Archived data into vault "secret_vault"
    -----------------------------------

    Isto codifica o segredo com a chave pública da instância de serviço.

Repita estes passos para cada instância de serviço que requer o segredo. Crie um novo cofre assimétrico para cada instância de serviço.

55.2. Recuperando um segredo de serviço para uma instância de serviço IdM

Esta seção descreve como uma instância de serviço pode recuperar o segredo do cofre de serviço usando uma chave privada de serviço armazenada localmente.

Pré-requisitos

Procedimento

  1. Faça o login como administrador:

    $ kinit admin
  2. Obter um bilhete Kerberos para o serviço:

    # kinit HTTP/webserver.idm.example.com -k -t /etc/httpd/conf/ipa.keytab
  3. Recuperar a senha do cofre de serviço:

    $ ipa vault-retrieve secret_vault --service HTTP/webserver.idm.example.com --private-key-file service-private.pem --out secret.txt
    ------------------------------------
    Retrieved data from vault "secret_vault"
    ------------------------------------

55.3. Mudando um segredo do cofre de serviço da IdM quando comprometido

Esta seção descreve como isolar uma instância de serviço comprometida, alterando o segredo do cofre de serviço.

Pré-requisitos

  • Você conhece a senha IdM administrator.
  • Você criou um cofre assimétrico para armazenar o segredo do serviço.
  • Você gerou o novo segredo e tem acesso a ele, por exemplo, no arquivo new-private-key-to-an-externally-signed-certificate.pem.

Procedimento

  1. Arquivar o novo segredo no cofre de instância de serviço:

    $ ipa vault-archive secret_vault --service HTTP/webserver.idm.example.com --in new-private-key-to-an-externally-signed-certificate.pem
    -----------------------------------
    Archived data into vault "secret_vault"
    -----------------------------------

    Isto sobrescreve o segredo atual armazenado no cofre.

  2. Recuperar o novo segredo apenas em casos de serviço não comprometidos. Para obter detalhes, consulte Recuperar um segredo de serviço para uma instância de serviço da IdM.

Recursos adicionais

Capítulo 56. Usando Ansible to manage IdM service vaults: armazenando e recuperando segredos

Esta seção mostra como um administrador pode usar o módulo ansible-freeipa vault para armazenar com segurança um segredo de serviço em um local centralizado. O cofre utilizado no exemplo é assimétrico, o que significa que, para utilizá-lo, o administrador precisa realizar os seguintes passos:

  1. Gerar uma chave privada usando, por exemplo, o utilitário openssl.
  2. Gerar uma chave pública com base na chave privada.

O segredo do serviço é criptografado com a chave pública quando um administrador o arquiva no cofre. Em seguida, uma instância de serviço hospedada em uma máquina específica no domínio recupera o segredo usando a chave privada. Somente o serviço e o administrador têm permissão para acessar o segredo.

Se o segredo for comprometido, o administrador pode substituí-lo no cofre de serviço e depois redistribuí-lo para aquelas instâncias de serviço individuais que não foram comprometidas.

Pré-requisitos

Esta seção inclui estes procedimentos:

Nos procedimentos:

  • admin é o administrador que administra a senha de serviço.
  • private-key-to-an-externally-signed-certificate.pem é o arquivo que contém o segredo do serviço, neste caso uma chave privada para um certificado assinado externamente. Não confunda esta chave privada com a chave privada utilizada para recuperar o segredo do cofre.
  • secret_vault é o cofre criado para armazenar o segredo do serviço.
  • HTTP/webserver1.idm.example.com é o serviço que é o proprietário do cofre.
  • HTTP/webserver2.idm.example.com e HTTP/webserver3.idm.example.com são os serviços dos membros do cofre.
  • service-public.pem é a chave pública de serviço utilizada para criptografar a senha armazenada em password_vault.
  • service-private.pem é a chave privada de serviço utilizada para decifrar a senha armazenada em secret_vault.

56.1. Garantir a presença de um cofre de serviço assimétrico na IdM usando o Ansible

Esta seção mostra como um administrador de Gerenciamento de Identidade (IdM) pode usar um livro de brincadeiras para criar um container de serviço com um ou mais cofres privados para armazenar informações sensíveis com segurança. No exemplo utilizado no procedimento abaixo, o administrador cria um cofre assimétrico chamado secret_vault. Isto assegura que os membros do cofre têm que autenticar usando uma chave privada a fim de recuperar o segredo no cofre. Os membros do cofre poderão recuperar o arquivo a partir de qualquer cliente IdM.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible. Este é o host no qual você executa as etapas do procedimento.
  • Você conhece a senha IdM administrator.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/vault:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. Obter a chave pública da instância de serviço. Por exemplo, utilizando a utilidade openssl:

    1. Gerar a chave privada service-private.pem.

      $ openssl genrsa -out service-private.pem 2048
      Generating RSA private key, 2048 bit long modulus
      .+++
      ...........................................+++
      e is 65537 (0x10001)
    2. Gerar a chave pública service-public.pem com base na chave privada.

      $ openssl rsa -in service-private.pem -out service-public.pem -pubout
      writing RSA key
  3. Opcional: Criar um arquivo de inventário se ele não existir, por exemplo inventory.file:

    $ touch inventory.file
  4. Abra seu arquivo de inventário e defina o servidor IdM que você deseja configurar na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  5. Faça uma cópia do arquivo do livro de jogo ensure-asymmetric-vault-is-present.yml. Por exemplo:

    $ cp ensure-asymmetric-vault-is-present.yml ensure-asymmetric-service-vault-is-present-copy.yml
  6. Abra o arquivo ensure-asymmetric-vault-is-present-copy.yml para edição.
  7. Adicione uma tarefa que copia a chave pública service-public.pem do controlador Ansible para o servidor server.idm.example.com.
  8. Modifique o restante do arquivo definindo as seguintes variáveis na seção de tarefas ipavault:

    • Defina a variável ipaadmin_password para a senha do administrador da IdM.
    • Definir o nome do cofre utilizando a variável name, por exemplo secret_vault.
    • Defina a variável vault_type para asymmetric.
    • Defina a variável service para o principal do serviço que possui o cofre, por exemplo HTTP/webserver1.idm.example.com.
    • Defina o public_key_file para a localização de sua chave pública.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Tests
      hosts: ipaserver
      become: true
      gather_facts: false
      tasks:
      - name: Copy public key to ipaserver.
        copy:
          src: /path/to/service-public.pem
          dest: /usr/share/doc/ansible-freeipa/playbooks/vault/service-public.pem
          mode: 0600
      - name: Add data to vault, from a LOCAL file.
        ipavault:
          ipaadmin_password: Secret123
          name: secret_vault
          vault_type: asymmetric
          service: HTTP/webserver1.idm.example.com
          public_key_file: /usr/share/doc/ansible-freeipa/playbooks/vault/service-public.pem
  9. Salvar o arquivo.
  10. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file ensure-asymmetric-service-vault-is-present-copy.yml

56.2. Adicionando serviços de membros a um cofre assimétrico usando o Ansible

Esta seção mostra como um administrador de Gerenciamento de Identidade (IdM) pode usar um Livro de Jogadas Ansioso para adicionar serviços de membros a um cofre de serviços para que todos eles possam recuperar o segredo armazenado no cofre. No exemplo utilizado no procedimento abaixo, o administrador do IdM adiciona os princípios dos serviços HTTP/webserver2.idm.example.com e HTTP/webserver3.idm.example.com ao cofre secret_vault que é de propriedade de HTTP/webserver1.idm.example.com.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible. Este é o host no qual você executa as etapas do procedimento.
  • Você conhece a senha IdM administrator.
  • Você criou um cofre assimétrico para armazenar o segredo do serviço.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/vault:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. Opcional: Criar um arquivo de inventário se ele não existir, por exemplo inventory.file:

    $ touch inventory.file
  3. Abra seu arquivo de inventário e defina o servidor IdM que você deseja configurar na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  4. Faça uma cópia do arquivo do livro de jogo data-archive-in-asymmetric-vault.yml. Por exemplo:

    $ cp data-archive-in-asymmetric-vault.yml add-services-to-an-asymmetric-vault.yml
  5. Abra o arquivo data-archive-in-asymmetric-vault-copy.yml para edição.
  6. Modifique o arquivo definindo as seguintes variáveis na seção de tarefas ipavault:

    • Defina a variável ipaadmin_password para a senha do administrador da IdM.
    • Defina a variável name para o nome do cofre, por exemplo secret_vault.
    • Defina a variável service para o proprietário do serviço do cofre, por exemplo HTTP/webserver1.idm.example.com.
    • Defina os serviços que você deseja ter acesso ao segredo do cofre usando a variável services.
    • Defina a variável action para member.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Tests
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      - ipavault:
          ipaadmin_password: Secret123
          name: secret_vault
          service: HTTP/webserver1.idm.example.com
          services:
          - HTTP/webserver2.idm.example.com
          - HTTP/webserver3.idm.example.com
          action: member
  7. Salvar o arquivo.
  8. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file add-services-to-an-asymmetric-vault.yml

56.3. Armazenando um segredo de serviço IdM em um cofre assimétrico usando o Ansible

Esta seção mostra como um administrador de Gerenciamento de Identidade (IdM) pode usar um livro de brincadeira possível para armazenar um segredo em um cofre de serviço para que ele possa ser recuperado posteriormente pelo serviço. No exemplo utilizado no procedimento abaixo, o administrador armazena um arquivo PEM com o segredo em uma caixa-forte assimétrica chamada secret_vault. Isto assegura que o serviço terá que autenticar usando uma chave privada a fim de recuperar o segredo do cofre. Os membros do cofre poderão recuperar o arquivo a partir de qualquer cliente IdM.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible. Este é o host no qual você executa as etapas do procedimento.
  • Você conhece a senha IdM administrator.
  • Você criou um cofre assimétrico para armazenar o segredo do serviço.
  • O segredo é armazenado localmente no controlador Ansible, por exemplo, no arquivo /usr/share/doc/ansible-freeipa/playbooks/vault/private-key-to-an-externally-signed-certificate.pem.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/vault:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. Opcional: Criar um arquivo de inventário se ele não existir, por exemplo inventory.file:

    $ touch inventory.file
  3. Abra seu arquivo de inventário e defina o servidor IdM que você deseja configurar na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  4. Faça uma cópia do arquivo do livro de jogo data-archive-in-asymmetric-vault.yml. Por exemplo:

    $ cp data-archive-in-asymmetric-vault.yml data-archive-in-asymmetric-vault-copy.yml
  5. Abra o arquivo data-archive-in-asymmetric-vault-copy.yml para edição.
  6. Modifique o arquivo definindo as seguintes variáveis na seção de tarefas ipavault:

    • Defina a variável ipaadmin_password para a senha do administrador da IdM.
    • Defina a variável name para o nome do cofre, por exemplo secret_vault.
    • Defina a variável service para o proprietário do serviço do cofre, por exemplo HTTP/webserver1.idm.example.com.
    • Defina a variável in para "{{ lookup('file', 'private-key-to-an-externally-signed-certificate.pem') | b64encode }}". Isto assegura que o Ansible recupere o arquivo com a chave privada do diretório de trabalho no controlador Ansible em vez de no servidor IdM.
    • Defina a variável action para member.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Tests
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      - ipavault:
          ipaadmin_password: Secret123
          name: secret_vault
          service: HTTP/webserver1.idm.example.com
          in: "{{ lookup('file', 'private-key-to-an-externally-signed-certificate.pem') | b64encode }}"
          action: member
  7. Salvar o arquivo.
  8. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file data-archive-in-asymmetric-vault-copy.yml

56.4. Recuperar um segredo de serviço para um serviço IdM usando o Ansible

Esta seção mostra como um usuário de Gerenciamento de Identidade (IdM) pode usar um Livro de Jogadas Ansivel para recuperar um segredo de um cofre de serviço em nome do serviço. No exemplo utilizado no procedimento abaixo, a execução do playbook recupera um arquivo PEM com o segredo de um cofre assimétrico chamado secret_vault, e o armazena no local especificado em todos os hosts listados no arquivo de inventário Ansible como ipaservers.

Os serviços se autenticam na IdM usando chaves, e se autenticam no cofre usando uma chave privada. É possível recuperar o arquivo em nome do serviço de qualquer cliente IdM no qual ansible-freeipa está instalado.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible. Este é o host no qual você executa as etapas do procedimento.
  • Você sabe a senha do administrador da IdM.
  • Você criou um cofre assimétrico para armazenar o segredo do serviço.
  • Você arquivou o segredo na caixa-forte.
  • Você armazenou a chave privada utilizada para recuperar o segredo do cofre de serviço no local especificado pela variável private_key_file no controlador Ansible.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/vault:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. Opcional: Criar um arquivo de inventário se ele não existir, por exemplo inventory.file:

    $ touch inventory.file
  3. Abra seu arquivo de inventário e defina os seguintes anfitriões:

    • Defina seu servidor IdM na seção [ipaserver].
    • Defina os anfitriões para os quais você deseja recuperar o segredo na seção [webservers]. Por exemplo, para instruir Ansible para recuperar o segredo para webserver1.idm.example.com, webserver2.idm.example.com e webserver3.idm.example.com, entre:
    [ipaserver]
    server.idm.example.com
    
    [webservers]
    webserver1.idm.example.com
    webserver2.idm.example.com
    webserver3.idm.example.com
  4. Faça uma cópia do arquivo do livro de jogo retrieve-data-asymmetric-vault.yml. Por exemplo:

    $ cp retrieve-data-asymmetric-vault.yml retrieve-data-asymmetric-vault-copy.yml
  5. Abra o arquivo retrieve-data-asymmetric-vault-copy.yml para edição.
  6. Modifique o arquivo definindo as seguintes variáveis na seção de tarefas ipavault:

    • Defina a variável ipaadmin_password para sua senha de administrador IdM.
    • Defina a variável name para o nome do cofre, por exemplo secret_vault.
    • Defina a variável service para o proprietário do serviço do cofre, por exemplo HTTP/webserver1.idm.example.com.
    • Defina a variável private_key_file para a localização da chave privada utilizada para recuperar o segredo do cofre de serviço.
    • Defina a variável out para o local no servidor IdM onde você deseja recuperar o segredo private-key-to-an-externally-signed-certificate.pem, por exemplo, o diretório de trabalho atual.
    • Defina a variável action para member.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Retrieve data from vault
      hosts: ipaserver
      become: no
      gather_facts: false
    
      tasks:
      - name: Retrieve data from the service vault
        ipavault:
          ipaadmin_password: Secret123
          name: secret_vault
          service: HTTP/webserver1.idm.example.com
          vault_type: asymmetric
          private_key: "{{ lookup('file', 'service-private.pem') | b64encode }}"
          out: private-key-to-an-externally-signed-certificate.pem
          state: retrieved
  7. Adicione uma seção ao playbook que recupera o arquivo de dados do servidor da IdM para o controlador Ansible:

    ---
    - name: Retrieve data from vault
      hosts: ipaserver
      become: no
      gather_facts: false
      tasks:
    [...]
      - name: Retrieve data file
        fetch:
          src: private-key-to-an-externally-signed-certificate.pem
          dest: ./
          flat: yes
          mode: 0600
  8. Adicione uma seção ao playbook que transfere o arquivo private-key-to-an-externally-signed-certificate.pem recuperado do controlador Ansible para os webservers listados na seção webservers do arquivo do inventário:

    ---
    - name: Send data file to webservers
      become: no
      gather_facts: no
      hosts: webservers
      tasks:
      - name: Send data to webservers
        copy:
          src: private-key-to-an-externally-signed-certificate.pem
          dest: /etc/pki/tls/private/httpd.key
          mode: 0444
  9. Salvar o arquivo.
  10. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file retrieve-data-asymmetric-vault-copy.yml

56.5. Mudando um segredo do cofre de serviço IdM quando comprometido usando o Ansible

Esta seção mostra como um administrador de Gerenciamento de Identidade (IdM) pode reutilizar um Livro de Jogadas Ansioso para alterar o segredo armazenado em um cofre de serviço quando uma instância de serviço tiver sido comprometida. O cenário no exemplo a seguir assume que em webserver3.idm.example.com, o segredo recuperado foi comprometido, mas não a chave para o cofre assimétrico que armazena o segredo. No exemplo, o administrador reutiliza os Livros de jogo possíveis usados ao armazenar um segredo em um cofre assimétrico e recupera um segredo do cofre assimétrico em hosts IdM. No início do procedimento, o administrador da IdM armazena um novo arquivo PEM com um novo segredo no cofre assimétrico, adapta o arquivo de inventário para não recuperar o novo segredo para o servidor web comprometido, webserver3.idm.example.com, e depois executa novamente os dois procedimentos.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible. Este é o host no qual você executa as etapas do procedimento.
  • Você conhece a senha IdM administrator.
  • Você criou um cofre assimétrico para armazenar o segredo do serviço.
  • Você gerou uma nova chave httpd para os serviços web rodando em hosts IdM para substituir a chave antiga comprometida.
  • A nova chave httpd é armazenada localmente no controlador Ansible, por exemplo, no arquivo /usr/share/doc/ansible-freeipa/playbooks/vault/private-key-to-an-externally-signed-certificate.pem.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/vault:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/vault
  2. Abra seu arquivo de inventário e verifique se o servidor IdM que você deseja configurar está definido corretamente na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:
  3. Abra seu arquivo de inventário e certifique-se de que os seguintes anfitriões estejam definidos corretamente:

    • O servidor da IdM na seção [ipaserver].
    • Os anfitriões para os quais você deseja recuperar o segredo na seção [webservers]. Por exemplo, para instruir Ansible a recuperar o segredo para webserver1.idm.example.com e webserver2.idm.example.com, entre:

      [ipaserver]
      server.idm.example.com
      
      [webservers]
      webserver1.idm.example.com
      webserver2.idm.example.com
    Importante

    Certifique-se de que a lista não contém o servidor web comprometido, no exemplo atual webserver3.idm.example.com.

  4. Abra o arquivo data-archive-in-asymmetric-vault-copy.yml para edição.
  5. Modifique o arquivo definindo as seguintes variáveis na seção de tarefas ipavault:

    • Defina a variável ipaadmin_password para a senha do administrador da IdM.
    • Defina a variável name para o nome do cofre, por exemplo secret_vault.
    • Defina a variável service para o proprietário do serviço do cofre, por exemplo HTTP/webserver.idm.example.com.
    • Defina a variável in para "{{ lookup('file', 'new-private-key-to-an-externally-signed-certificate.pem') | b64encode }}". Isto assegura que o Ansible recupere o arquivo com a chave privada do diretório de trabalho no controlador Ansible em vez de no servidor IdM.
    • Defina a variável action para member.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Tests
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      - ipavault:
          ipaadmin_password: Secret123
          name: secret_vault
          service: HTTP/webserver.idm.example.com
          in: "{{ lookup('file', 'new-private-key-to-an-externally-signed-certificate.pem') | b64encode }}"
          action: member
  6. Salvar o arquivo.
  7. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file data-archive-in-asymmetric-vault-copy.yml
  8. Abra o arquivo retrieve-data-asymmetric-vault-copy.yml para edição.
  9. Modifique o arquivo definindo as seguintes variáveis na seção de tarefas ipavault:

    • Defina a variável ipaadmin_password para sua senha de administrador IdM.
    • Defina a variável name para o nome do cofre, por exemplo secret_vault.
    • Defina a variável service para o proprietário do serviço do cofre, por exemplo HTTP/webserver1.idm.example.com.
    • Defina a variável private_key_file para a localização da chave privada utilizada para recuperar o segredo do cofre de serviço.
    • Defina a variável out para o local no servidor IdM onde você deseja recuperar o segredo new-private-key-to-an-externally-signed-certificate.pem, por exemplo, o diretório de trabalho atual.
    • Defina a variável action para member.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Retrieve data from vault
      hosts: ipaserver
      become: no
      gather_facts: false
    
      tasks:
      - name: Retrieve data from the service vault
        ipavault:
          ipaadmin_password: Secret123
          name: secret_vault
          service: HTTP/webserver1.idm.example.com
          vault_type: asymmetric
          private_key: "{{ lookup('file', 'service-private.pem') | b64encode }}"
          out: new-private-key-to-an-externally-signed-certificate.pem
          state: retrieved
  10. Adicione uma seção ao playbook que recupera o arquivo de dados do servidor da IdM para o controlador Ansible:

    ---
    - name: Retrieve data from vault
      hosts: ipaserver
      become: yes
      gather_facts: false
      tasks:
    [...]
      - name: Retrieve data file
        fetch:
          src: new-private-key-to-an-externally-signed-certificate.pem
          dest: ./
          flat: yes
          mode: 0600
  11. Adicione uma seção ao playbook que transfere o arquivo new-private-key-to-an-externally-signed-certificate.pem recuperado do controlador Ansible para os webservers listados na seção webservers do arquivo do inventário:

    ---
    - name: Send data file to webservers
      become: yes
      gather_facts: no
      hosts: webservers
      tasks:
      - name: Send data to webservers
        copy:
          src: new-private-key-to-an-externally-signed-certificate.pem
          dest: /etc/pki/tls/private/httpd.key
          mode: 0444
  12. Salvar o arquivo.
  13. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file retrieve-data-asymmetric-vault-copy.yml

Recursos adicionais

  • Para mais informações sobre o uso do Ansible to manage IdM vaults and service secrets e sobre variáveis de playbook, consulte o arquivo README-vault.md Markdown disponível no diretório /usr/share/doc/ansible-freeipa/ e os exemplos de playbooks disponíveis no diretório /usr/share/doc/ansible-freeipa/playbooks/vault/.

Capítulo 57. Garantir a presença e ausência de serviços na IdM usando o Ansible

Com o módulo Ansible service, o administrador de Gerenciamento de Identidade (IdM) pode garantir que serviços específicos que não são nativos da IdM estejam presentes ou ausentes na IdM. Por exemplo, você pode usar o módulo service para:

57.1. Assegurar a presença de um serviço HTTP na IdM usando um livro de jogo possível

Esta seção descreve como garantir a presença de um servidor HTTP na IdM usando um livro de reprodução possível.

Pré-requisitos

  • O sistema para hospedar o serviço HTTP é um cliente IdM.
  • Você tem a senha de administrador da IdM.

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file:

    $ touch inventory.file
  2. Abra o inventory.file e defina o servidor IdM que você deseja configurar na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present.yml. Por exemplo:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-copy.yml
  4. Abrir o arquivo /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-copy.yml Um possível arquivo de playbook para edição:

    ---
    - name: Playbook to manage IPA service.
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      # Ensure service is present
      - ipaservice:
          ipaadmin_password: Secret123
          name: HTTP/client.idm.example.com
  5. Adaptar o arquivo:

    • Alterar a senha do administrador da IdM definida pela variável ipaadmin_password.
    • Mude o nome de seu cliente IdM no qual o serviço HTTP está sendo executado, conforme definido pela variável name da tarefa ipaservice.
  6. Salvar e sair do arquivo.
  7. Execute a Pasta de reprodução possível especificando o arquivo da Pasta de reprodução e o arquivo do inventário:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-copy.yml

Etapas de verificação

  1. Entre na IDM Web UI como administrador da IdM.
  2. Navegue para IdentityServices.

Se HTTP/client.idm.example.com@IDM.EXAMPLE.COM estiver listado na lista Services, o livro de jogo possível foi adicionado com sucesso à IdM.

Recursos adicionais

57.2. Assegurar a presença de um serviço HTTP na IdM em um cliente não IdM usando um livro de jogo possível

Esta seção descreve como garantir a presença de um servidor HTTP na IdM em um host que não é um cliente IdM usando um livro de exercícios possível. Ao adicionar o servidor HTTP ao IdM, você também está adicionando o host ao IdM.

Pré-requisitos

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file:

    $ touch inventory.file
  2. Abra o inventory.file e defina o servidor IdM que você deseja configurar na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-without-host-check.yml. Por exemplo:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-without-host-check.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-without-host-check-copy.yml
  4. Abra o arquivo copiado, /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-without-host-check-copy.yml, para edição. Localize as variáveis ipaadmin_password e name na tarefa ipaservice:

    ---
    - name: Playbook to manage IPA service.
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      # Ensure service is present
      - ipaservice:
          ipaadmin_password: MyPassword123
          name: HTTP/www2.example.com
          skip_host_check: yes
  5. Adaptar o arquivo:

    • Defina a variável ipaadmin_password para sua senha de administrador IdM.
    • Defina a variável name para o nome do host no qual o serviço HTTP está sendo executado.
  6. Salvar e sair do arquivo.
  7. Execute a Pasta de reprodução possível especificando o arquivo da Pasta de reprodução e o arquivo do inventário:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-without-host-check-copy.yml

Etapas de verificação

  1. Entre na IDM Web UI como administrador da IdM.
  2. Navegue para IdentityServices.

Agora você pode ver HTTP/client.idm.example.com@IDM.EXAMPLE.COM listado na lista Services.

Recursos adicionais

57.3. Assegurar a presença de um serviço HTTP em um cliente IdM sem DNS usando um livro de jogo possível

Esta seção descreve como assegurar a presença de um servidor HTTP rodando em um cliente IdM que não tem entrada DNS usando um livro de jogo Ansible playbook. O cenário implícito é que o host IdM não tem uma entrada DNS A disponível - ou nenhuma entrada DNS AAAA se for usado IPv6 em vez de IPv4.

Pré-requisitos

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file:

    $ touch inventory.file
  2. Abra o inventory.file e defina o servidor IdM que você deseja configurar na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-with-host-force.yml. Por exemplo:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-with-host-force.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-with-host-force-copy.yml
  4. Abra o arquivo copiado, /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-with-host-force-copy.yml, para edição. Localize as variáveis ipaadmin_password e name na tarefa ipaservice:

    ---
    - name: Playbook to manage IPA service.
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      # Ensure service is present
      - ipaservice:
          ipaadmin_password: MyPassword123
          name: HTTP/ihavenodns.info
          force: yes
  5. Adaptar o arquivo:

    • Defina a variável ipaadmin_password para sua senha de administrador IdM.
    • Defina a variável name para o nome do host no qual o serviço HTTP está sendo executado.
  6. Salvar e sair do arquivo.
  7. Execute a Pasta de reprodução possível especificando o arquivo da Pasta de reprodução e o arquivo do inventário:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-is-present-with-host-force-copy.yml

Etapas de verificação

  1. Entre na IDM Web UI como administrador da IdM.
  2. Navegue para IdentityServices.

Agora você pode ver HTTP/client.idm.example.com@IDM.EXAMPLE.COM listado na lista Services.

Recursos adicionais

57.4. Assegurar a presença de um certificado assinado externamente em uma entrada de serviço IdM usando um livro de jogos possível

Esta seção descreve como usar o módulo ansible-freeipa service para garantir que um certificado emitido por uma autoridade certificadora externa (CA) seja anexado à entrada do IdM do serviço HTTP. Ter o certificado de um serviço HTTP assinado por uma CA externa em vez do IdM CA é particularmente útil se o seu IdM CA usa um certificado autoassinado.

Pré-requisitos

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file:

    $ touch inventory.file
  2. Abra o inventory.file e defina o servidor IdM que você deseja configurar na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo /usr/share/doc/ansible-freeipa/playbooks/service/service-member-certificate-present.yml, por exemplo:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-member-certificate-present.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-member-certificate-present-copy.yml
  4. Opcional: Se o certificado estiver no formato Privacy Enhanced Mail (PEM), converta o certificado para o formato Distinguished Encoding Rules (DER) para facilitar o manuseio através da interface de linha de comando (CLI):

    $ openssl x509 -outform der -in cert1.pem -out cert1.der
  5. Decodifique o arquivo DER para a saída padrão usando o comando base64. Use a opção -w0 para desativar a embalagem:

    $ base64 cert1.der -w0
    MIIC/zCCAeegAwIBAgIUV74O+4kXeg21o4vxfRRtyJm...
  6. Copie o certificado da saída padrão para a prancheta.
  7. Abra o arquivo /usr/share/doc/ansible-freeipa/playbooks/service/service-member-certificate-present-copy.yml para editar e visualizar seu conteúdo:

    ---
    - name: Service certificate present.
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      # Ensure service certificate is present
      - ipaservice:
          ipaadmin_password: MyPassword123
          name: HTTP/www.example.com
          certificate: |
            - MIICBjCCAW8CFHnm32VcXaUDGfEGdDL/...
          [...]
          action: member
          state: present
  8. Adaptar o arquivo:

    • Substitua o certificado, definido usando a variável certificate, pelo certificado que você copiou da CLI. Observe que se você usar a variável certificate: com o caractere "||" do tubo como indicado, você pode inserir o certificado ESTE CAMINHO em vez de tê-lo para inseri-lo em uma única linha. Isto torna a leitura do certificado mais fácil.
    • Alterar a senha do administrador da IdM, definida pela variável ipaadmin_password.
    • Mude o nome de seu cliente IdM no qual o serviço HTTP está sendo executado, definido pela variável name.
    • Alterar quaisquer outras variáveis relevantes.
  9. Salvar e sair do arquivo.
  10. Execute a Pasta de reprodução possível especificando o arquivo da Pasta de reprodução e o arquivo do inventário:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-member-certificate-present-copy.yml

Etapas de verificação

  1. Entre na IDM Web UI como administrador da IdM.
  2. Navegue para IdentityServices.
  3. Clique no nome do serviço com o certificado recém-adicionado, por exemplo HTTP/client.idm.example.com.

Na seção Service Certificate à direita, você pode ver agora o certificado recém-adicionado.

57.5. Utilização de um livro de jogo possível para permitir que usuários, grupos, anfitriões ou grupos anfitriões da IdM criem uma tabela de chaves de um serviço

Uma tabela de chaves é um arquivo contendo pares de chaves principais Kerberos e chaves criptografadas. Os arquivos keytab são comumente usados para permitir a autenticação automática de scripts usando Kerberos, sem exigir interação humana ou acesso a senha armazenada em um arquivo de texto simples. O script é então capaz de usar as credenciais adquiridas para acessar arquivos armazenados em um sistema remoto.

Como administrador de Gerenciamento de Identidade (IdM), você pode permitir que outros usuários recuperem ou mesmo criem uma tabela de chaves para um serviço executado no IdM. Ao permitir que usuários específicos e grupos de usuários criem keytabs, você pode delegar a administração do serviço a eles sem compartilhar a senha do administrador do IdM. Esta delegação proporciona uma administração de sistema mais fina.

Esta seção descreve como você pode permitir que usuários específicos de IdM, grupos de usuários, hosts e grupos de hosts criem uma tabela de chaves para o serviço HTTP rodando em um cliente IdM. Especificamente, descreve como você pode permitir que o usuário do IdM user01 crie uma keytab para o serviço HTTP rodando em um cliente IdM chamado client.idm.example.com.

Pré-requisitos

  • Você sabe a senha do administrador da IdM.
  • Você instalou o pacote ansible-freeipa no controlador Ansible.
  • Você cadastrou o serviço HTTP para a IdM.
  • O sistema para hospedar o serviço HTTP é um cliente IdM.
  • Os usuários e grupos de usuários do IdM que você deseja permitir a criação da tabela de chaves existem no IdM.
  • Os anfitriões e grupos anfitriões do IdM que você deseja permitir criar o keytab existem no IdM.

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file:

    $ touch inventory.file
  2. Abra o inventory.file e defina o servidor IdM que você deseja configurar na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_create_keytab-present.yml. Por exemplo:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_create_keytab-present.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_create_keytab-present-copy.yml
  4. Abrir o arquivo /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_create_keytab-present-copy.yml Um possível arquivo de playbook para edição.
  5. Adapte o arquivo alterando o seguinte:

    • A senha do administrador da IdM especificada pela variável ipaadmin_password.
    • O nome de seu cliente IdM no qual o serviço HTTP está sendo executado. No exemplo atual, ele é HTTP/client.idm.example.com
    • Os nomes dos usuários da IdM que estão listados na seção allow_create_keytab_user:. No exemplo atual, é user01.
    • Os nomes dos grupos de usuários da IdM que estão listados na seção allow_create_keytab_group:.
    • Os nomes dos anfitriões da IdM que estão listados na seção allow_create_keytab_host:.
    • Os nomes dos grupos anfitriões da IdM que estão listados na seção allow_create_keytab_hostgroup:.
    • O nome da tarefa especificada pela variável name na seção tasks.

      Depois de ser adaptado para o exemplo atual, o arquivo copiado tem este aspecto:

    ---
    - name: Service member allow_create_keytab present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Service HTTP/client.idm.example.com members allow_create_keytab present for user01
        ipaservice:
          ipaadmin_password: Secret123
          name: HTTP/client.idm.example.com
          allow_create_keytab_user:
          - user01
          action: member
  6. Salvar o arquivo.
  7. Execute a Pasta de reprodução possível especificando o arquivo da Pasta de reprodução e o arquivo do inventário:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_create_keytab-present-copy.yml

Etapas de verificação

  1. SSH para um servidor IdM como um usuário IdM que tem o privilégio de criar um keytab para o serviço HTTP particular:

    $ ssh user01@server.idm.example.com
    Password:
  2. Use o comando ipa-getkeytab para gerar a nova tabela de chaves para o serviço HTTP:

    $ ipa-getkeytab -s server.idm.example.com -p HTTP/client.idm.example.com -k /etc/httpd/conf/krb5.keytab

    A opção -s especifica um servidor do Centro de Distribuição de Chaves (KDC) para gerar a tabela de chaves.

    A opção -p especifica o principal cuja chaveta você deseja criar.

    A opção -k especifica o arquivo keytab para anexar a nova chave. O arquivo será criado se ele não existir.

Se o comando não resultar em um erro, você criou com sucesso uma tabela de chaves de HTTP/client.idm.example.com como user01.

57.6. Utilização de um livro de jogo possível para permitir que usuários, grupos, anfitriões ou grupos anfitriões da IdM recuperem uma tabela de chaves de um serviço

Uma tabela de chaves é um arquivo contendo pares de chaves principais Kerberos e chaves criptografadas. Os arquivos keytab são comumente usados para permitir a autenticação automática de scripts usando Kerberos, sem exigir interação humana ou acesso a uma senha armazenada em um arquivo de texto simples. O script é então capaz de usar as credenciais adquiridas para acessar arquivos armazenados em um sistema remoto.

Como administrador do IdM, você pode permitir que outros usuários recuperem ou mesmo criem uma tabela de chaves para um serviço executado no IdM.

Esta seção descreve como você pode permitir que usuários específicos de IdM, grupos de usuários, hosts e grupos de hosts recuperem uma tabela de chaves para o serviço HTTP rodando em um cliente IdM. Especificamente, ela descreve como permitir que o usuário do IdM user01 recupere a keytab do serviço HTTP rodando em client.idm.example.com.

Pré-requisitos

  • Você sabe a senha do administrador da IdM.
  • Você instalou o pacote ansible-freeipa no controlador Ansible.
  • Você cadastrou o serviço HTTP para a IdM.
  • Os usuários e grupos de usuários do IdM que você deseja permitir recuperar a tabela de chaves existem no IdM.
  • Os anfitriões e grupos anfitriões do IdM que você deseja permitir recuperar o keytab existem no IdM.

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file:

    $ toque inventory.file
  2. Abra o inventory.file e defina o servidor IdM que você deseja configurar na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_retrieve_keytab-present.yml. Por exemplo:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_retrieve_keytab-present.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_retrieve_keytab-present-copy.yml
  4. Abra o arquivo copiado, /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_retrieve_keytab-present-copy.yml, para edição:
  5. Adaptar o arquivo:

    • Defina a variável ipaadmin_password para sua senha de administrador IdM.
    • Defina a variável name da tarefa ipaservice para o diretor do serviço HTTP. No exemplo atual, ela é HTTP/client.idm.example.com
    • Especifique os nomes dos usuários da IdM na seção allow_retrieve_keytab_group:. No exemplo atual, é user01.
    • Especifique os nomes dos grupos de usuários do IdM na seção allow_retrieve_keytab_group:.
    • Especifique os nomes dos anfitriões da IdM na seção allow_retrieve_keytab_group:.
    • Especifique os nomes dos grupos anfitriões da IdM na seção allow_retrieve_keytab_group:.
    • Especifique o nome da tarefa usando a variável name na seção tasks.

      Depois de ser adaptado para o exemplo atual, o arquivo copiado tem este aspecto:

    ---
    - name: Service member allow_retrieve_keytab present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Service HTTP/client.idm.example.com members allow_retrieve_keytab present for user01
        ipaservice:
          ipaadmin_password: Secret123
          name: HTTP/client.idm.example.com
          allow_retrieve_keytab_user:
          - user01
          action: member
  6. Salvar o arquivo.
  7. Execute a Pasta de reprodução possível especificando o arquivo da Pasta de reprodução e o arquivo do inventário:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-member-allow_retrieve_keytab-present-copy.yml

Etapas de verificação

  1. SSH para um servidor IdM como um usuário IdM com o privilégio de recuperar uma tabela de chaves para o serviço HTTP:

    $ ssh user01@server.idm.example.com
    Password:
  2. Use o comando ipa-getkeytab com a opção -r para recuperar o keytab:

    $ ipa-getkeytab -r -s server.idm.example.com -p HTTP/client.idm.example.com -k /etc/httpd/conf/krb5.keytab

    A opção -s especifica um servidor do Centro de Distribuição de Chaves (KDC) a partir do qual você deseja recuperar a tabela de chaves.

    A opção -p especifica o principal cujo chaveiro você deseja recuperar.

    A opção -k especifica o arquivo keytab ao qual você deseja anexar a chave recuperada. O arquivo será criado se ele não existir.

Se o comando não resultar em um erro, você recuperou com sucesso uma tabela de chaves de HTTP/client.idm.example.com como user01.

57.7. Assegurar a presença de um Kerberos principal alias de um serviço usando um livro de jogo possível

Em alguns cenários, é benéfico para o administrador da IdM permitir que usuários, hosts ou serviços da IdM se autentiquem contra as aplicações Kerberos usando um pseudônimo principal Kerberos. Estes cenários incluem:

  • O nome do usuário mudou, mas o usuário deve ser capaz de entrar no sistema usando tanto o nome do usuário anterior quanto o do novo usuário.
  • O usuário precisa entrar usando o endereço de e-mail, mesmo que o domínio da IdM Kerberos seja diferente do domínio de e-mail.

Esta seção descreve como criar o principal alias de HTTP/mycompany.idm.example.com para o serviço HTTP em execução no site client.idm.example.com.

Pré-requisitos

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file:

    $ touch inventory.file
  2. Abra o inventory.file e defina o servidor IdM que você deseja configurar na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo /usr/share/doc/ansible-freeipa/playbooks/service/service-member-principal-present.yml. Por exemplo:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-member-principal-present.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-member-principal-present-copy.yml
  4. Abrir o arquivo /usr/share/doc/ansible-freeipa/playbooks/service/service-member-principal-present-copy.yml Um possível arquivo de playbook para edição.
  5. Adapte o arquivo alterando o seguinte:

    • A senha do administrador da IdM especificada pela variável ipaadmin_password.
    • O nome do serviço especificado pela variável name. Este é o nome principal canônico do serviço. No exemplo atual, é HTTP/client.idm.example.com.
    • O Kerberos principal alias especificado pela variável principal. Este é o pseudônimo que você deseja adicionar ao serviço definido pela variável name. No exemplo atual, é host/mycompany.idm.example.com.
    • O nome da tarefa especificada pela variável name na seção tasks.

      Depois de ser adaptado para o exemplo atual, o arquivo copiado tem este aspecto:

    ---
    - name: Service member principal present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Service HTTP/client.idm.example.com member principals host/mycompany.idm.exmaple.com present
        ipaservice:
          ipaadmin_password: Secret123
          name: HTTP/client.idm.example.com
          principal:
            - host/mycompany.idm.example.com
          action: member
  6. Salvar o arquivo.
  7. Execute a Pasta de reprodução possível especificando o arquivo da Pasta de reprodução e o arquivo do inventário:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-member-principal-present-copy.yml

Se a execução do playbook resultar em 0 tarefas inalcançáveis e 0 falhas, você criou com sucesso o host/mycompany.idm.example.com Kerberos principal para o serviço HTTP/client.idm.example.com.

Recursos adicionais

57.8. Garantir a ausência de um serviço HTTP no IdM usando um livro de jogo possível

Esta seção descreve como desenrolar um serviço da IdM. Mais especificamente, ela descreve como usar um livro de exercícios possível para garantir a ausência de um servidor HTTP chamado HTTP/client.idm.example.com na IdM.

Pré-requisitos

  • Você tem a senha de administrador da IdM.

Procedimento

  1. Criar um arquivo de inventário, por exemplo inventory.file:

    $ touch inventory.file
  2. Abra o inventory.file e defina o servidor IdM que você deseja configurar na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo /usr/share/doc/ansible-freeipa/playbooks/service/service-is-absent.yml. Por exemplo:

    $ cp /usr/share/doc/ansible-freeipa/playbooks/service/service-is-absent.yml /usr/share/doc/ansible-freeipa/playbooks/service/service-is-absent-copy.yml
  4. Abrir o arquivo /usr/share/doc/ansible-freeipa/playbooks/service/service-is-absent-copy.yml Um possível arquivo de playbook para edição.
  5. Adapte o arquivo alterando o seguinte:

    • A senha de administrador da IdM definida pela variável ipaadmin_password.
    • O Kerberos principal do serviço HTTP, conforme definido pela variável name da tarefa ipaservice.

      Depois de ser adaptado para o exemplo atual, o arquivo copiado tem este aspecto:

    ---
    - name: Playbook to manage IPA service.
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      # Ensure service is absent
      - ipaservice:
          ipaadmin_password: Secret123
          name: HTTP/client.idm.example.com
          state: absent
  6. Salvar e sair do arquivo.
  7. Execute a Pasta de reprodução possível especificando o arquivo da Pasta de reprodução e o arquivo do inventário:

    $ ansible-playbook -v -i path_to_inventory_directory/inventory.file /usr/share/doc/ansible-freeipa/playbooks/service/service-is-absent-copy.yml

Etapas de verificação

  1. Entre na IDM Web UI como administrador da IdM.
  2. Navegue para IdentityServices.

Se você não puder ver o serviço HTTP/client.idm.example.com@IDM.EXAMPLE.COM na lista Services, você garantiu com sucesso sua ausência na IdM.

Recursos adicionais

  • Você pode ver exemplos de Playbooks Ansíveis para garantir a presença e ausência de serviços na IdM incluindo uma lista de possíveis variáveis no arquivo Markdown README-service.md disponível no diretório /usr/share/doc/ansible-freeipa/.
  • Você pode ver exemplos de livros de exercícios possíveis para garantir a presença e ausência de serviços na IdM no diretório /usr/share/doc/ansible-freeipa/playbooks/config.

Capítulo 58. Permitindo aos usuários de AD administrar IdM

58.1. Anulações de ID para usuários AD

No Red Hat Enterprise Linux (RHEL) 7, a associação externa de grupos permite que usuários e grupos do Active Directory (AD) acessem recursos de Gerenciamento de Identidade (IdM) em um ambiente POSIX com a ajuda do System Security Services Daemon (SSSD).

O servidor IdM LDAP tem seus próprios mecanismos para garantir o controle de acesso. A RHEL 8 introduz uma atualização que permite adicionar uma substituição de usuário ID para um usuário AD como membro de um grupo IdM. Uma substituição de ID é um registro que descreve como um usuário específico do Active Directory ou propriedades do grupo deve se parecer dentro de uma visualização de ID específica, neste caso, a Visualização de Confiança Padrão. Como conseqüência da atualização, o servidor IdM LDAP é capaz de aplicar regras de controle de acesso para o grupo IdM ao usuário AD.

Os usuários AD agora são capazes de usar os recursos de autoatendimento da IdM UI, por exemplo, para carregar suas chaves SSH, ou alterar seus dados pessoais. Um administrador de AD é capaz de administrar completamente o IdM sem ter duas contas e senhas diferentes.

Nota

Atualmente, recursos selecionados na IdM ainda podem não estar disponíveis para os usuários AD. Por exemplo, definir senhas para usuários do IdM como um usuário AD do grupo IdM admins pode falhar.

58.2. Usando anulações de ID para permitir que usuários AD administrem IdM

Pré-requisitos

  • O fluxo idm:DL1 está habilitado em seu servidor de Gerenciamento de Identidade (IdM) e você mudou para as RPMs entregues através deste fluxo:

    # yum module enable idm:DL1
    # yum distro-sync
  • O perfil idm:DL1/adtrust está instalado em seu servidor IdM.

    # yum module install idm:DL1/adtrust

    O perfil contém todos os pacotes necessários para a instalação de um servidor IdM que terá um acordo de confiança com o Active Directory (AD), incluindo o pacote ipa-idoverride-memberof.

  • Um ambiente de trabalho IdM é criado. Para detalhes, consulte Instalando o Gerenciamento de Identidade.
  • É estabelecida uma confiança de trabalho entre seu ambiente IdM e AD.

Procedimento

Este procedimento descreve a criação e o uso de uma substituição de ID para um usuário AD para dar a esse usuário direitos idênticos aos de um usuário IdM. Durante este procedimento, o trabalho em um servidor IdM que é configurado como um controlador de confiança ou um agente de confiança. Para detalhes sobre controladores de confiança e agentes fiduciários, veja Trust controllers and trust agents em Gerenciamento de Identidade de Planejamento.

  1. Como administrador da IdM, crie uma substituição de ID para um usuário AD na Visão Padrão de Confiança. Por exemplo, para criar uma substituição de ID para o usuário ad_user@ad.example.com:

    # kinit admin
    # ipa idoverrideuser-add 'default trust view' ad_user@ad.example.com
  2. Adicionar a substituição de ID do Default Trust View como um membro de um grupo IdM. Se o grupo em questão for um membro de uma função IdM, o usuário AD representado pela substituição de ID ganhará todas as permissões concedidas pela função ao usar a API do IdM, incluindo tanto a interface de linha de comando quanto a interface web do IdM. Por exemplo, para adicionar a substituição de ID para o usuário ad_user@ad.example.com ao grupo admins:

    # ipa group-add-member admins --idoverrideusers=ad_user@ad.example.com

58.3. Gerenciando o IdM CLI como usuário AD

Este procedimento verifica se um usuário do Active Directory (AD) pode entrar na interface de linha de comando do Gerenciamento de Identidade (IdM) e executar comandos apropriados para sua função.

  1. Destruir o atual bilhete Kerberos do administrador da IdM:

    # kdestroy -A
    Nota

    A destruição do bilhete Kerberos é necessária porque a implementação da GSSAPI no MIT Kerberos escolhe credenciais do reino do serviço alvo por preferência, que neste caso é o reino do IdM. Isto significa que se uma coleta de cache de credenciais, a saber, KCM:, KEYRING:, ou DIR: tipo de cache de credenciais estiver em uso, um arquivo admin previamente obtido ou qualquer outra credencial do diretor do IdM será usado para acessar o IdM API em vez das credenciais do usuário AD.

  2. Obter as credenciais Kerberos do usuário AD para o qual foi criada uma anulação de ID:

    # kinit ad_user@AD.EXAMPLE.COM
    Password for ad_user@AD.EXAMPLE.COM:
  3. Teste que a substituição de ID do usuário AD goza dos mesmos privilégios decorrentes de ser membro do grupo IdM que qualquer usuário IdM desse grupo. Se a substituição de ID do usuário AD tiver sido adicionada ao grupo admins, o usuário AD pode, por exemplo, criar grupos no IdM:

    # ipa group-add some-new-group
    ----------------------------
    Added group "some-new-group"
    ----------------------------
      Group name: some-new-group
      GID: 1997000011

Capítulo 59. Habilitação de autenticação usando Nomes Principais de Usuários AD no IdM

59.1. Nomes principais de usuários em uma floresta AD confiável pela IdM

Como administrador de sistema de Gerenciamento de Identidade (IdM) que está conectado ao Active Directory (AD) por um contrato de confiança, você pode permitir que os usuários do AD utilizem o User Principal Names (UPNs) alternativo ao acessar os recursos no domínio do IdM. Uma UPN é uma alternativa user_login com a qual os usuários do AD se autenticam, e tem o formato de user_name@KERBEROS-REALM. Um administrador do sistema AD pode definir valores alternativos tanto para user_name quanto para KERBEROS-REALM, pois em uma floresta AD é possível configurar tanto apelidos Kerberos adicionais quanto sufixos UPN.

Por exemplo, se uma empresa usa o domínio AD.EXAMPLE.COM Kerberos, a UPN padrão para um usuário é user@ad.example.com. Entretanto, como administrador do sistema, você pode permitir que seus usuários possam fazer o login usando seus endereços de e-mail, por exemplo user@example.com.

Sempre que uma nova UPN for definida no lado AD, execute, como um administrador IdM, o comando ipa trust-fetch-domains em um servidor IdM, para garantir que as UPNs AD estejam atualizadas na IdM.

Nota

Os sufixos UPN para um domínio são armazenados no atributo multi-valor ipaNTAdditionalSuffixes na sub-árvore cn=trusted_domain_name,cn=ad,cn=trusts,dc=idm,dc=example,dc=com.

Alternativas, ou empresas, UPNs são especialmente convenientes se sua empresa experimentou recentemente uma fusão e você deseja fornecer a seus usuários um espaço unificado de nomes de logon.

59.2. Assegurando que os AD UPNs estejam atualizados na IdM

Quando você adicionar ou remover um sufixo de Nome Principal do Usuário (UPN) em uma floresta confiável do Active Directory (AD), atualize as informações para a floresta confiável no mestre do IdM.

Pré-requisitos

  • Certifique-se de que você obteve as credenciais de administrador da IdM.

Procedimento

  1. Digite o comando ipa trust-fetch-domains. Note que uma saída aparentemente vazia é esperada:

    [root@ipaserver ~]# ipa trust-fetch-domains
    Realm-Name: ad.example.com
    -------------------------------
    No new trust domains were found
    -------------------------------
    ----------------------------
    Number of entries returned 0
    ----------------------------
  2. Digite o comando ipa trust-show para verificar se a nova UPN foi buscada. Especifique o nome do domínio AD quando solicitado:

    [root@ipaserver ~]# ipa trust-show
    Realm-Name: ad.example.com
      Realm-Name: ad.example.com
      Domain NetBIOS name: AD
      Domain Security Identifier: S-1-5-21-796215754-1239681026-23416912
      Trust direction: Two-way trust
      Trust type: Active Directory domain
      UPN suffixes: example.com

A saída mostra que o sufixo example.com UPN agora faz parte da entrada do domínio ad.example.com.

Capítulo 60. Usando nomes de hosts DNS canonicalizados na IdM

A canonicalização do DNS é desativada por padrão nos clientes de Gerenciamento de Identidade (IdM) para evitar riscos potenciais de segurança. Por exemplo, se um atacante controla o servidor DNS e um host no domínio, o atacante pode fazer com que o nome de host curto demo seja resolvido para malicious.example.com. Neste caso, o usuário se conecta a um servidor diferente do esperado.

Esta seção descreve como usar nomes de host canonicalizados nos clientes da IdM.

60.1. Adicionando um pseudônimo a um diretor anfitrião

Por padrão, os clientes de Gerenciamento de Identidade (IdM) inscritos através do comando ipa-client-install não permitem o uso de nomes de host curtos nos princípios de serviço. Por exemplo, os usuários podem usar apenas host/demo.example.com@EXAMPLE.COM ao invés de host/demo@EXAMPLE.COM ao acessar um serviço.

Esta seção explica como adicionar um pseudônimo a um diretor Kerberos. Note que você pode, alternativamente, ativar a canonização dos nomes dos anfitriões no arquivo /etc/krb5.conf. Para detalhes, veja Seção 60.2, “Permitindo a canonicalização de nomes de anfitriões em princípios de serviço em clientes”.

Pré-requisitos

  • O cliente IdM é instalado.
  • O nome do anfitrião é único na rede.

Procedimento

  1. Autenticar-se na IdM como usuário do admin:

    $ parentes admin
  2. Acrescente o pseudônimo ao principal anfitrião. Por exemplo, para adicionar o pseudônimo demo ao principal anfitrião demo.examle.com:

    $ ipa host-add-principal demo.example.com --principal=demo

60.2. Permitindo a canonicalização de nomes de anfitriões em princípios de serviço em clientes

Esta seção descreve como você possibilita a canonicalização de nomes de anfitriões em serviços principais de clientes.

Observe que se você usar os pseudônimos principais do host, conforme descrito em Seção 60.1, “Adicionando um pseudônimo a um diretor anfitrião”, não é necessário habilitar a canonicalização.

Pré-requisitos

  • O cliente de Gerenciamento de Identidade (IdM) é instalado.
  • Você está logado no cliente IdM como usuário do root.
  • O nome do anfitrião é único na rede.

Procedimento

  1. Defina o parâmetro dns_canonicalize_hostname na seção [libdefaults] no arquivo /etc/krb5.conf para false:

    [libdefaults]
    ...
    dns_canonicalize_hostname = true

60.3. Opções para uso de nomes de host com a canonicalização do nome de host DNS habilitada

Se você definir dns_canonicalize_hostname = true no arquivo /etc/krb5.conf como explicado em Seção 60.2, “Permitindo a canonicalização de nomes de anfitriões em princípios de serviço em clientes”, você tem as seguintes opções ao usar um nome de anfitrião em um diretor de serviço:

  • Em ambientes de Gerenciamento de Identidade (IdM), você pode usar o nome completo do anfitrião em um principal serviço, como host/demo.example.com@EXAMPLE.COM.
  • Em ambientes sem IdM, mas se o host RHEL como membro de um domínio Active Directory (AD), nenhuma outra consideração é necessária, pois os controladores de domínio AD (DC) criam automaticamente princípios de serviço para os nomes NetBIOS das máquinas inscritas no AD.

Capítulo 61. Gerenciando a configuração global do DNS no IdM usando playbooks Ansible

Usando o módulo Red Hat Ansible Engine dnsconfig, você pode configurar a configuração global para o DNS do Gerenciamento de Identidade (IdM). As configurações definidas na configuração global do DNS são aplicadas a todos os servidores DNS do IdM. Entretanto, a configuração global tem prioridade menor do que a configuração para uma zona DNS IdM específica.

O módulo dnsconfig suporta as seguintes variáveis:

  • Os forwarders globais, especificamente seus endereços IP e o porto utilizado para a comunicação.
  • A política de envio global: apenas, primeiro, ou nenhum. Para mais detalhes sobre esses tipos de políticas de encaminhamento DNS, veja as políticas de encaminhamento DNS em IdM.
  • A sincronização das zonas de pesquisa para frente e para trás.

Pré-requisitos


Este capítulo inclui as seguintes seções:

61.1. Como a IdM garante que os forwarders globais do /etc/resolv.conf não sejam removidos pelo NetworkManager

A instalação do Gerenciamento de Identidade (IdM) com DNS integrado configura o arquivo /etc/resolv.conf para apontar para o endereço 127.0.0.1 localhost:

# Generated by NetworkManager
search idm.example.com
nameserver 127.0.0.1

Em certos ambientes, tais como redes que utilizam Dynamic Host Configuration Protocol (DHCP), o serviço NetworkManager pode reverter as mudanças no arquivo /etc/resolv.conf. Para tornar a configuração do DNS persistente, o processo de instalação do DNS do IdM também configura o serviço NetworkManager da seguinte maneira:

  1. O script de instalação do DNS cria um arquivo de configuração /etc/NetworkManager/conf.d/zzz-ipa.conf NetworkManager para controlar a ordem de busca e a lista de servidores DNS:

    # auto-generated by IPA installer
    [main]
    dns=default
    
    [global-dns]
    searches=$DOMAIN
    
    [global-dns-domain-*]
    servers=127.0.0.1
  2. O serviço NetworkManager é recarregado, o que sempre cria o arquivo /etc/resolv.conf com as configurações do último arquivo no diretório /etc/NetworkManager/conf.d/. Este é neste caso o arquivo zzz-ipa.conf.
Importante

Não modifique o arquivo /etc/resolv.conf manualmente.

61.2. Garantindo a presença de um forwarder global DNS na IdM usando o Ansible

Esta seção descreve como um administrador de Gerenciamento de Identidade (IdM) pode usar um Livro de Exercícios para garantir a presença de um encaminhador global de DNS no IdM. No procedimento de exemplo abaixo, o administrador do IdM garante a presença de um encaminhador global DNS para um servidor DNS com um endereço IP v4 de 7.7.9.9 e endereço IP v6 de 2001:db8::1:0 na porta 53.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible. Este é o host no qual você executa as etapas do procedimento.
  • Você sabe a senha do administrador da IdM.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra seu arquivo de inventário e certifique-se de que o servidor IdM que você deseja configurar esteja listado na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo forwarders-absent.yml. Por exemplo:

    $ cp forwarders-absent.yml garante a presença de um global-forwarder.yml
  4. Abra o arquivo ensure-presence-of-a-global-forwarder.yml para edição.
  5. Adapte o arquivo, definindo as seguintes variáveis:

    1. Altere a variável name para Playbook to ensure the presence of a global forwarder in IdM DNS.
    2. Na seção tasks, altere o name da tarefa para Ensure the presence of a DNS global forwarder to 7.7.9.9 and 2001:db8::1:0 on port 53.
    3. Na seção forwarders da parte ipadnsconfig:

      1. Alterar o primeiro valor ip_address para o endereço IPv4 do forwarder global: 7.7.9.9.
      2. Altere o segundo valor ip_address para o endereço IPv6 do forwarder global: 2001:db8::1:0.
      3. Verifique se o valor port está definido para 53.
    4. Mude o state para present.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Playbook to ensure the presence of a global forwarder in IdM DNS
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure the presence of a DNS global forwarder to 7.7.9.9 and 2001:db8::1:0 on port 53
        ipadnsconfig:
          forwarders:
            - ip_address: 7.7.9.9
            - ip_address: 2001:db8::1:0
              port: 53
          state: present
  6. Salvar o arquivo.
  7. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file ensure-presence-of-a-global-forwarder.yml

61.3. Garantindo a ausência de um encaminhador global DNS na IdM usando o Ansible

Esta seção descreve como um administrador de Gerenciamento de Identidade (IdM) pode usar um Livro de Exercícios para garantir a ausência de um encaminhador global de DNS no IdM. No procedimento de exemplo abaixo, o administrador do IdM garante a ausência de um encaminhador global DNS para um servidor DNS com um endereço IP v4 de 8.8.6.6 e endereço IP v6 de 2001:4860:4860::8800 na porta 53.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible. Este é o host no qual você executa as etapas do procedimento.
  • Você sabe a senha do administrador da IdM.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra seu arquivo de inventário e certifique-se de que o servidor IdM que você deseja configurar esteja listado na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo forwarders-absent.yml. Por exemplo:

    $ cp forwarders-absent.yml garante a ausência de um global-forwarder.yml
  4. Abra o arquivo ensure-absence-of-a-global-forwarder.yml para edição.
  5. Adapte o arquivo, definindo as seguintes variáveis:

    1. Altere a variável name para Playbook to ensure the absence of a global forwarder in IdM DNS.
    2. Na seção tasks, altere o name da tarefa para Ensure the absence of a DNS global forwarder to 8.8.6.6 and 2001:4860:4860::8800 on port 53.
    3. Na seção forwarders da parte ipadnsconfig:

      1. Alterar o primeiro valor ip_address para o endereço IPv4 do forwarder global: 8.8.6.6.
      2. Altere o segundo valor ip_address para o endereço IPv6 do forwarder global: 2001:4860:4860::8800.
      3. Verifique se o valor port está definido para 53.
    4. Verifique se o site state está configurado para absent.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Playbook to ensure the absence of a global forwarder in IdM DNS
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure the absence of a DNS global forwarder to 8.8.6.6 and 2001:4860:4860::8800 on port 53
        ipadnsconfig:
          forwarders:
            - ip_address: 8.8.6.6
            - ip_address: 2001:4860:4860::8800
              port: 53
          state: absent
  6. Salvar o arquivo.
  7. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file ensure-absence-of-a-global-forwarder.yml

61.4. Políticas de encaminhamento de DNS na IdM

IdM apóia as políticas padrão BIND forward first e only, assim como a política forward específica da IdM none.

Avançar primeiro (default)
O serviço IdM BIND encaminha as consultas DNS para o encaminhador configurado. Se uma consulta falhar devido a um erro ou timeout do servidor, o BIND volta à resolução recursiva usando servidores na Internet. A política forward first é a política padrão, e é adequada para otimizar o tráfego DNS.
Somente para frente
O serviço IdM BIND encaminha as consultas DNS para o encaminhador configurado. Se uma consulta falhar devido a um erro ou timeout do servidor, BIND retorna um erro para o cliente. A política forward only é recomendada para ambientes com configuração DNS dividida.
Nenhum (forwarding disabled)
As consultas DNS não são encaminhadas com a política de encaminhamento do none. A desativação do encaminhamento só é útil como um substituto específico de zona para a configuração do encaminhamento global. Esta opção é o equivalente IdM de especificar uma lista vazia de encaminhadores na configuração BIND.
Nota

Você não pode usar o encaminhamento para combinar dados na IdM com dados de outros servidores DNS. Você só pode encaminhar consultas para subzonas específicas da zona mestre no DNS do IdM.

Por padrão, o serviço BIND não encaminha as consultas para outro servidor se o nome DNS consultado pertence a uma zona para a qual o servidor IdM é autoritário. Em tal situação, se o nome DNS consultado não puder ser encontrado no banco de dados do IdM, a resposta NXDOMAIN é devolvida. O reencaminhamento não é utilizado.

Exemplo 61.1. Cenário de exemplo

O servidor IdM é autoritário para a zona DNS test.example.. O BIND está configurado para encaminhar as consultas ao servidor DNS com o endereço IP 192.0.2.254.

Quando um cliente envia uma consulta para o nome DNS nonexistent.test.example., a BIND detecta que o servidor IdM é autoritário para a zona test.example. e não encaminha a consulta para o servidor 192.0.2.254.. Como resultado, o cliente DNS recebe a mensagem de erro NXDomain, informando ao usuário que o domínio consultado não existe.

61.5. Utilização de um caderno de exercícios possível para garantir que a primeira política seja definida na configuração global do DNS do IdM

Esta seção descreve como um administrador de Gerenciamento de Identidade (IdM) pode usar um Livro de Exercícios para garantir que a política de encaminhamento global no DNS do IdM seja definida para forward first.

Se você utiliza a política de encaminhamento de DNS forward first, as consultas DNS são encaminhadas para o encaminhador configurado. Se uma consulta falhar devido a um erro ou timeout do servidor, o BIND volta à resolução recursiva usando servidores na Internet. A política de encaminhamento primeiro é a política padrão. Ela é adequada para a otimização do tráfego.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible, o host no qual você executa o procedimento. Para mais informações, consulte Instalando o pacote Ansible-freeipa.
  • Você sabe a senha do administrador da IdM.
  • Seu ambiente IdM contém um servidor DNS integrado.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra seu arquivo de inventário e certifique-se de que o servidor IdM que você deseja configurar esteja listado na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo set-configuration.yml. Por exemplo:

    $ cp set-configuration.yml set-forward-policy-to-first.yml
  4. Abra o arquivo set-forward-policy-to-first.yml para edição.
  5. Adapte o arquivo definindo as seguintes variáveis na seção de tarefas ipadnsconfig:

    • Defina a variável ipaadmin_password para sua senha de administrador IdM.
    • Defina a variável forward_policy para first.

      Excluir todas as outras linhas do livro original que são irrelevantes. Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Playbook to set global forwarding policy to first
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Set global forwarding policy to first.
        ipadnsconfig:
          ipaadmin_password: Secret123
          forward_policy: first
  6. Salvar o arquivo.
  7. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file set-forward-policy-to-first.yml

Recursos adicionais

  • Para mais informações sobre os tipos de políticas de encaminhamento disponíveis no DNS da IdM, consulte as políticas de encaminhamento do DNS na IdM.
  • Para mais exemplos de livros-jogo possíveis usando o módulo ansible-freeipa ipadnsconfig , consulte o arquivo README-dnsconfig.md Markdown disponível no diretório /usr/share/doc/ansible-freeipa/. O arquivo também contém as definições das variáveis ipadnsconfig.
  • Para mais exemplos de livros didáticos possíveis usando o módulo ipadnsconfig, consulte o diretório /usr/share/doc/ansible-freeipa/playbooks/dnsconfig.

61.6. Utilização de um caderno de exercícios possível para garantir que os encaminhadores globais sejam desativados no DNS da IdM

Esta seção descreve como um administrador de Gerenciamento de Identidade (IdM) pode usar um Livro de Jogadas Ansioso para garantir que os encaminhadores globais sejam desativados no DNS do IdM. A desativação é feita através da definição da variável forward_policy para none.

A desativação dos encaminhadores globais faz com que as consultas DNS não sejam encaminhadas. A desativação do encaminhamento só é útil como uma sobreposição de zonas específicas para a configuração do encaminhamento global. Esta opção é o equivalente IdM de especificar uma lista vazia de encaminhadores na configuração BIND.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible, o host no qual você executa o procedimento. Para mais informações, consulte Instalando o pacote Ansible-freeipa.
  • Você sabe a senha do administrador da IdM.
  • Seu ambiente IdM contém um servidor DNS integrado.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra seu arquivo de inventário e certifique-se de que o servidor IdM que você deseja configurar esteja listado na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo disable-global-forwarders.yml. Por exemplo:

    $ cp disable-global-forwarders.yml disable-global-forwarders-copy.yml
  4. Abra o arquivo disable-global-forwarders-copy.yml para edição.
  5. Adapte o arquivo definindo as seguintes variáveis na seção de tarefas ipadnsconfig:

    • Defina a variável ipaadmin_password para sua senha de administrador IdM.
    • Defina a variável forward_policy para none.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Playbook to disable global DNS forwarders
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Disable global forwarders.
        ipadnsconfig:
          ipaadmin_password: Secret123
          forward_policy: none
  6. Salvar o arquivo.
  7. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file disable-global-forwarders-copy.yml

Recursos adicionais

  • Para mais informações sobre os tipos de políticas de encaminhamento disponíveis no DNS da IdM, consulte as políticas de encaminhamento do DNS na IdM.
  • Para mais exemplos de livros-jogo possíveis usando o módulo ansible-freeipa ipadnsconfig , consulte o arquivo README-dnsconfig.md Markdown disponível no diretório /usr/share/doc/ansible-freeipa/. O arquivo também contém as definições das variáveis ipadnsconfig.
  • Para mais exemplos de livros didáticos possíveis usando o módulo ipadnsconfig, consulte o diretório /usr/share/doc/ansible-freeipa/playbooks/dnsconfig.

61.7. Utilização de um livro de reprodução possível para garantir que a sincronização das zonas de pesquisa para frente e para trás seja desativada no DNS do IdM

Esta seção descreve como um administrador de Gerenciamento de Identidade (IdM) pode usar um Livro de Jogadas possível para garantir que as zonas de busca frente e verso não estejam sincronizadas no DNS do IdM.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible, o host no qual você executa o procedimento. Para mais informações, consulte Instalando o pacote Ansible-freeipa.
  • Você sabe a senha do administrador da IdM.
  • Seu ambiente IdM contém um servidor DNS integrado.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra seu arquivo de inventário e certifique-se de que o servidor IdM que você deseja configurar esteja listado na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo disallow-reverse-sync.yml. Por exemplo:

    $ cp disallow-reverse-sync.yml disallow-reverse-sync-copy.yml
  4. Abra o arquivo disallow-reverse-sync-copy.yml para edição.
  5. Adapte o arquivo definindo as seguintes variáveis na seção de tarefas ipadnsconfig:

    • Defina a variável ipaadmin_password para sua senha de administrador IdM.
    • Defina a variável allow_sync_ptr para no.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Playbook to disallow reverse record synchronization
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Disallow reverse record synchronization.
        ipadnsconfig:
          ipaadmin_password: Secret123
          allow_sync_ptr: no
  6. Salvar o arquivo.
  7. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file disallow-reverse-sync-copy.yml

Recursos adicionais

  • Para mais exemplos de livros-jogo possíveis usando o módulo ansible-freeipa ipadnsconfig , consulte o arquivo README-dnsconfig.md Markdown disponível no diretório /usr/share/doc/ansible-freeipa/. O arquivo também contém as definições das variáveis ipadnsconfig.
  • Para mais exemplos de livros didáticos possíveis usando o módulo ipadnsconfig, consulte o diretório /usr/share/doc/ansible-freeipa/playbooks/dnsconfig.

Capítulo 62. Gerenciando zonas DNS no IdM

Como administrador de Gerenciamento de Identidade (IdM), você pode gerenciar como funcionam as zonas DNS do IdM. O capítulo descreve os seguintes tópicos e procedimentos:

Pré-requisitos

62.1. Tipos de zonas DNS suportadas

O Gerenciamento de Identidade (IdM) suporta dois tipos de zonas DNS: primary e forward zonas. Esta seção descreve esses dois tipos de zonas e inclui um cenário de exemplo para o encaminhamento DNS.

Nota

Este guia utiliza a terminologia BIND para tipos de zona que é diferente da terminologia usada para o DNS do Microsoft Windows. As zonas primárias em BIND servem ao mesmo propósito que forward lookup zones e reverse lookup zones no DNS do Microsoft Windows. As zonas forward em BIND servem ao mesmo propósito que conditional forwarders no DNS do Microsoft Windows.

Zonas DNS primárias

As zonas DNS primárias contêm dados DNS confiáveis e podem aceitar atualizações DNS dinâmicas. Este comportamento é equivalente à configuração type master na configuração padrão BIND. Você pode gerenciar as zonas primárias usando os comandos ipa dnszone-*.

Em conformidade com as regras DNS padrão, cada zona primária deve conter registros start of authority (SOA) e nameserver (NS). IdM gera esses registros automaticamente quando a zona DNS é criada, mas você deve copiar os registros NS manualmente para a zona mãe para criar a delegação adequada.

De acordo com o comportamento padrão do BIND, as consultas de nomes para os quais o servidor não é autoritário são encaminhadas para outros servidores DNS. Esses servidores DNS, os chamados forwarders, podem ou não ter autoridade para a consulta.

Exemplo 62.1. Exemplo de cenário para o encaminhamento DNS

O servidor IdM contém a zona principal test.example.. Esta zona contém um registro de delegação NS para o nome sub.test.example.. Além disso, a zona test.example. é configurada com o endereço IP do reencaminhador 192.0.2.254 para a subzona sub.text.example.

Um cliente que pergunta o nome nonexistent.test.example. recebe a resposta NXDomain, e nenhum encaminhamento ocorre porque o servidor da IdM é autoritário para este nome.

Por outro lado, a consulta do nome host1.sub.test.example. é encaminhada ao encaminhador configurado 192.0.2.254 porque o servidor IdM não é autoritário para este nome.

Encaminhar zonas DNS

Do ponto de vista da IdM, as zonas DNS de encaminhamento não contêm quaisquer dados confiáveis. Na verdade, uma "zona" forward normalmente contém apenas duas informações:

  • Um nome de domínio
  • O endereço IP de um servidor DNS associado ao domínio

Todas as consultas para os nomes pertencentes ao domínio definido são encaminhadas para o endereço IP especificado. Este comportamento é equivalente à configuração type forward na configuração padrão BIND. Você pode gerenciar as zonas de encaminhamento usando os comandos ipa dnsforwardzone-*.

As zonas de DNS para frente são especialmente úteis no contexto dos trusts do IdM-Active Directory (AD). Se o servidor DNS da IdM é autoritário para a zona idm.example.com e o servidor DNS da AD é autoritário para a zona ad.example.com, então ad.example.com é uma zona de encaminhamento DNS para a zona primária idm.example.com. Isso significa que quando uma consulta vem de um cliente IdM para o endereço IP de somehost.ad.example.com, a consulta é encaminhada para um controlador de domínio AD especificado na zona de encaminhamento DNS de ad.example.com IdM.

62.2. Adicionando uma zona DNS primária na IDM Web UI

Esta seção descreve como adicionar uma zona DNS primária usando a interface Web de Gerenciamento de Identidade (IdM).

Pré-requisitos

  • Você está logado como administrador da IdM.

Procedimento

  1. Na interface web da IdM, clique em Network ServicesDNSDNS Zones.

    Figura 62.1. Gerenciando zonas primárias DNS IdM

    dns master zone management
  2. Clique em Adicionar no topo da lista de todas as zonas.
  3. Forneça o nome da zona.

    Figura 62.2. Entrando em uma nova zona primária IdM

    dns master zone enter
  4. Clique em Adicionar.

62.3. Adicionando uma zona DNS primária em IdM CLI

Esta seção descreve como adicionar uma zona DNS primária na interface de linha de comando do Gerenciamento de Identidade (IdM) (CLI).

Pré-requisitos

  • Você está logado como administrador da IdM.

Procedimento

  • O comando ipa dnszone-add acrescenta uma nova zona ao domínio DNS. Para adicionar uma nova zona, é necessário especificar o nome do novo subdomínio. Você pode passar o nome do subdomínio diretamente com o comando:

    $ ipa dnszone-add newzone.idm.example.com

    Se você não passar o nome para ipa dnszone-add, o roteiro pede automaticamente.

Recursos adicionais

  • O comando ipa dnszone-add também aceita várias opções de linha de comando. Para obter uma lista completa dessas opções, execute o comando ipa dnszone-add --help.

62.4. Removendo uma zona DNS primária na IDM Web UI

Esta seção descreve como remover uma zona DNS primária do Gerenciamento de Identidade (IdM) usando a interface web do IdM.

Pré-requisitos

  • Você está logado como administrador da IdM.

Procedimento

  1. Na interface web da IdM, clique em Network ServicesDNSDNS Zones.
  2. Selecione a caixa de seleção pelo nome da zona e clique em Excluir.

    Figura 62.3. Remoção de uma zona DNS principal

    dns zone delete
  3. Na janela de diálogo Remove DNS zones, confirme que você deseja excluir a zona selecionada.

62.5. Remoção de uma zona DNS primária em IdM CLI

Esta seção descreve como remover uma zona DNS primária do Gerenciamento de Identidade (IdM) usando a interface de linha de comando do IdM (CLI).

Pré-requisitos

  • Você está logado como administrador da IdM.

Procedimento

  • Para remover uma zona DNS primária, digite o comando ipa dnszone-del, seguido do nome da zona que você deseja remover. Por exemplo:

    $ ipa dnszone-del idm.example.com

62.6. Prioridades de configuração do DNS

Você pode configurar muitas opções de configuração DNS em três níveis diferentes. Cada nível tem uma prioridade diferente.

Configuração específica da zona
O nível de configuração específica para uma determinada zona definida na IdM tem a mais alta prioridade. Você pode gerenciar a configuração específica de uma zona usando os comandos ipa dnszone-* e ipa dnsforwardzone-*.
Configuração DNS global
Se nenhuma configuração de zona específica for definida, o IdM usa a configuração DNS global armazenada no LDAP. Você pode gerenciar a configuração do DNS global usando os comandos ipa dnsconfig-*. As configurações definidas na configuração do DNS global são aplicadas a todos os servidores DNS do IdM.
Configuração em /etc/named.conf

A configuração definida no arquivo /etc/named.conf em cada servidor DNS da IdM tem a prioridade mais baixa. Ela é específica para cada servidor e deve ser editada manualmente.

O arquivo /etc/named.conf normalmente é usado apenas para especificar o encaminhamento DNS para um cache DNS local. Outras opções são gerenciadas usando os comandos para configuração DNS de zonas específicas e globais mencionados acima.

Você pode configurar as opções DNS em vários níveis ao mesmo tempo. Nesses casos, a configuração com maior prioridade tem precedência sobre a configuração definida em níveis inferiores.

62.7. Atributos de configuração das zonas DNS primárias do IdM

O Gerenciamento de Identidade (IdM) cria uma nova zona com certas configurações padrão, tais como os períodos de atualização, configurações de transferência ou configurações de cache. Nos atributos da zona DNS do IdM, você pode encontrar os atributos da configuração padrão da zona que pode ser modificada usando uma das seguintes opções:

Além de definir as informações reais para a zona, as configurações definem como o servidor DNS lida com as entradas de registros start of authority (SOA) e como atualiza seus registros a partir do servidor de nomes DNS.

Tabela 62.1. Atributos de zona DNS IdM

AtributoOpção de Linha de ComandoDescrição

Servidor de nomes autorizado

--name-server

Define o nome de domínio do servidor de nomes DNS principal, também conhecido como SOA MNAME.

Por padrão, cada servidor IdM se anuncia no campo SOA MNAME. Conseqüentemente, o valor armazenado no LDAP usando --name-server é ignorado.

Endereço de e-mail do administrador

--admin-email

Define o endereço de e-mail a ser usado pelo administrador da zona. Este padrão é o padrão da conta raiz no host.

Série SOA

--serial

Estabelece um número de série no registro SOA. Note que o IdM define o número da versão automaticamente e não se espera que os usuários o modifiquem.

Atualização SOA

--refresh

Define o intervalo, em segundos, para que um servidor DNS secundário espere antes de solicitar atualizações do servidor DNS primário.

Tentativa de SOA

--retry

Define o tempo, em segundos, para esperar antes de tentar novamente uma operação de atualização falhada.

A SOA expira

--expire

Define o tempo, em segundos, em que um servidor DNS secundário tentará realizar uma atualização antes de terminar a tentativa de operação.

Mínimo SOA

--minimum

Define o valor de tempo de vida (TTL) em segundos para cache negativo de acordo com a RFC 2308.

Tempo de SOA para viver

--ttl

Define TTL em segundos para registros no ápice da zona. Na zona example.com, por exemplo, todos os registros (A, NS ou SOA) sob o nome example.com são configurados, mas nenhum outro nome de domínio, como test.example.com, é afetado.

Tempo padrão para viver

--default-ttl

Define o valor padrão de tempo de vida (TTL) em segundos para caching negativo para todos os valores em uma zona que nunca teve um valor TTL individual definido antes. Requer um reinício do serviço named-pkcs11 em todos os servidores DNS da IdM após as mudanças para ter efeito.

Política de atualização BIND

--update-policy

Define as permissões permitidas aos clientes na zona DNS.

Atualização dinâmica

--dynamic-update=TRUE|FALSE

Permite atualizações dinâmicas dos registros DNS para os clientes.

Observe que se isto for definido como falso, as máquinas clientes IdM não poderão adicionar ou atualizar seu endereço IP.

Permitir transferência

--allow-transfer=string

Fornece uma lista de endereços IP ou nomes de rede que podem transferir a zona em questão, separados por ponto-e-vírgula (;).

As transferências de zona são desativadas por padrão. O valor padrão --allow-transfer é none.

Permitir consulta

--allow-query

Fornece uma lista de endereços IP ou nomes de rede que são autorizados a emitir consultas DNS, separados por ponto-e-vírgula (;).

Permitir a sincronização PTR

--allow-sync-ptr=1|0

Define se os registros A ou AAAA (forward records) para a zona serão sincronizados automaticamente com os registros PTR (reverse).

Transitários de zona

--forwarder=IP_address

Especifica um forwarder especificamente configurado para a zona DNS. Este é separado de qualquer encaminhador global usado no domínio IdM.

Para especificar vários forwarders, use a opção várias vezes.

Política para o futuro

--forward-policy=none|none|somente|primeiro

Especifica a política futura. Para informações sobre as políticas suportadas, consulte as políticas de encaminhamento DNS na IdM.

62.8. Editando a configuração de uma zona DNS primária na IDM Web UI

Esta seção descreve como editar os atributos de configuração de um DNS primário de Gerenciamento de Identidade (IdM) usando a interface web do IdM.

Pré-requisitos

  • Você está logado como administrador da IdM.

Procedimento

  1. Na interface web da IdM, clique em Network ServicesDNSDNS Zones.

    Figura 62.4. Gestão de zonas primárias DNS

    dns master zone management
  2. Na seção DNS Zones, clique no nome da zona na lista de todas as zonas para abrir a página da zona DNS.

    Figura 62.5. Edição de uma zona primária

    dns master zone edit
  3. Clique em Settings.

    Figura 62.6. A guia Configurações na página de edição da zona primária

    dns master zone page
  4. Alterar a configuração da zona, conforme necessário.

    Para informações sobre as configurações disponíveis, consulte os atributos da zona DNS do IdM.

  5. Clique em Salvar para confirmar a nova configuração.

    Nota

    Se você estiver mudando o tempo padrão de vida (TTL) de uma zona, reinicie o serviço named-pkcs11 em todos os servidores DNS da IdM para que as mudanças entrem em vigor. Todas as outras configurações são ativadas automaticamente imediatamente.

62.9. Editando a configuração de uma zona DNS primária em IdM CLI

Esta seção descreve como editar a configuração de uma zona DNS primária usando a interface de linha de comando (CLI) do Gerenciamento de Identidade (IdM).

Pré-requisitos

  • Você está logado como administrador da IdM.

Procedimento

  • Para modificar uma zona DNS primária existente, use o comando ipa dnszone-mod. Por exemplo, para definir o tempo de espera antes de tentar novamente uma operação de atualização falhada para 1800 segundos:

    $ ipa dnszone-mod --retry 1800

    Para mais informações sobre as configurações disponíveis e suas opções de CLI correspondentes, consulte os atributos da zona DNS do IdM.

    Se uma configuração específica não tiver um valor na entrada da zona DNS que você está modificando, o comando ipa dnszone-mod adiciona o valor. Se a configuração não tiver um valor, o comando sobrescreve o valor atual com o valor especificado.

    Nota

    Se você estiver mudando o tempo padrão de vida (TTL) de uma zona, reinicie o serviço named-pkcs11 em todos os servidores DNS da IdM para que as mudanças entrem em vigor. Todas as outras configurações são ativadas automaticamente imediatamente.

Recursos adicionais

  • Para obter informações detalhadas sobre ipa dnszone-mod e suas opções, execute o comando ipa dnszone-mod --help.

62.10. Transferências de zonas na IdM

Esta seção descreve como funcionam as transferências de zona em uma implantação de Gerenciamento de Identidade (IdM) que integrou o DNS.

Os servidores de nomes mantêm dados autorizados para suas zonas. Se você fizer alterações na zona em um servidor DNS que seja autoritário para a zona zone A DNS, você deve distribuir as alterações entre os outros servidores de nomes no domínio DNS IdM que estão fora do zone A. Um zone transfer copia todos os registros de recursos de um servidor de nomes para outro.

Importante

O DNS integrado ao IdM pode ser escrito por diferentes servidores simultaneamente. Os números de série Start of Authority (SOA) nas zonas IdM não são sincronizados entre os servidores DNS individuais da IdM. Por este motivo, configure seus servidores DNS fora da zona a ser transferida para usar apenas um servidor DNS específico dentro da zona a ser transferida. Isto evita falhas de transferência de zona causadas por números de série SOA não sincronizados.

IdM suporta transferências de zona de acordo com as normas RFC 5936 (AXFR) e RFC 1995 (IXFR).

Recursos adicionais

62.11. Permitindo transferências de zonas na IDM Web UI

Esta seção descreve como permitir transferências de zona no Gerenciamento de Identidade (IdM) usando a interface web do IdM.

Pré-requisitos

  • Você está logado como administrador da IdM.

Procedimento

  1. Na interface web da IdM, clique em Network ServicesDNSDNS Zones.
  2. Clique em Settings.
  3. Em Allow transfer, especifique os servidores de nomes para os quais você deseja transferir os registros da zona.

    Figura 62.7. Possibilitando transferências de zonas

    dns allow transfer
  4. Clique em Salvar na parte superior da página da zona DNS para confirmar a nova configuração.

62.12. Permitindo transferências de zonas no IdM CLI

Esta seção descreve como permitir transferências de zona no Gerenciamento de Identidade (IdM) usando a interface de linha de comando do IdM (CLI).

Pré-requisitos

  • Você está logado como administrador da IdM.
  • Você tem acesso root aos servidores DNS secundários.

Procedimento

  • Para habilitar transferências de zona no serviço BIND, digite o comando ipa dnszone-mod e especifique a lista de servidores de nomes que estão fora da zona a ser transferida para a qual os registros da zona serão transferidos usando a opção --allow-transfer. Por exemplo:

    $ ipa dnszone-mod --allow-transfer=192.0.2.1;198.51.100.1;203.0.113.1 idm.example.com

Etapas de verificação

  1. SSH para um dos servidores DNS para o qual a transferência de zona foi habilitada:

    $ ssh 192.0.2.1
  2. Transferir a zona DNS do IdM usando uma ferramenta como o utilitário dig:

    # dig @ipa-server zone_name AXFR

Se o comando não retornar nenhum erro, você habilitou com sucesso a transferência de zona para zone_name.

62.13. Recursos adicionais

Capítulo 63. Utilização de playbooks possíveis para gerenciar zonas DNS IdM

Como administrador de Gerenciamento de Identidade (IdM), você pode gerenciar como funcionam as zonas DNS do IdM usando o módulo dnszone disponível no pacote ansible-freeipa. O capítulo descreve os seguintes tópicos e procedimentos:

Pré-requisitos

63.1. Tipos de zonas DNS suportadas

O Gerenciamento de Identidade (IdM) suporta dois tipos de zonas DNS: primary e forward zonas. Esta seção descreve esses dois tipos de zonas e inclui um cenário de exemplo para o encaminhamento DNS.

Nota

Este guia utiliza a terminologia BIND para tipos de zona que é diferente da terminologia usada para o DNS do Microsoft Windows. As zonas primárias em BIND servem ao mesmo propósito que forward lookup zones e reverse lookup zones no DNS do Microsoft Windows. As zonas forward em BIND servem ao mesmo propósito que conditional forwarders no DNS do Microsoft Windows.

Zonas DNS primárias

As zonas DNS primárias contêm dados DNS confiáveis e podem aceitar atualizações DNS dinâmicas. Este comportamento é equivalente à configuração type master na configuração padrão BIND. Você pode gerenciar as zonas primárias usando os comandos ipa dnszone-*.

Em conformidade com as regras DNS padrão, cada zona primária deve conter registros start of authority (SOA) e nameserver (NS). IdM gera esses registros automaticamente quando a zona DNS é criada, mas você deve copiar os registros NS manualmente para a zona mãe para criar a delegação adequada.

De acordo com o comportamento padrão do BIND, as consultas de nomes para os quais o servidor não é autoritário são encaminhadas para outros servidores DNS. Esses servidores DNS, os chamados forwarders, podem ou não ter autoridade para a consulta.

Exemplo 63.1. Exemplo de cenário para o encaminhamento DNS

O servidor IdM contém a zona principal test.example.. Esta zona contém um registro de delegação NS para o nome sub.test.example.. Além disso, a zona test.example. é configurada com o endereço IP do reencaminhador 192.0.2.254 para a subzona sub.text.example.

Um cliente que pergunta o nome nonexistent.test.example. recebe a resposta NXDomain, e nenhum encaminhamento ocorre porque o servidor da IdM é autoritário para este nome.

Por outro lado, a consulta do nome host1.sub.test.example. é encaminhada ao encaminhador configurado 192.0.2.254 porque o servidor IdM não é autoritário para este nome.

Encaminhar zonas DNS

Do ponto de vista da IdM, as zonas DNS de encaminhamento não contêm quaisquer dados confiáveis. Na verdade, uma "zona" forward normalmente contém apenas duas informações:

  • Um nome de domínio
  • O endereço IP de um servidor DNS associado ao domínio

Todas as consultas para os nomes pertencentes ao domínio definido são encaminhadas para o endereço IP especificado. Este comportamento é equivalente à configuração type forward na configuração padrão BIND. Você pode gerenciar as zonas de encaminhamento usando os comandos ipa dnsforwardzone-*.

As zonas de DNS para frente são especialmente úteis no contexto dos trusts do IdM-Active Directory (AD). Se o servidor DNS da IdM é autoritário para a zona idm.example.com e o servidor DNS da AD é autoritário para a zona ad.example.com, então ad.example.com é uma zona de encaminhamento DNS para a zona primária idm.example.com. Isso significa que quando uma consulta vem de um cliente IdM para o endereço IP de somehost.ad.example.com, a consulta é encaminhada para um controlador de domínio AD especificado na zona de encaminhamento DNS de ad.example.com IdM.

63.2. Atributos de configuração das zonas DNS primárias do IdM

O Gerenciamento de Identidade (IdM) cria uma nova zona com certas configurações padrão, tais como os períodos de atualização, configurações de transferência ou configurações de cache. Nos atributos da zona DNS do IdM, você pode encontrar os atributos da configuração padrão da zona que pode ser modificada usando uma das seguintes opções:

Além de definir as informações reais para a zona, as configurações definem como o servidor DNS lida com as entradas de registros start of authority (SOA) e como atualiza seus registros a partir do servidor de nomes DNS.

Tabela 63.1. Atributos de zona DNS IdM

Atributovariável ansible-freeipaDescrição

Servidor de nomes autorizado

name_server

Define o nome de domínio do servidor de nomes DNS principal, também conhecido como SOA MNAME.

Por padrão, cada servidor IdM se anuncia no campo SOA MNAME. Conseqüentemente, o valor armazenado no LDAP usando --name-server é ignorado.

Endereço de e-mail do administrador

admin_email

Define o endereço de e-mail a ser usado pelo administrador da zona. Este padrão é o padrão da conta raiz no host.

Série SOA

serial

Estabelece um número de série no registro SOA. Note que o IdM define o número da versão automaticamente e não se espera que os usuários o modifiquem.

Atualização SOA

refresh

Define o intervalo, em segundos, para que um servidor DNS secundário espere antes de solicitar atualizações do servidor DNS primário.

Tentativa de SOA

retry

Define o tempo, em segundos, para esperar antes de tentar novamente uma operação de atualização falhada.

A SOA expira

expire

Define o tempo, em segundos, em que um servidor DNS secundário tentará realizar uma atualização antes de terminar a tentativa de operação.

Mínimo SOA

minimum

Define o valor de tempo de vida (TTL) em segundos para cache negativo de acordo com a RFC 2308.

Tempo de SOA para viver

ttl

Define TTL em segundos para registros no ápice da zona. Na zona example.com, por exemplo, todos os registros (A, NS ou SOA) sob o nome example.com são configurados, mas nenhum outro nome de domínio, como test.example.com, é afetado.

Tempo padrão para viver

default_ttl

Define o valor padrão de tempo de vida (TTL) em segundos para caching negativo para todos os valores em uma zona que nunca teve um valor TTL individual definido antes. Requer um reinício do serviço named-pkcs11 em todos os servidores DNS da IdM após as mudanças para ter efeito.

Política de atualização BIND

update_policy

Define as permissões permitidas aos clientes na zona DNS.

Atualização dinâmica

dynamic_update=TRUE|FALSE

Permite atualizações dinâmicas dos registros DNS para os clientes.

Observe que se isto for definido como falso, as máquinas clientes IdM não poderão adicionar ou atualizar seu endereço IP.

Permitir transferência

allow_transfer=string

Fornece uma lista de endereços IP ou nomes de rede que podem transferir a zona em questão, separados por ponto-e-vírgula (;).

As transferências de zona são desativadas por padrão. O valor padrão allow_transfer é none.

Permitir consulta

allow_query

Fornece uma lista de endereços IP ou nomes de rede que são autorizados a emitir consultas DNS, separados por ponto-e-vírgula (;).

Permitir a sincronização PTR

allow_sync_ptr=1|0

Define se os registros A ou AAAA (forward records) para a zona serão sincronizados automaticamente com os registros PTR (reverse).

Transitários de zona

forwarder=IP_address

Especifica um forwarder especificamente configurado para a zona DNS. Este é separado de qualquer encaminhador global usado no domínio IdM.

Para especificar vários forwarders, use a opção várias vezes.

Política para o futuro

forward_policy=none|none|somente|primeiro

Especifica a política futura. Para informações sobre as políticas suportadas, consulte as políticas de encaminhamento DNS na IdM.

Recursos adicionais

  • Você pode ver mais definições dos atributos do módulo ansible-freeipa ipadnszone no arquivo README-dnszone.md Markdown, disponível no diretório /usr/share/doc/ansible-freeipa/.

63.3. Usando Ansible to create a primary zone in IdM DNS

Esta seção mostra como um administrador de Gerenciamento de Identidade (IdM) pode usar um Livro de Jogadas Ansioso para garantir a existência de uma zona DNS primária. No exemplo utilizado no procedimento abaixo, um administrador de IdM garante a presença da zona DNS zone.idm.example.com.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible. Este é o host no qual você executa as etapas do procedimento.
  • Você sabe a senha do administrador da IdM.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/dnszone:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnszone
  2. Abra seu arquivo de inventário e certifique-se de que o servidor IdM que você deseja configurar esteja listado na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo dnszone-present.yml. Por exemplo:

    $ cp dnszone-present.yml dnszone-present-copy.yml
  4. Abra o arquivo dnszone-present-copy.yml para edição.
  5. Adapte o arquivo definindo as seguintes variáveis na seção de tarefas ipadnszone:

    • Defina a variável ipaadmin_password para sua senha de administrador IdM.
    • Defina a variável zone_name para zone.idm.example.com.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Ensure dnszone present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure zone is present.
        ipadnszone:
          ipaadmin_password: Secret123
          zone_name: zone.idm.example.com
          state: present
  6. Salvar o arquivo.
  7. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file dnszone-present-copy.yml

Recursos adicionais

  • Para mais informações sobre a zona DNS, consulte Tipos de zona DNS suportados.
  • Você pode ver mais exemplos de playbooks possíveis para o módulo ansible-freeipa ipadnszone no arquivo README-dnszone.md Markdown, disponível no diretório /usr/share/doc/ansible-freeipa/. O arquivo também contém as definições das variáveis ipadnszone.
  • Você pode ver exemplos de playbooks possíveis para o módulo ipadnszone no diretório /usr/share/doc/ansible-freeipa/playbooks/dnszone.

63.4. Utilização de um caderno de exercícios para garantir a presença de uma zona DNS primária no IdM com múltiplas variáveis

Esta seção mostra como um administrador de Gerenciamento de Identidade (IdM) pode usar um Livro de Jogadas Ansioso para garantir a existência de uma zona DNS primária. No exemplo utilizado no procedimento abaixo, um administrador de IdM garante a presença da zona DNS zone.idm.example.com. A Pasta de reprodução possível configura vários parâmetros da zona.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible. Este é o host no qual você executa as etapas do procedimento.
  • Você sabe a senha do administrador da IdM.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/dnszone:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnszone
  2. Abra seu arquivo de inventário e certifique-se de que o servidor IdM que você deseja configurar esteja listado na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo dnszone-all-params.yml. Por exemplo:

    $ cp dnszone-all-params.yml dnszone-all-params-copy.yml
  4. Abra o arquivo dnszone-all-params-copy.yml para edição.
  5. Adapte o arquivo definindo as seguintes variáveis na seção de tarefas ipadnszone:

    • Defina a variável ipaadmin_password para sua senha de administrador IdM.
    • Defina a variável zone_name para zone.idm.example.com.
    • Defina a variável allow_sync_ptr como verdadeira se você quiser permitir a sincronização de registros para frente e para trás, ou seja, a sincronização de registros A e AAAA com registros PTR.
    • Defina a variável dynamic_update para true para permitir que as máquinas clientes IdM adicionem ou atualizem seus endereços IP.
    • Defina a variável dnssec como verdadeira para permitir a assinatura inline DNSSEC de registros na zona.
    • Defina a variável allow_transfer para os endereços IP dos servidores de nomes secundários na zona.
    • Defina a variável allow_query para os endereços IP ou redes que estão autorizados a emitir consultas.
    • Defina a variável forwarders para os endereços IP dos forwarders globais.
    • Defina a variável serial para o número de série do registro SOA.
    • Definir os valores refresh, retry, expire, minimum, ttl, e default_ttl para os registros DNS na zona.
    • Defina o registro NSEC3PARAM para a zona usando a variável nsec3param_rec.
    • Defina a variável skip_overlap_check como verdadeira para forçar a criação de DNS mesmo que ela se sobreponha a uma zona existente.
    • Defina o skip_nameserver_check como verdadeiro para forçar a criação da zona DNS mesmo que o nameserver não seja resolúvel.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Ensure dnszone present
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure zone is present.
        ipadnszone:
          ipaadmin_password: Secret123
          zone_name: zone.idm.example.com
          allow_sync_ptr: true
          dynamic_update: true
          dnssec: true
          allow_transfer:
            - 1.1.1.1
            - 2.2.2.2
          allow_query:
            - 1.1.1.1
            - 2.2.2.2
          forwarders:
            - ip_address: 8.8.8.8
            - ip_address: 8.8.4.4
              port: 52
          serial: 1234
          refresh: 3600
          retry: 900
          expire: 1209600
          minimum: 3600
          ttl: 60
          default_ttl: 90
          name_server: server.idm.example.com.
          admin_email: admin.admin@idm.example.com
          nsec3param_rec: "1 7 100 0123456789abcdef"
          skip_overlap_check: true
          skip_nameserver_check: true
          state: present
  6. Salvar o arquivo.
  7. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file dnszone-all-params-copy.yml

Recursos adicionais

  • Para mais informações sobre a zona DNS, consulte Tipos de zona DNS suportados.
  • Para mais informações sobre quais atributos de zona DNS você pode configurar no IdM, consulte Atributos de configuração de zonas DNS primárias do IdM.
  • Você pode ver mais exemplos de playbooks possíveis para o módulo ansible-freeipa ipadnszone no arquivo README-dnszone.md Markdown, disponível no diretório /usr/share/doc/ansible-freeipa/. O arquivo também contém as definições das variáveis ipadnszone.
  • Você pode ver exemplos de playbooks possíveis para o módulo ipadnszone no diretório /usr/share/doc/ansible-freeipa/playbooks/dnszone.

63.5. Utilização de um caderno de exercícios para garantir a presença de uma zona para pesquisa DNS reversa quando um endereço IP é dado

Esta seção mostra como um administrador de Gerenciamento de Identidade (IdM) pode usar um Livro de Jogadas Ansioso para garantir a existência de uma zona DNS reversa. No exemplo usado no procedimento abaixo, um administrador IdM garante a presença de uma zona de busca DNS reversa usando o endereço IP e o comprimento de prefixo de um host IdM.

O fornecimento do comprimento do prefixo do endereço IP de seu servidor DNS usando a variável name_from_ip permite que você controle o nome da zona. Se você não indicar o comprimento do prefixo, o sistema consulta os servidores DNS das zonas e, com base no valor name_from_ip de 192.168.1.2, a consulta pode retornar qualquer uma das seguintes zonas DNS:

  • 1.168.192.in-addr.arpa.
  • 168.192.in-addr.arpa.
  • 192.in-addr.arpa.

Como a zona devolvida pela consulta pode não ser o que você espera, name_from_ip só pode ser usado com a opção state definida para present para evitar remoções acidentais de zonas.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible. Este é o host no qual você executa as etapas do procedimento.
  • Você sabe a senha do administrador da IdM.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/dnszone:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnszone
  2. Abra seu arquivo de inventário e certifique-se de que o servidor IdM que você deseja configurar esteja listado na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo dnszone-reverse-from-ip.yml. Por exemplo:

    $ cp dnszone-reverse-from-ip.yml dnszone-reverse-from-ip-copy.yml
  4. Abra o arquivo dnszone-reverse-from-ip-copy.yml para edição.
  5. Adapte o arquivo definindo as seguintes variáveis na seção de tarefas ipadnszone:

    • Defina a variável ipaadmin_password para sua senha de administrador IdM.
    • Defina a variável name_from_ip para o IP de seu servidor de nomes IdM, e forneça seu comprimento de prefixo.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

      ---
      - name: Ensure dnszone present
        hosts: ipaserver
        become: true
      
        tasks:
        - name: Ensure zone for reverse DNS lookup is present.
          ipadnszone:
            ipaadmin_password: Secret123
            name_from_ip: 192.168.1.2/24
            state: present
          register: result
        - name: Display inferred zone name.
          debug:
            msg: "Zone name: {{ result.dnszone.name }}"

    O playbook cria uma zona para pesquisa DNS reversa a partir do endereço IP 192.168.1.2 e seu comprimento de prefixo de 24. Em seguida, o playbook exibe o nome da zona resultante.

  6. Salvar o arquivo.
  7. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file dnszone-reverse-from-ip-copy.yml

Recursos adicionais

  • Para mais informações sobre a zona DNS, consulte Tipos de zona DNS suportados.
  • Você pode ver mais exemplos de playbooks possíveis para o módulo ansible-freeipa ipadnszone no arquivo README-dnszone.md Markdown, disponível no diretório /usr/share/doc/ansible-freeipa/. O arquivo também contém as definições das variáveis ipadnszone.
  • Você pode ver exemplos de playbooks possíveis para o módulo ipadnszone no diretório /usr/share/doc/ansible-freeipa/playbooks/dnszone.

Capítulo 64. Gerenciando o encaminhamento DNS na IdM

Os seguintes procedimentos descrevem como configurar encaminhadores globais DNS e zonas de encaminhamento DNS na Web UI de Gerenciamento de Identidade (IdM), a CLI de IdM, e usando o Ansible:

64.1. As duas funções de um servidor DNS IdM

O encaminhamento DNS afeta a forma como um serviço DNS responde às consultas DNS. Por padrão, o serviço Berkeley Internet Name Domain (BIND) integrado ao IdM atua tanto como um servidor DNS authoritative quanto como um servidor DNS recursive:

Servidor DNS autorizado
Quando um cliente DNS consulta um nome pertencente a uma zona DNS para a qual o servidor IdM é autoritário, BIND responde com os dados contidos na zona configurada. Os dados autorizados têm sempre precedência sobre quaisquer outros dados.
Servidor DNS recursivo
Quando um cliente DNS consulta um nome para o qual o servidor IdM não tem autoridade, a BIND tenta resolver a consulta usando outros servidores DNS. Se os encaminhadores não forem definidos, o BIND pergunta aos servidores raiz na Internet e usa um algoritmo de resolução recursiva para responder à consulta DNS.

Em alguns casos, não é desejável deixar a BIND entrar em contato diretamente com outros servidores DNS e realizar a recorrência com base nos dados disponíveis na Internet. Você pode configurar o BIND para usar outro servidor DNS, um forwarder, para resolver a consulta.

Quando você configura o BIND para usar um forwarder, as consultas e respostas são encaminhadas para frente e para trás entre o servidor IdM e o forwarder, e o servidor IdM atua como o cache DNS para dados não autorizados.

64.2. Políticas de encaminhamento de DNS na IdM

IdM apóia as políticas padrão BIND forward first e only, assim como a política forward específica da IdM none.

Avançar primeiro (default)
O serviço IdM BIND encaminha as consultas DNS para o encaminhador configurado. Se uma consulta falhar devido a um erro ou timeout do servidor, o BIND volta à resolução recursiva usando servidores na Internet. A política forward first é a política padrão, e é adequada para otimizar o tráfego DNS.
Somente para frente
O serviço IdM BIND encaminha as consultas DNS para o encaminhador configurado. Se uma consulta falhar devido a um erro ou timeout do servidor, BIND retorna um erro para o cliente. A política forward only é recomendada para ambientes com configuração DNS dividida.
Nenhum (forwarding disabled)
As consultas DNS não são encaminhadas com a política de encaminhamento do none. A desativação do encaminhamento só é útil como um substituto específico de zona para a configuração do encaminhamento global. Esta opção é o equivalente IdM de especificar uma lista vazia de encaminhadores na configuração BIND.
Nota

Você não pode usar o encaminhamento para combinar dados na IdM com dados de outros servidores DNS. Você só pode encaminhar consultas para subzonas específicas da zona mestre no DNS do IdM.

Por padrão, o serviço BIND não encaminha as consultas para outro servidor se o nome DNS consultado pertence a uma zona para a qual o servidor IdM é autoritário. Em tal situação, se o nome DNS consultado não puder ser encontrado no banco de dados do IdM, a resposta NXDOMAIN é devolvida. O reencaminhamento não é utilizado.

Exemplo 64.1. Cenário de exemplo

O servidor IdM é autoritário para a zona DNS test.example.. O BIND está configurado para encaminhar as consultas ao servidor DNS com o endereço IP 192.0.2.254.

Quando um cliente envia uma consulta para o nome DNS nonexistent.test.example., a BIND detecta que o servidor IdM é autoritário para a zona test.example. e não encaminha a consulta para o servidor 192.0.2.254.. Como resultado, o cliente DNS recebe a mensagem de erro NXDomain, informando ao usuário que o domínio consultado não existe.

64.3. Adicionando um forwarder global na IDM Web UI

Esta seção descreve como adicionar um forwarder DNS global na interface web de gerenciamento de identidade (IdM).

Pré-requisitos

  • Você está logado na IdM WebUI como administrador da IdM.
  • Você conhece o endereço do Protocolo Internet (IP) do servidor DNS para o qual encaminhar as consultas.

Procedimento

  1. Na interface web da IdM, selecione Network ServicesDNS Global ConfigurationDNS.

    Selecting DNS Forward Zones from the DNS menu
  2. Na seção DNS Global Configuration, clique em Add.

    Selecting the Add button
  3. Especifique o endereço IP do servidor DNS que receberá as consultas DNS encaminhadas.

    Entering the IP address of the global forwarder
  4. Selecione o Forward policy.

    Selecting the DNS forward policy and saving the DNS global configuration
  5. Clique em Save na parte superior da janela.

Etapas de verificação

  1. Selecione Network ServicesDNS Global ConfigurationDNS.

    Selecting DNS Global Configuration in IdM Web UI
  2. Verifique se o forwarder global, com a política de forward que você especificou, está presente e habilitado na IDM Web UI.

    Verifying the presence of the global forwarder

64.4. Adicionando um forwarder global no CLI

Esta seção descreve como adicionar um forwarder DNS global da interface de linha de comando (CLI).

Pré-requisitos

  • Você está logado como administrador da IdM.
  • Você conhece o endereço do Protocolo Internet (IP) do servidor DNS para o qual encaminhar as consultas.

Procedimento

  • Use o comando ipa dnsconfig-mod para adicionar um novo forwarder global. Especifique o endereço IP do reencaminhador DNS com a opção --forwarder.

    [user@server ~]$ ipa dnsconfig-mod --forwarder=10.10.0.1
    Server will check DNS forwarder(s).
    This may take some time, please wait ...
      Global forwarders: 10.10.0.1
      IPA DNS servers: server.example.com

Etapas de verificação

  • Use o comando dnsconfig-show para exibir os forwarders globais.

    [user@server ~]$ ipa dnsconfig-show
      Global forwarders: 10.10.0.1
      IPA DNS servers: server.example.com

64.5. Adicionando uma Zona de Encaminhamento DNS na interface web do IdM

Esta seção descreve como adicionar uma zona de encaminhamento DNS na Interface Web de Gerenciamento de Identidade (IdM).

Importante

Não utilize zonas de avanço, a menos que seja absolutamente necessário. As zonas dianteiras não são uma solução padrão e sua utilização pode levar a comportamentos inesperados e problemáticos. Se você tiver que usar zonas de encaminhamento, limite seu uso para anular uma configuração de encaminhamento global.

Ao criar uma nova zona DNS, a Red Hat recomenda usar sempre a delegação DNS padrão usando registros de nameserver (NS) e para evitar zonas de encaminhamento. Na maioria dos casos, o uso de um forwarder global é suficiente, e as zonas de encaminhamento não são necessárias.

Pré-requisitos

  • Você está logado na IdM WebUI como administrador da IdM.
  • Você conhece o endereço do Protocolo Internet (IP) do servidor DNS para o qual encaminhar as consultas.

Procedimento

  1. Na interface web da IdM, selecione Network ServicesDNS Forward ZonesDNS.

    Selecting DNS Forward Zones from the DNS menu
  2. Na seção DNS Forward Zones, clique em Add.

    Selecting the Add button
  3. Na janela Add DNS forward zone, especifique o nome da zona de avanço.

    Entering the name of the new Forward Zone
  4. Clique no botão Add e especifique o endereço IP de um servidor DNS para receber a solicitação de encaminhamento. Você pode especificar vários encaminhadores por zona de encaminhamento.

    Specifying the IP address of the forwarder DNS server
  5. Selecione o Forward policy.

    Choosing a Forward policy
  6. Clique em Add na parte inferior da janela para adicionar a nova zona de avanço.

Etapas de verificação

  1. Na interface web da IdM, selecione Network ServicesDNS Forward ZonesDNS.

    Selecting DNS Forward Zones from the DNS menu
  2. Verifique se a zona de forwarders que você criou, com os forwarders e a política de forwarders que você especificou, está presente e habilitada na IDM Web UI.

    Verifying the new forward zone is present

64.6. Adicionando uma Zona de Encaminhamento DNS no CLI

Esta seção descreve como adicionar uma zona de encaminhamento DNS a partir da interface de linha de comando (CLI).

Importante

Não utilize zonas de avanço, a menos que seja absolutamente necessário. As zonas dianteiras não são uma solução padrão e sua utilização pode levar a comportamentos inesperados e problemáticos. Se você tiver que usar zonas de encaminhamento, limite seu uso para anular uma configuração de encaminhamento global.

Ao criar uma nova zona DNS, a Red Hat recomenda usar sempre a delegação DNS padrão usando registros de nameserver (NS) e para evitar zonas de encaminhamento. Na maioria dos casos, o uso de um forwarder global é suficiente, e as zonas de encaminhamento não são necessárias.

Pré-requisitos

  • Você está logado como administrador da IdM.
  • Você conhece o endereço do Protocolo Internet (IP) do servidor DNS para o qual encaminhar as consultas.

Procedimento

  • Use o comando dnsforwardzone-add para adicionar uma nova zona de avanço. Especifique pelo menos um forwarder com a opção --forwarder se a política forward não for none, e especifique a política forward com a opção --forward-policy.

    [user@server ~]$ ipa dnsforwardzone-add forward.example.com. --forwarder=10.10.0.14 --forwarder=10.10.1.15 --forward-policy=first
    
    Zone name: forward.example.com.
    Zone forwarders: 10.10.0.14, 10.10.1.15
    Forward policy: first

Etapas de verificação

  • Use o comando dnsforwardzone-show para exibir a zona de encaminhamento DNS que você acabou de criar.

    [user@server ~]$ ipa dnsforwardzone-show forward.example.com.
    
    Zone name: forward.example.com.
    Zone forwarders: 10.10.0.14, 10.10.1.15
    Forward policy: first

64.7. Estabelecendo um Encaminhador Global DNS na IdM usando o Ansible

Esta seção descreve como um administrador de Gerenciamento de Identidade (IdM) pode usar um Livro de Exercícios para estabelecer um Encaminhador Global de DNS no IdM.

No procedimento de exemplo abaixo, o administrador da IdM cria um encaminhador global de DNS para um servidor DNS com um endereço IP (Internet Protocol) v4 de 8.8.6.6 e endereço IPv6 de 2001:4860:4860::8800 na porta 53.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible. Este é o host no qual você executa as etapas do procedimento.
  • Você sabe a senha do administrador da IdM.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra seu arquivo de inventário e certifique-se de que o servidor IdM que você deseja configurar esteja listado na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo set-configuration.yml. Por exemplo:

    $ cp set-configuration.yml establish-global-forwarder.yml
  4. Abra o arquivo establish-global-forwarder.yml para edição.
  5. Adapte o arquivo, definindo as seguintes variáveis:

    1. Altere a variável name para Playbook to establish a global forwarder in IdM DNS.
    2. Na seção tasks, altere o name da tarefa para Create a DNS global forwarder to 8.8.6.6 and 2001:4860:4860::8800.
    3. Na seção forwarders da parte ipadnsconfig:

      1. Alterar o primeiro valor ip_address para o endereço IPv4 do forwarder global: 8.8.6.6.
      2. Altere o segundo valor ip_address para o endereço IPv6 do forwarder global: 2001:4860:4860::8800.
      3. Verifique se o valor port está definido para 53.
    4. Mude o forward_policy para first.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Playbook to establish a global forwarder in IdM DNS
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Create a DNS global forwarder to 8.8.6.6 and 2001:4860:4860::8800
        ipadnsconfig:
          forwarders:
            - ip_address: 8.8.6.6
            - ip_address: 2001:4860:4860::8800
              port: 53
          forward_policy: first
          allow_sync_ptr: yes
  6. Salvar o arquivo.
  7. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file establish-global-forwarder.yml

Recursos adicionais

  • Você pode ver mais exemplos de playbooks possíveis para o módulo ansible-freeipa ipadnsconfig no arquivo README-dnsconfig.md Markdown, disponível no diretório /usr/share/doc/ansible-freeipa/. O arquivo também contém as definições das variáveis ipadnsconfig.

64.8. Garantindo a presença de um forwarder global DNS na IdM usando o Ansible

Esta seção descreve como um administrador de Gerenciamento de Identidade (IdM) pode usar um Livro de Exercícios para garantir a presença de um encaminhador global de DNS no IdM. No procedimento de exemplo abaixo, o administrador do IdM garante a presença de um encaminhador global DNS para um servidor DNS com um endereço IP v4 de 7.7.9.9 e endereço IP v6 de 2001:db8::1:0 na porta 53.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible. Este é o host no qual você executa as etapas do procedimento.
  • Você sabe a senha do administrador da IdM.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra seu arquivo de inventário e certifique-se de que o servidor IdM que você deseja configurar esteja listado na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo forwarders-absent.yml. Por exemplo:

    $ cp forwarders-absent.yml garante a presença de um global-forwarder.yml
  4. Abra o arquivo ensure-presence-of-a-global-forwarder.yml para edição.
  5. Adapte o arquivo, definindo as seguintes variáveis:

    1. Altere a variável name para Playbook to ensure the presence of a global forwarder in IdM DNS.
    2. Na seção tasks, altere o name da tarefa para Ensure the presence of a DNS global forwarder to 7.7.9.9 and 2001:db8::1:0 on port 53.
    3. Na seção forwarders da parte ipadnsconfig:

      1. Alterar o primeiro valor ip_address para o endereço IPv4 do forwarder global: 7.7.9.9.
      2. Altere o segundo valor ip_address para o endereço IPv6 do forwarder global: 2001:db8::1:0.
      3. Verifique se o valor port está definido para 53.
    4. Mude o state para present.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Playbook to ensure the presence of a global forwarder in IdM DNS
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure the presence of a DNS global forwarder to 7.7.9.9 and 2001:db8::1:0 on port 53
        ipadnsconfig:
          forwarders:
            - ip_address: 7.7.9.9
            - ip_address: 2001:db8::1:0
              port: 53
          state: present
  6. Salvar o arquivo.
  7. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file ensure-presence-of-a-global-forwarder.yml

Recursos adicionais

  • Você pode ver mais exemplos de playbooks possíveis para o módulo ansible-freeipa ipadnsconfig no arquivo README-dnsconfig.md Markdown, disponível no diretório /usr/share/doc/ansible-freeipa/. O arquivo também contém as definições das variáveis ipadnsconfig.

64.9. Garantindo a ausência de um encaminhador global DNS na IdM usando o Ansible

Esta seção descreve como um administrador de Gerenciamento de Identidade (IdM) pode usar um Livro de Exercícios para garantir a ausência de um encaminhador global de DNS no IdM. No procedimento de exemplo abaixo, o administrador do IdM garante a ausência de um encaminhador global DNS para um servidor DNS com um endereço IP v4 de 8.8.6.6 e endereço IP v6 de 2001:4860:4860::8800 na porta 53.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible. Este é o host no qual você executa as etapas do procedimento.
  • Você sabe a senha do administrador da IdM.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra seu arquivo de inventário e certifique-se de que o servidor IdM que você deseja configurar esteja listado na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo forwarders-absent.yml. Por exemplo:

    $ cp forwarders-absent.yml garante a ausência de um global-forwarder.yml
  4. Abra o arquivo ensure-absence-of-a-global-forwarder.yml para edição.
  5. Adapte o arquivo, definindo as seguintes variáveis:

    1. Altere a variável name para Playbook to ensure the absence of a global forwarder in IdM DNS.
    2. Na seção tasks, altere o name da tarefa para Ensure the absence of a DNS global forwarder to 8.8.6.6 and 2001:4860:4860::8800 on port 53.
    3. Na seção forwarders da parte ipadnsconfig:

      1. Alterar o primeiro valor ip_address para o endereço IPv4 do forwarder global: 8.8.6.6.
      2. Altere o segundo valor ip_address para o endereço IPv6 do forwarder global: 2001:4860:4860::8800.
      3. Verifique se o valor port está definido para 53.
    4. Verifique se o site state está configurado para absent.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Playbook to ensure the absence of a global forwarder in IdM DNS
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure the absence of a DNS global forwarder to 8.8.6.6 and 2001:4860:4860::8800 on port 53
        ipadnsconfig:
          forwarders:
            - ip_address: 8.8.6.6
            - ip_address: 2001:4860:4860::8800
              port: 53
          state: absent
  6. Salvar o arquivo.
  7. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file ensure-absence-of-a-global-forwarder.yml

Recursos adicionais

  • Você pode ver mais exemplos de playbooks possíveis para o módulo ansible-freeipa ipadnsconfig no arquivo README-dnsconfig.md Markdown, disponível no diretório /usr/share/doc/ansible-freeipa/. O arquivo também contém as definições das variáveis ipadnsconfig.

64.10. Garantindo que o DNS Global Forwarders seja desativado no IdM usando o Ansible

Esta seção descreve como um administrador de Gerenciamento de Identidade (IdM) pode usar um Livro de Exercícios para garantir que os Encaminhadores Globais DNS sejam desativados no IdM. No procedimento de exemplo abaixo, o administrador do IdM garante que a política de encaminhamento para o encaminhador global seja definida para none, o que efetivamente desabilita o encaminhador global.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible. Este é o host no qual você executa as etapas do procedimento.
  • Você sabe a senha do administrador da IdM.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra seu arquivo de inventário e certifique-se de que o servidor IdM que você deseja configurar esteja listado na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Verifique o conteúdo do arquivo disable-global-forwarders.yml Um possível arquivo de playbook que já está configurado para desabilitar todos os encaminhadores globais do DNS. Por exemplo:

    $ cat disable-global-forwarders.yml
    ---
    - name: Playbook to disable global DNS forwarders
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Disable global forwarders.
        ipadnsconfig:
          forward_policy: none
  4. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file disable-global-forwarders.yml

Recursos adicionais

  • Você pode ver mais exemplos de playbooks possíveis para o módulo ansible-freeipa ipadnsconfig no arquivo README-dnsconfig.md Markdown, disponível no diretório /usr/share/doc/ansible-freeipa/. O arquivo também contém as definições das variáveis ipadnsconfig.

64.11. Garantindo a presença de uma Zona de Encaminhamento DNS na IdM usando o Ansible

Esta seção descreve como um administrador de Gerenciamento de Identidade (IdM) pode usar um Livro de Exercícios para garantir a presença de uma Zona de Encaminhamento DNS no IdM. No procedimento de exemplo abaixo, o administrador do IdM garante a presença de uma zona de encaminhamento DNS para example.com a um servidor DNS com um endereço de Protocolo Internet (IP) de 8.8.8.8.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible. Este é o host no qual você executa as etapas do procedimento.
  • Você sabe a senha do administrador da IdM.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra seu arquivo de inventário e certifique-se de que o servidor IdM que você deseja configurar esteja listado na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo forwarders-absent.yml. Por exemplo:

    $ cp forwarders-absent.yml garantir presença-presença-forwardzone.yml
  4. Abra o arquivo ensure-presence-forwardzone.yml para edição.
  5. Adapte o arquivo, definindo as seguintes variáveis:

    1. Altere a variável name para Playbook to ensure the presence of a dnsforwardzone in IdM DNS.
    2. Na seção tasks, altere o name da tarefa para Ensure presence of a dnsforwardzone for example.com to 8.8.8.8.
    3. Na seção tasks, altere o título ipadnsconfig para ipadnsforwardzone.
    4. Na seção ipadnsforwardzone:

      1. Adicione a variável ipaadmin_password e configure-a para sua senha de administrador IdM.
      2. Adicione a variável name e configure-a para example.com.
      3. Na seção forwarders:

        1. Remover as linhas ip_address e port.
        2. Adicione o endereço IP do servidor DNS para receber pedidos encaminhados, especificando-o após um traço:

          - 8.8.8.8
      4. Adicione a variável forwardpolicy e configure-a para first.
      5. Adicione a variável skip_overlap_check e configure-a para true.
      6. Altere a variável state para present.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Playbook to ensure the presence of a dnsforwardzone in IdM DNS
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure the presence of a dnsforwardzone for example.com to 8.8.8.8
      ipadnsforwardzone:
          ipaadmin_password: password01
          name: example.com
          forwarders:
              - 8.8.8.8
          forwardpolicy: first
          skip_overlap_check: true
          state: present
  6. Salvar o arquivo.
  7. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file ensure-presence-forwardzone.yml

Recursos adicionais

  • Você pode ver mais exemplos de playbooks possíveis para o módulo ansible-freeipa ipadnsforwardzone no arquivo README-dnsforwardzone.md Markdown, disponível no diretório /usr/share/doc/ansible-freeipa/. O arquivo também contém as definições das variáveis ipadnsforwardzone.

64.12. Garantir que uma Zona de Encaminhamento DNS tenha vários encaminhadores na IdM usando o Ansible

Esta seção descreve como um administrador de Gerenciamento de Identidade (IdM) pode usar um Livro de Jogadas possível para garantir que uma Zona de Encaminhamento DNS no IdM tenha vários encaminhadores. No procedimento de exemplo abaixo, o administrador do IdM garante que a zona de encaminhamento DNS para example.com seja encaminhada para 8.8.8.8 e 4.4.4.4.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible. Este é o host no qual você executa as etapas do procedimento.
  • Você sabe a senha do administrador da IdM.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra seu arquivo de inventário e certifique-se de que o servidor IdM que você deseja configurar esteja listado na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo forwarders-absent.yml. Por exemplo:

    $ cp forwarders-absent.yml asseguram-presença-multiple-forwarders.yml
  4. Abra o arquivo ensure-presence-multiple-forwarders.yml para edição.
  5. Adapte o arquivo, definindo as seguintes variáveis:

    1. Altere a variável name para Playbook to ensure the presence of multiple forwarders in a dnsforwardzone in IdM DNS.
    2. Na seção tasks, altere o name da tarefa para Ensure presence of 8.8.8.8 and 4.4.4.4 forwarders in dnsforwardzone for example.com.
    3. Na seção tasks, altere o título ipadnsconfig para ipadnsforwardzone.
    4. Na seção ipadnsforwardzone:

      1. Adicione a variável ipaadmin_password e configure-a para sua senha de administrador IdM.
      2. Adicione a variável name e configure-a para example.com.
      3. Na seção forwarders:

        1. Remover as linhas ip_address e port.
        2. Adicione o endereço IP dos servidores DNS que você deseja garantir que estejam presentes, precedido por um traço:

          - 8.8.8.8
          - 4.4.4.4
      4. Mude a variável de estado para apresentar.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: name: Playbook to ensure the presence of multiple forwarders in a dnsforwardzone in IdM DNS
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure presence of 8.8.8.8 and 4.4.4.4 forwarders in dnsforwardzone for example.com
      ipadnsforwardzone:
          ipaadmin_password: password01
         name: example.com
          forwarders:
              - 8.8.8.8
              - 4.4.4.4
          state: present
  6. Salvar o arquivo.
  7. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file ensure-presence-multiple-forwarders.yml

Recursos adicionais

  • Você pode ver mais exemplos de playbooks possíveis para o módulo ansible-freeipa ipadnsforwardzone no arquivo README-dnsforwardzone.md Markdown, disponível no diretório /usr/share/doc/ansible-freeipa/. O arquivo também contém as definições das variáveis ipadnsforwardzone.

64.13. Assegurar que uma Zona de Encaminhamento DNS seja desativada no IdM usando o Ansible

Esta seção descreve como um administrador de Gerenciamento de Identidade (IdM) pode usar um Livro de Jogadas possível para garantir que uma Zona de Encaminhamento DNS seja desativada no IdM. No procedimento de exemplo abaixo, o administrador do IdM garante que a zona de encaminhamento DNS para example.com esteja desabilitada.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible. Este é o host no qual você executa as etapas do procedimento.
  • Você sabe a senha do administrador da IdM.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra seu arquivo de inventário e certifique-se de que o servidor IdM que você deseja configurar esteja listado na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo forwarders-absent.yml. Por exemplo:

    $ cp forwarders-absent.yml garantir-desabilitar-zona.yml
  4. Abra o arquivo ensure-disabled-forwardzone.yml para edição.
  5. Adapte o arquivo, definindo as seguintes variáveis:

    1. Altere a variável name para Playbook to ensure a dnsforwardzone is disabled in IdM DNS.
    2. Na seção tasks, altere o name da tarefa para Ensure a dnsforwardzone for example.com is disabled.
    3. Na seção tasks, altere o título ipadnsconfig para ipadnsforwardzone.
    4. Na seção ipadnsforwardzone:

      1. Adicione a variável ipaadmin_password e configure-a para sua senha de administrador IdM.
      2. Adicione a variável name e configure-a para example.com.
      3. Remover toda a seção forwarders.
      4. Altere a variável state para disabled.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Playbook to ensure a dnsforwardzone is disabled in IdM DNS
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure a dnsforwardzone for example.com is disabled
      ipadnsforwardzone:
          ipaadmin_password: password01
          name: example.com
          state: disabled
  6. Salvar o arquivo.
  7. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file ensure-disabled-forwardzone.yml

Recursos adicionais

  • Você pode ver mais exemplos de playbooks possíveis para o módulo ansible-freeipa ipadnsforwardzone no arquivo README-dnsforwardzone.md Markdown, disponível no diretório /usr/share/doc/ansible-freeipa/. O arquivo também contém as definições das variáveis ipadnsforwardzone.

64.14. Garantindo a ausência de uma Zona de Encaminhamento DNS no IdM usando o Ansible

Esta seção descreve como um administrador de Gerenciamento de Identidade (IdM) pode usar um Livro de Jogadas possível para garantir a ausência de uma Zona de Encaminhamento DNS no IdM. No procedimento de exemplo abaixo, o administrador do IdM garante a ausência de uma zona de encaminhamento DNS para example.com.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible. Este é o host no qual você executa as etapas do procedimento.
  • Você sabe a senha do administrador da IdM.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/dnsconfig:

    $ cd /usr/share/doc/doc/ansible-freeipa/playbooks/dnsconfig
  2. Abra seu arquivo de inventário e certifique-se de que o servidor IdM que você deseja configurar esteja listado na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo forwarders-absent.yml. Por exemplo:

    $ cp forwarders-absent.yml garantir-absence-forwardzone.yml
  4. Abra o arquivo ensure-absence-forwardzone.yml para edição.
  5. Adapte o arquivo, definindo as seguintes variáveis:

    1. Altere a variável name para Playbook to ensure the absence of a dnsforwardzone in IdM DNS.
    2. Na seção tasks, altere o name da tarefa para Ensure the absence of a dnsforwardzone for example.com.
    3. Na seção tasks, altere o título ipadnsconfig para ipadnsforwardzone.
    4. Na seção ipadnsforwardzone:

      1. Adicione a variável ipaadmin_password e configure-a para sua senha de administrador IdM.
      2. Adicione a variável name e configure-a para example.com.
      3. Remover toda a seção forwarders.
      4. Deixe a variável state como absent.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Playbook to ensure the absence of a dnsforwardzone in IdM DNS
      hosts: ipaserver
      become: true
    
      tasks:
      - name: Ensure the absence of a dnsforwardzone for example.com
        ipadnsforwardzone:
           ipaadmin_password: password01
           name: example.com
           state: absent
  6. Salvar o arquivo.
  7. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file ensure-absence-forwardzone.yml

Recursos adicionais

  • Você pode ver mais exemplos de playbooks possíveis para o módulo ansible-freeipa ipadnsforwardzone no arquivo README-dnsforwardzone.md Markdown, disponível no diretório /usr/share/doc/ansible-freeipa/. O arquivo também contém as definições das variáveis ipadnsforwardzone.

Capítulo 65. Gerenciando registros DNS no IdM

Este capítulo descreve como gerenciar os registros DNS na Gestão de Identidade (IdM). Como administrador do IdM, você pode adicionar, modificar e excluir registros DNS no IdM. O capítulo contém as seguintes seções:

Pré-requisitos

65.1. Registros DNS em IdM

O Gerenciamento de Identidade (IdM) suporta muitos tipos diferentes de registros DNS. Os quatro seguintes são utilizados com mais freqüência:

A

Este é um mapa básico para um nome de host e um endereço IPv4. O nome de registro de um registro A é um nome de host, como por exemplo www. O valor IP Address de um registro A é um endereço IPv4, tal como 192.0.2.1.

Para mais informações sobre os registros A, ver RFC 1035.

AAAA

Este é um mapa básico para um nome de host e um endereço IPv6. O nome de registro de um registro AAAA é um nome de host, tal como www. O valor IP Address é um endereço IPv6, tal como 2001:DB8::1111.

Para mais informações sobre os registros AAAA, consulte a RFC 3596.

SRV

Service (SRV) resource records mapear nomes de serviços para o nome DNS do servidor que está fornecendo esse serviço em particular. Por exemplo, este tipo de registro pode mapear um serviço como um diretório LDAP para o servidor que o administra.

O nome do registro de um registro SRV tem o formato _service._protocolcomo, por exemplo, _ldap._tcp. As opções de configuração para registros SRV incluem prioridade, peso, número da porta e nome do host para o serviço alvo.

Para mais informações sobre os registros SRV, ver RFC 2782.

PTR

Um registro ponteiro (PTR) adiciona um registro DNS reverso, que mapeia um endereço IP a um nome de domínio.

Nota

Todas as buscas de DNS reverso para endereços IPv4 utilizam entradas invertidas que são definidas no domínio in-addr.arpa.. O endereço reverso, na forma legível por humanos, é o inverso exato do endereço IP regular, com o domínio in-addr.arpa. anexado a ele. Por exemplo, para o endereço de rede 192.0.2.0/24, a zona reversa é 2.0.192.in-addr.arpa.

O nome do registro de um PTR deve estar no formato padrão especificado na RFC 1035, estendido na RFC 2317, e na RFC 3596. O valor do nome do host deve ser um nome de host canônico do host para o qual se deseja criar o registro.

Nota

Também é possível configurar zonas inversas para endereços IPv6, com zonas no domínio .ip6.arpa.. Para mais informações sobre zonas reversíveis IPv6, consulte a RFC 3596.

Ao adicionar registros de recursos DNS, observe que muitos dos registros exigem dados diferentes. Por exemplo, um registro CNAME requer um nome de host, enquanto um registro A requer um endereço IP. Na interface Web do IdM, os campos no formulário para adicionar um novo registro são atualizados automaticamente para refletir quais dados são necessários para o tipo de registro atualmente selecionado.

65.2. Adicionando registros de recursos DNS na IDM Web UI

Esta seção descreve como adicionar registros de recursos DNS na Interface Web de Gerenciamento de Identidade (IdM).

Pré-requisitos

  • A zona DNS à qual você deseja adicionar um registro DNS existe e é gerenciada pela IdM. Para mais informações sobre a criação de uma zona DNS no IdM DNS, consulte Gerenciando zonas DNS no IdM.
  • Você está logado como administrador da IdM.

Procedimento

  1. Na interface web da IdM, clique em Network ServicesDNSDNS Zones.
  2. Clique na zona DNS na qual você deseja adicionar um registro DNS.
  3. Na seção DNS Resource Records, clique em Adicionar para adicionar um novo recorde.

    Figura 65.1. Adicionando um novo registro de recursos DNS

    dns add record
  4. Selecione o tipo de registro a ser criado e preencha os outros campos, conforme necessário.

    Figura 65.2. Definição de um novo registro de recursos DNS

    dns add record form
  5. Clique em Adicionar para confirmar o novo recorde.

65.3. Acréscimo de registros de recursos DNS da IDM CLI

Esta seção descreve como adicionar um registro de recursos DNS de qualquer tipo a partir da interface de linha de comando (CLI).

Pré-requisitos

  • A zona DNS à qual você deseja adicionar um registro DNS existe. Para mais informações sobre a criação de uma zona DNS no IdM DNS, consulte Gerenciando zonas DNS no IdM.
  • Você está logado como administrador da IdM.

Procedimento

  1. Para adicionar um registro de recursos DNS, use o comando ipa dnsrecord-add. O comando segue esta sintaxe:

    $ ipa dnsrecord-add zone_name record_name --record_type_option=data

    No comando acima:

    • O zone_name é o nome da zona DNS à qual o registro está sendo adicionado.
    • O record_name é um identificador para o novo registro de recursos DNS.

    Por exemplo, para adicionar um registro DNS do tipo A de host1 à zona idm.example.com, entre:

    $ ipa dnsrecord-add idm.example.com host1 --a-rec=192.168.122.123

65.4. Opções comuns de ipa dnsrecord-*

Esta seção descreve as opções que você pode usar ao adicionar, modificar e excluir os tipos mais comuns de registros de recursos DNS para Gerenciamento de Identidade (IdM):

  • A (IPv4)
  • AAAA (IPv6)
  • SRV
  • PTR

Em Bash, você pode definir várias entradas listando os valores em uma lista separada por vírgula dentro de chaves de caracóis, como --⁠option={val1,val2,val3}.

Tabela 65.1. Opções de registros gerais

OptionDescription

--ttl=number

Define o tempo para viver para o registro.

--structured

Analisa os registros DNS brutos e os devolve em um formato estruturado.

Tabela 65.2. \Opções de discos "A"

OptionDescriptionExamples

--a-rec=ARECORD

Passa um único registro A ou uma lista de registros A.

ipa dnsrecord-add idm.example.com host1 --a-rec=192.168.122.123

Pode criar um wildcard Um registro com um determinado endereço IP.

ipa dnsrecord-add idm.example.com "*" --a-rec=192.168.122.123 [a]

--a-ip-address=string

Fornece o endereço IP para o registro. Ao criar um registro, a opção para especificar o valor do registro A é --a-rec. Entretanto, ao modificar um registro A, a opção --a-rec é usada para especificar o valor atual para o registro A. O novo valor é definido com a opção --a-ip-address.

ipa dnsrecord-mod idm.example.com --a-rec 192.168.122.123 --a-ip-address 192.168.122.124

[a] O exemplo cria um registro wildcard A com o endereço IP de 192.0.2.123.

Tabela 65.3. "\Opções de registro "AAAA

OptionDescriptionExample

--aaaa-rec=AAAARECORD

Passa um único registro AAAA (IPv6) ou uma lista de registros AAAA.

ipa dnsrecord-add idm.example.com www --aaaa-rec 2001:db8::1231:5675

--aaaa-ip-address=string

Fornece o endereço IPv6 para o registro. Ao criar um registro, a opção para especificar o valor do registro A é --aaaa-rec. Entretanto, ao modificar um registro A, a opção --aaaa-rec é usada para especificar o valor atual para o registro A. O novo valor é definido com a opção --a-ip-address.

ipa dnsrecord-mod idm.example.com --aaaa-rec 2001:db8::1231:5675 --aaaa-ip-address 2001:db8::1231:5676

Tabela 65.4. "\Opções de registro "PTR

OptionDescriptionExample

--ptr-rec=PTRRECORD

Passa um único registro PTR ou uma lista de registros PTR. Ao adicionar o registro DNS reverso, o nome da zona usado com o comando ipa dnsrecord-add é revertido, em comparação com o uso para adicionar outros registros DNS. Tipicamente, o endereço IP do host é o último octeto do endereço IP em uma determinada rede. O primeiro exemplo à direita adiciona um registro PTR para server4.idm.example.com com endereço IPv4 192.168.122.4. O segundo exemplo adiciona uma entrada de DNS reverso para a zona reversa 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. IPv6 para o host server2.example.com com o endereço IP 2001:DB8::1111.

ipa dnsrecord-add 122.168.192.in-addr.arpa 4 --ptr-rec server4.idm.example.com.

$ ipa dnsrecord-add 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa. 1.1.1.0.0.0.0.0.0.0.0.0.0.0.0 --ptr-rec server2.idm.example.com.

--ptr-hostname=string

Dá o nome do anfitrião para o registro.

 

Tabela 65.5. "SRV Opções de registro

OptionDescriptionExample

--srv-rec=SRVRECORD

Passa um único registro SRV ou uma lista de registros SRV. Nos exemplos à direita, _ldap._tcp define o tipo de serviço e o protocolo de conexão para o registro SRV. A opção --srv-rec define a prioridade, o peso, a porta e os valores alvo. Os valores de peso de 51 e 49 nos exemplos somam até 100 e representam a probabilidade, em porcentagem, de que um determinado registro seja utilizado.

# ipa dnsrecord-add idm.example.com _ldap._tcp --srv-rec="0 51 389 server1.idm.example.com."

# ipa dnsrecord-add server.idm.example.com _ldap._tcp --srv-rec="1 49 389 server2.idm.example.com."

--srv-priority=number

Estabelece a prioridade do registro. Pode haver vários registros SRV para um tipo de serviço. A prioridade (0 - 65535) define a classificação do registro; quanto menor o número, maior a prioridade. Um serviço tem que usar primeiro o registro com a prioridade mais alta.

# ipa dnsrecord-mod server.idm.example.com _ldap._tcp --srv-rec="1 49 389 server2.idm.example.com." --srv-priority=0

--srv-weight=number

Define o peso do recorde. Isto ajuda a determinar a ordem dos registros SRV com a mesma prioridade. Os pesos definidos devem somar até 100, representando a probabilidade (em porcentagem) de que um determinado registro seja utilizado.

# ipa dnsrecord-mod server.idm.example.com _ldap._tcp --srv-rec="0 49 389 server2.idm.example.com." --srv-weight=60

--srv-port=number

Dá o porto para o serviço no anfitrião alvo.

# ipa dnsrecord-mod server.idm.example.com _ldap._tcp --srv-rec="0 60 389 server2.idm.example.com." --srv-port=636

--srv-target=string

Fornece o nome do domínio do host alvo. Isto pode ser um único período (.) se o serviço não estiver disponível no domínio.

 

Recursos adicionais

  • Para mais informações sobre como usar ipa dnsrecord-add e quais tipos de registros DNS são suportados pela IdM, execute o comando ipa dnsrecord-add --help.

65.5. Eliminação de registros DNS na IDM Web UI

Esta seção descreve como excluir registros DNS no Gerenciamento de Identidade (IdM) usando a interface web do IdM.

Pré-requisitos

  • Você está logado como administrador da IdM.

Procedimento

  1. Na interface web da IdM, clique em Network ServicesDNSDNS Zones.
  2. Clique na zona da qual você deseja excluir um registro DNS, por exemplo example.com..
  3. Na seção DNS Resource Records, clique no nome do registro do recurso.

    Figura 65.3. Seleção de um registro de recursos DNS

    dns record delete select record
  4. Selecione a caixa de seleção com o nome do tipo de registro a ser apagado.
  5. Clique em Delete.

    Figura 65.4. Eliminação de um registro de recursos DNS

    dns record delete

O tipo de registro selecionado é agora excluído. A outra configuração do registro do recurso é deixada intacta.

Recursos adicionais

65.6. Exclusão de todo um registro DNS na interface web do IdM

Esta seção descreve como excluir todos os registros de um determinado recurso em uma zona usando a Interface Web de Gerenciamento de Identidade (IdM).

Pré-requisitos

  • Você está logado como administrador da IdM.

Procedimento

  1. Na interface web da IdM, clique em Network ServicesDNSDNS Zones.
  2. Clique na zona da qual você deseja excluir um registro DNS, por exemplo zone.example.com..
  3. Na seção DNS Resource Records, selecione a caixa de seleção do registro do recurso a ser excluído.
  4. Clique em Excluir.

    Figura 65.5. Eliminação de um registro completo de recursos

    dns record delete all

Todo o registro de recursos é agora apagado.

65.7. Eliminação de registros DNS na IDM CLI

Esta seção descreve como remover registros DNS de uma zona gerenciada pelo DNS do Gerenciamento de Identidade (IdM).

Pré-requisitos

  • Você está logado como administrador da IdM.

Procedimento

  • Para remover registros de uma zona, use o comando ipa dnsrecord-del e adicione o --recordType-rec junto com o valor recorde. Por exemplo, para remover um registro do tipo A:

    $ ipa dnsrecord-del example.com www --a-rec 192.0.2.1

    Se você executar ipa dnsrecord-del sem nenhuma opção, o comando solicita informações sobre o registro a ser apagado. Note que passar a opção --del-all com o comando remove todos os registros associados para a zona.

Recursos adicionais

  • Para informações detalhadas sobre como usar ipa dnsrecord-del e uma lista completa de opções aceitas pelo comando, execute o comando ipa dnsrecord-del --help.

65.8. Recursos adicionais

Capítulo 66. Usando Ansible to manage DNS records in IdM

Este capítulo descreve como gerenciar registros DNS em Gerenciamento de Identidade (IdM) usando um livro de exercícios possível. Como administrador do IdM, você pode adicionar, modificar e excluir registros DNS no IdM. O capítulo contém as seguintes seções:

66.1. Garantir a presença de registros DNS A e AAAA na IdM usando o Ansible

Esta seção mostra como um administrador de Gerenciamento de Identidade (IdM) pode usar um Livro de Jogadas Anível para garantir a presença de registros A e AAAA para um determinado host IdM. No exemplo utilizado no procedimento abaixo, um administrador de IdM garante a presença de registros A e AAAA para host1 na zona DNS idm.example.com.

Pré-requisitos

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/dnsrecord:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsrecord
  2. Abra seu arquivo de inventário e certifique-se de que o servidor IdM que você deseja configurar esteja listado na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo ensure-A-and-AAAA-records-are-present.yml. Por exemplo:

    $ cp ensure-A-and-AAAA-records-are-present.yml ensure-A-and-AAAA-records-are-present-copy.yml
  4. Abra o arquivo ensure-A-and-AAAA-records-are-present-copy.yml para edição.
  5. Adapte o arquivo definindo as seguintes variáveis na seção de tarefas ipadnsrecord:

    • Defina a variável ipaadmin_password para sua senha de administrador IdM.
    • Defina a variável zone_name para idm.example.com.
    • Na variável records, defina a variável name para host1, e a variável a_ip_address para 192.168.122.123.
    • Na variável records, defina a variável name para host1, e a variável aaaa_ip_address para ::1.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Ensure A and AAAA records are present
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      # Ensure A and AAAA records are present
      - name: Ensure that 'host1' has A and AAAA records.
        ipadnsrecord:
          ipaadmin_password: Secret123
          zone_name: idm.example.com
          records:
          - name: host1
            a_ip_address: 192.168.122.123
          - name: host1
            aaaa_ip_address: ::1
  6. Salvar o arquivo.
  7. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file ensure-A-and-AAAA-records-are-present-copy.yml

Recursos adicionais

  • Para mais informações sobre os registros A e AAAA, consulte os registros DNS em IdM.
  • Você pode ver mais exemplos de playbooks possíveis para o módulo ansible-freeipa ipadnsrecord no arquivo README-dnsrecord.md Markdown, disponível no diretório /usr/share/doc/ansible-freeipa/. O arquivo também contém as definições das variáveis ipadnsrecord.
  • Você pode ver exemplos de playbooks possíveis para o módulo ipadnsrecord no diretório /usr/share/doc/ansible-freeipa/playbooks/dnsrecord.

66.2. Garantir a presença de registros DNS A e PTR na IdM usando o Ansible

Esta seção mostra como um administrador de Gerenciamento de Identidade (IdM) pode usar um livro de reprodução possível para garantir a presença de um registro A para um determinado host IdM, com um registro PTR correspondente. No exemplo utilizado no procedimento abaixo, um administrador de IdM garante a presença de registros A e PTR para host1 com um endereço IP de 192.168.122.45 na zona idm.example.com.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible. Este é o host no qual você executa as etapas do procedimento.
  • Você sabe a senha do administrador da IdM.
  • A zona idm.example.com DNS existe e é gerenciada pela IdM DNS. Para mais informações sobre como adicionar uma zona DNS primária no DNS IdM, consulte Utilizando playbooks possíveis para gerenciar as zonas DNS IdM.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/dnsrecord:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsrecord
  2. Abra seu arquivo de inventário e certifique-se de que o servidor IdM que você deseja configurar esteja listado na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo ensure-dnsrecord-with-reverse-is-present.yml. Por exemplo:

    $ cp ensure-dnsrecord-with-reverse-is-present.yml ensure-dnsrecord-with-reverse-is-present-copy.yml
  4. Abra o arquivo ensure-dnsrecord-with-reverse-is-present-copy.yml para edição.
  5. Adapte o arquivo definindo as seguintes variáveis na seção de tarefas ipadnsrecord:

    • Defina a variável ipaadmin_password para sua senha de administrador IdM.
    • Defina a variável name para host1.
    • Defina a variável zone_name para idm.example.com.
    • Defina a variável ip_address para 192.168.122.45.
    • Defina a variável create_reverse para yes.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Ensure DNS Record is present.
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      # Ensure that dns record is present
      - ipadnsrecord:
          ipaadmin_password: Secret123
          name: host1
          zone_name: idm.example.com
          ip_address: 192.168.122.45
          create_reverse: yes
          state: present
  6. Salvar o arquivo.
  7. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file ensure-dnsrecord-with-reverse-is-present-copy.yml

Recursos adicionais

  • Para mais informações sobre os registros DNS A e PTR, consulte os registros DNS na IdM.
  • Você pode ver mais exemplos de playbooks possíveis para o módulo ansible-freeipa ipadnsrecord no arquivo README-dnsrecord.md Markdown, disponível no diretório /usr/share/doc/ansible-freeipa/. O arquivo também contém as definições das variáveis ipadnsrecord.
  • Você pode ver exemplos de playbooks possíveis para o módulo ipadnsrecord no diretório /usr/share/doc/ansible-freeipa/playbooks/dnsrecord.

66.3. Garantir a presença de múltiplos registros DNS na IdM usando o Ansible

Esta seção mostra como um administrador de Gerenciamento de Identidade (IdM) pode usar um livro de exercícios para garantir que múltiplos valores sejam associados a um registro DNS particular do IdM. No exemplo utilizado no procedimento abaixo, um administrador de IdM garante a presença de múltiplos registros A para host1 na zona DNS idm.example.com.

Pré-requisitos

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/dnsrecord:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsrecord
  2. Abra seu arquivo de inventário e certifique-se de que o servidor IdM que você deseja configurar esteja listado na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo ensure-presence-multiple-records.yml. Por exemplo:

    $ cp ensure-presence-multiple-records.yml ensure-presence-multiple-records-copy.yml
  4. Abra o arquivo ensure-presence-multiple-records-copy.yml para edição.
  5. Adapte o arquivo definindo as seguintes variáveis na seção de tarefas ipadnsrecord:

    • Defina a variável ipaadmin_password para sua senha de administrador IdM.
    • Na seção records, defina a variável name para host1.
    • Na seção records, defina a variável zone_name para idm.example.com.
    • Na seção records, defina a variável a_rec para 192.168.122.112 e para 192.168.122.122.
    • Defina um segundo registro na seção records:

      • Defina a variável name para host1.
      • Defina a variável zone_name para idm.example.com.
      • Defina a variável aaaa_rec para ::1.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Test multiple DNS Records are present.
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      # Ensure that multiple dns records are present
      - ipadnsrecord:
          ipaadmin_password: Secret123
          records:
            - name: host1
              zone_name: idm.example.com
              a_rec: 192.168.122.112
              a_rec: 192.168.122.122
            - name: host1
              zone_name: idm.example.com
              aaaa_rec: ::1
  6. Salvar o arquivo.
  7. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file ensure-presence-multiple-records-copy.yml

Recursos adicionais

  • Para mais informações sobre os registros A no DNS, consulte os registros DNS na IdM.
  • Você pode ver mais exemplos de playbooks possíveis para o módulo ansible-freeipa ipadnsrecord no arquivo README-dnsrecord.md Markdown, disponível no diretório /usr/share/doc/ansible-freeipa/. O arquivo também contém as definições das variáveis ipadnsrecord.
  • Você pode ver exemplos de playbooks possíveis para o módulo ipadnsrecord no diretório /usr/share/doc/ansible-freeipa/playbooks/dnsrecord.

66.4. Garantindo a presença de múltiplos registros CNAME na IdM usando o Ansible

Um registro de Nome Canônico (CNAME record) é um tipo de registro de recurso no Sistema de Nome de Domínio (DNS) que mapeia um nome de domínio, um pseudônimo, para outro nome, o nome canônico.

Você pode achar os registros CNAME úteis ao executar vários serviços de um único endereço IP: por exemplo, um serviço FTP e um serviço web, cada um rodando em uma porta diferente.

Esta seção mostra como um administrador de Gerenciamento de Identidade (IdM) pode usar um Livro de Jogadas Ansioso para garantir que múltiplos registros CNAME estejam presentes no DNS do IdM. No exemplo utilizado no procedimento abaixo, host03 é tanto um servidor HTTP quanto um servidor FTP. O administrador do IdM garante a presença dos registros CNAME www e ftp para o host03 Um registro na zona idm.example.com.

Pré-requisitos

  • Você instalou o pacote ansible-freeipa no controlador Ansible. Este é o host no qual você executa as etapas do procedimento.
  • Você sabe a senha do administrador da IdM.
  • A zona idm.example.com existe e é gerenciada pela IdM DNS. Para mais informações sobre como adicionar uma zona DNS primária no DNS IdM, consulte Utilizando playbooks possíveis para gerenciar as zonas DNS IdM.
  • O host03 Existe um registro na zona idm.example.com.

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/dnsrecord:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsrecord
  2. Abra seu arquivo de inventário e certifique-se de que o servidor IdM que você deseja configurar esteja listado na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo ensure-CNAME-record-is-present.yml. Por exemplo:

    $ cp ensure-CNAME-record-is-present.yml ensure-CNAME-record-is-present-copy.yml
  4. Abra o arquivo ensure-CNAME-record-is-present-copy.yml para edição.
  5. Adapte o arquivo definindo as seguintes variáveis na seção de tarefas ipadnsrecord:

    • (Opcional) Adaptar a descrição fornecida pelo name da peça.
    • Defina a variável ipaadmin_password para sua senha de administrador IdM.
    • Defina a variável zone_name para idm.example.com.
    • Na seção de variáveis records, defina as seguintes variáveis e valores:

      • Defina a variável name para www.
      • Defina a variável cname_hostname para host03.
      • Defina a variável name para ftp.
      • Defina a variável cname_hostname para host03.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Ensure that 'www.idm.example.com' and 'ftp.idm.example.com' CNAME records point to 'host03.idm.example.com'.
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      - ipadnsrecord:
          ipaadmin_password: Secret123
          zone_name: idm.example.com
          records:
          - name: www
            cname_hostname: host03
          - name: ftp
            cname_hostname: host03
  6. Salvar o arquivo.
  7. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file ensure-CNAME-record-is-present.yml

Recursos adicionais

  • Você pode ver mais exemplos de playbooks possíveis para o módulo ansible-freeipa ipadnsrecord no arquivo README-dnsrecord.md Markdown, disponível no diretório /usr/share/doc/ansible-freeipa/. O arquivo também contém as definições das variáveis ipadnsrecord.
  • Você pode ver exemplos de playbooks possíveis para o módulo ipadnsrecord no diretório /usr/share/doc/ansible-freeipa/playbooks/dnsrecord.

66.5. Garantir a presença de um registro SRV na IdM usando o Ansible

Um registro de serviço DNS (SRV) define o nome do host, número da porta, protocolo de transporte, prioridade e peso de um serviço disponível em um domínio. No Gerenciamento de Identidade (IdM), você pode usar os registros SRV para localizar servidores e réplicas do IdM.

Esta seção mostra como um administrador de Gerenciamento de Identidade (IdM) pode usar um livro de reprodução possível para garantir que um registro SRV esteja presente no DNS do IdM. No exemplo utilizado no procedimento abaixo, um administrador de IdM garante a presença do registro _kerberos._udp.idm.example.com SRV com o valor de 10 50 88 idm.example.com. Isto estabelece os seguintes valores:

  • Estabelece a prioridade do serviço em 10.
  • Estabelece o peso do serviço em 50.
  • Estabelece o porto a ser utilizado pelo serviço em 88.

Pré-requisitos

Procedimento

  1. Navegue até o diretório /usr/share/doc/ansible-freeipa/playbooks/dnsrecord:

    $ cd /usr/share/doc/ansible-freeipa/playbooks/dnsrecord
  2. Abra seu arquivo de inventário e certifique-se de que o servidor IdM que você deseja configurar esteja listado na seção [ipaserver]. Por exemplo, para instruir o Ansible a configurar server.idm.example.com, entre:

    [ipaserver]
    server.idm.example.com
  3. Faça uma cópia do arquivo do livro de jogo ensure-SRV-record-is-present.yml. Por exemplo:

    $ cp ensure-SRV-record-is-present.yml ensure-SRV-record-is-present-copy.yml
  4. Abra o arquivo ensure-SRV-record-is-present-copy.yml para edição.
  5. Adapte o arquivo definindo as seguintes variáveis na seção de tarefas ipadnsrecord:

    • Defina a variável ipaadmin_password para sua senha de administrador IdM.
    • Defina a variável name para _kerberos._udp.idm.example.com.
    • Defina a variável srv_rec para '10 50 88 idm.example.com'.
    • Defina a variável zone_name para idm.example.com.

      Este é o arquivo Ansible playbook modificado para o exemplo atual:

    ---
    - name: Test multiple DNS Records are present.
      hosts: ipaserver
      become: true
      gather_facts: false
    
      tasks:
      # Ensure a SRV record is present
      - ipadnsrecord:
          ipaadmin_password: Secret123
          name: _kerberos._udp.idm.example.com
          srv_rec: ’10 50 88 idm.example.com’
          zone_name: idm.example.com
          state: present
  6. Salvar o arquivo.
  7. Execute o livro de brincadeiras:

    $ ansible-playbook -v -i inventory.file ensure-SRV-record-is-present.yml

Recursos adicionais

  • Para mais informações sobre os registros SRV, consulte os registros DNS na IdM.
  • Você pode ver mais exemplos de playbooks possíveis para o módulo ansible-freeipa ipadnsrecord no arquivo README-dnsrecord.md Markdown, disponível no diretório /usr/share/doc/ansible-freeipa/. O arquivo também contém as definições das variáveis ipadnsrecord.
  • Você pode ver exemplos de playbooks possíveis para o módulo ipadnsrecord no diretório /usr/share/doc/ansible-freeipa/playbooks/dnsrecord.

Capítulo 67. Coleta de informações do IdM Healthcheck

O Healthcheck foi projetado como uma ferramenta de linha de comando manual que deve ajudá-lo a identificar possíveis problemas no Gerenciamento de Identidade (IdM).

Este capítulo descreve como você pode criar uma coleção de logs com base na saída do Healthcheck com rotação de 30 dias.

Pré-requisitos

  • A ferramenta Healthcheck só está disponível no RHEL 8.1 ou mais recente

67.1. Healthcheck na IdM

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

Nota

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

67.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

67.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.

67.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

67.2. Rotação de logs

A rotação de logs cria um novo arquivo de log todos os dias, e os arquivos são organizados por data. Como os arquivos de log são salvos no mesmo diretório, você pode selecionar um determinado arquivo de log de acordo com a data.

Rotação significa que há um número configurado para o número máximo de arquivos de log e se o número for excedido, o arquivo mais novo reescreve e renomeia o mais antigo. Por exemplo, se o número de rotação for 30, o trigésimo primeiro arquivo de log substitui o primeiro arquivo (mais antigo).

A rotação dos logs reduz os volumosos arquivos de logs e os organiza, o que pode ajudar na análise dos logs.

67.3. Configurando a rotação de logs usando o IdM Healthcheck

Esta seção descreve como configurar uma rotação de troncos com:

  • o cronômetro systemd
  • o serviço crond

O cronômetro systemd executa a ferramenta Healthcheck periodicamente e gera os logs. O valor padrão é definido para 4 da manhã todos os dias.

O serviço crond é utilizado para rotação de logs.

O nome padrão do log é healthcheck.log e os logs rotacionados usam o formato healthcheck.log-YYYYMMDD.

Pré-requisitos

  • Você deve executar os comandos como raiz.

Procedimento

  1. Habilite um temporizador systemd:

    # systemctl enable ipa-healthcheck.timer
    Created symlink /etc/systemd/system/multi-user.target.wants/ipa-healthcheck.timer -> /usr/lib/systemd/system/ipa-healthcheck.timer.
  2. Inicie o cronômetro systemd:

    # systemctl start ipa-healthcheck.timer
  3. Abra o arquivo /etc/logrotate.d/ipahealthcheck para configurar o número de logs que devem ser salvos.

    Por padrão, a rotação de registros é configurada para 30 dias.

  4. No arquivo /etc/logrotate.d/ipahealthcheck, configure o caminho para os logs.

    Por padrão, os logs são salvos no diretório /var/log/ipa/healthcheck/.

  5. No arquivo /etc/logrotate.d/ipahealthcheck, configure o tempo para a geração de logs.

    Por padrão, um registro é criado diariamente às 4 da manhã.

  6. Para utilizar a rotação de logs, assegure-se de que o serviço crond esteja habilitado e em funcionamento:

    # systemctl enable crond
    # systemctl start crond

Para começar com a geração de logs, inicie o serviço de healthcheck do IPA:

# systemctl start ipa-healthcheck

Para verificar o resultado, vá para /var/log/ipa/healthcheck/ e verifique se os logs foram criados corretamente.

Capítulo 68. Serviços de verificação usando o IdM Healthcheck

Esta seção descreve os serviços de monitoramento usados pelo servidor de Gerenciamento de Identidade (IdM) usando a ferramenta Healthcheck.

Para detalhes, veja Healthcheck em IdM.

Pré-requisitos

  • A ferramenta Healthcheck só está disponível no RHEL 8.1 e em versões mais recentes

68.1. Serviços Teste de Healthcheck

A ferramenta Healthcheck inclui um teste para verificar se algum serviço IdM não está funcionando. Este teste é importante porque os serviços que não estão em execução podem causar falhas em outros testes. Portanto, verifique se todos os serviços estão rodando primeiro. Você pode então verificar todos os outros resultados do teste.

Para ver todos os testes de serviços, execute ipa-healthcheck com a opção --list-sources:

# ipa-healthcheck --list-sources

Você pode encontrar todos os serviços testados com o Healthcheck sob a fonte ipahealthcheck.meta.services:

  • certmonger
  • dirsrv
  • gssproxy
  • httpd
  • ipa_custodia
  • ipa_dnskeysyncd
  • ipa_otpd
  • kadmin
  • krb5kdc
  • chamado
  • pki_tomcatd
  • sssd
Nota

Execute estes testes em todos os servidores principais da IdM ao tentar descobrir problemas.

68.2. Serviços de triagem utilizando o Healthcheck

Esta seção descreve um teste manual independente de serviços executados no servidor de Gerenciamento de Identidade (IdM) usando a ferramenta Healthcheck.

A ferramenta Healthcheck inclui muitos testes, cujos resultados podem ser encurtados:

  • excluindo todos os testes bem-sucedidos --failures-only
  • incluindo apenas testes de serviços --source=ipahealthcheck.meta.services

Procedimento

  • Para realizar o Healthcheck com avisos, erros e questões críticas relativas aos serviços, entre:

    # ipa-healthcheck --source=ipahealthcheck.meta.services -- somente falhas

Um teste bem sucedido exibe parênteses vazios:

[ ]

Se um dos serviços falhar, o resultado pode parecer semelhante a este exemplo:

{
  "source": "ipahealthcheck.meta.services",
  "check": "httpd",
  "result": "ERROR",
  "kw": {
    "status": false,
    "msg": "httpd: not running"
  }
}

Recursos adicionais

  • Para rever referências detalhadas, digite man ipa-healthcheck na linha de comando.

Capítulo 69. Verificando sua configuração de confiança IdM e AD usando o IdM Healthcheck

Esta seção ajuda você a entender e usar a ferramenta Healthcheck no Gerenciamento de Identidade (IdM) para identificar problemas com o IdM e um Active Directory trust.

Para maiores detalhes, ver Seção 67.1, “Healthcheck na IdM”.

Pré-requisitos

  • A ferramenta Healthcheck só está disponível no RHEL 8.1 ou mais recente

69.1. IdM e AD trust Testes Healthcheck

A ferramenta Healthcheck inclui vários testes para testar o status de sua confiança no Gerenciamento de Identidade (IdM) e no Active Directory (AD).

Para ver todos os testes de confiança, execute ipa-healthcheck com a opção --list-sources:

# ipa-healthcheck --list-sources

Você pode encontrar todos os testes sob a fonte ipahealthcheck.ipa.trust:

IPATrustAgentCheck
Este teste verifica a configuração do SSSD quando a máquina é configurada como um agente de confiança. Para cada domínio em /etc/sssd/sssd.conf onde id_provider=ipa garante que ipa_server_mode é True.
IPATrustDomainsCheck
Este teste verifica se os domínios de confiança correspondem aos domínios SSSD, comparando a lista de domínios em sssctl domain-list com a lista de domínios de ipa trust-find, excluindo o domínio IPA.
IPATrustCatalogCheck

Este teste resolve um usuário AD, Administrator@REALM. Isto preenche o catálogo AD Global e os valores do Controlador de Domínios AD na saída sssctl domain-status.

Para cada domínio de confiança procure o usuário com o id do SID 500 (o administrador) e depois verifique a saída de sssctl domain-status <domain> --active-server para garantir que o domínio esteja ativo.

IPAsidgenpluginCheck
Este teste verifica que o plugin sidgen está habilitado na instância do IPA 389-ds. O teste também verifica que os plugins IPA SIDGEN e ipa-sidgen-task em cn=plugins,cn=config incluem a opção nsslapd-pluginEnabled.
IPATrustAgentMemberCheck
Este teste verifica que o atual anfitrião é um membro do cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX.
IPATrustControllerPrincipalCheck
Este teste verifica que o atual anfitrião é um membro do cn=adtrust agents,cn=sysaccounts,cn=etc,SUFFIX.
IPATrustControllerServiceCheck
Este teste verifica que o atual host inicia o serviço ADTRUST no ipactl.
IPATrustControllerConfCheck
Este teste verifica que ldapi está habilitado para o backend passdb na saída da lista net conf.
IPATrustControllerGroupSIDCheck
Este teste verifica que o SID do grupo de administradores termina com 512 (Domain Admins RID).
IPATrustPackageCheck
Este teste verifica se o pacote trust-ad está instalado se o controlador de confiança e a confiança AD não estiverem habilitados.
Nota

Execute estes testes em todos os servidores principais da IdM ao tentar encontrar um problema.

69.2. Triagem da confiança com a ferramenta Healthcheck

Esta seção descreve um teste manual autônomo de um controle de saúde de confiança de Gerenciamento de Identidade (IdM) e Active Directory (AD) usando a ferramenta Healthcheck.

A ferramenta Healthcheck inclui muitos testes, portanto, você pode encurtar os resultados:

  • excluindo todos os testes bem-sucedidos --failures-only
  • incluindo apenas testes de confiança --source=ipahealthcheck.ipa.trust

Procedimento

  • Para executar o Healthcheck com avisos, erros e questões críticas na confiança, entre:

    # ipa-healthcheck --source=ipahealthcheck.ipa.trust -- somente faltas

O teste bem-sucedido exibe parênteses vazios:

# ipa-healthcheck --source=ipahealthcheck.ipa.trust --failures-only
[]

Recursos adicionais

  • Para rever referências detalhadas, digite man ipa-healthcheck na linha de comando.

Capítulo 70. Verificação de certificados usando o IdM Healthcheck

Esta seção ajuda na compreensão e uso da ferramenta Healthcheck no Gerenciamento de Identidade (IdM) para identificar problemas com certificados IPA mantidos pela certmonger.

Para detalhes, veja Healthcheck em IdM.

Pré-requisitos

  • A ferramenta Healthcheck está disponível apenas no RHEL 8.1 e mais recente.

70.1. Certificados IdM Testes de Healthcheck

A ferramenta Healthcheck inclui vários testes para verificar o status dos certificados mantidos pelo certmonger no Gerenciamento de Identidade (IdM). Para obter detalhes sobre certmonger, consulte Obtenção de um certificado IdM para um serviço usando o certmonger.

Este conjunto de testes verifica a expiração, validação, confiança e outras questões. Vários erros podem ser cometidos para o mesmo problema subjacente.

Para ver todos os testes de certificado, execute o ipa-healthcheck com a opção --list-sources:

# ipa-healthcheck --list-sources

Você pode encontrar todos os testes sob a fonte ipahealthcheck.ipa.certs:

IPACertmongerExpirationCheck

Este teste verifica as expirações em certmonger.

Se um erro for relatado, o certificado expirou.

Se um aviso aparecer, o certificado expirará em breve. Por padrão, este teste se aplica dentro de 28 dias ou menos antes da expiração do certificado.

Você pode configurar o número de dias no arquivo /etc/ipahealthcheck/ipahealthcheck.conf. Após abrir o arquivo, altere a opção cert_expiration_days localizada na seção padrão.

Nota

A Certmonger carrega e mantém sua própria visão sobre a expiração do certificado. Esta verificação não valida o certificado em disco.

IPACertfileExpirationCheck

Este teste verifica se o arquivo do certificado ou banco de dados do NSS não pode ser aberto. Este teste também verifica a expiração. Portanto, leia atentamente o atributo msg na saída de erro ou aviso. A mensagem especifica o problema.

Nota

Este teste verifica o certificado em disco. Se um certificado estiver faltando, não legível, etc., um erro separado também pode ser detectado.

IPACertNSSTrust
Este teste compara a confiança para os certificados armazenados nos bancos de dados do NSS. Para os certificados rastreados esperados em bancos de dados NSS, a confiança é comparada a um valor esperado e a um erro levantado em um não-correspondência.
IPANSSChainValidation
Este teste valida a cadeia de certificados dos certificados do NSS. O teste é executado certutil -V -u V -e -d [dbdir] -n [nickname]
IPAOpenSSLChainValidation

Este teste valida a cadeia de certificados dos certificados OpenSSL. Para ser comparável à validação do NSSChain aqui é o comando OpenSSL que executamos:

openssl verify -verbose -show_chain -CAfile /etc/ipa/ca.crt [arquivo cert]
IPARAAgent
Este teste compara o certificado em disco com o registro equivalente no LDAP em uid=ipara,ou=People,o=ipaca.
IPACertRevocation
Este teste utiliza o certmonger para verificar se os certificados não foram revogados. Portanto, o teste pode encontrar problemas relacionados a certificados mantidos somente por certmonger.
IPACertmongerCA

Este teste verifica a configuração da autoridade certificadora (CA). A IdM não pode emitir certificados sem a CA.

A Certmonger mantém um conjunto de ajudantes da CA. Na IdM, há uma CA chamada IPA que emite certificados através da IdM, autenticando-se como um principal anfitrião ou usuário, para certificados de anfitrião ou de serviço.

Há também dogtag-ipa-ca-renew-agent e dogtag-ipa-ca-renew-agent-reuse que renovam os certificados do subsistema CA.

Nota

Execute estes testes em todos os servidores principais da IdM ao tentar verificar a existência de problemas.

70.2. Triagem de certificados utilizando a ferramenta Healthcheck

Esta seção descreve um teste manual autônomo de um exame de saúde de certificado de Gerenciamento de Identidade (IdM) usando a ferramenta Healthcheck.

A ferramenta Healthcheck inclui muitos testes, portanto, é possível encurtar os resultados:

  • excluindo todos os testes bem-sucedidos --failures-only
  • incluindo apenas testes de certificado --source=ipahealthcheck.ipa.certs

Pré-requisitos

  • Os testes de saúde devem ser realizados como usuário root.

Procedimento

  • Para executar o Healthcheck com avisos, erros e questões críticas em relação aos certificados, entre:

    # ipa-healthcheck --source=ipahealthcheck.ipa.certs -- somente faltas

O teste bem-sucedido exibe parênteses vazios:

[]

O teste fracassado mostra a seguinte saída:

{
  "source": "ipahealthcheck.ipa.certs",
  "check": "IPACertfileExpirationCheck",
  "result": "ERROR",
  "kw": {
    "key": 1234,
    "dbdir": "/path/to/nssdb",
    "error": [error],
    "msg": "Unable to open NSS database '/path/to/nssdb': [error]"
  }
}

Este teste IPACertfileExpirationCheck falhou ao abrir o banco de dados do NSS.

Recursos adicionais

  • Para rever referências detalhadas, digite man ipa-healthcheck na linha de comando.

Capítulo 71. Verificação de certificados de sistema usando o IdM Healthcheck

Esta seção descreve uma ferramenta de Healthcheck em Gerenciamento de Identidade (IdM) para identificar problemas com certificados de sistema.

Para detalhes, veja Healthcheck em IdM.

Pré-requisitos

  • A ferramenta Healthcheck está disponível apenas no RHEL 8.1 ou mais recente.

71.1. Certificados de sistema Testes de Healthcheck

A ferramenta Healthcheck inclui vários testes para verificação de certificados de sistema (DogTag).

Para ver todos os testes, execute o ipa-healthcheck com a opção --list-sources:

# ipa-healthcheck --list-sources

Você pode encontrar todos os testes sob a fonte ipahealthcheck.dogtag.ca:

DogtagCertsConfigCheck

Este teste compara os certificados CA (Autoridade Certificadora) em seu banco de dados NSS com os mesmos valores armazenados em CS.cfg. Se eles não corresponderem, a CA não inicia.

Especificamente, ele verifica:

  • auditSigningCert cert-pki-ca contra ca.audit_signing.cert
  • ocspSigningCert cert-pki-ca contra ca.ocsp_signing.cert
  • caSigningCert cert-pki-ca contra ca.signing.cert
  • subsystemCert cert-pki-ca contra ca.subsystem.cert
  • Server-Cert cert-pki-ca contra ca.sslserver.cert

Se a Key Recovery Authority (KRA) estiver instalada:

  • transportCert cert-pki-kra contra ca.connector.KRA.transportCert
DogtagCertsConnectivityCheck

Este teste verifica a conectividade. Este teste é equivalente ao comando ipa cert-show 1 que verifica:

  • A configuração de proxy PKI no Apache
  • IdM sendo capaz de encontrar uma CA
  • O certificado de cliente agente RA
  • Correção das respostas do CA aos pedidos

Observe que o teste verifica um certificado com a série nº 1 porque você quer verificar se um cert-show pode ser executado e obter de volta um resultado esperado da CA (o certificado ou um não encontrado).

Nota

Execute estes testes em todos os servidores principais da IdM ao tentar encontrar um problema.

71.2. Certificados de sistema de triagem usando o Healthcheck

Esta seção descreve um teste manual independente de certificados de Gerenciamento de Identidade (IdM) usando a ferramenta Healthcheck.

Como a ferramenta Healthcheck inclui muitos testes, você pode limitar os resultados incluindo apenas os testes DogTag --source=ipahealthcheck.dogtag.ca

Procedimento

  • Para executar o Healthcheck restrito aos certificados DogTag, entre:

    # ipa-healthcheck --source=ipahealthcheck.dogtag.ca

Um exemplo de um teste bem sucedido:

{
  "source: ipahealthcheck.dogtag.ca",
  "check: DogtagCertsConfigCheck",
  "result: SUCCESS",
  "uuid: 9b366200-9ec8-4bd9-bb5e-9a280c803a9c",
  "when: 20191008135826Z",
  "duration: 0.252280",
  "kw:" {
    "key": "Server-Cert cert-pki-ca",
    "configfile":  "/var/lib/pki/pki-tomcat/conf/ca/CS.cfg"
    }
}

Um exemplo de um teste fracassado:

{
  "source: ipahealthcheck.dogtag.ca",
  "check: DogtagCertsConfigCheck",
  "result: CRITICAL",
  "uuid: 59d66200-1447-4b3b-be01-89810c803a98",
  "when: 20191008135912Z",
  "duration: 0.002022",
  "kw:" {
    "exception": "NSDB /etc/pki/pki-tomcat/alias not initialized",
    }
}

Recursos adicionais

  • Para rever referências detalhadas, digite man ipa-healthcheck na linha de comando.

Capítulo 72. Verificação do espaço em disco usando o IdM Healthcheck

Esta seção descreve como monitorar o espaço livre em disco do servidor de Gerenciamento de Identidade usando a ferramenta Healthcheck.

Para detalhes, veja Healthcheck em IdM.

Pré-requisitos

  • A ferramenta Healthcheck está disponível apenas no RHEL 8.1 e mais recente.

72.1. Teste de saúde do espaço em disco

A ferramenta Healthcheck inclui um teste para verificar o espaço disponível em disco. O espaço livre insuficiente em disco pode causar problemas com:

  • Logging
  • Execução
  • Cópias de segurança

O teste verifica os seguintes caminhos:

Tabela 72.1. Trilhas testadas

Caminhos verificados pelo testeMínimo espaço em disco em MB

/var/lib/dirsrv/

1024

/var/lib/ipa/backup/

512

/var/log/

1024

var/log/audit/

512

/var/tmp/

512

/tmp/

512

Para listar todos os testes, execute o ipa-healthcheck com a opção --list-sources:

# ipa-healthcheck --list-sources

O teste de verificação do espaço do sistema de arquivos é colocado sob a fonte ipahealthcheck.system.filesystemspace:

FileSystemSpaceCheck

Este teste verifica o espaço disponível em disco das seguintes maneiras:

  • O mínimo necessário de bytes brutos livres.
  • O espaço mínimo livre em disco percentage - the é codificado em código duro de 20%.

72.2. Triagem do espaço em disco utilizando a ferramenta Healthcheck

Esta seção descreve um teste manual autônomo do espaço em disco disponível em um servidor de Gerenciamento de Identidade (IdM) usando a ferramenta Healthcheck.

Uma vez que o Healthcheck inclui muitos testes, você pode reduzir os resultados por:

  • excluindo todos os testes bem-sucedidos --failures-only
  • incluindo apenas testes de verificação de espaço --source=ipahealthcheck.system.filesystemspace

Procedimento

  • Para executar o Healthcheck com avisos, erros e questões críticas em relação ao espaço disponível em disco, entre:

    # ipa-healthcheck --source=ipahealthcheck.system.filesystemspace -- somente falhas

Um teste bem sucedido exibe parênteses vazios:

[]

Como exemplo, um teste fracassado pode ser exibido:

{
  "source": "ipahealthcheck.system.filesystemspace",
  "check": "FileSystemSpaceCheck",
  "result": "ERROR",
  "kw": {
    "msg": "/var/lib/dirsrv: free space under threshold: 0 MiB < 1024 MiB",
    "store": "/var/lib/dirsrv",
    "free_space": 0,
    "threshold": 1024
  }
}

O teste fracassado informa que o diretório /var/lib/dirsrv ficou sem espaço.

Recursos adicionais

  • Para rever referências detalhadas, digite man ipa-healthcheck na linha de comando.

Capítulo 73. Verificação das permissões dos arquivos de configuração do IdM usando o Healthcheck

Esta seção descreve como testar arquivos de configuração de Gerenciamento de Identidade (IdM) usando a ferramenta Healthcheck.

Para detalhes, veja Healthcheck em IdM.

Pré-requisitos

  • A ferramenta Healthcheck só está disponível no RHEL 8.1 ou em sistemas mais novos.

73.1. Autorizações de arquivos Testes de saúde

A ferramenta Healthcheck testa a propriedade e as permissões de alguns arquivos importantes instalados ou configurados pela Gerência de Identidade (IdM).

Se você alterar a propriedade ou permissões de qualquer arquivo testado, o teste retorna um aviso na seção result. Embora isso não signifique necessariamente que a configuração não funcionará, significa que o arquivo difere da configuração padrão.

Para ver todos os testes, execute o ipa-healthcheck com a opção --list-sources:

# ipa-healthcheck --list-sources

O teste de permissões de arquivo é colocado sob a fonte ipahealthcheck.ipa.files:

IPAFileNSSDBCheck
Este teste verifica o banco de dados NSS 389-ds e o banco de dados da Autoridade Certificadora (CA). O banco de dados do 389-ds está localizado em /etc/dirsrv/slapd-<dashed-REALM> e o banco de dados da CA está localizado em /etc/pki/pki-tomcat/alias/.
IPAFileCheck

Este teste verifica os seguintes arquivos:

  • /var/lib/ipa/ra-agent.{key|pem}
  • /var/lib/ipa/certs/httpd.pem
  • /var/lib/ipa/private/httpd.key
  • /etc/httpd/alias/ipasession.key
  • /etc/dirsrv/ds.keytab
  • /etc/ipa/ca.crt
  • /etc/ipa/custodia/server.keys

    Se o PKINIT estiver habilitado:

  • /var/lib/ipa/certs/kdc.pem
  • /var/lib/ipa/private/kdc.key

    Se o DNS estiver configurado:

  • /etc/named.keytab
  • /etc/ipa/dnssec/ipa-dnskeysyncd.keytab
TomcatFileCheck

Este teste verifica alguns arquivos específicos de tomcat se uma CA está configurada:

  • /etc/pki/pki-tomcat/password.conf
  • /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
  • /etc/pki/pki-tomcat/server.xml
Nota

Execute estes testes em todos os servidores principais da IdM ao tentar encontrar problemas.

73.2. Triagem de arquivos de configuração usando o Healthcheck

Esta seção descreve um teste manual autônomo dos arquivos de configuração de um servidor de Gerenciamento de Identidade (IdM) usando a ferramenta Healthcheck.

A ferramenta Healthcheck inclui muitos testes. Os resultados podem ser reduzidos por:

  • excluindo todos os testes bem-sucedidos --failures-only
  • incluindo apenas testes de propriedade e permissões --source=ipahealthcheck.ipa.files

Procedimento

  1. Para executar testes de Healthcheck sobre propriedade e permissões do arquivo de configuração IdM, enquanto exibe apenas avisos, erros e questões críticas, entre:

    # ipa-healthcheck --source=ipahealthcheck.ipa.files -- somente faltas

Um teste bem sucedido exibe parênteses vazios:

# ipa-healthcheck --source=ipahealthcheck.ipa.files --failures-only
[]

Os resultados dos testes fracassados são semelhantes aos seguintes WARNING:

{
  "source": "ipahealthcheck.ipa.files",
  "check": "IPAFileNSSDBCheck",
  "result": "WARNING",
  "kw": {
    "key": "_etc_dirsrv_slapd-EXAMPLE-TEST_pkcs11.txt_mode",
    "path": "/etc/dirsrv/slapd-EXAMPLE-TEST/pkcs11.txt",
    "type": "mode",
    "expected": "0640",
    "got": "0666",
    "msg": "Permissions of /etc/dirsrv/slapd-EXAMPLE-TEST/pkcs11.txt are 0666 and should be 0640"
  }
}

Recursos adicionais

  • Para rever o material de referência detalhado, abra man ipa-healthcheck na linha de comando.

Capítulo 74. Verificação da replicação de IdM usando o Healthcheck

Esta seção descreve como testar a replicação do Gerenciamento de Identidade (IdM) usando a ferramenta Healthcheck.

Para detalhes, veja Healthcheck em IdM.

Pré-requisitos

  • A ferramenta Healthcheck está disponível apenas no RHEL 8.1 ou mais recente.

74.1. Testes de saúde de réplica

A ferramenta Healthcheck testa a configuração da topologia de Gerenciamento de Identidade (IdM) e procura por questões de conflito de replicação.

Para listar todos os testes, execute o ipa-healthcheck com a opção --list-sources:

# ipa-healthcheck --list-sources

Os testes de topologia são colocados sob as fontes ipahealthcheck.ipa.topology e ipahealthcheck.ds.replication:

IPATopologyDomainCheck

Este teste verifica:

  • se a topologia não está desconectada e se existem caminhos de replicação entre todos os servidores.
  • se os servidores não tiverem mais do que o número recomendado de acordos de replicação.

    Se o teste falhar, o teste retorna erros, tais como erros de conexão ou acordos de replicação em demasia.

    Se o teste for bem sucedido, o teste retorna os domínios configurados.

    Nota

    O teste executa o comando ipa topologysuffix-verify tanto para o domínio quanto para os sufixos ca (assumindo que a Autoridade Certificadora esteja configurada neste mestre).

ReplicaçãoConflitoCheque
O teste procura por entradas no LDAP correspondentes (&(!(objectclass=nstombstone))(nsds5ReplConflict=*)).
Nota

Execute estes testes em todos os servidores principais da IdM ao tentar verificar a existência de problemas.

74.2. Replicação de triagem usando o Healthcheck

Esta seção descreve um teste manual independente de uma topologia e configuração de replicação de Gerenciamento de Identidade (IdM) usando a ferramenta Healthcheck.

A ferramenta Healthcheck inclui muitos testes, portanto, é possível encurtar os resultados:

  • Teste de conflito de réplicas --source=ipahealthcheck.ds.replication
  • Teste de topologia correta --source=ipahealthcheck.ipa.topology

Pré-requisitos

  • Os testes de saúde devem ser realizados como usuário root.

Procedimento

  • Para executar o Healthcheck de replicação de conflitos e verificações de topologia, entre:

    # ipa-healthcheck --source=ipahealthcheck.ds.replication --source=ipahealthcheck.ipa.topology

Quatro resultados diferentes são possíveis:

  • SUCCESS - the teste aprovado com sucesso.

    {
      "source": "ipahealthcheck.ipa.topology",
      "check": "IPATopologyDomainCheck",
      "result": "SUCCESS",
      "kw": {
        "suffix": "domain"
      }
    }
  • WARNING - the teste aprovado, mas pode haver um problema.
  • ERROR - the test failed.

    {
      "source": "ipahealthcheck.ipa.topology",
      "check": "IPATopologyDomainCheck",
      "result": "ERROR",
      "uuid": d6ce3332-92da-423d-9818-e79f49ed321f
      "when": 20191007115449Z
      "duration": 0.005943
      "kw": {
        "msg": "topologysuffix-verify domain failed, server2 is not connected (server2_139664377356472 in MainThread)"
      }
    }
  • O teste  the- the falhou e afeta a funcionalidade do servidor IdM.

Recursos adicionais

  • Para rever referências detalhadas, abra man ipa-healthcheck na linha de comando.

Capítulo 75. Verificação dos registros DNS usando o IdM Healthcheck

Esta seção descreve uma ferramenta de Healthcheck em Gerenciamento de Identidade (IdM) para identificar problemas com os registros DNS.

Para detalhes, veja Healthcheck em IdM.

Pré-requisitos

  • A ferramenta Healthcheck dos registros DNS só está disponível no RHEL 8.2 ou mais recente.

75.1. Teste de saúde dos registros DNS

A ferramenta Healthcheck inclui um teste para verificar se os registros DNS esperados necessários para a auto-descoberta são resolúveis.

Para listar todos os testes, execute o ipa-healthcheck com a opção --list-sources:

# ipa-healthcheck --list-sources

O teste de verificação dos registros DNS é colocado sob a fonte ipahealthcheck.ipa.idns.

IPADNSSystemRecordsCheck
Este teste verifica os registros DNS do comando ipa dns-update-system-records --dry-run usando o primeiro resolvedor especificado no arquivo /etc/resolv.conf. Os registros são testados no mestre IPA.

75.2. Triagem de registros DNS usando a ferramenta Healthcheck

Esta seção descreve um teste manual autônomo dos registros DNS em um servidor de Gerenciamento de Identidade (IdM) usando a ferramenta Healthcheck.

A ferramenta Healthcheck inclui muitos testes. Os resultados podem ser reduzidos pela inclusão apenas dos testes dos registros DNS, adicionando a opção --source ipahealthcheck.ipa.idns.

Pré-requisitos

  • Os testes de saúde devem ser realizados como usuário root.

Procedimento

  • Para executar a verificação dos registros DNS, entre:

    # ipa-healthcheck --source ipahealthcheck.ipa.idns

    Se o registro for resolúvel, o teste retorna SUCCESS como resultado:

    {
        "source": "ipahealthcheck.ipa.idns",
        "check": "IPADNSSystemRecordsCheck",
        "result": "SUCCESS",
        "uuid": "eb7a3b68-f6b2-4631-af01-798cac0eb018",
        "when": "20200415143339Z",
        "duration": "0.210471",
        "kw": {
          "key": "_ldap._tcp.idm.example.com.:server1.idm.example.com."
        }
    }

    O teste retorna um WARNING quando, por exemplo, o número de registros não corresponde ao número esperado:

    {
        "source": "ipahealthcheck.ipa.idns",
        "check": "IPADNSSystemRecordsCheck",
        "result": "WARNING",
        "uuid": "972b7782-1616-48e0-bd5c-49a80c257895",
        "when": "20200409100614Z",
        "duration": "0.203049",
        "kw": {
          "msg": "Got {count} ipa-ca A records, expected {expected}",
          "count": 2,
          "expected": 1
        }
    }

Recursos adicionais

  • Para rever referências detalhadas, digite man ipa-healthcheck na linha de comando.

Capítulo 76. Demotar ou promover réplicas ocultas

Após a instalação de uma réplica, você pode mudar se a réplica está oculta ou visível.

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

Se a réplica for um mestre de renovação do CA, mude o serviço para outra réplica. Para detalhes, veja Mudança e reinicialização do mestre de renovação do IdM CA.

Nota

O recurso de réplica oculta está disponível no Red Hat Enterprise Linux 8.1 e, mais tarde, como uma Pré-visualização Tecnológica e, portanto, não é suportado.

Procedimento

  • Para esconder a réplica, entre:

    # ipa server-state replica.idm.example.com --state=hidden

    Alternativamente, você pode tornar a réplica visível com o seguinte comando

    # ipa server-state replica.idm.example.com --state=enabled

Capítulo 77. Configurações de segurança da Gestão de Identidade

Esta seção descreve as características de segurança relacionadas à Gestão da Identidade.

77.1. Como a Gestão de Identidade aplica as configurações de segurança padrão

Por padrão, o Gerenciamento de Identidade (IdM) no RHEL 8 utiliza a política de criptografia de todo o sistema. O benefício desta política é que você não precisa endurecer os componentes individuais da IdM manualmente.

Importante

A Red Hat recomenda que você utilize a política de criptografia de todo o sistema. A alteração das configurações individuais de segurança pode quebrar componentes do IdM. Por exemplo, o Java no RHEL 8 não suporta totalmente o protocolo TLS 1.3. Portanto, o uso deste protocolo pode causar falhas no IdM.

Recursos adicionais

  • Para mais detalhes sobre as políticas de criptografia de todo o sistema, consulte a página de manual crypto-policies(7).

77.2. O LDAP anônimo se vincula na Gestão da Identidade

Por padrão, os vínculos anônimos com o servidor LDAP de Gerenciamento de Identidade (IdM) são ativados. Os binds anônimos podem expor certas configurações ou valores de diretório. Entretanto, alguns utilitários, tais como realmd, ou clientes mais antigos da RHEL requerem binds anônimos habilitados para descobrir configurações de domínio ao registrar um cliente.

Recursos adicionais

  • Para obter detalhes sobre como desativar binds anônimas no servidor LDAP da IdM, consulte o Disabling Anonymous Binds na seção Red Hat Directory Server 11 Administration Guide.

Capítulo 78. Estabelecimento do Samba em um membro do domínio IdM

Esta seção descreve como configurar o Samba em um host que é unido a um domínio da Red Hat Identity Management (IdM). Os usuários do IdM e também, se disponíveis, dos domínios confiáveis do Active Directory (AD), podem acessar ações e serviços de impressão fornecidos pelo Samba.

Importante

O uso do Samba em um membro do domínio IdM é um recurso de Pré-visualização Tecnológica não suportado e contém certas limitações. Por exemplo, devido aos controladores de confiança IdM que não suportam o serviço de Catálogo Global, os hosts do Windows registrados no AD não conseguem encontrar usuários e grupos IdM no Windows. Além disso, os controladores de confiança IdM não suportam a resolução de grupos IdM usando os protocolos Ambiente de Computação Distribuída / Chamadas de Procedimento Remoto (DCE/RPC). Como conseqüência, os usuários AD só podem acessar os compartilhamentos e impressoras Samba dos clientes IdM.

Os clientes que implantam Samba nos membros do domínio IdM são encorajados a fornecer feedback à Red Hat.

Pré-requisitos

  • O host é unido como um cliente ao domínio IdM.
  • Tanto os servidores da IdM quanto o cliente devem rodar no RHEL 8.1 ou posterior.

78.1. Preparando o domínio IdM para instalar o Samba nos membros do domínio

Antes de estabelecer uma confiança com AD e se você quiser configurar o Samba em um cliente IdM, você deve preparar o domínio IdM usando o utilitário ipa-adtrust-install em um servidor IdM. Entretanto, mesmo que ambas as situações se apliquem, você deve rodar ipa-adtrust-install apenas uma vez em um master IdM.

Pré-requisitos

  • O IdM está instalado.

Procedimento

  1. Instalar os pacotes necessários:

    [root@ipaserver ~]# yum install ipa-server ipa-server-trust-ad samba-client
  2. Autenticar como usuário administrativo da IdM:

    [root@ipaserver ~]# kinit admin
  3. Execute o utilitário ipa-adtrust-install:

    [root@ipaserver ~]# ipa-adtrust-install

    Os registros do serviço DNS são criados automaticamente se a IdM foi instalada com um servidor DNS integrado.

    Se o IdM foi instalado sem um servidor DNS integrado, ipa-adtrust-install imprime uma lista de registros de serviços que devem ser adicionados manualmente ao DNS antes que você possa continuar.

  4. O roteiro lhe pede que o /etc/samba/smb.conf já existe e será reescrito:

    WARNING: The smb.conf already exists. Running ipa-adtrust-install will break your existing Samba configuration.
    
    Do you wish to continue? [no]: yes
  5. O script solicita que você configure o plug-in slapi-nis, um plug-in de compatibilidade que permite que clientes Linux mais antigos trabalhem com usuários confiáveis:

    Do you want to enable support for trusted domains in Schema Compatibility plugin?
    This will allow clients older than SSSD 1.9 and non-Linux clients to work with trusted users.
    
    Enable trusted domains support in slapi-nis? [no]: yes
  6. Quando solicitado, digite o nome NetBIOS para o domínio IdM ou pressione Enter para aceitar o nome sugerido:

    Trust is configured but no NetBIOS domain name found, setting it now.
    Enter the NetBIOS name for the IPA domain.
    Only up to 15 uppercase ASCII letters, digits and dashes are allowed.
    Example: EXAMPLE.
    
    NetBIOS domain name [IDM]:
  7. Você é solicitado a executar a tarefa da geração SID para criar um SID para qualquer usuário existente:

    Você quer executar a tarefa ipa-sidgen? [não] yes

    Quando o diretório é instalado pela primeira vez, pelo menos um usuário (o administrador do IdM) existe e como esta é uma tarefa de recursos intensivos, se você tiver um alto número de usuários, você pode executá-la em outro momento.

  8. (Optional) Por padrão, a faixa de portas Dynamic RPC é definida como 49152-65535 para Windows Server 2008 e posteriores. Se você precisar definir uma faixa de portas Dynamic RPC diferente para seu ambiente, configure o Samba para usar diferentes portas e abra essas portas em suas configurações de firewall. O exemplo a seguir define o intervalo de portas para 55000-65000.

    [root@ipaserver ~]# net conf setparm global 'rpc server dynamic port range' 55000-65000
    [root@ipaserver ~]# firewall-cmd --add-port=55000-65000/tcp
    [root@ipaserver ~]# firewall-cmd --runtime-to-permanent
  9. Reinicie o serviço ipa:

    [root@ipaserver ~]# ipactl restart
  10. 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)
    ...

78.2. Habilitando o tipo de criptografia AES no Active Directory usando um GPO

Esta seção descreve como ativar o tipo de criptografia AES no Active Directory (AD) usando um objeto de política de grupo (GPO). Certas características no RHEL 8, como a execução de um servidor Samba em um cliente IdM, exigem este tipo de criptografia.

Observe que a RHEL 8 não suporta os tipos fracos de criptografia DES e RC4.

Pré-requisitos

  • Você está logado no AD como um usuário que pode editar políticas de grupo.
  • O Group Policy Management Console está instalado no computador.

Procedimento

  1. Abra o Group Policy Management Console.
  2. Clique com o botão direito do mouse Default Domain Policy, e selecione Edit. O Group Policy Management Editor abre.
  3. Navegue para Computer Configuration Security Options PoliciesWindows SettingsSecurity Settings Local Policies → → → .
  4. Clique duas vezes na política Network security: Configure encryption types allowed for Kerberos.
  5. Selecione AES256_HMAC_SHA1 e, opcionalmente, Future encryption types.
  6. Clique OK.
  7. Feche o Group Policy Management Editor.
  8. Repita os passos para o Default Domain Controller Policy.
  9. Esperar até que os controladores de domínio Windows (DC) aplicassem automaticamente a política de grupo. Alternativamente, para aplicar o GPO manualmente em um CD, digite o seguinte comando usando uma conta que tenha permissões de administrador:

    C:|> gpupdate /force /target:computer

78.3. Instalação e configuração de um servidor Samba em um cliente IdM

Esta seção descreve como instalar e configurar o Samba em um cliente registrado em um domínio IdM.

Pré-requisitos

Procedimento

  1. Instale o pacote ipa-client-samba:

    [root@idm_client]# yum install ipa-client-samba
  2. Use o utilitário ipa-client-samba para preparar o cliente e criar uma configuração inicial do Samba:

    [root@idm_client]# ipa-client-samba
    Searching for IPA server...
    IPA server: DNS discovery
    Chosen IPA master: idm_server.idm.example.com
    SMB principal to be created: cifs/idm_client.idm.example.com@IDM.EXAMPLE.COM
    NetBIOS name to be used: IDM_CLIENT
    Discovered domains to use:
    
     Domain name: idm.example.com
    NetBIOS name: IDM
             SID: S-1-5-21-525930803-952335037-206501584
        ID range: 212000000 - 212199999
    
     Domain name: ad.example.com
    NetBIOS name: AD
             SID: None
        ID range: 1918400000 - 1918599999
    
    Continue to configure the system with these values? [no]: yes
    Samba domain member is configured. Please check configuration at /etc/samba/smb.conf and start smb and winbind services
  3. Por padrão, ipa-client-samba adiciona automaticamente a seção [homes] ao arquivo /etc/samba/smb.conf que compartilha dinamicamente o diretório home de um usuário quando este se conecta. Se os usuários não tiverem diretórios home neste servidor, ou se não quiserem compartilhá-los, remova as seguintes linhas do /etc/samba/smb.conf:

    [homes]
        read only = no
  4. Compartilhar diretórios e impressoras. Para detalhes, veja as seguintes seções na documentação Deploying different types of servers para RHEL 8:

  5. Abra as portas necessárias para um cliente Samba no firewall local:

    [root@idm_client]# firewall-cmd --permanent --add-service=samba-client
    [root@idm_client]# firewall-cmd --reload
  6. Habilitar e iniciar os serviços smb e winbind:

    [root@idm_client]# systemctl enable --now smb winbind

Etapas de verificação

Execute os seguintes passos de verificação em um membro diferente do domínio IdM que tenha o pacote samba-client instalado:

  1. Autenticar e obter um ingresso Kerberos para a concessão de bilhetes:

    $ kinit example_user
  2. Liste as ações no servidor Samba usando autenticação Kerberos:

    $ smbclient -L idm_client.idm.example.com -k
    lp_load_ex: changing to config backend registry
    
        Sharename       Type      Comment
        ---------       ----      -------
        example         Disk
        IPC$            IPC       IPC Service (Samba 4.12.3)
    ...

Recursos adicionais

  • Para detalhes sobre quais passos ipa-client-samba executa durante a configuração, consulte a página de manual ipa-client-samba(1).

78.4. Adicionar manualmente uma configuração de mapeamento de ID se a IdM confia em um novo domínio

O Samba requer uma configuração de mapeamento de identificação para cada domínio a partir do qual os usuários acessam recursos. Em um servidor Samba existente rodando em um cliente IdM, você deve adicionar manualmente uma configuração de mapeamento de ID após o administrador ter adicionado uma nova confiança a um domínio Active Directory (AD).

Pré-requisitos

  • Você configurou o Samba em um cliente da IdM. Posteriormente, uma nova confiança foi adicionada à IdM.
  • Os tipos de criptografia DES e RC4 para Kerberos devem ser desativados no domínio AD confiável. Por razões de segurança, a RHEL 8 não suporta esses tipos fracos de criptografia.

Procedimento

  1. Autenticar usando o keytab do host:

    [root@idm_client]# kinit -k
  2. Use o comando ipa idrange-find para exibir tanto o ID base quanto o tamanho da faixa de ID do novo domínio. Por exemplo, o comando a seguir exibe os valores para o domínio ad.example.com:

    [root@idm_client]# ipa idrange-find --name="AD.EXAMPLE.COM_id_range" --raw
    ---------------
    1 range matched
    ---------------
      cn: AD.EXAMPLE.COM_id_range
      ipabaseid: 1918400000
      ipaidrangesize: 200000
      ipabaserid: 0
      ipanttrusteddomainsid: S-1-5-21-968346183-862388825-1738313271
      iparangetype: ipa-ad-trust
    ----------------------------
    Number of entries returned 1
    ----------------------------

    Você precisa dos valores dos atributos ipabaseid e ipaidrangesize nos próximos passos.

  3. Para calcular a maior identificação utilizável, use a seguinte fórmula:

    alcance_máximo = ipabaseid ipaidrangesize - 1

    Com os valores da etapa anterior, o ID mais alto utilizável para o domínio ad.example.com é 1918599999 (1918400000 200000 - 1).

  4. Edite o arquivo /etc/samba/smb.conf, e adicione a configuração do mapeamento de identificação do domínio à seção [global]:

    idmap config AD : range = 1918400000 - 1918599999
    idmap config AD : backend = sss

    Especificar o valor do atributo ipabaseid como o valor mais baixo e o valor computado da etapa anterior como o valor mais alto do intervalo.

  5. Reinicie os serviços smb e winbind:

    [root@idm_client]# systemctl restart smb winbind

Etapas de verificação

  1. Autenticar como usuário do novo domínio e obter um ticket de concessão de Kerberos:

    $ kinit example_user
  2. Liste as ações no servidor Samba usando autenticação Kerberos:

    $ smbclient -L idm_client.idm.example.com -k
    lp_load_ex: changing to config backend registry
    
        Sharename       Type      Comment
        ---------       ----      -------
        example         Disk
        IPC$            IPC       IPC Service (Samba 4.12.3)
    ...

78.5. Recursos adicionais

Capítulo 79. Usando montagem automática na IdM

Automount é uma forma de gerenciar, organizar e acessar diretórios através de múltiplos sistemas. O programa Automount monta automaticamente um diretório sempre que o acesso a ele é solicitado. Isto funciona bem dentro de um domínio IdM, pois permite que diretórios sobre clientes dentro do domínio sejam compartilhados facilmente. Isto é especialmente importante com os diretórios residenciais dos usuários.

Na IdM, a montagem automática funciona com o diretório interno LDAP e também com os serviços DNS, se configurados.

79.1. Configuração de um servidor NFS Kerberos-aware

Este procedimento descreve como configurar um servidor NFS Kerberos sensível à Kerberos.

Pré-requisitos

Procedimento

  1. Se algum de seus clientes NFS suportar apenas criptografia fraca, como os clientes do Red Hat Enterprise Linux 5:

    1. Atualizar a configuração do servidor IdM Kerberos para permitir o fraco tipo de criptografia des-cbc-crc:

      $ ldapmodify -x -D "cn=directory manager" -w password -h ipaserver.example.com -p 389
      
      dn: cn=REALM_NAME,cn=kerberos,dc=example,dc=com
      changetype: modify
      add: krbSupportedEncSaltTypes
      krbSupportedEncSaltTypes: des-cbc-crc:normal
      -
      add: krbSupportedEncSaltTypes
      krbSupportedEncSaltTypes: des-cbc-crc:special
      -
      add: krbDefaultEncSaltTypes
      krbDefaultEncSaltTypes: des-cbc-crc:special
    2. No servidor NFS, adicione a seguinte entrada ao arquivo /etc/krb5.conf do servidor NFS permitir um fraco suporte a criptografia:

      allow_weak_crypto = verdadeiro
  2. Obter um bilhete Kerberos:

    [root@nfs-server ~]# kinit admin
  3. Se a máquina host NFS não tiver sido adicionada como cliente ao domínio IdM, crie a entrada host. Veja Adicionando entradas de host IdM da IdM CLI.
  4. Criar a entrada de serviço NFS:

    [root@nfs-server ~]# ipa service-add nfs/nfs-server.example.com
  5. Recupere uma tabela de chaves de serviço NFS para o servidor NFS usando o seguinte comando ipa-getkeytab que salva as chaves no arquivo /etc/krb5.keytab:

    [root@nfs-server ~]# ipa-getkeytab -s ipaserver.example.com -p nfs/nfs-server.example.com -k /etc/krb5.keytab

    Se algum de seus clientes NFS suportar apenas criptografia fraca, além disso, passe a opção -e des-cbc-crc para o comando para solicitar uma tabela de chaves criptografadas por DES.

  6. Verificar se o serviço NFS foi configurado corretamente na IdM, com sua tabela de chaves, verificando a entrada do serviço:

    [root@nfs-server ~]# ipa service-show nfs/nfs-server.example.com
      Principal name: nfs/nfs-server.example.com@IDM.EXAMPLE.COM
      Principal alias: nfs/nfs-server.example.com@IDM.EXAMPLE.COM
      Keytab: True
      Managed by: nfs-server.example.com
  7. Instale o nfs-utils pacote:

    [root@nfs-server ~]# yum instalar nfs-utils
  8. Execute o utilitário ipa-client-automount para configurar as configurações do NFS:

    [root@nfs-server ~] ipa-client-automount
    Searching for IPA server...
    IPA server: DNS discovery
    Location: default
    Continue to configure the system with these values? [no]: yes
    Configured /etc/idmapd.conf
    Restarting sssd, waiting for it to become available.
    Started autofs

    Por padrão, este comando permite o NFS seguro e define o parâmetro Domain no arquivo /etc/idmapd.conf para o domínio DNS do IdM. Se você usar um domínio diferente, especifique-o usando o --idmap-domain domain_name parâmetro.

  9. Edite o arquivo /etc/exports e adicione ações com a configuração de segurança krb5p Kerberos:

    /export  *(rw,sec=krb5:krb5i:krb5p)
    /home  *(rw,sec=krb5:krb5i:krb5p)

    Este exemplo compartilha os diretórios /export e /home em modo de leitura-escrita com a autenticação Kerberos habilitada.

  10. Reinicie e ative o nfs-server:

    [root@nfs-server ~]# systemctl restart nfs-server
    [root@nfs-server ~]# systemctl enable nfs-server
  11. Reexportar os diretórios compartilhados:

    [root@nfs-server ~]# exporttfs -rav
  12. Opcionalmente, configure o servidor NFS como um cliente NFS. Ver Seção 79.2, “Estabelecimento de um cliente NFS Kerberos”.

79.2. Estabelecimento de um cliente NFS Kerberos

Este procedimento descreve como criar um cliente NFS com consciência de kerberos.

Pré-requisitos

Procedimento

  1. Se os clientes NFS suportam apenas criptografia fraca, como um cliente Red Hat Enterprise Linux 5, defina a seguinte entrada no arquivo /etc/krb5.conf do servidor para permitir uma criptografia fraca:

    allow_weak_crypto = verdadeiro
  2. Se o cliente NFS não estiver registrado como cliente no domínio IdM, configure as entradas de host necessárias, conforme descrito em Adicionar entradas de host IdM da IdM CLI.
  3. Instale o nfs-utils pacote:

    [root@nfs-client ~]# yum instalar nfs-utils
  4. Obter um bilhete Kerberos antes de executar as ferramentas IdM.

    [root@nfs-client ~]# kinit admin
  5. Execute o utilitário ipa-client-automount para configurar as configurações do NFS:

    [root@nfs-client ~] ipa-client-automount
    Searching for IPA server...
    IPA server: DNS discovery
    Location: default
    Continue to configure the system with these values? [no]: yes
    Configured /etc/idmapd.conf
    Restarting sssd, waiting for it to become available.
    Started autofs

    Por padrão, isto permite o NFS seguro no arquivo /etc/sysconfig/nfs e define o domínio DNS IdM no parâmetro Domain no arquivo /etc/idmapd.conf.

  6. Adicione as seguintes entradas ao arquivo /etc/fstab para montar as ações do NFS do host nfs-server.example.com quando o sistema iniciar:

    nfs-server.example.com:/export  /mnt   nfs4  sec=krb5p,rw
    nfs-server.example.com:/home    /home  nfs4  sec=krb5p,rw

    Estas configurações configuram o Red Hat Enterprise Linux para montar o compartilhamento /export no diretório /mnt e o compartilhamento /home no diretório /home.

  7. Criar os pontos de montagem, se eles não existirem. Em nosso caso, ambos deveriam existir.
  8. Montar as ações da NFS:

    [root@nfs-client ~]# mount /mnt/
    [root@nfs-client ~]# mount /home

    O comando utiliza as informações da entrada /etc/fstab.

  9. Configurar o SSSD para renovar os bilhetes da Kerberos:

    1. Defina os seguintes parâmetros na seção de domínio IdM do arquivo /etc/sssd/sssd.conf para configurar o SSSD para renovar automaticamente os bilhetes:

      [domain/EXAMPLE.COM]
      ...
      krb5_renewable_lifetime = 50d
      krb5_renew_interval = 3600
    2. Reinicie o SSSD:

      [root@nfs-client ~]# systemctl restart sssd
Importante

O módulo pam_oddjob_mkhomedir não suporta a criação automática de diretórios domésticos sobre uma ação da NFS. Portanto, você deve criar manualmente os diretórios home no servidor na raiz do compartilhamento que contém os diretórios home.